Uh Hey, hi, Ron. Uh This is uh Shika Han Jura. And uh I'm presenting uh uh uh topic on uh microservices. Uh Well, I work as an engineering manager for VMWARE uh for the product known as VCFVM Ware Cloud Foundation.Uh So how I'm going through uh this engineering manager is uh around the microservices implementation. OK. So then uh uh let me start and give certain background on the, how does a company aligns on the strategic goals and what are the design and delivery principles? Uh When I talk about the strategic goals, uh the company really wants to move fast. Uh They want to basically enable your scalable business. Uh They want to enter the new markets and support innovation in the existing markets. Uh What are the design and delivery principles when I talk about design and delivery principles? Uh They are basically uh what are the agile uh methods they want to apply? Uh What are the eliminate integration, database and small independent services and continuous deployment.

So these are basically the strategic goals on which uh the company or an organization is moving and these are the design and delivery principles. So, uh generally, if the company wants to move fast and they want to have a, enable a kind of a scalable business. Uh Then there are certain design and delivery principles on which our architecture should get aligned. Uh Am I audible enough? Ok. OK. Thanks Laura. Uh This the, the, the thing I'm uh going over is uh ok. Uh I have spent a lot of uh ok. So let me uh give you a brief on how does my experience has evolved in terms of monolithic application. So I'll take you back in the history where we started uh building our monolithic applications way back in 2005. So the application used to start very small nimble and grown over a period of time. It used to run as a single uh thread or a process. And if you want to change one thing in a system, you have to basically uh rebuild the entire application. Uh When I say rebuild the entire application, it's basically you have to completely rebuild the entire web archive file or an enterprise archive file. And I'll take you a personal example where basically uh we were building an application for a big bank uh which is MX. Uh And then uh we had put the application in production, but the challenge was like uh there were certain middleware changes that we need to do. Uh So we had to bring the entire system down.

Uh build a small JSP page uh through which we are uh giving it. Uh It's like uh it's not available for some time uh build that page, bring the entire application down uh which is not the right way. Uh So this monolithic application existed for quite some time. And then there was an architecture pattern which was like service oriented architecture pattern uh which is defined as. So a uh the monolithic application were like cut, copy and paste. Uh When I say cut, copy and paste, the same architecture can be applied to different domains.

And when I say different domains, it could be a banking domain, it could be a financial domain, it could be an ecommerce domain or uh it could be a healthcare domain. Uh It was a similar and there was a transition in terms of like sla uh scaling the application. How do we scale and cut the application while layer there is a middleware layer and there is a backend service layer and this was entirely uh being developed by a set of engineers. Uh There was one of the major drawback in building this monolithic application was uh there were only a few set of developers who knew like uh this is the application uh they knew from the scratch. Uh So if few set of developers have onboarded while the application is being built of uh from scratch, uh Those are the set of people who knew about the entire application. And since now this application was huge. Uh It obviously takes a longer time to initialize that uh application. And if you have to change a small U I component and generally the UX experience evolves.

And if you have to change a small U I on a front end application, uh we have to completely rebuild as an er file as a war file and then completely deploy it. So this was my major experience has been with banking industry uh working across uh different banks as Bank of America and MX. And these are the set of applications I have seen over the period of time. OK. Uh Now, coming back, this was monolithic uh in the year of 2005 to 2008 and 10. Then the service oriented applications architecture came up. Uh Now coming to the what are microservices uh by the definition if we go, it is basically small autonomous services that work together and are modeled around the business to me. And when I say small, uh what do you mean by small uh small means? Uh is it the number of lines of code? Does that? Uh the small applies? Uh small means uh is it the team size not with respect to microservices here? The small word means if I have to change uh my microservice module uh does take me more than a month uh to completely revamp that module. So ideally, the word small here means if I have to change a microservice module.

It should not take me more than four weeks uh revamp that application. OK. Uh So that's the word small here means by word microservices. And when I say uh they work together and are modeled around the business domain. So there are two things that we need to very clearly understand uh in terms of business domain and the bounded context. And I have uh my further slides in terms of defining uh how does a business uh domain matter in a microservice architecture pattern? And what do you mean by bounded context? So let me just uh walk you through in terms of uh mm uh how does the microservices are modeled around business uh domain? Uh When I say business domain, there is a financial because I have mostly worked in the financial industry and now I have moved to VM Ware for the cloud applications. So when I say Business Domain, uh it could be a financial domain, uh e-commerce domain or uh health care. OK. And when I talk about, let me take an example of uh financial domain. Uh So you have customer, you have deposits, loans, rewards, investment payments and bill pay. Uh These are the different entities on which this uh uh business uh uh this financial domain is. And these are the language which the product team also talks about. And then there is a bounded context.

When I say investment under investment, there can be different sub entities on which uh the investment portfolio allies. So this is from the business side on which domain we are aligning. And what is the bounded context? When I talk about context, it means a kind of artificial boundary around which our entities should be aligned. So this is uh this is one of the principle on which the microservice architecture should be uh aligned is that uh we should, we should first identify in which domain we are working and what are the different bounded context. Uh What it will help us basically is uh once we define our domain and bounded context, our technical implementation will also look uh uh in a way is like aligned with these business languages. And with this, what happens, the rest implementations are quite stable if we define these rest implementations around the bounded context. Uh So before this is one of the uh eight principles uh around which the microservice architecture should be aligned is around the domain driven business uh design and the boundary context. OK.

