Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS Cloud For Breakfast - Building Microservices in the Cloud

241 views

Published on

The AutoScout24 journey to AWS and Microservices. With a strong emphasis on the cultural change.
Digital Transformation from the trenches.

Published in: Software
  • Be the first to comment

  • Be the first to like this

AWS Cloud For Breakfast - Building Microservices in the Cloud

  1. 1. AWS Cloud for Breakfast | 27.04.2017 | Christian Deger | @cdeger Highway to heaven Building microservices in the cloud
  2. 2. Christian Deger Chief Architect christian.deger@scout24.com @cdeger
  3. 3. Microservices on AWS?
  4. 4. Speed Independent deployable Fast local decisionsAutonomous teams Strong boundaries Loosely coupled Technology diversity Scale the organization Why Microservices?
  5. 5. Cloud = no physical limitations
  6. 6. Agility
  7. 7. Agility • Technical agility
  8. 8. Agility • Technical agility • Organizational agility
  9. 9. 2.4 million vehicles
  10. 10. 2000 servers 2 data centers MTBF optimized
  11. 11. Development “Change” Operations “Stability” Dev and Ops Silos
  12. 12. New CEO
  13. 13. talent? Do you attract
  14. 14. 21st century What does a tech company look like?
  15. 15. Great design Universally connected Mobile first Instant business value Massive data insight Highly available
  16. 16. good, but not great Hmm, we are
  17. 17. Reboot everything
  18. 18. .NET/Windows to JVM/Linux Monolith to microservices Data center to AWS Devs + Ops to collaboration culture Involve product people
  19. 19. “Death Star” diagrams Amazon 2008 Twitter 2013
  20. 20. http://scs-architecture.org/ Self-contained systems = microservices flavor Team 1 Team 2 Team 3 One business capability is owned, built and run as an SCS by one team. Self-contained systems are vertical slices integrated at the UI.
  21. 21. Same direction
  22. 22. STRATEGIC GOALS Goals of the business side ARCHITECTURAL PRINCIPLES High-Level Principles DESIGN AND DELIVERY PRINCIPLES Tactical measures REDUCE TIME TO MARKET Establish fast feedback loops to learn, validate and improve. Remove friction, hand-offs and undifferentiated work. MOBILE FIRST Start small and use device capabilities. SUPPORT DATA-DRIVEN DECISIONS Provide relevant metrics and data for user and market insights. Validate hypothesis for problems worth solving. YOU BUILT IT, YOU RUN IT The team is responsible for shaping, building, running and maintaining its products. Fast feedback from live and customers helps us to continuously improve. ORGANIZED AROUND BUSINESS CAPABILITIES Build teams around products not projects. Follow the domain and respect bounded contexts. Make boundaries explicit. Inverse Conway Maneuver. LOOSELY COUPLED By default avoid sharing and tight coupling. No integration database. Don’t create the next monolith. MACRO AND MICRO ARCHITECTURE Clear separation. Autonomous micro services within the rules and constraints of the macro architecture. AWS FIRST Favor AWS platform service over managed service, over self-hosted OSS, over self built solutions. DATA-DRIVEN/METRIC-DRIVEN Collect business and operational metrics. Analyze, alert and act on them. ELIMINATE ACCIDENTAL COMPLEXITY Strive to keep it simple. Don’t over-engineer. Focus on necessary domain complexity. AUTONOMOUS TEAMS Make fast local decisions. Be responsible. Know your boundaries. Share findings. INFRASTRUCTURE AS CODE Automate everything: Reproducible, traceable, auditable and tested. Immutable servers. CROSS-FUNCTIONAL TEAMS Engineers from all backgrounds work together in collaborative teams as engineers and share responsibilities. No silos. BE BOLD Go into production early. Value monitoring over tests. Fail fast, recover and learn. Optimize for MTTR not MTBF. SECURITY, COMPLIANCE AND DATA PRIVACY Build with least privilege and data privacy in mind. Know your threat model. Limit blast radius. COST EFFICIENCY Run your segment in the right balance of cost and value. ONE SCOUT IT Foster collaboration. Harmonize and standardize tools. Pull common capabilities into decoupled platform services. Version 2.0 Icons made by Freepik from www.flaticon.com are licensed under CC BY 3.0 BEST TALENT Autonomy, purpose and mastery: We know why we do things, we decide how to approach them and deliberately practice our skills.
  23. 23. Build MeasureLearn
  24. 24. Conway’s Law “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”
  25. 25. Autonomous teams business capabilities organized around
  26. 26. You build it, you run it.
  27. 27. We are all engineers!
  28. 28. Follow the trail
  29. 29. Guilds Self-organizing; common interests; across teams Macro architecture, infrastructure, front end, QA... Beware of Mandelbrot teams
  30. 30. Continuous delivery
  31. 31. Application code in one repository per service. CI Deployment package as artifact. CD Deliver package to servers Delivery pipeline—data center
  32. 32. Application code and infrastructure specification in one repository per service. CI Deployment package and infrastructure declaration as artifact. CD 1. Create or update service infrastructure. 2. New instances pull down package and start application. Delivery pipeline—AWS
  33. 33. No staging environment
  34. 34. Cattle, not pets
  35. 35. Hamburgers, not cattle
  36. 36. Event streaming
  37. 37. Monitoring is the new testing
  38. 38. 015 Teams 045 Lambda functions 250 Repositories 075 Microservices 019 Systems Status quo
  39. 39. Picture Credits Wandergeselle by Sigismund von Dobschütz, licensed under CC-BY-SA-3.0 "HotWheels - '69 Ford Torino Talladega“ by Leap Kye, licensed under CC BY-ND 2.0 Enterprise IT Adoption Cycle by Simon Wardley under CC BY-SA 3.0 Leosvel et Diosmani by Ludovic Péron under CC BY-SA 3.0 Spare wheel by Brian Snelson under CC BY 2.0 Stopwatch by William Warby under CC BY 2.0

×