Introduction to microservices

Editor's Notes

• #5: Microservices Loosely coupled service oriented architecture with bounded context - Adrian Cockcroft Developing single application as a suite of independent small services Each service is running in it’s own process and communicating over lightweight protocols like HTTP (synchronous) or over a lightweight message bus like Akka (reactive / asynchronous)
• #8: Services build around bounded business context - Bounded Context is a central pattern in Domain-Driven Design Dividing the business model into different bounded context – the bounded context can have unified model like order and order items Explicit about relationship between the context Creating whole domain model is not feasible or costs too much resources
• #9: Loosely coupled service oriented architecture with bounded context – Adrian Cockcroft
• #20: In the new world, it is not the big fish which eats the small fish, it’s the fast fish which eats the slow fish. —Klaus Schwab, Chairman World Economic Forum
• #21: http://theartofscalability.com/ - Abbot & Fisher X Axis – Horizontal scaling Handles 1/N of the load Load balancers needs to do round-robin or resource based allocation of requests If caching, then potentially all data can be cached at each application copy Can’t handle increased application complexity and cost of development Y Axis – Functional decomposition Microservices architecture is one implementation of this scaling methodology Z axis – Partitioning / Sharding Each server runs identical copy of the application But each server is responsible for serving requests for a particular subset of data, say employees between ids 1-1000, 1001-2000 and so on Load balancer needs to be smart – route traffic based on partitioning rules Solves some of the problems of X-axis scaling – notably cache and fault isolation Still Can’t handle increased application complexity and cost of development
• #38: Microservices will trigger organization change Cross functional teams that owns the whole functionality – Dev, QA, Product Owner, DBA -> Conway’s law Freedom and responsibility You build it, you run it! Learning Organization Continuously transform itself to stay ahead of competitors Microservices are not about agility, being tech savvy or cloud transformation – it’s about innovation & building business model Smaller agile team of developers – Innovative, nimble & embracing change Lean startup – MVP, feedback -> continue/pivot/stop Versioning of Contracts Enforce version contracts so that different versions of Microservices can communicate with one another Deploy only versions that play well with each other Forward compatibility & Backward compatibity Benefits Release cycle - 4-6 weeks Fully independent team Parallel development Cleaner API design “Fear of change” to “Eagerness to peel off the monolith” Challenges What to peel off Distributed systems are complex Versioning of contracts Operations overhead Testing
• #39: Monolith first! Don’t even consider Microservices unless your system is really complex System complexity and business component boundaries evolve Monolith provides agility, innovation and speed when starting with MVP Microservices come with a premium of managing suite of services Martin Fowler Almost all the successful microservice stories have started with a monolith that got too big and was broken up Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. Recommend Microservices first approach for Monolith rewrite When you know the domain really really well! Containers & Orchestration Package services as containers - run on any platform Container Orchestration – Kubernetes, Swarm, Rancher Monitoring Failover and auto-scaling CI/CD Workflows – code defined, testable and repeatable Benefits Common infrastructure Products as monolith –respond to MVP feedback and pivot/continue Scaling independently Teams talk to each other Opened new possibilities – from on-prem Enterprise to SaaS on cloud Challenges Tools and design of distributed systems Monitoring – Way harder than monolith Cloud native deployment Domain driven design – services with well defined seams