Uh This, I'll take you uh example of uh where we had kind of had a culture of automation. So before we build on uh microservice, we I'll give you one example where we were building uh microservices for our financial applications. Uh We basically built two microservices over a period of three months. Uh We were good. Uh We were happy with the content and we delivered those two microservices over a period of time, we built another 10 microservices over a period of nine months. Uh We got another good confidence and then gradually moved into 60 microservices over a period of 18 months. Uh the flaw which uh we discovered uh uh during this uh progress and it was more of a hockey stick implementation from 2 to 10 to 7060 microservices. We have built over a period of 18 months. What we lost. Uh Here is uh we didn't put enough thought on the culture of automation. And when I say culture of automation is, do I have an infrastructure automation in place? Uh or uh do I still need to go ahead and raise a request to procure our machines? Uh Is my automated testing. The functional test, the unit test are in place and is my every code which I'm checking to uh my repository is a release candidate or not. So if you consider all these things, uh the idea that one of the uh second principle on which the microservices should be built is before adding your fourth or fifth microservice, uh You should build a culture of automation should be in place.

Uh We should be able to easily procure our uh machines or our V MS or our containers and every check in should be a release candidate. Uh This is super important because otherwise we are spending a lot of time in our development of building our new microservices. But we are not spending time uh in doing the infrastructure automation. OK. Uh The third uh principle that you should build your microservices is uh h your implementation details. Uh When I say hide your implementation details is uh let's say you have uh a microservice one and it is talking to a database and getting all the details. Let's say the database has uh payment related information and you have a microservice one which all this information. Uh Now suppose there is another second microservice which wants to get some additional details about the payment history or the transactional details. It also starts talking to your uh DB directly instead of talking uh and this is good if you have one or two microservice. But let's say if there are 10 microservices and all 10 microservices are talking to the TB. So instead of uh going and talking to 10 microservices to the same TB, and suppose there is a change in schema or if you want to change the column name, you have to go ahead and basically uh change all these 10 microservices, which is not the right way to do it.

Now, looking uh on the right hand side, this is the approach that you should take uh hide your most of your implementation details behind your microservice. And if any other service wants to get any information from microservice, one, it should talk to the service rather than talking directly to that database So this is a very critical uh I would say uh uh uh principle on which the microservice architecture pattern should be implemented.

Uh The services should interact with another service to get data internally from their back end database. They should not directly talk to the DB and get those details because if there are 100 microservices and if there is a change in schema change in the column or change of any, you have to bring the DB down and go ahead and modify all these 50 odd microservices. OK. Uh The next principle which I want to give you an example is uh deploy independently. Uh When I say deploy independently, the ones which I have put is uh the host uh could be a machine. Uh It could be a VM or it could be a container. Uh If you are deploying uh one service on a particular host on the right hand side, which I have mentioned. Uh And if you are dependent that the other four services needs also deployment on the same host uh fix that first. Uh Because uh it has a binded uh basically uh uh continuation that all five services should be uh deployed first on that host. On the left hand side, it should always be one microservice should be touched. And when I say host host here means like it's a isolated or isolated operating system. And uh it could be a virtual machine, it could be a container.

And during this time, the uh Docker technology came and kind of uh had a very uh good review on the Dockers, how they can be aligned with the microservices. So always deploy independently uh with a particular host or a virtual or a container so that they get uh an isolated environment and you are able to take these in the production. OK. Uh The next principle which I want to talk about is consumer driven contracts. Uh This is very important because if you are making one service uh ready for production, uh and there are a number of services which are dependent and you are making change, let's say to the payment service. Uh The consumer of the payment service should be aware uh are my expectations run uh against the payment service. So reward service has a set of expectations from the and these set of expectations are basically uh given as an executable in terms of unit test uh in terms of functional test to the payment service and these can be integrated in your C I CD pipeline. Uh So, in a way, uh when our change in the payment service is gonna get into production, are all my consumers being tested effectively so that I haven't broken any functionality.

Uh This is important because uh we are talking of fast changing environment, we are talking about the environment uh which needs to scale. Uh So any kind of expectations should be well, defined by the consumer. Uh so that the other provider of the service, when it is making those changes, it can run these expectations and then uh it can basically go and execute this as part of C I CD pipeline. So this is important, we define these consumer driven contracts. Here. I have shown like one expectation which the reward service has on payment service. There could be another service, let's say on the deposits or on the bill pay. Those also have a list of expectations from the payment service. They should be executed before the payment service goes and kind of deploys it in the production. OK. Uh The next thing is uh coexist endpoints. Uh There are cases where you have to break your uh customers and over the period of time, the versions of the service is uh gonna change and evolve from version one to version two. So basically, let's say I have a payment service which is on version one. And over a period of time, there are two me and uh there are uh enhancements or improved methods through which we can do the payment.

