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 ?!

3. Christian Deger Chief Architect cdeger@autoscout24.com @cdeger

4. 2,4 Million Vehicles

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”

11. New CEO

12. Talent? Do you attract

13. 21st Century What does a tech company look like?

14. Great Design Universally Connected Mobile First Instant Business Value Massive Data Insight Highly Available

15. good, but not great Hmm, we are

16. Reboot everything

17. Project Tatsu

19. .NET / Windows to JVM / Linux Monolith to Microservices Data center to AWS Devs + Ops to Collaboration culture Involve product people

20. Major JVM Languages

21. No traction in major internet companies Major JVM Languages

22. Major JVM Languages No traction in major internet companies Not accepted by C# developers

23. Major JVM Languages No traction in major internet companies Not accepted by C# developers Attracts talent Is a starting point

24. Why Microservices?

25. Why Microservices? Speed Independent deployable Fast local decisionsAutonomous teams Strong boundaries Loosely coupled Technology diversity Scale the organization

26. Microservices – The bad parts

27. Microservices – The bad parts • Operational complexity • Distributed system • Difficult to change boundaries

28. Loosely coupled service oriented architecture with bounded contexts. —Adrian Cockcroft Microservices are small, autonomous services that work together. —Sam Newman

29. “Death Star” Diagrams Amazon 2008 Twitter 2013

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.

32. same direction

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. Build MeasureLearn

35. http://de.slideshare.net/adriancockcroft/microxchg-microservices

36. Conway’s Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”

37. Autonomous teams business capabilities organized around

38. Two Pizza Rule Jeff Bezos ’

39. collaboration culture

40. We are all engineers!

41. You build it, you run it.

42. Monitoring is the new testing

43. How (not) to share shared nothing as default loosely coupled fast local decisions voluntary adoption exception: macro concerns

44. Follow the trail

45. Guilds Self-organizing; common interests; across teams Macro Architecture, Infrastructure, Frontend, QA... Beware of mandelbrot teams

47. Continuous Delivery

48. DevOps Survey

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. Application code in one repository per service. CI Deployment package as artifact. CD Deliver package to servers Delivery Pipeline – Data Center

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. Cattle, not pets

53. Separate code deployment feature release from

54. http://martinfowler.com/articles/feature-toggles.html

55. No staging environment

56. • Consumer driven contracts • Smoke tests • Canary releases • Shadow traffic • Semantic monitoring Integrate in production

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. https://aws.amazon.com/resources/gartner-2016-mq-learn-more/ Gartner Magic Quadrant for Cloud IaaS - 2016

60. http://www.slideshare.net/AmazonWebServices/introduction-to-microservices-66320469/

61. SQS + S3 Kinesis + S3 Kinesis + DynamoDB SQS + DynamoDB Proxy + DynamoDB DynamoDB Evolution

62. Unlimited Infrastructure with APIs

63. Right-Sizing Cost Optimization Elasticity Reservations Cost Transparency Cost Driven Design

65. Migration strategy

66. Frontend integration Loosely coupled Autonomous teams High optimization

67. PageSpeed Module css (page+fragment) js (page+fragment) ngx_pagespeed css (page) js (page) css (fragment) js (fragment)

68. Event Streaming

69. Event Sourcing one way data highway and data pumps

70. Templates • Faster bootstrapping • Copied not inherited • Collect and share best practices

71. Everything fails, all the time. Werner Vogels, CTO Amazon, 2008

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

74. Commit to Production 20 Minutes Cycle Time New Service 1 Day Service Bootstrapping 3 Days Frontend 4 Days Backend

75. 015 Teams 025 Lambda Functions 200 Repositories 040 Microservices 009 Systems Status Quo

76. Learners Experienced Ramp up First 8 teams: Split teams to share knowledge

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. Learners Experienced Ramp up Plan for next teams: Coach don’t split Coaching

79. Tribes/Segments/Departments

80. Product Platform Product vs Platform – Mind the gap Pull vs Push? Disconnect?

81. An act of Deliberate Collective Learning • Big Picture • Design Level http://eventstorming.com/

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