The document discusses Airbnb's transition from a monolithic architecture to microservices, emphasizing the development of a robust DevOps culture and best practices learned over time. Key points include the importance of independent deployments, modular service structures, and automated processes for scaling and delivery. It also provides insights on challenges faced during this transition and highlights the principles of continuous integration, monitoring, and standardized service creation.

1. From Monolith to Microservices:
@MELANIECEBULA / SEPT 2017 / FUTURESTACK
How to Scale Your Architecture

2. 65k 191 4 mil
countriescities listings
What is airbnb?
AN ONLINE MARKETPLACE FOR SHARING HOMES

3. Who am I?

4. 100%
Availability
100%
Productivity

5. Our time together
Moving to MicroservicesScaling the MonolithA Brief History
The origins of our
DevOps culture, and
how that shapes our
tools
The challenges we face
as we scale Monolithic
deploys
The best practices for
transitioning to
microservices (that we
learned the hard way)

6. A BRIEF HISTORY

7. 1 GitHub repo 1 SRE Sysops
“Monorail”
OUR MONOLITHIC RUBY ON RAILS APPLICATION

8. 1. triage
2. coordinate
3.communicate
Sysops
INCIDENT RESPONSE

9. DEVOPS CULTURE

10. Sysops
today
40
on-calls
2
primaries
2
shifts
engineers on
the rotation
sysops buddies weekdays
weekends

11. • Sysops Training every quarter
• Sysops training establishes best
practices for on-call and incident
response
• 33% of engineers have attended a
Sysops training
• Service on-calls can escalate to Sysops
• Blameless postmortem culture
Sysops training

12. Scaling Sysops

13. Monitoring &Alerting

15. • STATSD protocol
• Automatically collect system metrics
• Metrics live alongside feature code
• Easy for any developer to write
• Service dashboards with both business metrics and system metrics
Metrics
ALONGSIDE CODE

16. Alerts
CONFIGURATION AS CODE

17. SCALING MONORAIL DEPLOYS

18. When it starts to
become a problem
MONORAIL LOC
0
1000000
2000000
3000000
4000000
2009 2010 2011 2012 2013 2014 2015 2016 2017 2018

19. All developers are
expected to “own” their
features from
implementation to
production.
Each developer is
expected to:
• deploy their changes
• monitor their changes
• roll back, abort, or
revert if necessary
Democratic deploys

20. • everything merged into master is
deployable to production
• frequent deploys (with smaller batches)
• automate as much as possible
Continuous Delivery

21. Scaling Deploy Process
• builds, tests, and deploys must be fast
and reliable
• ping authors when they need to take
action
• automatic (and fast) reverts
• merge queue
• automatic rollbacks for new exceptions

22. THE MOVE TO
MICROSERVICES

23. “Essentially, a microservices architecture is a method of
developing software applications as a suite of independently
deployable, small, modular services in which each service
runs a unique process and communicates through a well-
defined, lightweight mechanism to serve a business goal.”
— someone on the internet
What is a microservices architecture?

24. Why Not Microservices?
• Distributed systems
are hard!
• Naming things is
hard!
• Having to support
different languages /
frameworks

25. Why Microservices?
• Independent
deployment
• Modular structure /
Ownership
• Secure / Performant
• Upgrading
dependencies

26. Why Microservices?
SCALING CONTINUOUS DELIVERY

27. Why Microservices?
Deploys per week (all apps, all environments)

28. Why Microservices?
75,000
production deploys
per year

29. Service registry
and discovery
Message busConfiguration
Management
Microservices architecture
THE BARE MINIMUM
Chef
Kubernetes
Smartstack
Envoy
with Kafka

30. Microservices architecture
AS YOU START TO SCALE
• Rapid provisioning (AWS instances)
• Devops culture
• Basic monitoring / alerting
• Continuous Delivery

31. Moment of Truth
Are we committed to microservices?

32. Services 900
developers
300
services
4k
deploys per week

33. Service Creation Challenges
• Supporting different languages / frameworks
• Services own their own data
• Standardized configuration
• Monitoring with microservices
• Splitting the Monolith into services

34. Monorail P1 P2 P3 P4
UI Layer
API Layer
Splitting the Monolith
Vertical concerns
Horizontal concerns

35. UI Layer
API Layer
Splitting the Monolith
Vertical concerns
Horizontal concerns

36. Standardize Service Creation
NO SNOWFLAKES

37. Standardize Service Creation
OKAY BUT HOW?
Standardize and simplify your configuration!
• lives as code, inside application repository
• automatically tested and validated as part of CI
• can deployed and consumed as an artifact
• has a standardized format and defaults

38. 1. Monolith first
2. Devops culture
3. Configuration as code
4. Monitoring and Alerting
5. Continuous delivery
6. Automate what you can
7. Your first service is going to be bad
8. Services own their own data
9. Break apart the Monolith
10. Standardize service creation
The important part
10 TAKEAWAYS