Micro services
- 1. Microservices Practicalities and Things to watch out for Parthiban J https://www.linkedin.com/in/parthibanj-ea/
- 2. What is Micro services ? Framework ? Deployment model ? Architectural Pattern ? Obviously , Microservices is not a silver bullet and is not the only way to architect applications
- 3. The Difference • Tightly coupled • Scaling is an issue • Functionality as services • Must fit into overall design • Rules and protocols govern communication • Loosely coupled • Bounded context • Scalable • What you expose to consumers • Could be a single service or a collection Monolith SOA Microservices API
- 4. Why Microservices • Deploy individually without impacting other services • Independent deployment = Quicker time to market • Selective scaling • Fault Isolation
- 5. The Ecosystem Composition DB Architecture Service Definition Service Registry Service Discovery Deployment Security Composition – Decompose by business capability, by sub domain DB Architecture – Dedicate DB per service, Shared DB Service Definition – Contract definition Service Registry – Self Registry, Third Party Service Discovery – Client side, Server side Deployment – VM, Containers, Serverless Security – API Gateway, Tokens
- 6. The First step – Identifying your services Domain driven design (DDD) Entity outside domain Inventory Order Product Customer Order History Price …… ……. Your Domain Define & use integration channels for external communications Sub Domain • Domain = Your problem space , your scope • DDD -> Break your complex problem into sub domains • Identify : Entities, interactions and their boundaries • Bounded context • Define rules of interactions and place the ownership of management appropriately Tips - Building a service catalogue • Focus on single responsibility - service must do one thing and only one thing • Fine Vs Coarse grain -> Transaction block sizes must be manageable
- 7. Dedicated Vs Shared DB • Segregated ownership • Cross references Vs Data Redundancy Vs Scalability considerations • Data Sync – Changelogs, events , pull Ordering DB Ordering Customers Sales Customer DB Sales DB Dedicated DB ( Preferred ) Shared DB Ordering Customers Sales Shared DB (Trade Off ) • Will work, but must be cautious about responsibility segregation • Multiple schemas within a same DB is an option • Always keep selective scaling and change management in mind
- 8. Transaction Management CAP Theorem – You can have just 2 and not all 3 Eventual Consistency • Will have to move from strict to eventual consistency • Can be implemented in 2 ways : • 2 Phased commit • Prepare phase • Commit phase • SAGA pattern • Choreography • Orchestration Consistency Querying • CRUD vs CQRS • Traditional CRUD – Create, Read, Update, Delete model • CQRS - Command Query Responsibility Segregation • 2 Different models for Write and Read • Command – Create / Update transactions • Query – Read
- 9. Service Definition Reasons why you must have a contract • Let the world know what the service is about • Document your service contract – Input & output • Use : RAML, Swagger or any tool • Some tools let you generate code from contract definitions.. Yay ! • You can even write test automation scripts from contract Hey world am here This is how you reach me
- 10. Service Registry Self Registry Third Party Service Registry Service Registry RegistrarHeartbeat (De)Register Heartbeat Register • Service instances are responsible for registering and deregistering • Pro : Does not need other components to manage registrations • Con : Every service / framework used must implement a registering mechanism • “Registrar” component manages service registration. Many deployment environments have service registration inbuilt • Pro : Do not have to implement the registration per implementation language and framework • Con : Registrar is one more component to manage and assure availability
- 11. Service Discovery • Client queries registry and is responsible for load balancing • E.g Ribbon – load balancer • Client just calls a DNS URL. • E.g AWS elastic load balancer (ELB) Client Side Server Side Service Registry Service Service Service Client Service Registry Service Service Service Client Load Balancer
- 12. Deployment models Deploy them on a traditional VM as multiple instances Deploy them on a dedicated VMs Of course, You can deploy them as containers Serverless, Yay !! Why not
- 13. Security – Gateways and Tokens API Gateway Security Routing API mgmt. Audit …… S1 S3 S2 S4 Client 1 Client 2 Client 3 API Gateway Vs Service registry – Most API gateways have inbuilt integration to registries API Gateway Vs Service mesh – Mesh is a network communication infrastructure. Circuit breaker, fault injection, health check Client 1 Client 2 Client 3 Design Goal : Stateless Knowing State: Stick sessions, session replication Tokens : JWT, OAuth
- 14. Other things to consider Service Segregation Audits Safety Nets Exception Handling • Data Services • Business services • Aggregators • Event handlers • Listeners • Transaction tracking • AOP – Standard elements • Timeouts • Circuit breakers • Asynchronous • Retry • Appropriate HTTP codes • Functional errors in response