So we move to the version we do and how does the reward service know or how the any other service knows that it has moved from version one to version two. Uh Either we should give the end customer sufficient amount of time. Uh so that it is moving from version one to version two. And we have to uh basically keep both the code bases ready and uh give them uh as a repository in the G have both the uh uh code base uh available. And over a period of time, we can uh slowly move all our customers from version one to version two. Uh one of the important uh principles on which the microservices should be implemented is decentralize all of the things. Uh When I say decentralize all of the things of the number one thing is uh freedom uh freedom for the engineers to choose what is the tech stack they are building on. So this is super important in terms of uh uh the technology, the right kind of use case uh the right kind of tech stack, they want to build their applications on uh self-service. Uh There should not be a ticketing mechanism to basically procure your machines. It should be like self sufficient. Uh Initially, what we had is in terms of governance, we should, we had an enterprise architect who is basically uh seeing everything like how the architecture and the design are happening.

Uh Instead of that, uh there has to be a self governance or uh self-governing team of people who are looking what kind of uh implementations we are doing and what are the right strategies to do it. And there is a wonderful tool uh swagger in terms of having your uh uh swagger basically for your documentations and those things. So decentralize all of the things in terms of one of the principles on microservices. Uh This, I'll give you one very practical example in uh isolation of the failure. Uh So we were building an application and it was basically taking 30 to 60 concurrent request and uh it was talking to the downstream systems and suddenly one find the request reached from 30 to 60 to almost more than 900 concurrent request. So what was happening? The downstream one of the service was consuming more of the uh resources and it was consuming all the compute intensive resources. And during this time, uh the service uh slowly uh all the threads started consuming and redirecting to this microservices. One and it brought the whole of the application down. Uh It took a good amount of time to find out the root cause uh which is the service who is consuming the maximum number of resources. So it's very important that you isolate the failure.

What we did is like we fixed the timeouts. Uh The timeouts were really bad in terms of it were taking almost two minutes to uh get the response back from the downstream system. There was only one thread pool for all the service which was handling the concurrent request. Uh We fixed that and we gave multiple thread pools and uh to basically align with each of the service. And we also introduced certain kind of circuit breakers uh which were kind of in case there is an issue with one particular microservice, it disconnects from the other uh whole of the system. Uh while we are fixing it, it does not bring the whole system down. OK. Uh The one principle is on aggregation monitoring and observing uh the things which uh now that we know the other principles in terms of our uh bounded context, domain driven, hide your implementation details, uh deploy independently consumer driven contacts. And we have built this huge system uh which is over, let's say around 100 150 micro. And if there is an issue, how do we log those? So log is very important in terms of either you have a tool. Uh You can have a cabana as a log aggregated tool.

Uh You can have stats uh which are pulled uh uh as a uh and uh in terms of Splunk as this thing or uh you while we are building your sixth or seventh microservice, you have a correlation ID or um an ID basically which tracks all the way uh the request and the response are going on.

So this is important in terms of I would say in uh aggregating your logs, uh finding out the latency, finding out your performance, finding out um how the responses are coming from other microservices. So you are basically logging everything around your uh microservice path. Hm.

Uh Now that I have talked about on the principles of microservice. When do we actually have to use the microservice? The top most reason I would suggest is if the need is for uh scaling the applications. And uh when there is a need that you have to deploy multiple instances of the service, uh the business requirement is it should be highly scalable. Uh The microservices are the right art pattern, uh independent deploy ability. Uh You have to de and move fast in an agile world. Uh move to the new uh uh markets fast. Uh go ahead and independently deploy these microservices. And if you need organizational autonomy, uh giving full freedom to the engineers in uh thinking. Uh what is the right stack, the right technology. What is the right language we should use? Then we need to go ahead and have microservices here. I'll give you some um insight on like what are the advantages of microservices? Uh One is technology heterogeneity. Uh You can use any if it is if your use case demands of an SQL uh BASED database or uh if there is a need for no SQL database uh under no SQL. If uh if there is a need for document store or graph store, you can decide what is the right database, your service should talk to. And similarly uh from the scaling perspective.

Uh If you are thinking like uh for example, I have a microservice, let's say post uh pictures and friends and post should have only let's say two instances of the service running, uh pictures should have more instances of the service running and friends should have this thing.

You can easily tune these uh uh different instances uh for a particular service. So these are two important things in terms of technology, heterogeneity, uh resiliency. Uh and in terms of scaling, OK. Uh The parting words uh is uh what it actually gives you is uh it gives you more options and more decisions. Uh So you have an architectural design pattern uh where you basically have more options, more decisions. What is tech stack? Uh How do I want to deploy it? What is the automation I have to implement? Uh what is the consumer driven contracts? And it does not uh give you like you have to start a big bank rewrites, but a series of changes made to it. Uh So at the parting word, I would just suggest like change is inevitable, embrace it and microservices in case uh you have a small change in the U I application you have, you can just go ahead and change that scenario, uh employ it in production. Uh Thanks for joining this uh uh uh my presentation. And uh any questions, please free to add in the uh chat window. Thank you.