Microservices in der Cloud - Software Architecture Summit Berlin 2016
Download as PPTX, PDF1 like990 views
The document discusses the transformation of AutoScout24's architecture from a monolithic structure to microservices in the cloud, emphasizing the need for speed, autonomy, and scalability through independent deployable services. It highlights the importance of continuous delivery, organizational culture changes, and the adoption of AWS for operational efficiency. Key principles include reducing time to market, autonomous team responsibility, and using data-driven metrics to guide decisions and improvements.
Microservices in der Cloud - Software Architecture Summit Berlin 2016
- 1. Christian Deger @cdeger | AutoScout24 Microservices in der Cloud Mit AutoScout24 auf der Überholspur
- 2. Workshop: Questions at any time Interactive discussions Share your experiences Everyone can contribute ?!
- 5. Microservices in the cloud adoption?
- 6. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
- 7. Monolith SVN Monorepo .NET Webforms Swimlanes Git repos .NET MVC Shared database Swimlanes: • Teams wanted to be faster and more autonomous • Rough extraction of a capability • Code duplication of base functionality • Separate delivery pipelines • Frequent releases • ”Composition” using subdomains Cash-Stack $$
- 8. 2000 Servers 2 Data Centers MTBF optimized
- 9. Dev and Ops Silos Development “Change” Operations “Stability”
- 13. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
- 14. New CEO
- 17. 21st Century What does a tech company look like?
- 19. Great Design Universally Connected Mobile First Instant Business Value Massive Data Insight Highly Available
- 20. good, but not great Hmm, we are
- 22. Project Tatsu
- 24. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
- 25. .NET / Windows to JVM / Linux Monolith to Microservices Data center to AWS Devs + Ops to Collaboration culture Involve product people
- 27. No traction in major internet companies Major JVM Languages
- 28. Major JVM Languages No traction in major internet companies Not accepted by C# developers
- 29. Major JVM Languages No traction in major internet companies Not accepted by C# developers Attracts talent Is a starting point
- 33. Why Microservices? Speed Independent deployable Fast local decisionsAutonomous teams Strong boundaries Loosely coupled Technology diversity Scale the organization
- 34. Microservices – The bad parts
- 36. Microservices – The bad parts • Operational complexity • Distributed system • Difficult to change boundaries
- 37. Loosely coupled service oriented architecture with bounded contexts. —Adrian Cockcroft Microservices are small, autonomous services that work together. —Sam Newman
- 38. “Death Star” Diagrams Amazon 2008 Twitter 2013
- 39. 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 System are vertical slices integrated at the UI.
- 40. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
- 41. same direction
- 42. 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.
- 45. Conway’s Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
- 47. Two Pizza Rule Jeff Bezos ’
- 50. You build it, you run it.
- 51. Monitoring is the new testing
- 52. How (not) to share shared nothing as default loosely coupled fast local decisions voluntary adoption exception: macro concerns
- 53. Follow the trail
- 54. Guilds Self-organizing; common interests; across teams Macro Architecture, Infrastructure, Frontend, QA... Beware of mandelbrot teams
- 55. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
- 57. DevOps Survey
- 58. Forsgren, Nicole and Humble, Jez, The Role of Continuous Delivery in IT and Organizational Performance (October 27, 2015). Forsgren, N., J. Humble (2016). "The Role of Continuous Delivery in IT and Organizational Performance." In the Proceedings of the Western Decision Sciences Institute (WDSI) 2016, Las Vegas, NV. . Available at SSRN: http://ssrn.com/abstract=2681909 or http://dx.doi.org/10.2139/ssrn.2681909 DevOps Science
- 59. Application code in one repository per service. CI Deployment package as artifact. CD Deliver package to servers Delivery Pipeline – Data Center
- 60. 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
- 62. Cattle, not pets
- 66. • Consumer driven contracts • Smoke tests • Canary releases • Shadow traffic • Semantic monitoring Integrate in production
- 67. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
- 68. http://archive.oreilly.com/network/2006/12/20/web-20-bezos.html —Jeff Bezos 2006 Avoid undifferentiated heavy lifting Undifferentiated Your Idea Undifferentiated Your Idea On Premise: AWS:
- 69. https://aws.amazon.com/resources/gartner-2016-mq-learn-more/ Gartner Magic Quadrant for Cloud IaaS - 2016
- 70. http://www.slideshare.net/AmazonWebServices/introduction-to-microservices-66320469/
- 71. SQS + S3 Kinesis + S3 Kinesis + DynamoDB SQS + DynamoDB Proxy + DynamoDB DynamoDB Evolution
- 72. Unlimited Infrastructure with APIs
- 74. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
- 76. Frontend integration Loosely coupled Autonomous teams High optimization
- 78. PageSpeed Module css (page+fragment) js (page+fragment) ngx_pagespeed css (page) js (page) css (fragment) js (fragment)
- 79. Event Streaming
- 80. Event Sourcing one way data highway and data pumps
- 81. Templates • Faster bootstrapping • Copied not inherited • Collect and share best practices
- 82. Everything fails, all the time. Werner Vogels, CTO Amazon, 2008
- 83. Resilience, Availability • Chaos engineering • Timeouts/ Circuit Breaker • Bulkheads Availability := MTTF MTTF + MTTR MTTF: Meant Time To Failure MTTR: Mean Time To Recovery http://techblog.netflix.com/2014/09/introducing-chaos-engineering.html
- 84. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
- 85. Commit to Production 20 Minutes Cycle Time New Service 1 Day Service Bootstrapping 3 Days Frontend 4 Days Backend
- 86. 015 Teams 025 Lambda Functions 200 Repositories 040 Microservices 009 Systems Status Quo
- 88. Learners Experienced Ramp up First 8 teams: Split teams to share knowledge
- 89. https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/ ”Who is on a team matters less than how the team members interact, structure their work, and view their contributions.” The five keys to a successful Google team
- 90. Learners Experienced Ramp up Plan for next teams: Coach don’t split Coaching
- 92. Product Platform Product vs Platform – Mind the gap Pull vs Push? Disconnect?
- 93. An act of Deliberate Collective Learning • Big Picture • Design Level http://eventstorming.com/
- 96. Picture Credits Tatsu Sign by Martin Lewison from The Hague, Zuid-Holland, The Netherlands under CC BY-SA 2.0 Martin Fowler by Webysther Nunes under CC BY-SA 4.0 Werner Vogels by Guido van Nispen under CC BY 2.0 "HotWheels - '69 Ford Torino Talladega“ by Leap Kye, licensed under CC BY-ND 2.0 Differences between Traditional vs Next Generation by Simon Wardley under CC BY-SA 3.0 Enterprise IT Adoption Cycle by Simon Wardley under CC BY-SA 3.0 And the future is private 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 Wandergeselle by Sigismund von Dobschütz under CC BY-SA 3.0 Wheel clamps Texas by Richard Anderson from Denton, United States (Boots.) under CC BY-SA 2.0 Sharing Sucks (4536747557) by eyeliam from Portland, United States under CC BY 2.0 Traffic Jam by Doo Ho Kim under CC BY-SA 2.0 Puzzling by Bernd Gessler (Own work) CC BY-SA 3.0 Amazon16 by Neil Palmer/CIAT under CC BY-SA 2.0 Pizza by Jakob Dettner, Rainer Zenz under CC BY-SA 2.0 de Bezos’ Iconic Laugh by Steve Jurvetson under CC BY 2.0