Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Microservice  Ecosystems    
at  Scale    	
Randy Shoup
@randyshoup
linkedin.com/in/randyshoup
Architecture  
Evolution	
• eBay
•  5th generation today
•  Monolithic Perl à Monolithic C++ à Java à microservices
• T...
Microservice  Ecosystems  
at  Scale	
•  Ecosystem of Services
•  Designing a Service
•  Building and Operating a Service
Microservice  Ecosystems  
at  Scale	
•  Ecosystem of Services
•  Designing a Service
•  Building and Operating a Service
Ecosystem    
of  Services	
•  Hundreds to thousands of
independent services
•  Many layers of dependencies,
no strict tie...
Google    
Service  Layering	
•  Cloud Datastore: NoSQL service
o  Highly scalable and resilient
o  Strong transactional c...
Evolution,    
not  Intelligent  Design	
•  No centralized, top-down design of the system
•  Variation and Natural selecti...
“Every  service  at  Google  is  
either  deprecated  or  not  ready  
yet.”  
	
 	
 	
 	
-­‐‑-­‐‑  Google  engineering  p...
Architecture  without  an  
Architect?	
•  No “Architect” title / role
•  Appearance of clean layering is an emergent
prop...
Microservice  Ecosystems  
at  Scale	
•  Ecosystem of Services
•  Designing a Service
•  Building and Operating a Service
Characteristics  of  an  
Effective  Service	
•  Single-purpose
•  Simple, well-defined interface
•  Modular and independen...
Service  
Anti-­‐‑PaKerns	
•  The “Mega-Service”
o  Overbroad area of responsibility is difficult to reason about, change
...
Service  
Anti-­‐‑PaKerns	
•  Shared persistence
o  Breaks encapsulation, encourages “backdoor” interface violations
o  Un...
Service    
Persistence	
•  Option 1: Operate your own data store
o  Store to your own instance(s) of MySQL, etc., owned a...
Maintaining    
Interface  Stability	
•  Backward / forward compatibility of interfaces
o  Can *never* break your clients’...
Microservice  Ecosystems  
at  Scale	
•  Ecosystem of Services
•  Designing a Service
•  Building and Operating a Service
Goals  of  a    
Service  Owner	
•  Meet the needs of my clients …
•  Functionality
•  Quality
•  Performance
•  Stability...
Responsibilities  of  a  
Service  Owner	
•  End-to-end Ownership
o  Team owns service from design to deployment to retire...
Service  as    
Bounded  Context	
•  Primary focus on my service
o  Clients which depend on my service
o  Services which m...
Service-­‐‑Service    
Relationships	
•  Vendor – Customer Relationship
o  Friendly and cooperative, but structured
o  Cle...
Charging  and    
Cost  Allocation	
•  Charge customers for *usage* of the service
o  Aligns economic incentives of custom...
Architecture  
Evolution	
• eBay
•  5th generation today
•  Monolithic Perl à Monolithic C++ à Java à microservices
• T...
“If  you  don’t  end  up  regreKing  
your  early  technology  
decisions,  you  probably  over-­‐‑
engineered.”	
-- me
Thank  You!	
•  @randyshoup
•  linkedin.com/in/randyshoup
Prochain SlideShare
Chargement dans…5
×

Microservices Practitioner Summit Jan '15 - Microservice Ecosystems At Scale - Randy Shoup

3 490 vues

Publié le

Randy Shoup from eBay and Google.

While first-order goals are almost always driven by the needs of scalability and velocity, this evolution also produces second-order effects on the organization as well. This session will discuss building and operating modern microservice architectures at scale, using specific examples from both Google and eBay.

Full video here: http://www.microservices.com/randy-shoup-microservice-ecosystems-at-scale

Publié dans : Technologie

