designing systems that don't suck - amazon s3 · pdf file • devops should never be an...
Post on 17-Oct-2020
Embed Size (px)
Designing and Building Systems that Don’t Suck
Homeland of Linux Edition
Who is Matt Lancaster and why is he talking to
Begin with Goals
• Understand the business goals of what you’re designing • Understand how these relate to technical goals • Quantify success, and ensure that the metric is well understood
• Define a Minimum Viable Product (MVP) that aligns with business goals • As Technology Architects, you must be involved in design-time activities • Neither creative nor technology are special, both are needed
USE GOALS AS CONSTRAINTS & EARLY DAYS
Establish Vision, Choose Patterns
Before you truly begin the design process, take
some time to establish a vision for the whole
system. Take some time to write out a very
high level functional description of the system.
Take a page or two to write it out.
If you immediately knew what this was, you had as much fun as I did in university… or you’re a
• From the narrative you wrote, pay attention to the verbs, and how you’re describing interaction. • Does it feel Realtime? Asynchronous? Synchronous? Do actions feel like
moments in time? (e.g. Events)? • This will help determine interaction patterns
• Can you group the subjects into components?
• DDD is a lost art. Rediscover it • What are your functional domains? How are they grouped?
DOMAIN DRIVEN DESIGN
• You’re ready to begin selecting patterns, but be careful! • Don’t get too stuck in the bleeding edge, but also don’t get stuck in the
stone age • Consider constraints before selection • How do your domains interact, based on the above? • What business problems are you solving for?
PATTERNS: BE MODERN, BUT PRAGMATIC
Example Biz Problem: Technology Limits User Experience Cause: Legacy UI technologies, Fragmented UI
Solution Patterns: Client/API, Modular UI
Solution Details (NOT YET!)
Booking Loyalty On-
• Sketch out your high level system on a whiteboard • Use a thick marker… don’t allow yourself to be drawn into the details
• Be pragmatic
• Vision != Ideology
• Don’t make meaningless compromise
Trumpism of Architecture #1: “IF YOU’RE
GOING TO BE THIKING ANYWAY, THINK
Don’t Drink the Kool Aid - Fruit Punch Edition
Drilling Down: Architecture Components
• Not tool selection (yet) • Think in big terms (e.g. API, Event Stream, Data source) • Be Minimalist! • Component-based patterns reign supreme (e.g. Microservices)
EXAMPLE COMPONENT: MICROSERVICE
Architecture Astronauts at Work
• DRY!!!!!!!!!!!! … !!!!
• That said, don’t be afraid to build a
better mouse trap
• Don’t be an architecture astronaut!
Trumpism of Architecture #2 “PATTERNS
FIRST!!! PATTERNS FIRST!!!!”
Don’t Drink the Kool Aid – Lime Edition
USE BETTER TOOLS
• Select tools based on your components, not the other way around • Prioritize developer productivity • Don’t forget machines!
• Unless you’re doing .NET, trend toward *nix (e.g. Macs) • Remember: if developers have shitty machines, they’re slow
USE BETTER TOOLS: PRINCIPLES
Don’t Just Assemble Packages
• It never ends well!
• Where should you use something off the
shelf vs build?
• Are you solving for a common business
process, or something of unique value to the
• (common example) If you need a few
simple REST APIs, is a full blown API
gateway solution needed?
• Don’t use a Rolls Royce to plow a bean
field (don’t overthink problems)
USE ‘GOLDILOCKS’ TOOLS
TLDR; THIS POINT IN THREE TWEETS
MICROSERVICE: TOOLS VIEW
Queues and Busses
• Deliverability beats Purity
• Don’t be a technology hipster
• Don’t be a fanboy (or fangirl)
• Pick your battles
• Sometimes old things are used because
they’re really good
• Java can usually get it done (more
Trumpism of Architecture #3: “SOMETIMES
THE BEST COMPONENTS ARE THE ONES
YOU ELIMINATE… BIGGLY”
Don’t Drink the Kool Aid - Orange Edition
Don’t Forget Delivery
• Every software system needs an engineering system • Isolate features, apply full quality definition before merge • DevOps should never be an afterthought • Embrace Behavior Driven Design / Development
• What is your vertical slice? • How can you use a vertical slice to improve delivery?
• Instrumentation & Measurement • Measuring waste • Measuring quality
• Waterfall/Wagile makes most new IT architectures impossible • Bloated teams, project mindset, org model mismatch can make your
lives hell • Be mindful of culture
MAKE SURE THE ORG/PROCESS DOESN’T PRECLUDE NEW ARCHITECTURE
• Switch from ’Infantry Divisions’ to ’Special Forces Teams’ FIT TEAMS TO ARCHITECTURE AND ENGINEERING SYSTEM
Test Complexity: Multiplication vs. Addition
• Tech debt is never paid down
• Culture eats strategy (and delivery) for
Trumpism of Architecture #4: “MAKE
ARCHITECTURE GREAT AGAIN!!!”
Don’t Drink the Kool Aid – Grape Edition