1 / 35

NASSCOM Presentation On Microservices Database Architecture by Tudip.

One of the reasons behind Tudip's success over these 9 years is our intention to help the people around.<br>In another such endeavor, our CTO Mr. Tushar Apshankar spoke about 'Database design for containerized microservices' in NASSCOM product conclave at Pune.<br>Herewith sharing the PPT presentation for the same.

tudiptechnologies
Télécharger la présentation

NASSCOM Presentation On Microservices Database Architecture by Tudip.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Tudip Technologies Continuously Delivering Digital Solutions with Integrity | Innovation | Serenity https://tudip.com/

  2. Database Design for Containerized Microservices

  3. The world where we live in... Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations. -  M. Conway Corollary by James and Neil: Therefore: Make sure the organization is compatible with the product architecture. “ ”

  4. OTT System in Microservice Architecture

  5. What is Microservice Architecture? As per Martin Fowler, services in a microservice architecture (MSA) are often processes that communicate over a network to fulfill a goal using technology-agnostic protocols such as HTTP. Services are independently deployable. Services are organized around fine-grained business capabilities. Services can be implemented using different programming languages, databases, hardware and software environment, depending on what fits best. This does not mean that a single microservice is written in a patchwork of programming languages.

  6. Salient features of Microservices • Multiple Components • Built For Business, instead of technology • Simple Routing • Decentralized • Failure Resistant • Evolutionary

  7. Overall Microservices Loose coupling is the operative word, that means microservices should be able to be modified without requiring changes in other microservices.

  8. Microservices Pros • Freedom to independently develop and deploy services • A microservice can be developed by a fairly small team • Code for different services can be written in different languages (though practitioners discourage it) • Easy integration and automatic deployment • Easy to understand and modify for developers, thus can help a new team member become productive quickly • The developers can make use of the latest technologies • The code is organized around business capabilities • When change is required in a certain part of the application, only the related service can be modified and redeployed—no need to modify and redeploy the entire application • Better fault isolation: if one microservice fails, the other will continue to work • Easy to scale and integrate with third-party services • No long-term commitment to technology stack

  9. Microservices Cons • Due to distributed deployment, testing can become complicated and tedious • Increasing number of services can result in information barriers • The architecture brings additional complexity as the developers have to mitigate fault tolerance, network latency, and deal with a variety of message formats as well as load balancing • Being a distributed system, it can result in duplication of effort • When number of services increases, integration and managing whole products can become complicated • In addition to several complexities of monolithic architecture, the developers have to deal with the additional complexity of a distributed system • Developers have to put additional effort into implementing the mechanism of communication between the services • Handling use cases that span more than one service without using distributed transactions is not only tough but also requires communication and cooperation between different teams

  10. How Micro a Microservice should be? Amazon's policy is that the team implementing a microservice should be small enough that they can be fed by two-pizzas.

  11. Is it all Rosy?

  12. The Hardest Part About Microservices: Database Design

  13. Yes, database is the DOG!

  14. Broadly, you have 2 options!

  15. Option # 1, Monolithic Database

  16. Option #1.1, Variation of Monolithic Database

  17. Option #2, Multiple Databases

  18. Problems in Monolithic Database • You can NOT scale a service without scaling the database • You can not deploy a service because change in 1 schema, going to affect other microservices and hence you can not do Continuous Integration/Continuous Deployments • You would be stuck with an RDBMS OR NoSQL and can NOT pick what works the best • And hence, service preference of the DB would be completely lost

  19. Well, what about 2PC (Phase Commits) • 2PC, is a mechanism for implementing a transaction across different software components (multiple databases, message queues etc.) • Well, if that is how you implement, the ghosts of limitations of Monolithic Database are going to Haunt You!

  20. Again, monolithic database is a DOG!

  21. The Hardest Part About Microservices:Your Data But challenges of the Database per Service.. https://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/

  22. Multiple Databases has its own challenges! • Complexity of managing multiple SQL and NoSQL databases • Implementing business transactions that span multiple services is not straightforward. Moreover, many modern (NoSQL) databases don’t support them. The best solution is to use the Saga pattern. Services publish events when they update data. Other services subscribe to events and update their data in response. • Implementing queries that join data that is now in multiple databases is challenging.

  23. Saga • Implement each business transaction that spans multiple services as a saga. • A saga is a sequence of local transactions. • Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.

  24. Saga Continues

  25. 2 ways to coordinating the Saga • There are two ways of coordination sagas: • Choreography - each local transaction publishes domain events that trigger local transactions in other services • Orchestration - an orchestrator (object) tells the participants what local transactions to execute

  26. Here is choreography-based Saga

  27. Choreography-based saga

  28. Orchestration-based saga

  29. And here is an Orchestra

  30. And then there is always CQRS

  31. CQRS: Command Query Responsibility Segregation

  32. How did it work in one of our OTT project?

  33. What all we have used in this application? Saga Along with CQRS

  34. References • https://en.wikipedia.org/wiki/Microservices • https://en.wikipedia.org/wiki/Conway%27s_law • https://microservices.io/patterns/data/event-sourcing.html • https://auth0.com/blog/introduction-to-microservices-part-4-dependencies/ • https://stackoverflow.com/questions/41640621/data-sharing-between-micro-services • https://www.baeldung.com/transactions-across-microservices

  35. Thank You Know more about Tudip here!

More Related