designing systems that don't suck - amazon s3€¦ · • devops should never be an...

Designing and Building Systems that Don’t Suck

Homeland of Linux Edition

Contents

Who is Matt Lancaster and why is he talking to

me?

• Goals

• Patterns

• Components

• Tools

• Delivery

Begin with Goals

4

UNDERSTANDING GOALS

5

• 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

UNDERSTANDING GOALS

6

• 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

Vision Quest!

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

botanist.

9

• 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?

VISIONING

10

• DDD is a lost art. Rediscover it• What are your functional domains? How are they grouped?

DOMAIN DRIVEN DESIGN

11

• 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

12

Example Biz Problem: Technology Limits User ExperienceCause: Legacy UI technologies, Fragmented UI

Solution Patterns: Client/API, Modular UI

Solution Details (NOT YET!)

Representative technologies

Booking LoyaltyOn-

Prem UIs

Modular UI

Separate SPAs

Common Framework

APIs

Content

13

• Sketch out your high level system on a whiteboard• Use a thick marker… don’t allow yourself to be drawn into the details

WHITEBOARDING

Story Time

Visioning together!

• Be pragmatic

• Vision != Ideology

• Don’t make meaningless compromise

Trumpism of Architecture #1: “IF YOU’RE

GOING TO BE THIKING ANYWAY, THINK

YUUUGE”

Don’t Drink the Kool Aid - Fruit Punch Edition

Drilling Down: Architecture Components

17

• 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)

COMPONENT SELECTION

18

EXAMPLE COMPONENTS

19

EXAMPLE COMPONENT: MICROSERVICE

Story Time

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

23

• 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

business?

• (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

26

TLDR; THIS POINT IN THREE TWEETS

27

MICROSERVICE: TOOLS VIEW

Story Time

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

slowly)

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

31

• 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

DELIVERY PRINCIPLES

32

• What is your vertical slice?• How can you use a vertical slice to improve delivery?

• Instrumentation & Measurement• Measuring waste• Measuring quality

EMBRACE LEAN

33

• 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

34

• Switch from ’Infantry Divisions’ to ’Special Forces Teams’FIT TEAMS TO ARCHITECTURE AND ENGINEERING SYSTEM

Story Time

Test Complexity: Multiplication vs. Addition

• Tech debt is never paid down

• Culture eats strategy (and delivery) for

breakfast

Trumpism of Architecture #4: “MAKE

ARCHITECTURE GREAT AGAIN!!!”

Don’t Drink the Kool Aid – Grape Edition

Questions?

FINNISH FINISH