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

Click here to load reader

Post on 17-Oct-2020

0 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • 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 Experience Cause: Legacy UI technologies, Fragmented UI

    Solution Patterns: Client/API, Modular UI

    Solution Details (NOT YET!)

    Representative technologies

    Booking Loyalty On-

    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