Decompose that WAR! A pattern language for microservices Chris Richardson Author of POJOs in Action Founder of the original CloudFoundry.com @crichardson chris@chrisrichardson.net http://plainoldobjects.com http://microservices.io @crichardson
Presentation goal Why patterns and pattern languages? A pattern language for microservices @crichardson
About Chris @crichardson
About Chris Founder of a startup that’s creating a platform for developing event-driven microservices @crichardson
For more information https://github.com/cer/event-sourcing-examples http://microservices.io http://plainoldobjects.com/ https://twitter.com/crichardson @crichardson
Agenda Why a pattern language for microservices? Core patterns Deployment patterns Communication patterns @crichardson
In 1986… http://en.wikipedia.org/wiki/Fred_Brooks @crichardson
Yet almost 30 years later developers are still passionately arguing over “silver bullets” @crichardson
Suck/Rock Dichotomy JavaScript vs. Java Spring vs. Java EE Functional programming vs. Object-oriented Containers vs. Virtual Machines http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html @crichardson
Gartner Hype Cycle It’s It’s not awesome awesome Trade-offs understood http://upload.wikimedia.org/wikipedia/commons/b/bf/Hype-Cycle-General.png @crichardson
How we make decisions Rationalize with our intellect Decide using emotions http://en.wikipedia.org/wiki/Mahout @crichardson
We need a better way to discuss and think about technology @crichardson
What’s a pattern? Reusable solution to a problem occurring in a particular context @crichardson
The structure of a pattern = Great framework for discussing and thinking about technology @crichardson
The structure of a pattern Name Context aka the situation Problem (conflicting) issues Forces etc to address Solution Resulting context Related patterns @crichardson
Benefits Resulting context Drawbacks Issues to resolve @crichardson
Alternative solutions Related patterns Solutions to problems introduced by this pattern @crichardson
Pattern language A collection of related patterns that solve problems Access to Water in a particular domain Relationships Promenade Pattern A results in a context that has a problem Local townhall solved by Pattern B Patterns A and B solve the Intimacy gradient same problem Pattern A is a Light on two sides specialization of pattern B http://en.wikipedia.org/wiki/A_Pattern_Language
Meta-pattern Problem : How to talk/reason about technology? Context : Emotional software development culture Solution : Use the pattern format Benefit : More objective Drawback : Less exciting Related patterns : It’s awesome! @crichardson
Motivating Solution Work Pattern Pattern Service-per- in Solution A Solution B Container General Specific progress Deployment Service-per-VM Multiple Services per host Single Service per Host Core Monolithic Microservice architecture architecture Partitioning API gateway Server-side Communication Client-side discovery discovery Style Remote Procedure Messaging Invocation Service registry Discovery Self registration 3rd party registration @crichardson
Agenda Why a pattern language for microservices? Core patterns Deployment patterns Communication patterns @crichardson
@crichardson
Let’s imagine you are building an online store REST/JSON Browser/ StoreFrontUI Client HTML Product Info Service SQL Recommendation Database Service Review Service Order Service @crichardson
Problem: what’s the deployment architecture? @crichardson
Forces There is a team of developers that must be productive The application must be easy to understand and modify Do continuous deployment Run multiple instances for scalability and availability Use emerging technologies (frameworks, programming languages, etc) @crichardson
Pattern: Monolithic architecture WAR/EAR StoreFrontUI HTML Product Info REST/JSON MySQL Browser/ Service Client Database Recommendation Service Simple to Review Service develop Order Service test Tomcat deploy scale @crichardson
Examples everywhere @crichardson
But when the application is large … @crichardson
Intimidates developers @crichardson
Obstacle to frequent deployments Need to redeploy everything to change one component Interrupts long running background (e.g. Quartz) jobs Eggs in Increases risk of failure one basket Fear of change Updates will happen less often - really long QA cycles e.g. Makes A/B testing UI really difficult @crichardson
Overloads your IDE and container Slows down development @crichardson
Obstacle to scaling development But the backend is not working I want to update yet! the UI Lots of coordination and communication required @crichardson
Requires long-term commitment to a technology stack @crichardson
Pattern: Microservice architecture @crichardson
Apply functional decomposition Y axis - functional decomposition Scale by g n splitting r i n a o l i m i different things t i t i s r a g p n a i t t t a i s l p d g s n - y i h s b t i x e a l a Z c S X axis - horizontal duplication @crichardson
Microservice architecture Product Info Product Info Service Browse Products UI Recommendation Service Checkout UI Order management Review UI Service Account Order management UI Service Apply X-axis and Z-axis scaling to each service independently @crichardson
Examples http://techblog.netflix.com/ ~600 services http://highscalability.com/amazon-architecture 100-150 services to build a page http://www.addsimplicity.com/downloads/ eBaySDForum2006-11-29.pdf http://queue.acm.org/detail.cfm?id=1394128 @crichardson
Benefits Smaller, simpler apps Easier to understand and develop Less jar/classpath hell - who needs OSGI? Faster to build and deploy Scales development: develop, deploy and scale each service independently Improves fault isolation Eliminates long-term commitment to a single technology stack System level architecture vs. service level architecture Easily and safely experiment with new technologies @crichardson
Drawbacks Complexity of developing a distributed system Implementing inter-process communication Handling partial failures Implementing business transactions that span multiple databases (without 2PC) Complexity of testing a distributed system Complexity of deploying and operating a distributed system Managing the development and deployment of features that span multiple services Fortunately solutions exists @crichardson
The benefits typically outweigh the drawbacks for large, complex applications @crichardson
Issues to address How to deploy the services? How do the services communicate? How do clients of the application communicate with the services? How to partition the system into services? …. @crichardson
Agenda Why a pattern language for microservices? Core patterns Deployment patterns Communication patterns @crichardson
We have applied the microservices pattern: How to deploy the services? @crichardson
Forces Services are written using a variety of languages, frameworks, and framework versions Each service consists of multiple service instances for throughput and availability Building and deploying a service must be fast Service must be deployed and scaled independently Service instances need to be isolated Resources consumed by a service must be constrained Deployment must be cost-effective @crichardson
@crichardson
Pattern: Multiple service instances per host Host (Physical or VM) Service-A Service-B Service-C Instance-1 Instance-2 Instance-2 Process WAR OSGI bundle @crichardson
Benefits and drawbacks Benefits Drawbacks Efficient resource utilization Poor/Terrible isolation Fast deployment Poor visibility (with WAR/OSGI deployment) Difficult to limit resource utilization Risk of dependency version conflicts Poor encapsulation of implementation technology
Pattern: Service instance per host @crichardson
Pattern: Service per VM host VM Service deployed as VM packaged as Service image VM Service VM Service @crichardson
Example http://techblog.netflix.com/ ~600 services packer.io is a great tool @crichardson
Benefits and drawbacks Benefits Drawbacks Great isolation Less efficient resource utilization Great manageability Slow deployment VM encapsulates implementation technology Leverage AWS infrastructure for Autoscaling/Load balancing
Pattern: Service per Container host VM Container Service deployed as Container packaged as Container Service image Service VM Container Service @crichardson
Examples @crichardson
Benefits and drawbacks Benefits Drawbacks Great isolation Immature infrastructure for deploying containers Great manageability Container encapsulates implementation technology Efficient resource utilization Fast deployment
Recommend
More recommend
