 Hi Al, today we are going to discuss about how to choose a right database for your microservices. If you see the industry trends from the last one decade, the architecture got changed and microservices architecture got introduced in most of the applications. This is Dr. Vamsi Mohan from India and today we are going to discuss about how to choose a right database for your microservices. Before going to that session, I want to share my details about my profile, my experience and my credentials as well. I am a co-founder and CTO in Hubber Technologies which is based out of India and I am next hundred CIOs for the year of 2020. And also I got CXO Excellence Award for the year 2021 and I am top 50 global thought leaders and influencers for RPA in data center technologies and cybersecurity. Coming to my credentials of academic, I hold PhD in computer science and engineering and holding several patents in data transmission and cybersecurity. I did my post graduation in computer science and technology and I hold a master's degree in management from IMA Hemsworth. I like writing and publishing papers and I published 40 plus national and international papers successfully. And also I have successfully driven several industry academia initiatives with various tier one and tier two technology institutions globally. Apart from that, I am an industry speaker in several national and international conferences. Coming to today's topic which we are going to discuss is the agenda will be looking like this. We are going to discuss about the introduction. We are going to discuss about microservices versus monolithic architecture. And we will be talking about micro front ends. How it is different from the traditional front end technologies as well as we are going to discuss about how microservice architecture tackles the drawbacks of monolithic architecture. As well as some portion which we are going to talk about monolithic databases and also some of the microservices database patterns like a database service or a shared database services we are going to discuss about it. And as part of choosing a right database for microservices which we are going to discuss about and also some of the different database models which we are going to talk about. Basically, the poly got persistence models as well as multimodal databases which we are going to talk about in this session as well as what are the different drivers behind choosing a right database for microservices are also we will be going to discuss about it. And finally, we will be talking about the recommendations what kind of a database is suits the microservices architecture as well as followed by the conclusion what kind of a database is right for your microservice applications. Coming to the introduction part of the microservices is as we discussed microservices are gaining popularity from the last one decade with respect to the infrastructure as well as with respect to the loosely coupled architecture. And because of that the loosely coupled architecture as well as the downsized development and the testing setups it came as a familiar in the market as well as it helps to go to market strategies quite easily. And most of these microservices based applications it takes less time to go to the market as well as we have discussed about the it is actually it is the rejection of tightly coupled or a tightly connected architecture apart like not like a monolithic applications or a monolithic architecture it is not completely not tightly coupled and it is a completely a loosely coupled architecture. And because of these some of some of the specialized features like a self-contained and autonomous features actually created the specialty for this microservices and widely popular because of these autonomous and self-contained behaviors. If you see on my screen I have actually shown two different diagrams one is the diagram one states about your monolithic architecture which is completely tightly coupled like the user module threads module as well as the post module is completely coupled as part of your monolithic application. In this application the entire application is tightly coupled and at a time you have to deploy. However in the second diagram it is completely classified decoupled into three different bundles code bundles I mean to say is basically the users threads as well as the post services. And with respect to these kind of a loosely coupled architecture if any module like a users or a threads or a post is not working properly you can you can the developers can work on only particular module or a particular microservice bundle and the other two microservices or a functionalities will work as is as intended without taking any downtime or application outage. And coming to the architecture types of microservices versus monolithic as we discussed monolithic architecture is tightly coupled and because of the tightly coupled the entire functionality will be bundled as a one single bundle or a one component which will be hosted or which will be deployed as a code bundle in the container or a server. And because of that if any feature or any patch you are introducing on top of this code bundle you have to take the outage and at the same time you have to take a complete deployment of this entire code bundle. And this creates time consumption with respect to the deployment as well as it proportionally the testing efforts will increase. If you see in the diagram of a monolithic architecture the user interface business logic and data access layers are tightly coupled as well as all three layers are connected to the single database. All these calls the user interface business logic and data access layers are completely coupled and as a as considered as a single bundle and it will be a huge size with respect to the code bundles as well. Unlike monolithic microservices are lightweight components as well as it is a loosely coupled architecture because of that the entire functionality will be distributed into different code bundles or a different smaller functionality applications which we call it as microservice applications. These are all differently classified and deployed each component as an independent autonomous unit. With respect to that if you see on my right side of the image you will be able to see different microservices as a different applications which will be hosted and at the same time these microservices are connected to the different databases lightweight databases. These lightweight databases which we call it as a micro DBs or micro databases. Basically how it works is microservices will be directly talking to the concerned micro databases which is a lightweight and because of that there is no need for there is no need for there is no need for entire bundling the entire activity and microservices are having microservice application is also known as a microservices architecture which organizes as an application as set of interconnected services. Basically it is highly maintainable and testable products as well as it is a loosely coupled architecture and independently deployed code bundles where the independent lightweight components can be deployed across in the containers and organized around different business capabilities owned by the smaller teams to develop and test and host these applications. Basically if you see different kind of a functionalities will be split into based on the business functionalities it will be split into the different modules as well as the applications those those modules or applications will be considered as microservices. Coming to the microservice patterns we we call it as micro frontends which we are talking as but of the table of contents like what is the difference between actual actual frontend code as well as the microservices frontends. In case of microservice frontends it is a it is again it is a lightweight component and because of that each micro each microservices application will be having their own micro frontends as well as micro databases. These micro frontends are also a lightweight unlike monolithic frontends. Monolithic frontends basically the entire the frontend layer or a UI layer is coupled with the with the business logic and hosted as a single component. However here the micro frontends will also be considered as a independent deployable unit or a bundle which can be deployed independently which will talk to the microservices I concerned microservices as well as it it surfaces the business requirements. Basically if you if you see on my screen on the on the right side the source control of the source control of three different microservices or micro applications is interacting to for surfacing a production application. If you see micro frontend A is Vue J is which is a which is a JavaScript component which is directly talking to the microservice and it is directly hosted to the production. As well as the microservice B or a micro frontend B is having the AngularJS and it is directly talking to the another microservice as well as the microservice micro frontend C is developed with ReactJS which is interacting with the business component of a microservice C and and it will be independently deployed in the production as a different components and all together it will be working as a single application however it is deployed as a different independent components. Coming to the benefits of the micro frontends is basically the micro frontend architecture is very simpler the simpler and that is why it is easy to maintain and manage the code and also it is independent development teams can collaborate on the frontend applications and they can they can develop easily and also they can provide a mean of migrating from old app by having a new app running side by side with it basically how it works is in case of migration or UI transformations without disturbing the old application we can create a new app parallely for the parallel run and till the completion of the entire development we can parallely develop as well as deploy in the production as an app and once these frontend application is completely developed and working fine in the production you can dismantle or wipe off wipe it off the older application of the older view basically it helps for the your parallel run as well and how microservice architecture tackles the drawbacks of monolithic architecture some of the components which we are talking about is flexibility as we have discussed microservices architecture is more flexible and different microsales can be developed since it is a smaller core core basis it is easier to manage the code as well as deploy and upgrade easily and it is it is coming to the reliability microservice architecture is reliable and even out of out of 10 features if any one feature is goes down the entire application doesn't go down we can we can fix the issue and and whatever the feature went for went for down or or the fix which you have applied those component are those microservice you can deploy it and it starts interacting with the other microservices through different ways of communication and also we were talking about the development speed how fast these microservices will be will be interacted and how fast we can develop as we have discussed these microservices are smaller in size and the code bundles are very lightweight because of that the development the feature development is quite faster as well as it don't take much time for the hosting as well as deployment as well as loading these components to the developer system even even testing of a particular feature is also quite faster because of the less code or the the lightweight component and and one of the advantages is building complex application basically you can develop as a independent different components and integrate or you can you can establish a communication between these independent components and it will surface the entire application application functionality basically you can you can develop as a smaller components and you can you can deploy it and once once the communication mechanism is established gradually it the complex application you can develop it easily even the independent components can be further broken into the smaller independent tasks which can be deployed independently as a microservice and also with respect to the scalability scalability is one of the advantages for the microservices each microservices can be scaled individual and as we discussed previously it is in smaller in size as well as caching of some of the data is very effective because of the less size and the cacv a kind of a features like a continuous integration and continuous deployment will be there quite faster and easier as well because smaller in the in the code the continuous integration of your the developers code will be directly checking into the SEM system as well as once it is checked into the SEM system the continuous testing and continuous deployment cycles are quite faster because of the less code as well as the scalable of in size and we were talking about micro front ends and how it is different from monolithic front ends now in this in this slide which we are going to discuss about the monolithic databases a monolithic database is a framework where data is stored transformed centrally as a single data store monolithic data architectures are managed by one team as well as whose business domains are relatively simple and the data is quite rarely changing if if it is an in case of a dynamic changing of the requirements as well as well as dynamic changing of the data models it is quite difficult to manage this monolithic databases as well as coming coming to the scalability of these monolithic databases or it is the data architecture can't scale indefinitely and most monolithic databases don't auto scale it as an application were workload as well as data volumes increase exponentially monolithic databases gradually becomes low when the time passes and also it is expansive and hard to maintain these kind of monolithic databases the ability to consume and harmonize the ubiquitous data in one place managed by the central team is also a difficult and it impacts on the on the team morale as well as the team it increases the team burden as well as monolithic databases often have high latency and throughput that naturally arise from the concurrent database read writes from the different disconnected teams with monolithic data architectures it is also challenging to respond to new needs without altering the entire data pipelines basically the agility is quite less compared to the microservice databases and here it is it is a one complete database which will be directly talking to the application because of that if there is any any particular new requirement comes it impacts on the application as well as it impacts on the database as well eventually the the third monolithic architecture lacks of a modularity and suffers the homogenization of the technology basically this is this is one of the advantages when we are talking about different databases talking to the single application it is quite complex in case of a monolithic databases basically your application is directly talking to a one one database only it cannot interact with the different databases even if it is a hybrid kind of a monolithic databases when we are talking about even the databases should be the similar kind of the same databases like a oracle or a mySQL server or mssql server or a db2 kind of a application it should be homogeneous not one application can talk to a different kinds of a databases this is one of the drawback with the monolithic applications as well as a monolithic databases eventually a monolithic database would naturally result in inpatient data consumers disconnected data procedures and a backlogged engineering team burdens by towering the technical depths basically what what will happen is because of the complexity the team morale will go down as well as some of the technical depths will increase and it cannot be scaled according to the the agile requirements we were talking about different micro database patterns basically database we call it as a database dedicated databases to the microservices which is an ideal scenario for the microservice based applications the idea is simple each microservice has its own data store unlike the entire database and because of that assume in my screen you can see the service a is interacting with one database a small small lightweight database as well as service b is interacting with the another data another small database and service c is interacting with the another small database because of this the smaller in size of the database it will be it will be quite easier to interact also the performance of these the performance of these request response system is quite possible and coming to coming to the heterogenicity of different kinds of databases interacting if you see on my screen service a is interacting with the my school database and the service b is interacting with MongoDB database and service a is interacting with the customer database basically you are the same application even though the front end or the microservice is developed with one particular technology or environment it can easily talk to different databases I didn't get that could you try again and coming to individual data stores are easily scalable on my on my screen you can see different databases and it is easier to understand the services within the data as a whole finally the data database per service we are able to use polyglot persistence we can use different database technologies for different microservices in case of database per application and this is an ideal scenario when we are talking about microservice architecture and it is especially for the scratch development of applications are a greenfield kind of applications and the second kind of a application is a micro database shared database with the different microservices this is this is this kind of a scenarios will come as part of your transformations with the database is core for the business activities and we don't want to optimize or normalize the database and the front end code as well as the microservices will be optimized the entire application code is normalized or optimized into different microservices and still it is interacting with the one database even though you can you can reap some benefits with respect to the application leaves from the micro front ends and microservices but when it comes to the database the the cons basically the button is still there with the with the existing database because the database is not normalized or refactored with respect to the micro databases and also all different kinds of a microservices will be interacting with the single database and because of this the number of requests will be more to the single database and microservices with shared database can't easily scale unless unless it is it is not recommended unless we cannot avoid the situation as well as the database will be a single point for all these applications and if anything happens to the database or a schema automatically all the applications will stop working working and the application will directly go for a outage and coming to coming to the concept of how to choose a database for microservices is basically various databases if you see from the last one decade we have seen multiple new databases introduced recently today database market is brimming with different possibilities and you can pick the best database for your needs however the database choosing of these databases also depends on the application structure as well as what kind of a frameworks you are using we can by deciding on a method for constructing different database models and and and when we are talking about these different database patterns or different database types one is a polygot persistence as well as the second one is a multimodal databases which we can discuss in the subsequent slides on my screen you can see what are the different kinds of a databases comes as part of your relational database relation database databases or a databases schemas as well as what are the different databases basis or a data stores comes as part of your non-relational schemas polygot persistence basically we are talking about one is two one similar kind of a thing which we we have discussed as part of your micro dbs or a micro macintz basically if you see on my screen service a interacting with one database service b is interacting with one database as well as services is interacting with another database because of that the basically the service the services or application layer is a quite simple and lightweight which is interacting with the lightweight database and because of that different the the processing is quite faster as well as the microservice architecture enables difference kind kind of data store technologies with respect to the different technologies basically applying the polygot performance and each development team can choose the persistence technology that suits their needs if you see on my on my screen service a is interacting with the Cassandra as a core application data as well as service b is interacting with a key value pair of a database which is for the difference data as well as service c is interacting with document database which is for the content and service d is interacting with the graph database basically if you see different functionalities are sitting in different microservices as well as these microservice are interacting with different data a smaller chunk of the data in the form of a micro databases and and as part of this example you can see different kinds of a databases as well basically one one microservice is interacting with the Cassandra and one microservice is interacting with a key value pairs as well as one microservice is interacting with document them kind of a kind of a services and the the another way the another kind of services are multimodal databases you can use multimodal approach it allows database to support more different kinds of databases if you see for instance you can see my the diagram which i have shown as part of the screen the service a service b service c and service d there are four different services and the first three services are interacting to the the core database and the service d is interacting with different uh uh graph database even though even though that the database is we basically the types of the database is completely different uh you can see service a is a Cassandra uh interacting to the database and service b is interacting to the key value and services interacting as as part of the json and service d is directly interacting with the graph database the multimodal approach offers what polycode persistence count but operationally it is a very simple when you only have a one platform it's easier to manage the system if each service has its own model of interacting with the data the polycode performance fits perfectly for the microservices and your application if the if your application is not too complex and it is better to stick for this kind of a mechanism and you can actually in in in hybrid kind of uh approaches you can combine both these uh this kind of uh uh approaches and uh we were talking about uh different different non-relational database models as well as we were talking about uh some of the multimodal and polycode models what kind of a database lies as part of uh these kind of a patterns uh non-relational databases is basically it is a no SQL or a no SQL kind of a different types of a databases if you see on my screen some of the uh widely popular no SQL uh databases I have given as part of uh this example like a MongoDB or S&R uh Neo4j or Redis kind of uh databases are widely popular as part of your non-relational uh relational databases and uh second kind of uh databases are uh document databases the databases uh the database of this type of uh store query data as a JSON like documents document databases offers and in due to data models and uh and basically the uh you don't have to uh run any joins or decompose data across the tables document maps the objects in the application code itself because of that uh the entire entire uh uh dependencies will be taken care in the application code itself and uh and since since document database are distributed systems they are easily scalable and document database are perfect for the content management and the storing storing catalogs and you can apply uh for the blog applications or e-commerce platforms popularly uh these kind of a document databases we call it as uh uh widely popular as a MongoDB or a uh Cloudant database or examples for the document databases and another another kind of uh uh databases key way key value databases uh which we used to write probably one ticket back uh the key value pair kind of uh uh operations or when we when we have implemented certain data structures uh these key value uh pair of our data we used to manage in the traditional old systems here also is the same same kind of operation mechanism it happens uh the key value data uh suits for the session oriented applications and uh there are some of the databases like uh Radish Amazon DynamoDB as well as Oracle NoSQL databases are widely popular uh for this key value pair kind of for databases basically the key will be assigned uh a unique key will be assigned to the data or a value and uh when when we have searched when when when the search criteria triggers automatically uh the value will be picked as part of the data and it will be visible to the end user uh this this is uh this is more more on the conventional method the key value databases there are certain data uh algorithms are available for uh for uh extracting the data and another another kind of uh databases uh graph DB basically graph DB uses the graph data models this is this is also uh we used to uh apply an in as part of our data structure methodologies uh which the data is uh is these data entities are connected in the in the form of nodes and uh relationship uh stored in the edges the main value of the graph is stored and uh navigate those relationships and it is quite faster as well as uh it is there is no uh unlimited uh relationships you can establish it with it and uh basically uh it is it is widely used for the fraud detection as well as social media networks and uh recommendation engines and some of the databases like uh orient dp new 4j or amazon nipchoo are popularly widely uh accepted in in the industry as part of the graph DB and uh and another another kind of uh uh databases are column-based database and relation databases column-wise uh based database uh data is stored in in the form of columns basically uh some of some of the pure uh database management systems will store uh this kind of uh databases you can you can use column-based uh databases building and uh data warehouse uh kind of uh tools and uh there are there are certain tools like uh apache kessender apache hbase are widely popular uh and and uh these columns store is a great solution for the big data uh processing and uh relational databases which we are talking about uh some of some of the these uh relational databases the data is uh stored as part of rows and columns and uh and this is this is a standard technique or uh uh the standard way of storing the data and uh some of some of the databases like a db2 mysql server or uh post-bis SQL or a rackle kind of uh uh application or databases are widely popular as part of this and uh a rational database is uh excellent fit for uh services that manage low volume of a stable data like uh high volumes basically uh the volumes are limited in case of a relational databases and uh drivers behind choosing a right database for microservices is basically uh there are different kinds of uh classifications or a categories which you can think of one is a fmr data basically the temporary data store uh which uh for supporting the user request as well as the caching techniques uh kind of operations you can use as part of fmr data and the second kind of a data is uh transient data uh which where you can store uh the logs messages and signals uh and as well as the time series data uh will come as part of the transient data you have to uh you have to choose a right database for uh uh right categories and also the operational data uh what kind of uh uh operation data you are storing as part of it and uh for this json graph or uh relational database are quite uh uh quite friendly as well recommended for this this kind of operational data and the fourth one is a transactional data which is having the uh uh acid kind kind acid kind of uh controls where uh the transactions will be happened and committed and stored as a persistent uh uh data records uh you have to choose uh on what kind of a data you are managing it or uh you are dealing with it and based on that uh a right for a right kind of a data right kind of a uh database type you can use it basically uh one of the uh one of the advantages with microservices are it can easily talk to different databases uh like like uh if you have a app model data you can use one kind of a database as well as when uh you are using the transactional data you can use uh another kind of a database uh and operational data you can use another kind of a database basically uh you have a quite uh you have a quite flexibility to choose your uh requirements and you can choose your own databases and coming to the uh recommendations and conclusions uh basically what we strongly suggest is uh basically uh give the choose a right requirements for the right right databases for the right requirements and it is it is not uh like a no SQL or we cannot say no SQL might be a right uh option or rational relational databases are the right approach uh as we discussed in the previous slide uh for the right requirements right database can be chosen and also you can give flexibility to the different the team capability as well and uh with that uh one is the implementation flexibility as well as the team flexibility you can achieve uh with respect to the my this microservices strategy thank you very much and uh it is a pleasure sharing my experience with you all thank you