class: center, middle # MicroServices ## A first look --- # Context / Caveats Based upon: * Research on MicroServices, primarily * https://microservices.io * https://martinfowler.com/articles/microservices.html * **NO** Professional Experience --- # Underlying Principles * [Scale Cube](http://microservices.io/articles/scalecube.html) * [Single Responsibility Principle](https://en.wikipedia.org/wiki/Single_responsibility_principle) * [Conway's Law](https://en.wikipedia.org/wiki/Conway%27s_law) --- # Scale Cube <center> <img alt="Scale Cube from microservices.io" src="http://microservices.io/i/DecomposingApplications.021.jpg" height="240" width="320" /> </center> 1. X-Axis / Horizontal Duplication - run multiple copies of an application behind a load balancer 1. Y-Axis / Functional Decomposition - split application into multiple pieces performing different functions 1. Z-Axis / Data Partitioning - split application into multiple pieces operating over part of the full data set ??? Functional decomposition is the road to Microservices --- # Single Responsibility Principle > The single responsibility principle is a computer programming principle that states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. -- * Easier to understand a single service -- * Improved Fault Isolation between services -- * Independent release schedules ??? Microservices result from applying the Single Responsibility Principle to a large Application --- # Conway's Law > "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." -- * Increase autonomy of Organizational units, including implementation language -- * Promote more rigorous boundaries between functional areas ??? Microservices are Conway's law made explicit --- # Downsides of Microservices * It's a **Distributed Service** -- * Harder to design * Transactions that span multiple services are tricky * Increased coordination costs when use cases span multiple services -- * Harder to develop * Developers often need access to other services under development * Tools need to catch up -- * Harder to test -- * Service Monitoring can be tricky -- * Deployment dependencies can be tricky -- * May need service registry to know what is available and where -- * Increased resource consumption for duplicated infrastructure ??? How do you know if a service instance goes down? And what do you do? Infrastructure could be multiple JVM, Application Servers, VM --- # Your Milage May Vary My target application consists of multiple "services" running as threads communicating via queues -- But * Development team is less than 2 FTE -- * Would need a complete redesign of the service monitoring and control -- * Resource constraints appear to be external, rather than internal ??? Amazon has the 2-pizza rule - teams should not be larger than what 2 pizzas can feed