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.

Microservices in der Cloud - Software Architecture Summit Berlin 2016

474 views

Published on

http://software-architecture-summit.de/session/microservices-in-der-cloud-mit-autoscout24-auf-die-ueberholspur/

Keine Lust mehr auf Stau im Rechenzentrum? Wieso nicht einen Gang zulegen und auf die Überholspur wechseln? Lernen Sie, wie AutoScout24 die Autobahn in der Cloud baut. Wir erfinden uns grundlegend neu und wechseln vom Monolithen zu Microservices, von .NET auf Windows zu Scala auf Linux, vom Rechenzentrum zu AWS und von getrennter Entwicklung und Betriebsabteilung zu einer Kultur der Zusammenarbeit. An diesem Beispiel aus der Praxis werden sie erfahren, wieso diese Transformation wichtig ist, wie man „Cloud-native“ wird, wie eine Architektur sich entwickelt, wie autonome Teams Software entwickeln und betreiben und wie Prinzipien Orientierung geben.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Microservices in der Cloud - Software Architecture Summit Berlin 2016

  1. 1. Christian Deger @cdeger | AutoScout24 Microservices in der Cloud Mit AutoScout24 auf der Überholspur
  2. 2. Workshop: Questions at any time Interactive discussions Share your experiences Everyone can contribute ?!
  3. 3. Christian Deger Chief Architect cdeger@autoscout24.com @cdeger
  4. 4. 2,4 Million Vehicles
  5. 5. Microservices in the cloud adoption?
  6. 6. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
  7. 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. 8. 2000 Servers 2 Data Centers MTBF optimized
  9. 9. Dev and Ops Silos Development “Change” Operations “Stability”
  10. 10. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
  11. 11. New CEO
  12. 12. Talent? Do you attract
  13. 13. 21st Century What does a tech company look like?
  14. 14. Great Design Universally Connected Mobile First Instant Business Value Massive Data Insight Highly Available
  15. 15. good, but not great Hmm, we are
  16. 16. Reboot everything
  17. 17. Project Tatsu
  18. 18. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
  19. 19. .NET / Windows to JVM / Linux Monolith to Microservices Data center to AWS Devs + Ops to Collaboration culture Involve product people
  20. 20. Major JVM Languages
  21. 21. No traction in major internet companies Major JVM Languages
  22. 22. Major JVM Languages No traction in major internet companies Not accepted by C# developers
  23. 23. Major JVM Languages No traction in major internet companies Not accepted by C# developers Attracts talent Is a starting point
  24. 24. Why Microservices?
  25. 25. Why Microservices? Speed Independent deployable Fast local decisionsAutonomous teams Strong boundaries Loosely coupled Technology diversity Scale the organization
  26. 26. Microservices – The bad parts
  27. 27. Microservices – The bad parts • Operational complexity • Distributed system • Difficult to change boundaries
  28. 28. Loosely coupled service oriented architecture with bounded contexts. —Adrian Cockcroft Microservices are small, autonomous services that work together. —Sam Newman
  29. 29. “Death Star” Diagrams Amazon 2008 Twitter 2013
  30. 30. 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.
  31. 31. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
  32. 32. same direction
  33. 33. 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.
  34. 34. Build MeasureLearn
  35. 35. http://de.slideshare.net/adriancockcroft/microxchg-microservices
  36. 36. Conway’s Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
  37. 37. Autonomous teams business capabilities organized around
  38. 38. Two Pizza Rule Jeff Bezos ’
  39. 39. collaboration culture
  40. 40. We are all engineers!
  41. 41. You build it, you run it.
  42. 42. Monitoring is the new testing
  43. 43. How (not) to share shared nothing as default loosely coupled fast local decisions voluntary adoption exception: macro concerns
  44. 44. Follow the trail
  45. 45. Guilds Self-organizing; common interests; across teams Macro Architecture, Infrastructure, Frontend, QA... Beware of mandelbrot teams
  46. 46. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
  47. 47. Continuous Delivery
  48. 48. DevOps Survey
  49. 49. 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
  50. 50. Application code in one repository per service. CI Deployment package as artifact. CD Deliver package to servers Delivery Pipeline – Data Center
  51. 51. 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
  52. 52. Cattle, not pets
  53. 53. Separate code deployment feature release from
  54. 54. http://martinfowler.com/articles/feature-toggles.html
  55. 55. No staging environment
  56. 56. • Consumer driven contracts • Smoke tests • Canary releases • Shadow traffic • Semantic monitoring Integrate in production
  57. 57. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
  58. 58. 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:
  59. 59. https://aws.amazon.com/resources/gartner-2016-mq-learn-more/ Gartner Magic Quadrant for Cloud IaaS - 2016
  60. 60. http://www.slideshare.net/AmazonWebServices/introduction-to-microservices-66320469/
  61. 61. SQS + S3 Kinesis + S3 Kinesis + DynamoDB SQS + DynamoDB Proxy + DynamoDB DynamoDB Evolution
  62. 62. Unlimited Infrastructure with APIs
  63. 63. Right-Sizing Cost Optimization Elasticity Reservations Cost Transparency Cost Driven Design
  64. 64. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
  65. 65. Migration strategy
  66. 66. Frontend integration Loosely coupled Autonomous teams High optimization
  67. 67. PageSpeed Module css (page+fragment) js (page+fragment) ngx_pagespeed css (page) js (page) css (fragment) js (fragment)
  68. 68. Event Streaming
  69. 69. Event Sourcing one way data highway and data pumps
  70. 70. Templates • Faster bootstrapping • Copied not inherited • Collect and share best practices
  71. 71. Everything fails, all the time. Werner Vogels, CTO Amazon, 2008
  72. 72. 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
  73. 73. Agenda Background Why change? Preparing The journey Continuous delivery Why AWS? Technical migration Status quo and learnings
  74. 74. Commit to Production 20 Minutes Cycle Time New Service 1 Day Service Bootstrapping 3 Days Frontend 4 Days Backend
  75. 75. 015 Teams 025 Lambda Functions 200 Repositories 040 Microservices 009 Systems Status Quo
  76. 76. Learners Experienced Ramp up First 8 teams: Split teams to share knowledge
  77. 77. 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
  78. 78. Learners Experienced Ramp up Plan for next teams: Coach don’t split Coaching
  79. 79. Tribes/Segments/Departments
  80. 80. Product Platform Product vs Platform – Mind the gap Pull vs Push? Disconnect?
  81. 81. An act of Deliberate Collective Learning • Big Picture • Design Level http://eventstorming.com/
  82. 82. 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

×