Microservices Practitioner Summit Jan '15 - Microservice Ecosystems At Scale - Randy Shoup

  1. 1. Microservice  Ecosystems     at  Scale     Randy Shoup @randyshoup linkedin.com/in/randyshoup
  2. 2. Architecture   Evolution • 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
  3. 3. Microservice  Ecosystems   at  Scale •  Ecosystem of Services •  Designing a Service •  Building and Operating a Service
  4. 4. Microservice  Ecosystems   at  Scale •  Ecosystem of Services •  Designing a Service •  Building and Operating a Service
  5. 5. Ecosystem     of  Services •  Hundreds to thousands of independent services •  Many layers of dependencies, no strict tiers •  Graph of relationships, not a hierarchy C B A E F G D
  6. 6. Google     Service  Layering •  Cloud Datastore: NoSQL service o  Highly scalable and resilient o  Strong transactional consistency o  SQL-like rich query capabilities •  Megastore: geo-scale structured database o  Multi-row transactions o  Synchronous cross-datacenter replication •  Bigtable: cluster-level structured storage o  (row, column, timestamp) -> cell contents •  Colossus: next-generation clustered file system o  Block distribution and replication •  Borg: cluster management infrastructure o  Task scheduling, machine assignment Cloud   Datastore Megastore Bigtable Colossus Borg
  7. 7. Evolution,     not  Intelligent  Design •  No centralized, top-down design of the system •  Variation and Natural selection o  Create / extract new services when needed to solve a problem o  Services justify their continued existence through usage o  Deprecate services when no longer used
  8. 8. “Every  service  at  Google  is   either  deprecated  or  not  ready   yet.”   -­‐‑-­‐‑  Google  engineering  proverb
  9. 9. Architecture  without  an   Architect? •  No “Architect” title / role •  Appearance of clean layering is an emergent property •  (+) No central approval for technology decisions o  Most technology decisions made locally instead of globally
  10. 10. Microservice  Ecosystems   at  Scale •  Ecosystem of Services •  Designing a Service •  Building and Operating a Service
  11. 11. Characteristics  of  an   Effective  Service •  Single-purpose •  Simple, well-defined interface •  Modular and independent •  Isolated persistence (!) A C D E B
  12. 12. Service   Anti-­‐‑PaKerns •  The “Mega-Service” o  Overbroad area of responsibility is difficult to reason about, change o  Leads to more upstream / downstream dependencies •  “Leaky Abstraction” Service o  Interface reflects provider’s model of the interaction, not the consumer’s model o  Consumer’s model is typically more aligned with the domain, simpler, more abstract o  Leaking provider’s model in the interface constrains evolution of the implementation
  13. 13. Service   Anti-­‐‑PaKerns •  Shared persistence o  Breaks encapsulation, encourages “backdoor” interface violations o  Unhealthy and near-invisible coupling of services o  (-) Initial eBay SOA efforts
  14. 14. Service     Persistence •  Option 1: Operate your own data store o  Store to your own instance(s) of MySQL, etc., owned and operated by the service •  Option 2: Use a persistence service o  Store to your own partition(s) of Dynamo, Bigtable, etc., operated as a service by another team •  è Only external access to data store is through published service interface
  15. 15. Maintaining     Interface  Stability •  Backward / forward compatibility of interfaces o  Can *never* break your clients’ code o  Often multiple interface versions o  Sometimes multiple deployments o  Majority of changes don’t impact the interface in any way •  Explicit deprecation policy o  Strong incentive to wean customers off old versions (!)
  16. 16. Microservice  Ecosystems   at  Scale •  Ecosystem of Services •  Designing a Service •  Building and Operating a Service
  17. 17. 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
  18. 18. Responsibilities  of  a   Service  Owner •  End-to-end Ownership o  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 Accountability o  Freedom to choose technology, methodology, working environment o  Responsibility for the results of those choices
  19. 19. Service  as     Bounded  Context •  Primary focus on my service o  Clients which depend on my service o  Services which my service depends on •  Very little worry about o  The complete ecosystem o  The underlying infrastructure •  Cognitive load is very bounded •  è Small, nimble service teams Service Client   A Client   B Client   C
  20. 20. Service-­‐‑Service     Relationships •  Vendor – Customer Relationship o  Friendly and cooperative, but structured o  Clear ownership and division of responsibility •  Customer can choose to use service or not (!) o  Must be strictly better than the alternatives of build, buy, borrow
  21. 21. Charging  and     Cost  Allocation •  Charge customers for *usage* of the service o  Aligns economic incentives of customer and provider o  Motivates both sides to optimize efficiency •  Free usage leads to waste o  No incentive to control usage or find more efficient alternatives •  E.g., App Engine usage at Google o  Charging one particularly egregious internal customer led to 10x reduction in usage
  22. 22. Architecture   Evolution • 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
  23. 23. “If  you  don’t  end  up  regreKing   your  early  technology   decisions,  you  probably  over-­‐‑ engineered.” -- me
  24. 24. Thank  You! •  @randyshoup •  linkedin.com/in/randyshoup

×