Microservices
Download as PPTX, PDF0 likes173 views
The document discusses microservices, which is an approach to developing software applications as suites of independently deployable services. Key points include: - A microservice is a discrete unit of functionality that can be accessed remotely and operated independently. Microservices have specific outcomes, are self-contained, act as black boxes, and may use other underlying services. - Microservices divide applications into small, independent components with their own databases. This allows each service to be developed, deployed, and scaled independently. - The microservices approach has advantages like improved modularity, flexibility, and fault tolerance but also has drawbacks like increased complexity in testing and coordination across services. - Major challenges in implementing microservices include partitioning
Microservices
- 2. WHAT IS A SERVICE? A service is a discrete unit of functionality that can be accessed remotely and acted upon independently A service has four properties It represents a business activity with a specified outcome. It is self-contained. It is a black box for its consumers. It may consist of other underlying services 2
- 3. WHAT IS SOA? A service-oriented architecture is a style of computer software where services are provided to the other components by application components, through a communication protocol over a network. The basic fundamental principles of service oriented architecture is independent of vendors, products and technologies. e.g. SOAP, REST, Messaging, WCF 3
- 4. WHAT ARE MICROSERVICES? Microservices are an implementation approach for SOA? Some may not agree An application is developed as a suite of small services. Services are independently build and deployed component Each service has its own database May use synchronous or asynchronous calls 4
- 5. CHARACTERISTICS Built around business capabilities Independently developed from each other Independently deployed Scaled independently A dedicated team works for each service during lifecycle 5
- 6. TRADITIONAL TEAMS 6 Actually it is just Rohan
- 7. MSA TEAMS (CROSS FUNCTIONAL) 7
- 8. ADVANTAGES 8 Each microservice is relatively small Easier for a developer to understand Easy to refactor, debug and test Speeds up build and deployment Each service can be deployed independently of other services Easier to deploy new versions of services frequently Can be scaled independently
- 9. ADVANTAGES 9 Improved fault tolerance The other services will continue to handle requests. One component of a monolithic architecture can bring down entire system. Eliminates any long-term commitment to a technology stack Every service can have its own tech stack suited for its functionality Learning curve
- 10. DRAWBACKS 10 Adds complexity to the system Implement the inter-service communication mechanism Distributed transactions Lots of network calls? A usual method call becomes an across the network service call Testing is more difficult
- 11. DRAWBACKS 11 Increased resource uses Separate environments, CI/CD mechanisms Increased memory consumption e.g. separate JVM for each service Use cases that spawn across multiple services require very careful co-ordination between teams Biggest hurdle is to to find how to partition the system into microservices
- 12. CHALLENGES 12 Database partitioning Application partitioning Inter-service communication
- 13. DATABASE PARTITIONING 13 Generally the most difficult part Joins, sorting and referential integrity Handle in the application code Create steps in transactions that can be played out Event driven Eventual consistency
- 14. EVENTUAL CONSISTENCY 14 How to design eventually consistent business logic Atomically update DB and publish event Distributed transactions? Slow, Deadlock prone Database triggers? DB specific, error prone
- 15. EVENTUAL CONSISTENCY CONTD 15 eBay solution Update DB, create event Consume event Mark event as consumed Error prone, does not work in race conditions What is the solution?
- 16. EVENTUAL CONSISTENCY CONTD 16 Present is a fold over history Do not update database Just publish events Events update DB Maintain ordering of events Replay events to arrive at a state Complicates the design, duplicate events will be tricky
- 17. DATABASE PARTITIONING CONTD 17 Create master-slave strategy Synching databases Polyglot persistence Most NoSql databases have no acid properties, joins or transactions
- 18. APPLICATION PARTITIONING 18 Partition along use cases Several new services to handle calls from other services Application logging is tricky Central or local, inter service calls log tailing is difficult Deployment strategy
- 19. APPLICATION PARTITIONING 19 Code dependencies needs to be managed Better not to have dependent modules Handle global configuration data Zookeeper?
- 20. INTER-SERVICE COMMUNICATION 20 Technology REST Messaging Performance Unreliable communication Failover, slow response, circuit breakers etc
- 21. PITFALLS 21 Testing each service is easy Testing the whole system is not, who owns integration? Technology Pluralism Should not lead to technology explosion, no one can understand the whole system Independent deployment hastens release cycle Watch out for dependencies between services Release, monitoring and versioning must be standardized
- 22. PITFALLS CONTD 22 Refactoring a service is easy Its another beast to refactor across services Development is MSA oriented But CI/CD pipeline is not Teams are still built around technology and not services
- 23. KNOWN USERS 23 Amazon Netflix eBay
- 24. QUESTIONS? 24
- 25. FOOD FOR THOUGHT ARE MICROSERVICES FOR EVERYONE?