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.

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”

13. Agenda
Background
Why change?
Preparing
The journey
Continuous delivery
Why AWS?
Technical migration
Status quo and learnings

14. New
CEO

15. Talent?
Do you attract

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

21. Reboot
everything

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

26. Major JVM Languages

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

32. Why Microservices?

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.

43. Build
MeasureLearn

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

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

46. Autonomous teams
business capabilities
organized around

47. Two Pizza Rule
Jeff Bezos ’

48. collaboration culture

49. We are all
engineers!

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

56. Continuous
Delivery

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

63. Separate
code deployment
feature release
from

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

65. No
staging
environment

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

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

74. Agenda
Background
Why change?
Preparing
The journey
Continuous delivery
Why AWS?
Technical migration
Status quo and learnings

75. Migration strategy

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

91. Tribes/Segments/Departments

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