Microservices tech talk
Download as PPTX, PDF1 like263 views
Microservices are an architectural style that structures an application as a collection of small, independent services that communicate over well-defined interfaces. This style draws from service-oriented architecture (SOA) principles but with lessons learned around using REST instead of SOAP, keeping services small and independent, and embracing distributed and decentralized control. While microservices provide benefits like independence and agility, they also introduce complexity from having many distributed components and integration points that require strong testing and operational practices.
Microservices tech talk
- 2. Definition of Microservices • SOA without the vendors • + Lessons learned after 10+ years: – REST >> SOAP – Simplicity – Higher granularity -> Micro
- 3. SOA Principles – Still valid • High decoupling: – Service has its own lifecycle • Allows releasing often with fewer changes with lower risk • Rolling upgrades • Canaries – Isolation • Communication through well defined interfaces, usually remote • Share nothing, service owns its persistence schema – Stateless • Clients maintain state for the flow
- 4. SOA Principles - Lessons Learned • SOAP model is too rigid, REST is extensible • Clients everywhere: HTML, devices, M2M, IoT • Backwards compatibility is a must, usually we do not own clients • Design the interface upfront, aim for consensus with client developers if feasible • Refactor or rebuild the service, the smaller the service the cheaper to refactor/rebuild. Just keep the interfaces untouched
- 5. SOA Principles - Lessons Learned II • Resource versioning when backwards compatibility is not possible, adds lots of complexity, code forking • HTTP as standard: Load Balancers, Proxies, Firewalls. Still more communication mechanisms are required, mostly intra-dc: Kafka, RabbitMQ, Akka cluster, etc • Remote interfaces promote better isolation than local interfaces. • Enhances team autonomy, easier to experiment new technologies in smaller services that can be rewritten if necessary. REST interfaces are quite agnostic of implementation technology • Strong Functional and Regression Testing – more exposed interfaces mean that more effort is required to assess the services data and behavior is correct • Integration tests are costly – lots of integration points to test, system is complex so having a working integration environment is difficult and costly.
- 6. Micro, nano or pico?? • Service granularity depends on several factors: – Organizational: Conway’s Law – Latency: The more granular, the more latency we add, more so in the high percentiles – Release policy – Integration testing
- 7. Risks and caveats • Services too small: – Risk of becoming orphaned, no team maintaining it – Chattiness, client needs to talk to multiple services for a given functionality • Too coarse: – more changes in each release – More difficult to refactor • Backwards compatibility is expensive • Somewhat chaotic systems and organization, difficult to have the whole picture, less standarized and more distributed • Complex systems design as everything is distributed • Complex debugging as a transaction usually flows through several services
- 8. Related Topics • Continuous Delivery – Microservices are deployed often, CD is almost a requirement to deploy as often as microservices require • Chaos Monkey – Resilience importance is more relevant because of the number of components involved in a flow/transaction • Eventual consistency – CAP is usually balanced towards AP, availability and partition tolerance are more important than immediate consistency • Immutable deployments – new containers are created that package the new version, traffic is progressively directed to this newly created cluster. Rollback is trivial • Service discovery – configuration is difficult, many integration configuration points difficult to operate manually