from the monolith to microservices - craftconf 2015
TRANSCRIPT
![Page 1: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/1.jpg)
From the Monolith to Microservices
Lessons from Google and eBay
Randy Shoup
@randyshoup
linkedin.com/in/randyshoup
![Page 2: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/2.jpg)
ArchitectureEvolution
• eBay • 5th generation today
• Monolithic Perl Monolithic C++ Java microservices
• Twitter• 3rd generation today
• Monolithic Rails JS / Rails / Scala microservices
• Amazon• Nth generation today
• Monolithic C++ Java / Scala microservices
![Page 3: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/3.jpg)
ArchitectureEvolution
• The Monolith
• Ecosystem of Services
• Building and Operating a Service
• Service Anti-Patterns
![Page 4: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/4.jpg)
ArchitectureEvolution
• The Monolith
• Ecosystem of Services
• Building and Operating a Service
• Service Anti-Patterns
![Page 5: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/5.jpg)
The Monolithic Architecture
2-3 monolithic tiers
• {JS, iOS, Android}
• {PHP, Ruby, Python}
• {MySQL, Mongo}
Presentation
Application
Database
![Page 6: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/6.jpg)
The Monolithic Application
Simple at first
In-process latencies
Single codebase, deploy unit
Resource-efficient at small scale
Pros
Coordination overhead as team grows
Poor enforcement of modularity
Poor scaling (vertical only)
All-or-nothing deploy (downtime, failures)
Long build times
Cons
![Page 7: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/7.jpg)
The Monolithic Database
Simple at first
Join queries are easy
Single schema, deployment
Resource-efficient at small scale
Pros
Coupling over time
Poor scaling and redundancy (all-or-nothing, vertical only)
Difficult to tune properly
All-or-nothing schema management
Cons
![Page 8: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/8.jpg)
“If you don’t end up regretting your early technology decisions, you probably over-engineered”
-- me
![Page 9: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/9.jpg)
ArchitectureEvolution
• The Monolith
• Ecosystem of Services
• Building and Operating a Service
• Service Anti-Patterns
![Page 10: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/10.jpg)
Microservices
• Single-purpose
• Simple, well-defined interface
• Modular and independent
• Fullest expression of encapsulation and modularity
• Isolated persistence (!)
A
C D E
B
![Page 11: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/11.jpg)
Microservices
Each unit is simple
Independent scaling and performance
Independent testing and deployment
Can optimally tune performance (caching, replication, etc.)
Pros
Many cooperating units
Many small repos
Requires more sophisticated tooling and dependency management
Network latencies
Cons
![Page 12: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/12.jpg)
Ecosystem of Services
• Hundreds to thousands of
independent services
• Many layers of dependencies,
no strict tiers
• Graph of relationships, not a
hierarchy
CB
A EF
GD
![Page 13: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/13.jpg)
Google Service Layering
• Cloud Datastore: NoSQL serviceo Highly scalable and resilient
o Strong transactional consistency
o SQL-like rich query capabilities
• Megastore: geo-scale structured databaseo Multi-row transactions
o Synchronous cross-datacenter replication
• Bigtable: cluster-level structured storageo (row, column, timestamp) -> cell contents
• Colossus: next-generation clustered file systemo Block distribution and replication
• Borg: cluster management infrastructureo Task scheduling, machine assignment
Cloud Datastore
Megastore
Bigtable
Colossus
Borg
![Page 14: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/14.jpg)
Evolution, not Intelligent Design
• No centralized, top-down design of the system
• Variation and Natural selectiono Create / extract new services when needed to solve a problem
o Deprecate services when no longer used
o Services justify their existence through usage
• Appearance of clean layering is an emergent
property
![Page 15: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/15.jpg)
Architecture without an Architect?
• No “Architect” title / role
• (+) No central approval for technology decisionso Most technology decisions made locally instead of globally
o Better decisions in the field
![Page 16: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/16.jpg)
Standardization
• Standardized communicationo Network protocols
o Data formats
o Interface schema / specification
• Standardized infrastructureo Source control
o Configuration management
o Cluster management
o Monitoring, alerting, diagnosing, etc.
![Page 17: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/17.jpg)
Standards become standards by
being better than the alternatives!
![Page 18: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/18.jpg)
ServiceIndependence
• No standardization of service internalso Programming languages
o Frameworks
o Persistence mechanisms
![Page 19: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/19.jpg)
In a mature ecosystem of services,
we standardize the arcs of the
graph, not the nodes!
![Page 20: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/20.jpg)
Creating New Services
• Spinning out a new serviceo Almost always built for particular use-case first
o If successful and appropriate, form a team and generalize for multiple use-cases
• Pragmatism wins
• Exampleso Google File System
o Bigtable
o Megastore
o Google App Engine
o Gmail
![Page 21: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/21.jpg)
Deprecating Old Services
• What if a service is a failure?o Repurpose technologies for other uses
o Redeploy people to other teams
• Exampleso Google Wave -> Google Apps
o Multiple generations of core services
![Page 22: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/22.jpg)
“Every service at Google is either
deprecated or not ready yet.”
-- Google engineering proverb
![Page 23: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/23.jpg)
ArchitectureEvolution
• The Monolith
• Ecosystem of Services
• Building and Operating a Service
• Service Anti-Patterns
![Page 24: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/24.jpg)
Goals of a Service Owner
• Meet the needs of my clients …• Functionality
• Quality
• Performance
• Stability and reliability
• Constant improvement over time
• … at minimum cost and effort• Leverage common tools and infrastructure
• Leverage other services
• Automate building, deploying, and operating my service
• Optimize for efficient use of resources
![Page 25: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/25.jpg)
Responsibilities of a Service Owner
• End-to-end Ownershipo Team owns service from design to deployment to retirement
o No separate maintenance or sustaining engineering team
o DevOps philosophy of “You build it, you run it”
• Autonomy and Accountabilityo Freedom to choose technology, methodology, working environment
o Responsibility for the results of those choices
![Page 26: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/26.jpg)
Service-Service Relationships
• Vendor – Customer Relationshipo Friendly and cooperative, but structured
o Clear ownership and division of responsibility
o Customer can choose to use service or not (!)
• Service-Level Agreement (SLA)o Promise of service levels by the provider
o Customer needs to be able to rely on the service, like a utility
![Page 27: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/27.jpg)
Service-Service Relationships
• Charging and Cost Allocationo Charge customers for *usage* of the service
o Aligns economic incentives of customer and provider
o Motivates both sides to optimize for efficiency
o (+) Pre- / post-allocation at Google
![Page 28: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/28.jpg)
ArchitectureEvolution
• The Monolith
• Ecosystem of Services
• Building and Operating a Service
• Service Anti-Patterns
![Page 29: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/29.jpg)
ServiceAnti-Patterns
• The “Mega-Service”o Overbroad area of responsibility is difficult to reason about, change
o Leads to more upstream / downstream dependencies
• Shared persistenceo Breaks encapsulation, encourages “backdoor” interface violations
o Unhealthy and near-invisible coupling of services
o (-) Initial eBay SOA efforts
![Page 30: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/30.jpg)
ServiceAnti-Patterns
• “Leaky Abstraction” Serviceo Interface reflects provider’s model of the interaction, not the consumer’s
model
o Consumer’s model is more aligned with the domain, simpler, more
abstract
o Leaking provider’s model in the interface constrains evolution of the
implementation
![Page 31: From the Monolith to Microservices - CraftConf 2015](https://reader035.vdocuments.us/reader035/viewer/2022062300/55a67e2a1a28ab776f8b46d7/html5/thumbnails/31.jpg)
Thank You!
• @randyshoup
• linkedin.com/in/randyshoup
• Slides will be at slideshare.net/randyshoup