Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Evolutionary Serverless Architecture

E8f66870d1204779ecc45f2695faa73e?s=47 Michael Wittig
February 16, 2018

Evolutionary Serverless Architecture

A system architecture often struggles to adapt to new requirements. Serverless architectures can evolve over time because we can replace the building blocks at any time.

E8f66870d1204779ecc45f2695faa73e?s=128

Michael Wittig

February 16, 2018
Tweet

Transcript

  1. Evolutionary Serverless Architecture From hackathon to product - marbot.io

  2. HELLO! I am Michael Wittig cloudonaut.io and AWS in Action

    (Manning) hello@marbot.io - @hellomichibye 2
  3. 3 From hackathon...

  4. 4 ...to product

  5. 5 ▰ Incremental change ▰ Fitness functions ▰ Appropriate coupling

  6. Hi, marbot here! I’m a Slack bot supporting your DevOps

    team to detect and solve incidents on AWS. 6
  7. Why marbot? ▰ smart escalation algorithm minimizes distraction and response

    time ▰ configures AWS monitoring for you ▰ fun and easy to use chatbot ▰ contextual help to resolve AWS incidents 7
  8. 8

  9. Fitness function ƒ: X→figure of merit 9

  10. Key fitness functions ▰ Never lose alerts ▰ End user

    latency < 200 ms ▰ Code coverage > 80 % ▰ Monitoring coverage > 90 % ▰ Managed over self-managed 10
  11. Architecture 11

  12. 12 Diagrams powered by:

  13. Key fitness functions ▰ • Never lose alerts ▰ •

    End user latency < 200 ms ▰ • Code coverage > 80 % ▰ • Monitoring coverage > 90 % ▰ • Managed over self-managed 13
  14. 14

  15. Key fitness functions ▰ • Never lose alerts ▰ •

    End user latency < 200 ms ▰ • Code coverage > 80 % ▰ • Monitoring coverage > 90 % ▰ • Managed over self-managed 15
  16. 16

  17. Key fitness functions ▰ • Never lose alerts ▰ •

    End user latency < 200 ms ▰ • Code coverage > 80 % ▰ • Monitoring coverage > 90 % ▰ • Managed over self-managed 17
  18. Summary 18

  19. Start as simple as possible ▰ Automate deployment ▰ Use

    small managed building blocks ▰ Add monitoring/tracking everywhere ▰ Don’t optimize 19
  20. Evolve the architecture over time ▰ Analyze monitoring/tracking data ▰

    Optimize where necessary ▰ Decouple (e.g. with Step Functions) 20
  21. Other learnings ▰ Step functions are awesome timers ▰ User

    interaction with step functions is ugly ▰ Idempotent state transitions ▰ Remote calls need retry logic 21
  22. CREDITS Special thanks to all the people who made and

    released these awesome resources for free: ▰ Presentation template by SlidesCarnival ▰ Photographs by PEXELS 22
  23. 23 Good Bye! Checkout marbot.io cloudonaut.io, and AWS in Action

    hello@marbot.io - @hellomichibye