Transcript for:
Lecture on Microservices - Overview and Best Practices

Microservices is the New Age Technological Marvel that is used by today's Industries to create and deploy applications. So it's a great time for you to start learning about this trending technology. Hi all I welcome you to this Microservices full course and what follows is a session that will give you a complete insight to get you started with Microservices. So without further Ado, let's take a look at our agenda for today. So we're going to start with introduction to Microservices where we will discuss what microservices are their benefits and how they differ from other architectures next. We'll talk about micro services with other Technologies such as Docker and spring boot later on we'll compare microservices with other service-oriented architectures and talk about Microsoft versus with API moving on with our session. We understand how different design patterns can be followed to create applications using micro services. And then we'll talk about what tools can be used with Microservices. After that. We look into the various ways through which we can secure a micro Services applications. Finally towards the end. We'll talk about the top interview questions of micro services that will help you Ace your interviews with that. We come to the end of today's agenda. Now before we begin kindly take out a second to subscribe to our Edureka YouTube channel and don't forget to hit the Bell icon to never miss an update on the latest Technologies also, so if you're looking for an online certification training on microservices do check out the link in the description box below on that note. Let's get started why we need Microservices so before microservices, We all know that there is an architectural pattern called more of the architecture that was used. All right, so there are certain disadvantages of that architecture. But let me first explain you that architecture what exactly monolithic architecture means so basically in this the Ty software is composed in a single piece that is designed to be self-contained. So what I mean by that basically all the components of a monolithic program are interconnected and interdependent or in other words, if I have to put it I will say that it will give you a tightly coupled software where each component along with its Associated components must be present in order to execute or compile the code. So all of these components are actually dependent on each other. So if you notice a definition that is there in front of your screen, it says that most of the carcass Picture is like a big container right think of it as a big container where in all the software components of an application are assembled together and tightly packaged. Right? So if you notice that there is an example in front of your screen, so there's a server-side application, right which executes a domain specific logic it will retrieve an update data from the database and at the same time populate. The HTML view is to be sent to the browser. So it is basically a big container or I can say that it is not divided into small small services or not divided into small small components. So even these components that are there. Are pretty tightly coupled right? So I will give you a better example of what exactly monolithic architecture is. Let me just move forward. So let us discuss a classic example of an e-commerce website like Amazon and Flipkart. All right, so everyone actually visits these websites quite often. So that's a perfect example to you know, explain so let's understand what monolithic architecture exactly means with this example. So as you see that in basic e-commerce application, we have common option of customer service, right products. Service and card service which a customer can access through their browser. Right? And when you launch the application, it is deployed as a single monolithic application. There's only one single instance if you can notice so we have customer service product service and cart service and when you deploy all these Services, it will be basically a single monolithic application. Now, what you can do is in order to scale it you can run multiple instances of this application behind a load balancer right now. Let me discuss few advantages of this application. So first of all it is Very simple to develop right as a goal of the development Tools in IDs is to support the development of Monolithic application. It makes a development really easy and One Direction. All right now is pretty simple to deploy because you have to deploy the executable file at the run time to launch the application that executable file can be a word file is there now this very simple scale as well because you know in order to scale your application. All you have to do is run multiple copies of the application behind a load balancer now since everything comes with its pros and cons monolithic architecture. Also has few major drawbacks. Let's discuss about them one by one. The first disadvantage is large and complex applications. Now if you have a large application or you can see with the increase in size the application, it becomes really complex to understand and modify such applications. Right and as a result development slows down and modularity breaks down over time more ever because it can be difficult to understand how to correctly Implement a change and due to that the quality of code declines over time. Let's see what is an excess Advantage. So the next disadvantage is slow. So what I mean by that as the application and the respective teams grow the application becomes difficult to understand and modify right because it's pretty huge in size and there are multiple teams working on it. So it becomes really difficult to understand and modify also the larger the codebase leads to slower ID, which makes the developers less productive. So the code base is pretty large because the entire application is one monolithic application, right? There are not different if it's overseas present not blocks continuous development. So what I mean by that a large monolithic application is An obstacle to frequent deployments. Let me tell you how in order to update one component. You have to redeploy the entire application which interrupts the background task. So if I have to take the example of the e-commerce website if I have to update the card service, I have to redeploy the entire application the entire application which includes the customer's always a product service all these Services right? So there is also a chance that components that haven't been updated will fail to start correctly. Alright, because of many dependency issues or anything, right and as a result the risk associated. Redeployment increases which discourages frequent updates. I hope you are getting my point. Let's see what we have next. So the next point is unscalable. I know I've told you that it's pretty easy to scale. But let me tell you what are the disadvantages when it comes to scalability and in terms of Monolithic architecture. So each copy of application instance will get access to all the data, right which makes caching less effective and increase memory consumption along with input/output traffic also different application components have different resource requirements. One might be cpu-intensive right while other might be Memory intensive and with a monolithic architecture. We cannot scale each component in dependency, right? So if you can see the example that is there in front of your screen. So here we have customer service product service and guard service is one instance. And this is how we are scaling it. Right if I have to increase only the customer service after scale up the customer service. I have to do that for product and cart Services. Well right now it is pretty unreliable as well. Let me tell you how so because of the tightly coupled components if one of them. Goes down the entire system will fail to run what I mean by that. If one of my say production of space that will in turn lead to the downfall of my entire application, right and because of all the modules are running within the same process a bug in any module can potentially bring down the entire process more ever since all the instance of the application are identical the bug will impact the availability of the entire application. This makes the monolithic architecture highly unstable and unreliable. The last in the final point is inflexible. So how is it inflexible guys with the monastic architecture becomes really difficult to adopt a new Frameworks and languages suppose you have million lines of codes written with XYZ framework. Now, it would be extremely expensive in terms of time as well as cost to rewrite the entire application to use the newer ABC framework, right even if that framework was considerably better and as a result, there is a huge barrier to adopting new technologies. I hope you're getting my point. So why is it very expensive because you know, you have written million lines of code in some language now you To use some other language, right? So it becomes really expensive and time-consuming task. And even if the new language of the framework is considerably better but you know, there's a huge barrier in adopting such new technology. So I hope you have understood the various disadvantages of Monolithic architecture now is the time to understand what exactly is Microsoft with architecture microservices also known as Microsoft is architecture is an architectural style that structures and application as a collection of small autonomous services. Modeled around a business domain now if I have to put it in simpler terms. Basically it is a self-contained process which avails different and unique business capabilities. Now, if you have large applications built using this architectural pattern, it can be broken down to small multiple Services which together access one large system but behind the scenes, it's a Microsoft Office. So what I am trying to say here is we have multiple services on all of these Services, they don't share the data structure, but they will be communicating through apis, right? A major advantage of breaking down the system is now each microservice can focus on only one single business capability which definitely leads to a better quality and throw and it's obviously becomes easy for you to understand when I explain you with a example again, I'm going to take the e-commerce site example. Now if you remember in monolithic architecture all the components were in a single module, but if you see here with Microsoft is architecture all the components are divided into separate modules, which communicate with each other using a well-defined. Interface usually rest our messaging now the communication between the micro Services is a stateless communication where each pair of request and response is an independent transaction and because of this microservices can communicate effortlessly moreover in Microsoft's architecture. The data is Federated. All right. So let me just break it down for you. Each microservice is responsible for its own data model and data because of which interaction with each microservices handled by different instants and like in monolithic architecture where we had only An instant head we have multiple instances for different different microservices. So we have three microservices here customer Microsoft waste product Microsoft which and card Microsoft's right? Each of them have their own instances. They have their own data model and they have their own data. So this is what exactly Microsoft's architecture is. Now, let's dig a bit deeper into its architecture and understand what it is. Now as you can see in a Microsoft is architecture so which is a small independent and Loosely coupled. So, let me just tell you where it is. So with these are multiple so which is right these A pretty small in size and they're independent and Loosely covered now each of these Services have a separate code base, which can be managed by a small development team and it is deployed independently, right? So this service will have a code bases service will have a code base. The service will have a code bit. Similarly. All of them will have a code base which will be not huge in size. And when you compare it with the monolithic architecture, all of these services are running in one instance. I hope you are getting my point now basically a team can update an existing service without rebuilding in deploying the entire application. For example, if I have to update this particular service, I Have to do it for the other services as well. I can just read deploy this service independently now services are responsible for persisting their own data or external State internal implementation details of each services are hidden from other services moreover. They don't need to share the same technology stack libraries or Frameworks is well, right you getting my points. They might not have the same technology or same libraries of the same framework and they have their own database and things like that. So they are pretty independent from each other besides for the microservices themselves some other components appear in typical Mike. Service architecture. So let me just discuss that so the first part is management. So the management component is responsible for placing services or nodes identifying failures rebalancing Services across nodes and so forth right then let's talk about service discoveries. Now service Discovery the task of this component is to basically maintain a list of services and which nodes are located on it enables service look up to find the endpoint for a service. Let's talk about API Gateway now, right so API Gateway is The entry point for clients. So this client won't call all the services directly write will first go to this API Gateway which will forward the call to the appropriate services on the back end, right if I'm a client I'll request for this particular service then after call the API Gateway and which will in turn call the service on the back end now the API Gateway might aggregate the responses from several services and return the aggregator response. Now, it might be possible to write a client request for multiple services. So at that time it will aggregate the results from various services and Turn the aggregated response. Right? So I hope I am clear with the architecture. Let us focus on what are the features of Microsoft has architecture. The first feature is small focused. So what it means it means that the aim of microservice Architecture is Simplicity, you know, so that it can be re-written in maintained without any extra efforts by the development team, right? That's what I mean by small focused. The next point is Loosely coupled. So as I've already mentioned multiple times at each microservices independent of Each other and do not need to coordinate as well. This makes a development as well as a deployment it real quick guys, right? So if I have to update a particular service, I'll only update that so which I won't, you know, update the other services rights that way deployment becomes really quick. So that's the big Advantage now, let's talk about language neutral. So to be a good microservice, it must be language neutral. So what I mean by that for example in an application few Services can be written in Python for fast deployment. Whereas few might be written in Java because its speed and extensive libraries. Right. So depends on the Microsoft Office what kind of programming language we are using so it doesn't really affect the other services right now bound it context. So it means that each microservice doesn't need to understand the implementation of other Microsoft's so these are few features of Microsoft's architecture. Now, let's talk about various advantages of microservice architecture the firstly independent development. So each microservices can be developed independently where a single development team can build test and deploy service. I don't need to explain this much independent development means if I have a product service and I can independently focus on product service where a team of developers are writing code for that particular service testing it and deploying it now independent deployment means that you can update a service without having to redeploy the entire application bug fixes and feature releases are more manageable and less risky as well because you have to focus on one particular service. You have to deploy update one particular service. You don't have to care about the other service or the entire application as such right? So next is Vault isolation. So it is a very big Advantage guys. It's basically if a service goes down, it won't take the entire application down with it. For example, if my card service goes down. My entire application is largely unaffected unlike the monastic architecture where if one of my component goes down the entire application fails to work next is mix technology start because of this feature teams can pick any technology which fits best for their service right and last but not the least granular scaling which means that Services can be scaled independently unlike my monastic architecture where you know after A couple instances. So in order to scale are I can only scale a particular service if I have to you know, increase the card service then I can just scale up the card services instead of scaling up the entire application. Let's let's move forward. So there's a lot of companies which are using Microsoft which is we have Amazon Netflix. SoundCloud Twitter Who board PayPal lot of companies, right and why this happens because the applications become easier to manage when they're broken down into smaller composable pieces. So without any further delay, let's begin with our hands on will be using spring boot because it provides a a way to provide Java applications quickly and simply through an embedded server and by default. It is version of Tom cap. It will basically eliminate the need of java ee containers and which springboard we can expose component such as rest Services independently exactly is proportionally Microsoft is architecture that we have just discussed in any maintenance of the components. We no longer make the redeploy of its consumers. I'll tell you what exactly I mean, what is the consumer for this lab will be use Eclipse oxygen and Maven 3? Now to illustrate the concept of microservice. What we will do will create 3 Maven projects in this Hands-On and each of them will symbolize back and functionality or you can say reusable apis and one of them held a composition fair to put it in simpler way. I will say it will be a consumer of the other two. So one application or one service will be a consumer of the other two Services, right? So we'll be creating three simple Maven projects that I've already done. I'll just open my clips and show you that so my first Maven project is basically diagnosed with Microsoft. He's then we have dr. Microservice and we have patient microservice. So this doctor microservice is the consumer right and consumer the other two microservices that is patient and a diagnosis. Alright, so that is how it is done. Now if I have to explain one of these Services, let me explain to the patient microservice first so over here as you can notice that we have a palme D'Or XML file. So basically this bombed or XML file will stablish all the dependencies right before we start coding the first class that we create that we call. Negation will be identical in all three projects and it only works as an initiator to Spring boot that we call a Spring boot application annotation. So that's how it is. If you notice here, we have application or Java. So it will be common application or Java and application configuration or Java the two packages that we have created will be common for all the other Microsoft uses as well. So if I show you a doctor's is well now here also, we have application or Java and application config dot Java similarly for diagnosis. As well. If you notice we have both application or Java and the other things as well. Now, we have patient or Java and we have patient rest dot Java, right? So the patient Java here, we have defined all the variables like, you know, the email ID of the patient name and things like that and this patient rest dot Java will be used to provide the input the variables. I hope you are getting my point but a patient rest or job is basically to provide the input. I won't be explained in the code here in the upcoming tutorials. I'll be explaining the entire Microsoft which you know, how the code works and I think all the technical details you can find the next tutorial and this I'm just giving you an overview of how things work in Microsoft versus and we have this application config class as well right the package. So let me tell you why we actually use it is basically it is a resource configuration class, which is basically a resource manager responsible for exposing rest services for application consumers, right so basically for messaging right so the rest services for messaging and it is a stateless service for application consumers and we can notice a patient or Java and giant rest or Java are in the same package right now. Let me tell you how I've defined a ports here. So all I have to do is right click go to properties click on run debug settings. I mean I go to arguments right so I just have to write - the server dot Port 8:08 one so you can see that my patient Microsoft is will be running at a 14-0. It was when I started let me just start all these Services one by one so I'll start this first. Let's click on run a spring boot app similarly click on right click on this and I'll just run it as spring boot up again, and I'll run this also as a springboard app. So does that now? Let me just open my browser. All right. So this is for Port 8:08 one writes my poor a zero eight one is for patient to let me just click over there. Let me reload this page again. So here I have my patient Microsoft is similarly. My poor a0 A2 is for diagnosis, right so are high of the diagnosis microservice and finally my port 8 0 8 3 basically is a consumer. All right. It's a doctor microservice and in the URL if you notice I have written. Patient ID right diagnosis and consultation, right? So basically we'll get you know, this particular patient has been diagnosed with this disease and this is the consultation right? So, let me just reload this again for you so I can just go ahead and change the diagnosis as well. I can make this as to write sobre child has been diagnosed with a different disease now similarly if I make it as one she has been diagnosed with viral fever here, right? So that is what the difference is. Basically this particular Microsoft which is a consumer of the other two Services, right? So you can even think of it as an e-commerce application. I know it's not of that level but consider it something like, you know customers production orders. So this patient Microsoft which will become the order Microsoft's right and the other two will become customer and products. So this order Microsoft will be a consumer of the product and customers a similarly in this example. We have patient and doctors we have patient. My resolve is and we have diagnosis Microsoft OS and we also have Doctor Microsoft Office, which is actually a consumer of the other two service. Today, I'm going to discuss Microsoft versus with spring boot. So let's move forward and have a look at the agenda for today. So this is what we'll be discussing today. We'll Begin by understanding. What are the various challenges with the microservice architecture after that will understand. What is the need for spring Boot and how it overcomes the challenges of a microservice architecture. Then we are going to discuss a use case that we will Implement practically in today's session and I will also tell you about what are the various tools required in order to execute that use case. So let's begin guys will first start with what are the various challenges with microservice architecture. The first challenge that we are going to discuss is called perceptibility. Now as we know that in a Microsoft is there are small components to deploy and maintain and there are many of them. So there are many small components that we need to deploy and maintain and at times it becomes very difficult guys to Monitor and identify problems, right if I take the classic example of an e-commerce website so over there we have multiple small small Services running for example the card so which it can be the product service or the customer service. So there are multiple Services running and we need to deploy and maintain those services. So at times it becomes very difficult to Monitor and Aunt if I problems so what we require we require great perceptibility around all of these components. The next challenge is configuration management. Now, there is a great need to maintain the configurations for the components across the various environments because we have small small components, right the idea behind microservices to break down a notch break down an application into small composable pieces that can talk to each other. So we need to configure these components across various environments. That is also a very big challenge guys. Now the next challenge is debugging now, it becomes very Difficult to probe each and every service for an error, right? So you have multiple Services running now to debug error in each of those Services is very difficult. So what we need, we need centralized logging and dashboards to make it easy to debug the problems, right then an excellent that we are going to discuss is basically consistency now think about it guys. You cannot have a wide range of tools solving the same problem, right? And we know that it is important to Foster Innovation, but we also know that it is also important to have some decentralized governance around The languages platforms technology and tools which are used for implementing or deploying or even monitoring the microservices, right? So I hope you are getting my point. So maintaining consistency is also a very big problem. Now, the next point is automating the components. It becomes very difficult guys to automate everything because there are a number of smaller components instead of a moonlit that is built deployment and monitoring. So in order to automate this entire Cycles, it's very difficult. So these are the challenges with the micro service architecture now, let us see the solution so It's spring boot now spring boot enables building production-ready applications quickly and provide many non functional features. Let me discuss few of them. So the first feature that I'm going to talk about is embedded servers. So these servers are easy to deploy with the containers. Then the next point is it helps in monitoring multiple components. So you have various various components are various Services running. So in order to monitor those Services we can do that with the help of spring boot then and finally it facilitates in configuring the components externally, so we saw whatever the Changes were right the consistency perceptibility configuration management Automation and all the challenges that we have just discussed were completely removed with the help of spring boot. So let's move forward and now we are going to focus on how to build a top sports bra. So this is our use case guides will be building a top sports brand. Let us see how we are going to do that. So in this pre-boot microservice example, we'll be creating top sports brand application, which will have three sources so you can see it in the diagram is well, so we have three services here one is Eureka's over then we have item catalog server. And then we have a church service. So these are the three services that will be running now. Let me discuss each of these one by one. So the first thing is Eureka service now this service will register every microservice and then the client microservice will look up to the you take us over to get a dependent microservice to get the job done for I mean by that is a user will approach this Eureka service which will have the other two Services registered with it. So this is basically called a registry service in this industry service. We have the other two Services already registered so based on what the user. Zur want Eureka server will get a dependent microservice to get the job done. So I hope you have understood that now let's move forward and we are going to focus on what our item catalog service. So item catalog service will generate the list of sports brands which are popular in the market. So whatever the list of sports band rather popular it will generate that and then the edge service is also pretty much similar to the Standalone item catalog service. However, it will have fallback capabilities which prevent the client from receiving an HTTP error when the service is not available right now. We have understood this architecture. Let me just repeat it once more. So we have a Eureka service which is owned by Netflix. And this is basically a registry service and we have the other microservices registered in this service. The item catalog service will have the sports brands. Then the edge service will basically give us the op sports brand will filter only the top sports brand. This is how the architecture of our a spring boot application is. So we have given the numbers as well in the diagram. So the first thing is it will register the other two applications in Eureka service. So first will register the eye. Item catalog then we will register the edge service then will produce a sports brand names item catalog service and the edge service will filter only the top sports brats. So this is what is going to happen in today's use case. Now. Let us see what are the tools I'm going to use. So I'm going to use Java 8 Eclipse IDE oxygen and the spring tools. So let me just quickly open my Eclipse IDE, and I'll explain you the code there. So this is my Eclipse IDE guys and over here. I've already written the code in order to execute the use case. I'll just take give you a walkthrough of what I've done here. So I have all the He's always had that I mentioned in the slide. So we have Eureka service. We have H of s and we have item catalog. So start with Eureka service first. I've already written it. So I'll just quickly show you how you can do that. Click on new over here. Go to other and over here select spring starter project click on next and just a couple of minutes and then just give the name to your service and then go ahead and click on next and the dependency. So we want the Eureka server as a dependency in this finally click on finish. So that's all you have to do and real fine you Lakers over already created? And over here, the first thing that I wanted to show you is application properties so over here I've mentioned the port I've modified it a bit. So what modification I've done I modify the file to add a port number and I've disabled the registration the port number is eight seven six one and this and I've disabled the registration right next what I'll open, I'll just open your a car service application dot Java, right? So for that so this is the file that I was talking about and over here. I've added a couple of notation forces enabled you. Above the spring boot application. So this Eureka server that you are seeing. I've added that above the spring boot application. Right? So this annotation will configure a registry that will allow other applications to communicate since I want the other applications obviously communicate with it. So it will basically configure a registry and it will allow the other applications to communicate so that's all for Eureka service. Let me just go ahead and quickly run it to show you how it looks like in the browser. So I'll just click on run as a springboard application and you can see that it has started running out. Ready, and I'll just quickly open my browser and at Port eight seven six one so you can see that Eureka service is running at Port eight seven six one, but currently you can see there are no instances which are registered with Eureka. Right? So we need the other two services to be registered here. So this is it for Eureka server. Now, let me talk about item catalog. So for item catalog, what we need to do is again click on new. Go to other spring starter project. Like we have done it in Eureka Services. Well given name whatever name you want to give them in the dependencies are a lot of dependencies that we need to import. So let me just talk about that. The first thing we need to import is an actuator, right? So we need to click on this and we need to import this. So what is an actuator it is a feature that will help us to Monitor and manage our application after actuator. I need to import Eureka discovery. Yeah, so I need to import this Eureka Discovery for Service registration since I want my service to be registered in the Eureka server. So for this I need to impose this particular dependency. Then I'm going to import jpa which is basically to save or retrieve data after that. I'll import H2, which is an in-memory database. All right, then I'm going to import the rest repositories. I did these repositories are basically to expose JP repositories as rest endpoints. Then I'm going to import web. Alright, so here we can see that we have web here. So web will basically is nothing but staying Embassy and embedded Tomcat then I'll import Dev tools they have tools. All right. So this is to Auto reload the application when there's any change in the file. Now, I'm going to import lombok in order to you know, just to reduce the boilerplate code. So since I've already done that I won't create another project here. Another service are basically so let me just give you a walkthrough of the code that I've written here. So first, let me show you the item catalog. application dot Java file So this is how it looks like first of all the couple of annotation. So enable Discovery client is basically to register my application in the Eureka server. Then we have a one more annotation springboard application. Right? And so after that what I have written, so this is my main class. All right, the main class will be executed for some application and this is responsible for item catalog execution the item catalog application execution. All right, then I have purel notations at the rate data all argument Constructor. So in order to explain You that let me just tell you what a Droid data is a convenient shortcut annotation that bundles the features of to string, you know equals and hashcode getter Setter required argument Constructor together. Alright, so people who are familiar with Java know all these annotations then the second generation I'm using is all argument Constructor generator. So basically it will generate a Constructor with 1 parameter for each field in your class. All right, so Fields marked with at the rate not null result in a null checks on these parameters, then we have no argument Constructor will generate a Constructor with The no parameters. Yeah, after that we have at the rate to string. So it will also pretty easy. So either a tostring is basically, you know, it gives you the facility so that you don't have to start a debugger to see your Fields. You can just let lombok generate a tostring for you and then the entirety is basically is a lightweight persistence domain object typically an entity represents a table in a relational database and each entity instance corresponds to a row in that table. So the primary programming artifact of an entity is the entity class. Although entities can use Helper classes as well. So this is about the annotations. So the next thing that I'm telling you about is a parameterised Constructor of the item class. So let me just write that here as well. So it is a bad a meter erised Constructor of the item class. And here we are defining the class members along ID and the string name. So next we have a repository rest resource. So basically we have an interface item repository that we are extending with JP repository over here what we are doing we are defining an implementation of the command line. Runner interface that we need to override the run method and this method will be executed after the application context is loaded and right before the spring application run method is completed. So this is basically generate the key value pair using the for each Loop and we are basically overriding the run method to print our key value pair. So that's what we are doing here. So, I believe you have understood this code or people who are familiar with Java for them. It's not a tough task, right? So it's a pretty basic code. So let me just say we are creating an item entity a JP a repository for it and we are also creating a command line burner to populate database with the default data. All right, so that's what we have done here. Now let me go to the application dot properties and I wanted to show you a couple of things that so yeah in this application dot properties what we have done. We have added an application name in the file to display the Eureka service and set the port to 8:08 it now also in the cloud properties file. So let me just show you the cloud properties file as well. So you need to add all of these things in your Cloud properties file is well. So this is the Eureka instance hostname. Then we have the non secure Port mention here the metadata map to the instance ID. Over here we have it. Then you record or instance lease renewal interval in seconds is 5 then Eureka client region, the default reason registry fetch interval seconds is we have given it as 5 so all of these things will be available with you. If you can mention your e-mail ID in the comment section, you can find the entire code there. So mention your email ID in the comment section and will reply with the entire code use in the video since I've configured Port 8:08 to let me just go ahead and quickly run this first I'll clean it using Maven. So I'll just click on Maven clean. And now I'm going to build it using Maven again. So just click on run as go to. Maven build over here type string - boot: run and just hit enter. So let me just go to the you rake us over. Let me just refresh this link one, right so you can see that item catalog Services already registered my Eureka server now. Let me just go to the port 8:08 to / items So it is displaying basically all the items present in my item catalog servers, right? So let's just go through it. It's pretty easy guys. So we have the name of the sports brand right then we have again a bad boys. And you have Air Jordan Mike added us although sports brands that we were talking about and the size of the page total elements and everything. You can have a look and just play around with it. So I'll just go back to my Eclipse IDE once more so now we are going to create an edge service now add Services have told you it is pretty similar to the Standalone item. So we That we have created. However, it will have fallback capabilities which will prevent the client from receiving an HTTP error when the service is not available and how we are going to do that similar fashion. Like we have created item catalog. All you have to do is click on file go to new. And go to other select spring starter project here. Click on next give a name to your service. Whatever name you feel like then go to next then over here. We need to add dependencies. So let me just tell you about that. The first dependency we need is Eureka Discovery. So just type here Eureka Discovery select that right. So this is basically for Service registration like we have done in the item catalog Services. Well, so this will be registered in my Eureka solo. Then we are going to add a fiend dependency. Let me just type that first. So yeah. Let's begin dependencies. Basically a declarative web service client. All right, and now once it is done, we are going to add Azul. So basically zul is provides an intelligent routing system. So just click on Google as well. Once that is done. I am going to import rest repositories. So these rest repositories are have told you earlier as well is Bill expose the JP repositories as rest endpoints then I'm going to again ADD web as well. So I've done that in the item catalog as well. So just click on web. It is basically a spring MVC with spring MVC architecture and embedded Tomcat. Right? So like we have MVC and MVP architecture then I'm going to type in here hysterics. So this historic just let me just check it once yeah, so it is a circuit breaker to stop cascading failure and enables resilience, right? So that's what it is used for then let's go ahead and add one more dependency. That is lombok. Lombok is basically to reduce the boilerplate code that I've done in the past. U.s. Project as well. So I'll just click on cancel because I have already done that. You can just go ahead and click on finish and you will find the HOV is present here something like this, right? So now let me just take you through the edge Services well. We know that the item catalog Services running on Port 8:08 to so what we need to do. We need to configure this application to run on a different port. Ah, now, this is pretty obvious guys, right? So let me just open this application dot properties and you can see that I've configured at Port 8 0 8 9 right and I've given the application name for a similar reason basically to add my service in the Eureka. So right now I need to create the cloud properties file that I've already done right? You can see it over here the cloud properties file. It is already present. I need to add some code here that I have done it in the item catalog Services. Well, so this code you can again find it once you you know ba mention your email ID in the comment section will reply you ASAP with the code. All right. All right. We just open Edge service application dot Java file so that I can find it here right now in order to you know enable Fein hysterics and registration with the Eureka server add the appropriate and notation. So what are the properties that annotations? We have enabled the inclines. We have enabled circuit breaker we have discovery. Giant Zuul proxy and springboard application obviously, right? So these are the annotations that we are going to use and after that let me explain you the code. Although it's pretty simple guys people who know Java will find it really easy to understand. So this is again the main class which Java will basically execute the first in my application, right? Then I have a couple of Getters and Setters methods defined here. I have an API adapter that will return the array list of our items and the finally in see the public collection item good item that you can see it in the end. Yeah, this is basically for collecting items and adding it into a list. Finally. This private. Boolean is great item. This will return true and false if the item is not available for a particular brand. All right, so this is pretty easy guys now over here. I've created a D2 now. Let me just take you through the core once more. So if you notice here, I've already created a dto and item detail which means data transfer object in this same file and at the long box at the rate data will generate to In methods we Getters and Setters the appropriate Constructor. All right, then I've created item client interface. So if you scroll down you can see that we have an item client interface so we can see that we have an item client interface that uses Fein to communicate to the item catalog server. So we have talked about item catalog service. So this item client interface will use steam to communicate with the item catalog service. Right? Then we have a rest controller below the item client so over here we have the rest controller that will filter out. Less than top brands and shows a top brands endpoint. So slashed our top brand endpoint. So it will filter out the Brand's right it will it will add a filter to all the brands that we have in order to get the top brands, right? So that's what the rest controller will do. Now what I'm going to do, I'm going to start this service for you. So I have configured this service at Port 8 0 8 9. So, let me just quickly go ahead and run this for you. I'm going to first click on run as Maven clean. So I'm going to quickly run this as a springboard. Up and let us see what happens. All right. So let me just quickly open the you take us over. Right and I'll just refresh this and you'll see that there are two instances currently registered with Eureka, right? So you can see that there are two instances currently registered with Eureka. Now, let me just quickly go to a particular oat. That is a 0 8 9 so I'll just type in here localhost:8080 9 / top - brands. And here we go, so we have got the top brands. So we have lining Puma Bad Boys in Air Jordan right now. What I'll do, I'll just quickly shut down the item catalog service application for that. Let me go back and I'm going to shut down the item catalog application. So this is what we have done in this particular use case. Now if we shut down the item catalog service application, you'll get a 500 internal server error, right? So just go ahead and try it yourself and let us see if you get that or not. It's pretty easy guys pretty basic application that we have. He added but a lot of things to learn from today's session. I'm going to focus on Microsoft restraining. So without any further Ado, let us move forward and have a look at the agenda for today. So this is what we'll be discussing today. We'll Begin by understanding. What is the use case that we are going to implement in today's session after that. I'm going to tell you about the few Basics which are required in order to execute that use case. Like what exactly is microservice? What is monolithic architecture? What is darker and how Docker can be used in Microsoft? Isis and finally I'm going to tell you how to implement the use case using Docker after that. I'm going to discuss the course content of microservices training provided by a director. So let's move forward and we'll discuss the use case that we are going to implement in today's session. So this is a problem statement of I use case guys. We have a node.js application and mySQL database running in the same instance or you can say in a local laptop. So this is a typical example of a monolithic architecture. So let us just focus on few problems with this architecture and then we'll see what is the solution to it. So let us now discuss the problems associated with this monolithic architecture. I'll just give you a small introduction to all of these challenges later on. I'll discuss it once more when I'm talking about monolithic architecture. So I hope that is fine with you all. So the first thing is large and complex applications. So if the size of our application is pretty large and it becomes really complex to understand and modify such applications when you use a monolithic architecture, you'll actually understand that when I'm talking about monolithic architecture in detail, you'll understand why are these problems there with such an architectural pattern? Then it also leads to slow development as the application in the respective teams grow the application becomes difficult to understand and modify and also the larger the codebase it leads to slower ID. Then at the same time. It blocks countenance development as well and it is pretty unscalable. So each copy of the application instance will access all of the data which makes caching less effective and increase memory consumption and input-output traffic also different applications components have different resource requirements. For example, Euro one might be CP. Pensive while another might be memory-intensive. So with the monolithic architecture we cannot scale each component independently, then it is pretty unreliable because of the tightly coupled components that we have here. All right. So if any of the component goes down the whole application will fail to run and then finally it is inflexible as well. So with more literature architecture, it becomes really difficult to adopt new Frameworks and languages. So this is the problem statement of a use case guys. Let us see what are the solution to such a problem. So it is nothing but Microsoft has now what I'm going to do here is I am going to To create two separate Services one called user service. Another is test database running on different Docker container. All right. So with this what we have we have separate services or you can see we have separate microservices compared to a monolithic architecture that we had just seen so what I've done here is this monolithic architecture where my node.js and MySQL were running on the same instance. I've divided them into two separate microservices one is user service. Another is test database and both of these obviously are running on a different doctor. And then so this is nothing but an example of Microsoft Office. So this is a use case that we are going to implement in today's session guys. So now we are going to compare before and after Microsoft's is basically we're going to find out the differences between the micro services and a monolithic architecture. So let's begin guys. So let's take the classic example of an e-commerce website now from the diagram also, we can observe that in the monolithic architecture. We have all the features running at the same instance. For example, we have customer service. We have product service we have card service, right? All of these instances are Lying on a single instance and sharing a common database. All right. So this is a typical example of a monolithic architecture, but then with microservices each feature was allotted a different micro service which handles their own data and performs different functionalities. All right. So this is the basic difference between the monolithic and Microsoft's architecture. So the idea behind Microsoft, which is that few applications become easier to manage when they're broken down into smaller composable pieces that talks to each other. So that is what exactly microservice is. Let's move forward and we are going to focus on I guess always architecture. So we are going to discuss it in much more detail. So let me discuss this architecture with you now over here. We have different clients coming from different devices and they're trying to use services such as search build configure another management capabilities. Now, all of these services are separated based on their domains and functionalities and a further allotted to individual microservices. So you can see we have microservice a b c and d probably this is for your search service. This is for your build services for configure like that. We have many other services as well. Now these microservices have their own load balancer and execution environment to execute their functionalities and at the same time captures data in their own databases. So microservice a will have its own load balancer and execution environment and we'll have it its own database as well similarly for other microservices. Also now all the microservices communicate with each other through a stateless server, which is either rest or a message bus now the all the functionalities performed are microservices are communicate to the clients by API gate when a client gives a request it will first go to the API Gateway and all the internal points are connected from this API gate. So anybody who connects to the API Gateway automatically gets connected to the complete system. So I believe guys have given you a good introduction to what exactly are microservices. What is monolithic architecture why we use Microsoft Office is what are the various challenges with monolithic architecture. Let's move forward and now we are going to discuss what exactly is darker now, what is the occur if I have to give a definition I would say At its heart the docker is a software which lets you create an image image is nothing but a template for a virtual machine and then run instances of that image in a contain. So that's what Docker is. Alright. I have a question popped on my screen. This is from Quinn. He's asking can you tell me the differences between virtual machine and Docker and which is better find so bitch is better. I would say talker. Let me just give you a few reasons for that. First of all Docker is pretty lightweight, right. You have all the binaries and libraries there in your Tanner required for your application which can be a Microsoft Office application as well. Plus it's pretty lightweight plus it doesn't use as your guest operating system. It uses the host operating system unlike the virtual machines and you don't have to pre-allocate any Ram in the containers and like your virtual machine. So, I believe you I've given you enough differences between the two already is Alpha is the answer now. Let me just take you through the diagram that is there in front of your screen. So here we have a host operating system on top of that we have dr. Engine, right? So we have couple of applications running on Top of Docker engine so we have couple of containers as well. Alright, so basically what we have done we have containerize the two applications into different containers. So we have binaries in libraries along with the application in one container and similarly for the container to as well. We have similar configuration. So all the binaries and libraries required for an application of present inside a Docker container. All right. Now, let me just go ahead and discuss few components of Docker. So I'm going to start with what our Docker images and what are Docker containers. So Docker images as I have told you are reading. A template which are used to create containers now Docker maintains vast repository of images called the docker Hub, which is nothing but a git repository of Docker images now with Docker images, we can create Docker containers. All right, and they contain everything required to run your application. Now, this is all about Docker images in Docker containers. So let me just quickly open my Virtual Machine and I'll show you a few basic commands of docker. So this is my Center as virtual machine guys over here. I've already installed Docker. So let me just go ahead and quickly start Docker. So the command to start Docker is systemctl start talker. So it has started now. Let me just clear my terminal again. And now I'm going to try out few commands and then exit the container. So now what I'm going to do is I'm going to show you how you can pull images from Docker Hub. Right? So I'm going to pull Ubuntu image from Docker Hub. So let me just tell you how you can do that. All you have to do is Click. Occurred pull Ubuntu that's all you have to do. It will first check the local system if there are any images available if there are no images available, then it will go ahead and check it and Docker Hub and pull then image for us from Doc it up. As you can see that it is pulling from Docker Hub right now because it couldn't find it locally. So it says that downloaded newer image for Ubuntu latest, which means we have successfully downloaded the Ubuntu image. Now. Let me just hit a command called Docker PS and this will give me all the images all the containers which are there in my system right now. Now if I have to run this container, what I have to do is I have type in head Docker Run - it and at the name of my image or you can even use the image ID. So I am in open to container right now so over here you can you know, try out a few doc it commands. I'll Exit from here now and yeah, let me just clear my terminal again. So what we have done we have basically pulled an image of Ubuntu from Docker Hub. And then we build a container from that image. That's what we have done till now. Let me show you how Docker Hub looks like so for that I'll open my browser. Now this is the official website that is half doctor.com. You need to go to this particular URL and you can just go ahead and create an account for free and get started. You can find all the images plus you can upload your own images as well. If you want just going to type my username and password. I'll be logged into Docker Hub. So this is how a doctor of looks like guys. We have couple of tabs here repository Stars contributed create a repository create an organization explore repositories. So just go ahead and play around with it and You'll understand it. I'm just going to tell you how to search an image here. So if I want anyone to image, this is the official Ubuntu image here guys. Similarly, you can go ahead and search whatever images that you want. All right, so let me just close it for now. So we have just discussed what exactly is darker what our images and what our containers I've also executed practically. I told you how you can pull in a bun to image and create a container from that. Let's move forward and we'll focus on Docker registry. Now, I won't spend a lot of time on Docker registry because it is nothing but a storage component of Docker images Docker is own cloud. Depository for Docker images similarly, you can have either public or private repositories on Docker Hub as well. So it's basically a storage component for all the docker images. Now, I'm going to talk about Docker compose because this is what I am going to use in today's session. Now what exactly Docker compose has when you have multiple containers then Docker compose makes it easier to configure and run applications that are there in those containers what I mean by that consider the example that is there in front of your screen. So imagine I'm Able to Define three containers one running a web app another running a post Grace and a third rate is now all-in-one yamen file and then running those three connected containers with a single command. That's what Docker compose is. So we have three applications and we write the configurations for all of these three applications. We have defined all of these three applications running on different containers in a Docker compose pile. That is Docker compose or Yaman and then with one single command, I can run all of these three containers. That's what Docker compose is. All right, so I'm going to show you. Really how it works. Let's move forward for now. Now this is basically a use case of how Docker can be used in an industry. So I'm going to write a Docker file complex requirements for a Microsoft Office in an easy to write dockerfile. Now from that Docker file, I can create Docker images and intern run as many Docker containers as I want now that Docker image, I can upload that onto the docker hub from which various teams beat staging or production can put that image and prepare as many containers is they want now whatever was there in my Laptop is replicated in my staging as well as in my production environment or it or you can say throughout the sdlc. So this is how you can use Docker. Although there are multiple use cases right available. So you can just this is one way of using Docker guys now doctor for Microsoft Office is so just an example how we can use Docker for microservice. Basically imagine. We have separate services for an online shopping service. We have account service product catalog card service and orders over right all of them have their own database so we can turn all of these services on a different Docker container. I'm going to show you practically how you can do that. So let me just quickly go ahead and discuss few advantages of Docker in Microsoft versus what are the various advantages that we get when we run Docker with micro Services the First Advantage is packaging. So a piece of software usually consists of a number of components. Now these components may be bundled together or distributed separately and I usually themselves composed of various files. This can include executables binaries documentation, etc. Etc. Now, Make software distribution convenient there must be some way of assembling all of these pieces together into one cohesive whole so traditionally this was done using one of a number of mechanisms like zip files or tar balls Debian or RPM packages or language specific packages, for example, npm python Wheels rubygems, etc, etc. So these all have their own trade-offs, but they have one thing in common. They do not solve the entire problem. Zip files need an agreed-upon format for their contents, Debian and RPM packages are os specific. Vic and notoriously difficult to work and the rest are the language specific systems that do a proper job of handling application dependencies outside of the scope of their language now Docker makes it possible to achieve the granularity of portable microservices through its packaging. So I hope you got my point now, let's talk about distribution. So in order to share software with others or to deploy some way the software package needs to be tracked in a central place and accessible across the organization now Docker solve this problem by providing a standardized a Hi for a registry Service as well as an open source implementation for now. The standard Docker registry is not quite user-friendly right and lack some features available. In other systems such as yam and app. However, this will improve with time and that will happen definitely guys runtime isolation. Now, if you worry about efficient resource utilization, you're likely tempted to run multiple microservices per host or right now. This is definitely doable but can present some challenges. Let me discuss those challenges. So I just discuss one such challenge, which is called. Dependency management, for example if service one requires the library with version one point XY service to require the same library, but with an incompatible version 2 point x will likely run into a problem. If you are using a package manager that installs packages system-wide such as after yum some ecosystems provide a way to isolate the application environment into a specific directory one example of this is pythons virtual environment node.js npm also does this by default as well? However, the isolation offered by these system is far from perfect any dependency on Freeze or executables outside of the language is sandbox can still result in conflicts another issue that comes up and running multiple Microsoft offices on the same host is protection against Rogue processes that use more than their fair share of memory or CPU prior to container technology or Docker containers. The main way to achieve this would have been to run multiple virtual machines right now Docker solve this dependency isolation Problem by packaging the entire OS image along with all the dependencies. It solves the The isolation Problem by providing and enforcing explicit CPU and memory constraints similarly Dockers runtime isolation allows you to run multiple API microservices side by side on the same host with greater ease and maintainability. So different teams working on different microservices will not affect the runtime of others if I have to give an example think of it, like if a revision of an API is needed the APA microservice running in a Docker container can be redeployed without affecting other apis and finally the installation process lasts. Wantage of Docker in Microsoft Office, is it how simple it is to install you can just go ahead and refer if you installation videos. So these are various advantages of using Docker n microservices. Now, let us discuss the implementation of the use kit already told you what I'm going to do here. I have a monolithic architecture that has node.js and MySQL running on one single instance. I'm going to create two microservices user service and database running on two different containers, and I'm going to run those containers using Docker compose. I'll just quickly open my Virtual Machine and I'll show you how I have implemented this use case. So this is my Center is virtual machine again guys. Now for doing local development will need to install MySQL and create a test database for us now for local development. We need to install MySQL and created test database now creating a local database and running scripts on it is an easy start but can get messy lots of uncontrolled stuff going on. It might work. We could even control it with some shell scripts checked into our repo, but what if other I was already have my SQL installed. What if they have a database already with creative name users which we want to create. So because of all of these reasons we are going to create a - database server n Docker. So I'll just tell you how to do that. So this is a great talker use case guys be might not want to run our production database in Darker, but we can spin up a clean my SQL database in no time as a Docker container for development leaving a development machine clean and keeping everything we do controlled and repeatable. So in order to do that that the command that I'm going to type in here is pretty easy guys. Let me just go ahead and quickly do that. So it is Docker Run - - name now after give the name to my database. So let that be DB then my SQL password. I need to give root password. Which is equal to 1 2 3 whatever password that you want to give just go ahead and do that now Define a port here. So double 3:06 of my host and I will 3:06 of my container as well and the image so I just want the my SQL: latest image. All right, so it's pretty easy. So here we go. So that started now it is giving us a few warnings. You don't need to worry about that. So this starts a my SQL instance running allowing access through port double 3:06 using the root password 1 2 3 so we know that Docker and tells that the engine we want to run an image and the name of the image is MySQL: latest. All right, so let me just quickly open one more Tab and over here. What I'm going to show you is that image that we have just downloaded. So this is the name of our image. This is the port plus we have downloaded created about a minute ago, right? We can find all the details here now. I'll do let's connect to this image and see what's there. Alright, so I'm just going to type in here Docker execute - it the name of my image is DB slash bin slash bash. And here we go. Now over here if I type here my SQL - user that is root. And the password is one two three, so you can see that so over here. I will just type my SQL databases. Semicolon so my SQL database I'm sorry. It will be show databases by mistake. I've typed MySQL databases. So here it is. You can see all the information here. Right? So what we did we basically executed a talker exe see - it´d be tells Docker we want to execute a command in the container name DB we can also use the ID or just the first few letters of the idea is well and - it ensures that we have an interactive terminal MySQL - you wrote - P 1 2 3 We have given that is a command. We actually run as a process in the container which in this case is just the my SQL time so we can create databases tables users. Whatever we need. Basically now, let me just move out of this. Let's type in here exit and one more exit. Alright, so we're done now now running my SQL inside a container has already introduced, you know, if you Docker tricks, so we are running MySQL inside a Docker container. So now what we need to do is we need to create a test database folder with a script to start the database stop the database and set up the test database. So let me just tell you what I'm talking about. So I'll just go to a particular directory now, we'll have to create a test database folder with a script to start the Database Top the database and set up the test data now for that what I will do I'll just quickly go to a directory that is documents over here are enter. So this is my application guys. Let me just clear my terminal now over here. I Directory called test database so let me just show you that me clear my terminal so over here I have three scripts one is to start the database that is start out. Sh. Another is to stop the database. And then the final one is to set up the database is well. Now, let me just show you what I have written in each of these files. So let me just start with the startup script start or sh and you can use whatever editor you want. You can even use a cat command that will display it on your terminal itself. So this is a script to start my S database right? It's pretty self-explanatory. You can go ahead and Have a look at this. All right. So this is my startup script. Now. Let me show you the setup script that I'm talking about. So I'm just going to do a cat command here set up dots equal. So this has all of my data. So it has my email addresses and various phone numbers and things like that. It is available here. This is my setup script. Now, what I need to do is I need to create a stop Crypt as well. Stop dog. Sh, so here we have stopped the database and remove the container so docker Stop DB and Docker remove DB. So before removing any container, you need to first stop it and that's what we are doing here as well. And then we are removing it r m stands for removing the database now. Let me clear my terminal so we are done with wrapping up the test database now. We need to create a Microsoft offices in node.js. So this video basically talks about how we can use Microsoft versus with Docker and what exactly are Microsoft versus I won't go into too much detail of node.js application and I'm talking about so let me just highlight the areas and takeaways so Just go to a particular directory called user service and let me just clear my terminal so over here you can see that we have multiple folders and files present here. So starting from package dot Json. So this is basically used for dependencies and metadata then index dot JS is nothing but a main entry point of the application. So we have API as well. So this API file includes our apis and the API test then we have a config directory as well. This is basically the Enthusiasts configurations of our application then we have the repository directory which provides the abstraction over our database and then we have server directory as well that will contain the server setup code. This is how we have created the node.js application. I mean just clear my terminal again. Now if you want the code for this application again, you can find it through the link that is present in the chat box. And if you're watching this video on YouTube, you can mention your name and email ID in the comment section will reply you ASAP with the code. So this application that I've built here is basically a allows us to get all the users or to even search a user using the email. So in the set of the SQL file, we have seen that we have given all the data the email address in the phone number. So this is what my application is all about. It's pretty basic but it's very good example to understand why we should use Docker with Microsoft versus right? So now let me just hit few commands. So now to start that I'll just use a startup that sh script that I've written and here we go. So it is waiting for the database to start up. So it is done. Now. We have started our test database. All right. So in order to stop it, we can just use a stop script that is dot slash stop door. Sh and that's all we have to do. All right. So let me just open one mode tab here so over here, I'll just run my node.js application. So let me first go to that particular directory. So all I have to do is here npm install. All right, so this will set up everything for me. So it is up to date in four point eight to six seconds and the next command is to start my application. So all I'm going to type in here is npm start. So service started successfully at Port 8 1 2 3 now, let me just open my browser and I show you how the application looks like. This is my browser guys. I'll just go to Local Host Port 8 1 2 3 / users. So here we can find all the users with the email ID and phone number. So this is how Our obligation looks like guys. So now I'm going to tell you how to dock your eyes are Microsoft offices. So here we have a micro service which we can run on a development box as long as it has a compatible version of node.js installed. What we would like to do is set up our service so that we can create a Docker image from it. Allowing us to deploy our services anywhere with suppose Docker and one way to do is to create a Docker file. So as I told you earlier is well during the use case that we write complex requirements for a project or a Microsoft ways and an easy to write Docker file. So this Docker file is what I'm talking about right now. So a Docker file is recipe that tells Docker engine how to build your image will create a simple dockerfile in US user service directory and start to explore how we can adapt it to our needs. So I've already done that. Let me just quickly show you where it is present, so So just quickly go to that particular directory where I've already written that yeah. Let me just hit an LS command and you can find that we have test database and user service here as well apart from that. We have a composed or camel file and integration tests, which I'm going to tell you about data. You don't have to worry about it right now. Let's talk about Docker file. So we'll go to this user service. All right, so let me just go there are my terminal and you can see that we have a dockerfile present here as you can see that we have a Docker file present here. So let me just Quickly show you the contents of this Docker file. So what we have done here, first of all, we are telling the occur to use note for as base image CMD command tells Docker that this image should run the node executable when the executable terminals the container shuts down. Then what we have done we have made use of add command to copy everything. Alright, so you can see that we have an add command here to copy everything and then current directory to a folder in the container called app. We then use run to run a command in this image and the image which installs are modules. And finally, we expose the server Port 8 1 2 3 telling Docker we intend to support inbound connections on 8 1 2 3 then run us over code. So this is how our dockerfile looks like now. Let me just go ahead and close it. Similarly. I have written the dockerfile for my test database as well. So let me just quickly go to that particular directory. So here in the test database we can currently see when we hit analyst command that we have two files one is dockerfile set up dot SQL file, but I have actually told you to create start dot sh. Top Dog sh is well along with Theta dot sequel. There was no talk of 5. So now that we are not familiar with Docker we can improve on this looking onto my SQL image documentation on the docker Hub. There's a note which tells us the dots equal or dot SSH file added to the images folder will be executed when setting up the DB. So what I have done basically I have replaced my start dot sh and stopped or SS scripts with Docker file. All right, so let me just quickly show you how the dockerfile here. Looks like it's pretty easy. Although I let me just open it through GL. It so when use my SQL 5 as my base image after that. I have given the password for my database then the name then the surveys and then the MySQL password password is 1 2 3 add setup dots equal to Docker entry point. I need DB dot d so over here. I've just written that to use MySQL 5 as my base image then provided the root password database name user service. Then we have provided the bicycle password and then we have used the add command. Let me just quickly save it and Close it. So that was pretty basic guys writing a Docker file. Now. Once we have written these Docker files, what we can do is we can make use of a command called Docker Bill - T Test database so Docker Bell - T Test database. So this command Docker Bill - t-test - database will actually build a new image from the dockerfile that you can see over here. Right? So it will build a new image from that particular dockerfile similarly if I type in here instead of build If I type in here Run - I T Test database. So this will run a container with this image. All right little basically ran container with this image the previous Commander. I've showed you will build an image from the dockerfile and this will run a container from that particular image. This is why we use a Docker files. Let me just quickly go ahead and clear my terminal and now I'm going to talk about composing so building and running each container is still somewhat, you know time-consuming we can take things a step further with dog. Compose tool which have discussed during the slides as well. So Doc is composed lets you create a file which defines each container in your system the relationship between them and build or run them all now, what we need to do is create a new file in the root of s project called Docker - compose dot Yaman. So it's a yam elf. I'll let me just go back and hit an LS command here and you can see that we have dr. Ivan composed dot HTML file present. So let me just quickly take you through that particular file. I'll use G edit in order to you know, open that file you can use. Whatever editor or you can even use the cat command to open that on the terminal and means increase the size of it. Yeah, so I have written all the doctor files that I first want to build and create an image and linking the different Docker images or the docker container. So you can see that I have Services here user service and build will basically I need to specify build value for each of us always tells Docker way to go and find that particular dockerfile. So the first one is dot slash user's - service the name of the container is user underscore. Service and the port that is present here. It should be linked to my database right depends on the database environment is database underscore host is equal to D. Be similarly. My database image can be built using the dockerfile which is President test underscore database. So it is pretty basic. Let me just quickly save it and close it. Let me just clear my terminal again. So I need to sign in as a root user for that. I'm just going to type in here the password. So now what I'm going to do, I'm just going to type in here Docker - compose build. So this will build the docker images for me set is successfully build now. Let me just clear my terminal and now I'm going to run this application. So for that I'm going to type in here doc it - compose up. That's all I have to do and here we go. It's always started successfully running on Port 8 1 2 3. So let me open my browser and check whether it's working or not. Local Host 8 1 2 3 / user. So as you can see that application is working here here. I have all the email IDs and phone numbers which are there in my setup dot SQL file. This session is about the difference between the applications which are implementing SOA which is service oriented architecture and software applications, which are implementing the micro Services architecture. So without wasting any time, let me get started. Now before we go into details about SOA and microservices. Let's see what is a monolithic application and how that function. First of all you can think of a monolithic application as a container, which is basically I think the number of software components right? There can be a number of software components as part of your software application. And if they are all hosted together and delivered together, then that's called a monolithic application. Now there are various challenges with any software application which is implementing the monolithic architecture. First of all, they are not flexible. Okay, monolithic applications. They cannot be built using different Technologies. That's the problem. The Second Challenge is that they are unreliable even if one feature of the system does not work then the entire system. Mm will not work. The third challenge is that these monolithic applications are not scalable. They cannot be easily scaled. And even if the application needs to be updated then the complete system has to be rebuilt. The next problem is that with these monolithic applications. They block continuous development all the features cannot be built and deployed at the same time. They will have to be done separately. The next challenge with monolithic applications is that the development is very slow. They take a lot of time to be built since each and every time It has to be built one after the other and most of all the monolithic applications are not fit for complex architecture because of course you cannot use different Technologies. You are very limited and very constraint, right? So that is the challenge with monolithic applications. So now let's go on to SOA, which is nothing but service-oriented architecture now with SOA these services or features. They are broken down, right? The entire software application is not built as one but the different features teachers and the different services are broken down into smaller components, right? So that's why it's called coarse grained architecture and over here. If we have let's say one software application inside the which it provides and if it provides like five features or four features, then all those are four features are delivered by four different services. And that is what you can see over here, right? There are four different services. And each of these Services would have multiple tasks inside them and these smaller tasks are together. Tell or ask one particular feature and the whole software application comprises of a number of these features, but with microservices, it's a little more different. Now these features or services are further broken down into tasks level services. So here it was feature level Services. Whereas the services here. They are task level each and every task in a particular feature that was broken down and that's why you have multiple tasks and multiple services in a micro service architecture. Chop and that is why this is called fine grained architecture. So that is what the differences are between these three on a high level. Now before I go further and confuse you people let me just go into more details about the differences between SOA and microservices. You can think of the difference between SOA and microservices with the help of these images. So SOA is like an orchestra similar to you having multiple performers, you will have multiple services. But each of these performers will be controlled by one potato director and similarly in Rip even though you have a multiple Services these services will be interacting with one another and then they will be delivered as one particular software application. But whereas in case of a micro service there are multiple or let's say there are independent performers, but these independent performers are not controlled by any director. So they work separately and they work in silos. So that is a different. So I hope you can understand the difference between the two from these images right even though they work together. Are they are controlled by one particular director and that's why this is called a centrally governed architecture and whereas microservices you do not have a centrally governed architecture and that's why it's called a decentralized governing architecture. So let me go forward and talk about the difference between these two which is nothing but Micro service and SOA with respect to certain parameters. Let's look at the difference between them with respect to architecture and coordination. So first of all in SOA, there are four different. Types of services versus Business Service the Nexus Enterprise service, then we have application service and then we have infrastructure service. So these four service types together form your SOA and they together delivered your software application. Now, what are these different services? And what do they do? Let's see that first is business service. Right? So your business service is the one that's going to be performing your core business operations and it It can be either a represented by XML or by web service definition language. And then we have Enterprise service. The Enterprise service is that service which implements the functionality defined by all business service and the Enterprise service does it with the help of the application service and the infrastructure service now moving on we have application servers. The application service is the actual core application or the core functionality of that feature and these applications? Offices can be either invoked directory or they can be invoked through a user interface. And now we have infrastructure service the infrastructure service refers to those non-business or those not technical operations such as editing scaling or security and all these things. Those are the different Services enough SOA. But in case of micro Services architecture, you do not have these many types of services. You just have a functional service and you have an infrastructure service. The functional service is basically So the combination of a business service and Enterprise service and an application service now a functional service is a fine-grained service. So basically if your Robb business logic or your business operations requires a particular feature to work then the task that is related to exactly that particular feature that is performed by the functional service and besides a functional service. We have an infrastructure service and the infrastructure service over here is very similar to the infrastructure service that is there. An SOA the it does all the non business or the non technical operations. Such as your security auditing and logging. Okay, so that is the difference with respect to architecture and coordination. So now moving on to the next slide, we have a true genius interoperability. Now what this means is any software application and need not be developed on the same programming language. Now when your main software application you might have a smaller applications, right? And each of those smaller applications could be written on Java or it could be written on C dot dot net or it could be written on. On C sharp or python or anything now when it's written in different programming languages, it's tough for them to interact with one another and if you want the different services to communicate with one another then you would have to bring a particular platform. Right? So that's where you have this messaging middle web. So in case of SOA, there is something called as a messaging middleware which acts as a communication point or the interaction point between the different applications which are in a different language. So you can see that this application is on either C sharp for.net and This is on plastic javabeans, right? So now here it's C plus plus and here is Java so and all of these communications they go through this one quadrature messaging middleware, but in case of micro Services, we do not have any broker here the communication happens directly between application to application. Even if they are in different programming languages, even if they are structurally different and even if they are built on different grounds, so look at this if you have a C sharp or a.net application, which is communicating with a Java application, but then how does it happen? It happens with the help of a rest API. There is a direct communication between these two services and similarly. If you have another Java application which wants to communicate with another Java application. The communication would take place with the help of rest API and similarly Java to C sharp or dotnet would again take place with the help of a rest API. So there is no broker here or middleman, which is a messaging Middle where the communication is directly to the other application. Then comes service granularity. If you can remember I earlier told that in microservices you do not have the software delivered as a whole right? It is broken down into smaller features. And if you're basically performing an operation which involves multiple applications or multiple Services, then those services are called by one another when it's needed so as an end user as a consumer, you might be performing one operation. Okay, so that one operation would not be calling all the different Services it would call. One service and this service when it needs to interact with the second service. This would make the call to service to and similarly your service to when needed it would call service number 3 and similarly the ones the service requested made the server's response is also given to the one that's invoking the request now the catcher is each and every service requests and service response takes hundred milliseconds. Okay. So let's assume it takes this much time the API calls and this is in case of micro services. So in the micro service architecture when each call takes a hundred milliseconds Is in total for this service to get successfully returned it would take 600 milliseconds. Now, that's an awful lot of time for an API call to complete successfully write for an API called be made successfully and to be returned and this is where it is different from an SOA. So when case of an SOA the service consumer would again be calling would we would be performing one particular operation? And what happens here is this operation would be calling the different Services all at the same time. So the and over here would be calling the service number one service number 2 and service number three, it should be encompassed all together. So one particular call be made to the servers and all three would be serviced at the same time and by this you would be saving time because all the three requests and responses would be made simultaneously so you would be saving a good 400 milliseconds over here. So that is a difference in service granularity between SOA and microservices. So the next difference we are going to see is with respect to component. Eric this is very similar to the previous slide again, right because then it would be the same order service which will be interacting with your different smaller applications each for customer management and for warehouse management and for order fulfillment and the data again would be stored in different databases But there again is a difference in microservices because in the micro Services architecture for each and every application so for customer management, we have a separate order service and that order service would be accessing its On database for Barros management, you have a separate order service which would be accessing a different database and then for order fulfillment, which is again a different application. This would be using a different order service and this order service would be using a different database from where it would be accessing data, right? So that's how there's a difference in even component sharing between these two architectures and then we have the next difference between them. And that is the middle wire versus API layer this we also spoke about earlier write your essay. You just made your bed for communication and your microservices uses an API layer for communication. So that is about the differences between SOA and microservices. Now, let's go ahead and look at the differences between the two by understanding with an example of a shopping cart. So every e-commerce portal will have a shopping cart right where you can add your products to the cart and then you can check out later so for adding an item for removing an item for checking, what is the tax for checking the total? Bill amount for all those things you have a shopping cart application. And then finally we have another application which is the main application which gives details about the product. So it will give us details about the product name. What is the product ID? What is the product rate how many quantities are present and all different other options, right? What color the product is and all these things now, these are three different applications and when they work together you get the complete software application right now each of These applications would have a smaller tasks a shopping Card application. Like I told you before it would have an add or remove functionality where you can add a product your card. You can remove a product from your cart. You can check what is a bill in your cart. You can check out. What is the tax that is there and all these things similarly. If you talk about a product catalog you have other tasks, right? So all these tasks together form one particular application service in case of RSA shopping application, but in case of micro services Has shopping application each of the different tasks that these Services provide those tasks are broken down into smaller fine-grained services. So here we have feature level Services Where Shopping Cart is one feature product catalog is one feature and user account application is one more feature, but in case of micro Services, we have a separate billing service for shipping. We have a shipping options service. We have tax calculation service, right? So the different tasks in this particular feature. It's broken down similarly for product. Catalog application. We have different tasks level breakdown such as display product service. We have an update display service. We have user default service and many more similar for user account application. Right? We have a send email service and many more now that you've understood that microservices is all about breaking a particular feature or a feature level service into task level services. So, let's see how microservices shopping application is different. So first, let's take the case. Sofware micro-service shopping application is better. So here we'll have certain features which are common to multiple applications. Right? So we have was something like display image server. So it's a smaller task level servers over here. But the image of the product of being displayed might be common across all the three applications. It might be present in the shopping cart also and the image of the product might be present in the user account application also with us showing which were the products. Which the particular use of pot and then you might have the product you might have the image of the product the product catalog application also. So in this case if there's a change in the image Dimensions or in the license of the image or anything with respect to the products image, then the code of course would be similar in all the three applications write the code may be some law but the code has to be changed everywhere. Right? And when you change the code when you re work, then it causes a lot of problems again now when you changed The code here you're changing the functionality and that might cause this particular application to behave abnormally it might have bugs or the application might cause failure and similarly. If you change the code over here, then even this might throw errors and you might have bugs similarly to this particular application also, so if you want to avoid all those things you have to test each of these applications to separately after changing the code and after updating the required details and after testing it you will have to deploy each of these applications and you have to deploy them separately. All these things is time-consuming, right? So it is the same thing that you are doing across all the different parts of your application. But even though you're doing it everywhere, even though you're doing something similar you will have to test and deploy each of them. And sometimes you might have errors in only one particular application and not everywhere. So these are all time consuming tasks. But if it's in case of a microservices shopping application, you would not have this problem because all the different tasks over here. They are provided as a service if you want to change the way the products image looks then you will have to change. And only this particular application, right? So by only changing this service your job will be done. You do not have to worry about the other services and you do not have to change anything over there. So the main change you will have to be doing will be restricted to only this particular service. So you save time and you save effort over here in case of micro Services shopping application. Now this was a use case where the microservices shopping application was better, but then there are also times when an SOA shopping application is better for you, but this was a Sick use case of where a micro service shopping application is a best fit. But let's see a use case where an SOA type of a shopping application and the SOA architecture comes out better and that example is when your product is not actually that big. So in this case, yeah, you have a lot of functionalities you have a lot of features and tasks. So just consider the example of a very simple software application which show needs three primary functionalities one much as our shopping cart, which in to where you can add your you can add your items and then you have another user account application where you'll have the user profile and then you'll have a product information application. Right so over here all these different applications will not have too many sub level features or sublevel applications the a very straightforward. They're very simple in this case. If you're having if you're implementing microservices architecture, then you will have to go through a lot of trouble which is simply be avoided because your application is in itself very simple. We also just you know, create one one website where you can have one website in which you have a cart where in you can add your products which you want a bike. Then when you're checking out you can have the user information displayed and then you have details about the product which is separate application. So in this case, it could just be these three different services. So that is the difference between an SOA. So I think by now you understand that neither of them is better than the other right. So there are times when microservices is preferred and there are times when SOS prefer and you can not hardcore it by saying that one is better than the other. In today's Industries where software applications are built on a day-to-day basis developers always have to keep in mind regarding the architecture and the implementation of the code and also the UI through which the user will interact with the application. Now the only way to make sure that all these parameters are met is by using micro services and API in the session guys will focus on the differences between the two and I also talked about how and where microservices and API I come together in the architecture, right? So on that note, let's get started with today's session. So the topics for today's session are as you can see on my screen will start this session by understanding what our apis once I tell you what our API is we'll talk about where our apis used in microservices. And finally, I'll tell you the differences between the two right. So on that note, let's get started with today's session. But before that I would like to request all of you to subscribe to our a direct our YouTube channel to get daily notified on the Going to acknowledge. He's now if you consider an e-commerce application, what do you think are the main three functionalities of it example, let's say you using Amazon. What all do you see your customer? Right? You see all the products on Amazon and then you put your products into the cart and finally you order those products, right? That is basically the simple workflow. If you have to understand now, if you have to build this application using microservices, what you can do is you can have mainly three functionalities that is the customer information. The products available in the cart and all the products available on the website right now all these three functionalities can be put into different different Services what I mean by that is you can have service a having customer information service be having the products available in the cart and service Lee having all the products available in the application right now when the customer goes forward and orders a particular product. You can have a composite microservice which will basically take data from all these free services and generate the output for the client. Right. So I hope you've got an idea of what I'm talking about right now. As I was telling you that you know before microservices came into the picture. There was monolithic architecture. How do you think all these functionalities of the application was stored in this kind of architecture? Well, it's really simple what would happen would be all these three services that is the customer service the product service and the card service would be residing in a single area and then they would be a data access layer through which you can access the data, right? So as you can see on my screen you have a client browser. Zur through which the client requests for the information so as soon as the client would request for the information on the application that request would be passed to this particular area where all the functionalities are present and the data would be retrieved from the data access layer and the database so if I have to just Define monolithic architecture for you, then it's really simple guys monolithic architecture is an architectural style in which all the functionalities or the required components would be inside one single block, right? So, I hope that particular part is clear on that note. Let's get into the second topic for today's session. That is what our apis. What do you think apis are obviously everybody has heard of this term API, right? So you can basically understand apis as a point of contact through which all the services communicate with each other to process the client request and send the response. Right? So, for example, let's say, you know, you've sent a client request. Let's say on Amazon you've requested for a phone, right? So if you just type phone what will happen is that you want this particular request will be sent through apis. To the respective functionality or a feature right and that particular functionality or a feature will retrieve the requested data and then we'll send back the response to the client. Right? So if you see your client, then this particular functionality or a feature present in the application and then in between both of you there's a pi/2 which we can communicate right. So I hope that point was clear now while building and using these applications. What developers do is that, you know, we basically use the crude operations when I say crude operations what I mean by that is we basically In the sauce read and Source updated resource and delete a resource. So apis are generally developed by using the rest quick style. And these methods are nothing but the HTTP methods now, I'm sure you must have got confused when I said create a resource read the resource updated resource and delete a resource. Well guys, it's really simple to understand. For example, let's say, you know, you're using book my show and then you want to find out the details of a specific movie. So what you do is you send a client's request. So when you send a client request you basically we asking for the information, right? So what will happen is that you know, the information has to be read and then the response has to be sent is applied. So that's basically reading the resource coming to creating updating and deleting. This is from basically the developer side where you know, they keep adding the information to the application or maybe specific movies details are updated or maybe the complete movies deleted, right? So basically the information of the movies deleted once it is out of the market, right? So that's how basically it works now whenever we send the request. As to what happens is that we're basically sending an HTTP request, right? So for that we use the HTTP methods, right? So next in the session, let's understand the different HTTP methods. So the HTTP methods are as you can see on my screen. We basically have the post get put and delete methods. So whenever you want to create a resource you basically use the post method whenever you want to read a resource you use the get method whenever you want to update a resource you used for What method and whenever you want to delete a resource, you use the delete method, right? So basically guys apis use these methods to basically communicate between the client and the respective functionality of the features of the application right. Now. If you want to know more about HTTP methods and apis you can refer to my session on what is this API? So on that note, this is all that you have to understand to understand the differences between apis and microservices. Right? So now that I've told you you know, what am I? Elvis's and what our apis let's continue. Where are exactly apis used in micro Services. Now when I was explaining apis for you, I was always saying that you know, they're basically a middle person between the client and the respective feature of the functionality now, obviously that particular feature or the functionality can go into a specific service, right? So let's say, you know, we have a functionality of all the products present in the application, but that particular feature can be present in a specific service, right? So now when a client request for all The products available in the application the request can directly go to that particular service and the response can be generated back. So I hope that point is clear. So what you can do is basically the application that we took the example that we took we had a client browser and in the monolithic architecture the customer information the product service and the card service all these three services basically all these three functionalities were residing in the same area and then there was a common data access layer and then a common database right now when you break down this Application or maybe even you refactor this application into microservices. What you can do is you can have a specific microservice and then you can have its own data access layer and database and for each microservice. There's a separate API, right? So basically the customer micro service will have a specific API its data access layer and database similarly goes for the product micro service and the card micro service now, it's not necessary that you know this single database for each and every microservice. It may also happen. And that you know two or three microservices share a common database to which the data is retrieved, right? So basically guys if you have to understand where apis are used in microservices, it's really simple. Each service will basically have its own API provides. The services will communicate with the client. Right? So, for example, let's say, you know, you're a client and then you're asking for your own information your own customer details. What will happen is as soon as you send the request basically the API Gateway will decide to which service this particular request has to be sent. Now since we want the customer details this particular request will directly go to the customer microservice. And what will happen is that you the required data will be retrieved from the API. And then again the API will send back the requested response to the client. Right? So basically that's all that you have to understand guys that you know, each service will have its own API and then through that particular API, you can communicate with that particular service right now. It's not necessary that you know, you need information from a single service right even in that scenario. Is what will happen is that you know, each micro service will generate the requested data and all of them together will send back the requested response to the client. Right? So, I hope that you understood where our API is used in micro Services right now. Let's move forward with the final topic for today's session. That is the differences between micro services and API now in this tutorial on Microsoft versus was a pi. I hope that you know, you've understood what are basically microservices and what our API is Guys. These are completely two different things. Microservices is basically an architectural style through which you can build the applications in the form of small and autonomous Services coming to apis apis are a set of procedures and functions, which allow the consumer to use the underlying service of an application. Right? So basically guys this is the main difference between micro services and API that microservices basically an architecture to which you can build the application and apis is basically like a middle person between the client and the services through which you can establish. Location between both of them right? So I hope that point is clear also from the example that I explained you. I'm hoping that you know, it's clear to you that you know apis are a part of Microsoft versus and thus it helps these Services communicating with each other. However, while communicating with the other services each service can have its own crude operations to store the relevant data in the database not only this but while performing the crude operations API is generally accept in return the parameters based on the request sent by the user. So for example If the customer wants to know the order details, right, so maybe he must have ordered few items. What will happen is that you know, the product details will be fetched from the product service the billing address and the contact details will be fetched from the customer service and the product purchased will be fetched from the cart service. Right? So basically if you have to, you know generate a specific data, or maybe if you want a specific data, all these Services can communicate within each other with the help of apis and generate the requested response, right? So I hope it's clear to you guys. So guys this was the basic differences between microservices and Epi Microsoft is is basically a simple architectural style and apis are a set of procedures and functions, which allow the consumer to use the underlying surface of the application. So if you're someone who is aspiring to build an application using microservice architecture, I would always see that, you know, make sure that you know, your API is a working and then all the services are working are collaborated with the apis in such a way that you know, no request is high. And maybe all the clients requests are satisfied with the requested response. Right? So I would just say go forward and build applications using micro services in today's market microservices have become the go-to solution to build any kind of application. They're often known to solve various kind of challenges, but this is not the end to the story as skilled professionals often face challenges while using this architecture itself. So in the session guys will discuss on the The various design patterns that you can use while setting up an application using micro services. So on that note, let's take a look at the topics for today's session. So the topic for today's session are as you can see on my screen will start this session by understanding. Why do we need design patterns? And then we'll look into what exactly design patterns are and then I'll talk about the principles behind microservices. Once you understand the principles behind microservices. I'll finally end the session by talking about the Microsoft versus design patterns. Before I move forward with the session, I would like to request all of you to subscribe to our red. You make a YouTube channel to get daily notified on the top trending Technologies, right? So on that note, let's get started with today's session. So the first topic for today's session is why do we need design patterns? So to understand this topic just consider the scenario where you have a team of developers. Let's say 30 developers right now, you're given a project to basically build similar kind of applications as a team lead. What will you do you'll just do Vice these three applications to a group of 10 10 10 developers, right? So the group one will have project 1 group 2 will have project to group 3 will have project free and all these three groups will have each of ten developers, right? So now when this team of developers start developing the application, they can follow different set of processes, right? So when I say process what I mean, that is the way they're developing the application, right so they can follow a particular part to develop an application. Right? So let's say the group one is following process one group two is following. Dual and group three following process tree right now. What can happen is that maybe process one works completely fine what I mean by that is that you know, there's no errors and then whatever errors are coming. Also. There's no latency time. There's no disadvantage in using that kind of process. Right? But if you consider any other two processes, let's say process to and process tree. It may happen that you know, they could be few errors and maybe that's not the right way to build the application, right? So what could happen is that you know, I'm not saying that you know process one is the Only way to build an application. Maybe they have a better way when compared to process to and processed rewrite. So as the team lead what you clearly understand is that you know your development team cannot build the application using process to and process tree, right? So to ensure that all the teams follow the same process or maybe of same pattern you can use this concept of design patterns when the teams working on various projects use the same pattern to build similar applications, right? So basically they will select a particular pattern. And we'll build all the applications based on that particular pattern itself on that particular pattern. You'll make sure that you know, you have the maximum Advantage is that you can get for your application, right? So that is the need of design patterns guys. Basically if you have to understand the need in a single line, then you get us understand the fact that you know, design patterns are used to make sure that you know, your complete team is on the same plate and everybody is following the same process or maybe the same pattern to build the application, right? So I hope you've understood what is the need of design pattern, right? Right. So now let's understand what exactly design patterns are what my previous explanation you might have clearly understood that you know design patterns are basically a simple pattern based on which you build an application. But yet if I have to Define design patterns for you, then design patterns or software design patterns can be defined as a soffit template or a description to solve a problem that occurs in multiple instances while designing a software application or a software framework, right? So I hope you've understood what exactly design patterns are there. Basically just a top fit template or a pattern or maybe a description to solve a particular problem. And that particular problem is seen in multiple instances, right? So when you want to solve a problem, which is in multiple instances, you can go forward and choose the design patterns, right? So now that you know what our design patterns so next in the session, let's look into the principles behind microservices. So the principles behind microservices are as you can see in my screen, it starts with independent and autonomous Services basically because you know eat Services be independent of the other service, right that is because each service is either created for a domain or a business capability and each service has its own functionality, right? So that is the first principle coming to Second principle. That is scalability. So when you build microservices, what you can do a sickly do is for example, let's say you have for services for a specific business domain then what you can do is you can scale a specific service individually without scaling the others, right? So let's say in the example that I took that is the e-commerce application we had free. Right customers orders and product. So if you want to scale the customer service individually, you can definitely go forward and scale that particular service and you do not have to scale the orders or the product service similarly goes for the other services. Also coming to the third principle that is decentralization. The decentralization is basically when you know, you do not have a centralized architecture right what I mean by that is for a specific business domain when you build an application using microservices, your complete control is not there for a specific service, right? So all the controls are basically divided into Individual Services coming to resilient Services. I would say micro services are red seal and services because you know, let's say even if one service is completely down the complete application will not go down. So in the incomes application, let's say the product service is down. That doesn't mean that you know, your application will stop working only that particular service is not working and the team will be working on that particular service do get back the service. Right? So the only point that you have to understand is that you know, even if a service caused. On the complete application doesn't go down. Next we have is Real Time load balancing. So obviously when a client sends requests, it may happen that you know, you have to retrieve data from multiple Services over there. The load balancer comes into the picture and then it defines how much CPU or how much GPU should be used for a particular service to get the data and similarly how the clients request should be passed. Right? So that's happening real time. And in this kind of architecture the client doesn't have to wait for a really long time. Right? So you get the outputs within seconds coming to Availability. I think the principle itself defines its functionality. It's basically means that the services are available 24/7 and all these Services can be basically used as much as they want right coming to the next principle that is continuous delivery true devops integration. Well biker Services is one such technology or maybe you know, once it's framework that you can understand which you can collaborate with devops to get containers delivery of the output. Right. So once you understand devops, you'll understand how to deploy a service and how to get the outputs. After that, we come to the next principle that is seamless API integration and continuous monitoring all the microservices have a specific API Gateway, which is basically the entry point to the clients request, right? So whatever clients request has been sent and it will be first sent to the API Gateway through which the request will be forwarded to the specific microservices. And obviously these micro services are continuously monitored whether the response is sent back or not, or maybe if the service is down or not coming to the next principle that is isolation from failures. So when I say A isolation from failures what I mean by that is, you know all the services even if they're down on maybe if they have any specific errors that particular service will solve its own error and it won't disturb the complete application. So let's say in the e-commerce application that we considered. Let's see if the product service is facing few errors. Then what will happen is only that particular service will be basically taken into account and the errors will be solved and those errors will not affect the application or maybe the other two Services coming to Auto provisioning or to provisioning is basically Ability to deploy the information by itself, right? So basically the service will generate the information for the clients request automatically without anybody's help. Right? So Guys, these were the basic principles behind microservices that is independent and autonomous Services scalability decentralization Brazilian Services real-time load balancing availability continuous delivery through devops integration seamless API integration and continuous monitoring isolation from failures and auto provisioning. Right? So guys, I hope you've understood Understood the principles behind microservices, right? So now once you start building microservices you often face future challenges to because of which you have to start using design patterns. So since this session is basically based on microservices will be looking into the microservices design patterns. So let's get started with the first design pattern that is aggregator. So when you hear the term aggregator what comes onto your mind in Computing World aggregator refers to a website or a program that collects related items of data and displays them. So even in microservices pattern aggregator is basically a web page and invokes very services to get the required information or achieve the required functionality apart from this when you basically build the microservices architecture, maybe a Microsoft is application by breaking down the monolithic application or the monolithic architecture the source of output gets divided right? So when I say monolithic architecture, you can just consider it to be a one big block right? So when you break that one big block into All small Services the source of output also gets divided right? So this pattern basically proves to be beneficial when you need an output by combining data from multiple services. So if you consider a client sending a request and maybe if we need data from two Services, then aggregator is a design pattern that you should go for right now. How do you think that happens? So what basically happens is that you know, let's say we have two Services when a client sends a request and maybe that you know, we want the data from both these services. So what will happen is that both? These services will be having their own database. So with the help of aggregator design pattern what will happen is that you know, each transaction will have a unique ID So based on that particular ID. The request will be sent and all the data will be collected from The Individual Services and the required business logic would be finally applied after that. What will happen is that you know, whatever data is collected. It will be published to the rest endpoint and later on what will happen is that the data will be consumed by the respective Services which require that data right? So it could be a specific consumer or maybe a user. Maybe a group of users or so on right? So if you have to understand aggregate the patent guys, it's really simple. So aggregate the pattern is basically a web page which invokes Media Services to get required information. So whenever a client requires a specific information from two or three services, you can go forward with this aggregated design pattern also before I move forward to the next design pattern. I would like to mention over here is that you know, aggregate the pattern is basically based on the drive principle. So what happens is that, you know, based on this principle you can abstract the Just a business logic into composite microservices and aggregate that particular business logic into one service. Right? So let's say you have a business logic, right? So that particular business logic, what you can do is maybe you can put that particular business logic into two to three microservices later on. What you can do is you can aggregate that business logic into one specific service, right? So, for example, if you consider two Services service a and service we then you can individually scale the services simultaneously by providing the data to the composite service, right? So that was about the aggregate that design patterns guys. Let's move forward with the next design pattern. That is API Gateway now microservices are built in such a way that you know, each service has its own functionality. But when an application is broken down into small autonomous Services, they could be a few problems that a developer might face now the problems could be how can I request information from multiple microservices? How can different devices require different data to respond for the same back end database service or how to transform data? To a consumer requirement from reusable microservices or how to handle multiple protocols request. Right? So Guys, these are basically few problems that all the developers face. Well, if you wish to solve these problems, then I would say the solution to these kind of problems could be the API Gateway design pattern. So the API Gateway design patterns at this is not only the concerns that I mentioned right now, but also it solves many other problems. This particular pattern can be considered as a proxy service to router requested are concerned. Service. So basically as I mentioned before API Gateway is the entry point to the clients request also being a variation of the aggregate service. It can send the request to multiple services and similarly aggregate the results back to the composite service or the consumer service, right? So the API Gateway as I mentioned is basically at the entry point for all the micro services and can create fine-grained apis for different types of clients, right? So maybe you have a client sending a specific request or maybe the client B sends a different. Frank was right. So with the help of this particular pattern, you can create fine-grained apis for all different kinds of crimes. And for the request also since developers are always concerned about, you know, how to handle multiple protocol request API Gateway scan convert the protocol request from one type to another type similarly. It can also offload the authentication responsibility of a specific microservice. So once the client sends the request these requests are basically passed to the API Gateway which acts as an entry point to Add the clients request to the appropriate microservices, then with the help of the load balancer the load of the request is handle and the requests are sent to the respective Services. Right? So micro service is also used this service discovery, which basically acts as a guide to find the route of communication between each of them. So when I say each of them, I mean to microservices so microservices can communicate with each other via stateless server. That is either by HTTP request or message bus, right? So with the help of API gate Pattern guys a client's request is basically forwarded to the correct microservice. And even if there are different kinds of clients using different UI so maybe different protocols and they want the data from the same back end service. Then API Gateway design pattern is your solution, right? So I hope that you have understood. What is API Gateway design pattern now, let's move forward with the next design pattern that is Chained or chain of responsibility. So the chain or chain of responsibility design pattern basically produces a single output, which is a combination of the People change output. I hope that is clear to you guys, right? So as the name suggests in this particular design pattern what happens is that the client request is passed to let's say service a and then the request is passed to service p and then the request is passed the service C. Similarly the responses first collected from service see to service be and then some service be to service a and finally it goes to the client. Right? So as the name suggests guys the chained or the chain of responsibility design patterns produces a single output, which is a combination of the Multiple chained outputs. So for example, if you have three services lined up in a chain, then the request from the client is first received by service a and then this service communicates with the next service service be and collect the required data. Finally the second service communicates with the third service to generate the considered output. And what happens is that all these Services response is sent again from service E2 service be service be to service a and finally to the client, right? So all these services use synchronous HTTP request or ponds for messaging also under the request passes through all the services and the respective responses are generated. The client does not get any output. Right? So guys, this is kind of a disadvantage in this particular design pattern because you know, let's say, you know, you have 20 Services lined up and maybe the client request is a very big request, right? So until all the data is collected from all these particular services and then the response back is generated. The client does not see any output right? So it's always recommended not to make any long chain as a Line has to wait until the chain is completed. Right? But before I move forward to the design pattern one more important aspect of which you need to understand is basically that, you know, the request from service a to service be may look completely different from how the request is from service be to service e similarly is the case for response. Maybe the response from service see to service be may be completely different from service be to service a right. So that's what you have to understand about the chain of responsibility or chain design pattern guys. Now, let's move Forward with the next design pattern that is asynchronous messaging design pattern. So what do you understand by this term asynchronous messaging? Obviously, the messaging pattern between microservices is not synchronous, right? So in the previous design pattern, we had discussed synchronous messaging right? So that was because you know service a communicates with service B and B to C, right but in asynchronous messaging pattern, it's not necessary that you know, all the services communicate like, you know Service A to B or B to C, maybe service a can directly communicate so bossy and maybe Always seek and communicate with service be or maybe service be does not communicate at all. Right and service speak communicates with service a right. So basically what you have to understand is that you know, since the client wait a long time without any output in synchronous messaging and maybe you do not want the client to wait for a long time. This is where basically you use the asynchronous messaging design pattern, right? So in this particular pattern what happens is that all the services communicate with each other, but maybe they do not have to communicate with each other sequentially. So if you consider three services as I just mentioned before service a b and c the request from client can be directly sent to serve a c and service be simultaneously when I say simultaneously what happens is that you know, the single request from client is sent to both the services together that a service e and service be so then what will happen is that you know, these requests will be in a queue. So when I say Q you can understand that it is basically a line of requests. So when a client requests simultaneously sent to two Services you basically The Q and A Part from that but you also have to understand is that you know, let's say the service is sends a request to server see it's not necessary that you know service see sends back a response to service a itself. Maybe it can follow a different part and then finally response can be sent right. So the path is not defined and it is not done sequentially in asynchronous messaging pattern. Right? So guys that was about asynchronous messaging design pattern next. Let's move forward with the next design pattern that is database design patent or share data design pattern. Now for every application there's obviously a humongous amount of data present, right? So when we break down an application from its monolithic architecture to microservices, it's very important to know that you know, each micro service has a sufficient amount of data to process the request right? So I hope that point is clear to you when we break down the monolithic application into small small Services. We need to make sure that you know, each micro service has sufficient amount of data to process the clients request. So either the system can have the database Each service or it can have shared database per service, right? So when I say database for service what I mean that is, you know each microservice in the system will have a specific database for themselves and share data base for service is basically when two or three microservices together share a specific database right now, you can use the database for service or shade database for service to solve various problems. So the problems could be basically the duplication of data and inconsistency different Services have different kinds of stories requirements. So the problems could be basically the duplication of data and inconsistency different Services have different kinds of storage requirements few business transactions can query the data with multiple services and denormalization of data is not easy, right? So to solve these kinds of problems. Basically you can use the database for service or the shade database for service. Right? So if you have to solve let's say, you know duplication of data and inconsistency. I may be different Services have different kinds of storage requirements or maybe a few business transactions can query the data. Multiple Services, I think you should go for database for service as it will then be accessed by Microsoft versus API itself, right? So H microservice will have its own database ID, which thereafter prevents the other services in the system to use that particular database, right? So only that particular micro service are can access a specific database present for that particular microservice itself, right? So apart from this to solve the issue of denormalization, you can go forward with the share data bases per service to align more than one. Database for each microservice. So what will happen is that this will help you gather data for the monolithic applications which are broken down into microservices. But you have to keep in mind that you know, you have to limit this databases to two or three microservices else scaling. These services will be a big problem. Right? So guys that was about the database design patterns. Let's move forward with the next design pattern that is the event sourcing design pattern. So the event sourcing design pattern basically creates events regarding the changes in the application. Date so these events are stored as a sequence of events to help the developers track with change was made when and by home, right? So with the help of this you can always adjust the application state to cope up with the past changes and also you can query these events for any data change and simultaneously published events from the event store. Right? So once the events are published you can see the changes of the application State on the presentation layer, right? So that was about event sourcing design pattern guys event sourcing design patterns. Is basically used to create events regarding the changes in the application state, right? You've done a specific change and maybe you want to go back to the previous change that you have done. You can always use this particular kind of pattern to go back and see what changes was made and when and by home, right? So that was about event sourcing design pattern guys. Let's move forward with the next design pattern that is Branch pattern. So what do you understand by Branch? Pardon obviously as the name suggests, it's all about branches, right? So for a specific service, you can have different branches. Right. So the branch might the service design pattern is basically a design pattern in which you can simultaneously process the request and response from two or more independent microservices. So unlike the chain design pattern that are discussed before the request is not passed in the sequence, but the request is passed two or more mutually exclusive microservices chains, right? So this design pattern basically extends the aggregated design pattern and provides the flexibility to produce responses from multiple chains or a single chain, right? Right. So for example, if you consider an e-commerce application, then you may need to retrieve the data from multiple sources and this data could be a collaborated output from various Services, right? So you can use the branch pattern to retrieve the data from multiple sources, right? So the branch pattern is really simple to understand guys. It's basically where you want to simultaneously process the request and the response from multiple microservices, right? So these could be either in a single chain, or maybe it could be in multiple chains also, but yes, it's not necessary that you At the request of the response is done in a sequential manner. So guys that was about the branch battle. Now, let's move forward with the next pattern that is command query responsibility segregated design pattern. So command query responsibility segregated design pattern or more commonly known as cqrs is basically used when you want to query for a specific data right now. What happens is that you know, when you have microservices design in the form of database for service or shade database with service, what happens is that you know, you have limited Access to database right? So basically you cannot Implement a query as the data is limited to only a single database. So in such scenario, we basically use the cqrs pattern. So according to this pattern what happens is that the application will be divided into two parts that is command and query. So the command part will basically handle all the requests related to create update and delete while the query part will take care of the materialized views, right? So the materialized views are updated through a sequence of events, which are created. I think the eventsource pattern that I just discussed before so in the cqrs pattern guys, you basically divide the application into two parts. That is the command and the query the command will take care of the request energy to create update and delete and the query part would basically take care of the materialized views, right? So with the help of this pattern you can make sure that you know, you have good access to your data bases and then the clients request is satisfied. Also, you can make sure that you know, your materialized views are updated through a sequence of event which are again created using the event sourcing design. Turn so guys that was about the cqrs pattern. Now, let's move forward with the next pattern that is circuit break pattern. So the circuit break pattern as the name suggests is basically used to stop the process of request and response if a service is not working. So for example, let's say a client is sending requests to retrieve data from multiple services, but due to some issues one of the services down. Now, there are mainly two problems which will see first. The client will not have any knowledge about the service being down, right? So he or she will be continuously sending the request to that particular service. The second problem that we see is basically the network resources will be exhausted with low performance and bad user experience as the client without knowing will be waiting for the response to come back. Right? So to avoid such problems, what you can do is you can go forward and use the circuit break up design pattern. So with the help of this design pattern the client will invoke a remote service via proxy the proxy will basically behave as a circuit barrier. So whenever the number of failures Cross the threshold number the circuit breaker trips for a particular time period and then all the attempts to invoke the remote servers will fall in this timeout period right? So once that timeout period is finished the circuit breaker will allow a limited number of tests to pass through and only if those requests are succeeded the circuit breaker resumes back to the normal operation, right? So just in case if the test don't go through then they will be a failure and the timeout period will begin again, right? So in this particular pattern everybody have to understand is that is basically that No, when the number of failures cross a threshold number the circuit breaker will trip for a particular time period and then all the attempts to invoke that particular service will fall in that particular period right once that time period is done what will happen is that you know as the circuit breaker will allow a limited number of tests to pass through and only if the test succeed it will resume back to normal operation else. It will show failure again and again the timeout period will begin again. So with the help of circuit breaker pattern guys, you can make sure that you know, there's no exhaustion of the network. Horses with low performance and always the user experience is kept under good bloat, right? So that was about the circuit breaker design pattern guys. Now, let's move forward with the last design pattern for today's session that is decomposition design pattern. So micro services are basically developed with an ID on the developers mind to create small services with each having their own functionality, but breaking an application into small autonomous units has to be done logically, right? So to decompose a smaller a big application into small services. You can go forward and use the decomposition patterns. So with the help of this patterns, either you can decompose an application based on the business capability or based on subdomains. So for example, if you consider an e-commerce application, then you can have separate services for orders products and customers if you decomposed by business capabilities, but in the same scenario, if you design the application by decomposing by subdomains, then you can have services for each and every class so here in the example that had considered before that is the e-commerce. Even if you consider a customer as a class, then this class will be used in customer management customer support customer query and so on right so to decompose you can use the domain-driven design through which the whole domain model is broken down into sub domains. Then each of these subdomains will have their own specific model or a scope that is basically the bounded context. So now when a developer designs microservices, he or she will Design those services around that particular scope or bounded context, right either you can decompose Says by business capabilities or buy domains right now. Obviously these patterns might be sounding very feasible to you. But yes, these patterns are not feasible for a big monolithic application. This is because of the fact that you know, identifying subdomains or business capabilities is not an easy task for big applications. Right? So the only way to decompose big monolithic applications is by following the wind pattern or the Strangler pattern. So the wind pattern or the Strangler pattern is basically based on the analogy. To a wine which basically strangles a tree that it is wrapped around right? So when this pattern is applied onto web application a call goes back and forth to each you are I call and the service is broken down into different domains. These domains are then hosted by separate Services, right? So according to the standard pattern two separate applications will live side by side in the same URI space and one domain will be taken into account at an instance of time So eventually what happens is that you know the new refracted application. Actually wraps around or you can say strangles or replaces the original application until you can shut down the monolithic application. Right? So guys that was about to strangle pattern and I hope you have understood what is the composition pattern. So in the session guys will focus on the different tools that you can use to manage your services. All right. So without wasting any further time, let's take a look at the topics for today's session. So we'll start today's session by Understanding different tools used in micro Services based on various parameters or you can understand as used for different stuff. Right? For example, I'll start with different operating systems using which you can build your services then I'll talk about the different programming languages you can use to build microservices. Once I'm done with that. I'll talk about the tools for API management and testing the tools for messaging the different tool kits available in the market after that. I'll talk about the different architecture Frameworks the tool for orchestrations to tools for monitoring and finally the server list. So on that note, let's get started with today's session. But before we start with today's session, I would like to request all of you to subscribe to our idiotic our YouTube channel to get daily notified on the top printing Technologies. So on that note, let's get into the main topic for today's session that is microservices tools. Now, if you ask me what are microservices my answer would be really simple microservices tools are basically a collection of various tools and Technologies having different functionalities these tools are you Used in various stages of building an application and help the developer to work with he's all right, so they come with basically predefined functions algorithms and a very user-friendly gy to make sure that you know developers can build their applications in an easy manner not only this but startups to multinational companies have been using micro services in the day-to-day business activities today and to make sure that you know, they can build the application in an easy way many other companies are building of new tools and Technologies, right? So while building it Application using microservices. I will not see that, you know only a single tool is enough. Maybe I would say a couple of tools together will help you build the application in a more easy way. So on that note, let's look into the different tools that we can use for different purposes. So starting with the first one that is operating system. Now one of the most important factors of building an application is setting a proper Foundation of your application. So this is basically done by the operating system now, Lennox is one such operating system, which It is most commonly used in today's market to build applications with the help of Linux containers. It provides a self-contained execution environment and lets you orchestrate small to big services like security networking and storage. So if you ask me, what are the better choices of Linux family, there are with a red hat and Ubuntu are the go-to solutions for anybody in today's market, but they come with a lot of unnecessary functionality which are not needed for microservices apart from these Linux providers have also come up with tools such as Dominic red hat and Ubuntu including lxt, which is basically a container oriented hypervisor. So I would say that, you know, you can go for any operating system that your company chooses to build an application or maybe you're comfortable with but Linux is one such operating system, which is growing in today's market and helps developers to build the applications easily. Now, let's move forward with the next one that is programming languages. Now the main advantage of microservices that different languages and Technologies can be used Used to build different Services of the same application. So what I mean by that is you know, let's say you have five services in the same application. Now the first service can be built using python the second one can be built using Java the third one can be built using go programming language and so on so it basically gives the developers to freedom to choose the technology stack and build the application. But the most popular programming languages used in microservices our spring Boot and Alexia. So talk about spring boot first springboard. Please simplifies the creation of recipes microservices with the help of spring boot Frameworks in just a few lines of code. Right? So if you ask me the features of springboard, then it provides auto-configuration to load a set of default configurations for quick start of the applications. It comes with embedded termcat servlet containers and Jetty to avoid the usage of War files springboard also has an opinion to reduce the developer effort and simplifies the main configuration and finally it consists of a wide range of apis for monitoring and managing. Applications in the development side and also on the production side. So springboard is one such programming language guys, which is very famous in the field of microservices and you would always see that you know developers are trying to build microservices using this particular framework. All right, so that was about springboard next. Let's move forward with the next programming language. That is Alexia. Now, Alexia is a general-purpose programming language which runs on the alang virtual machine now Alexia shares the same abstractions for building fault tolerant and distributed. Applications so if you want me to mention few features of Alexia that I would say developers can easily write the code in short fast and maintainable banner. This code basically runs an isolated light with processes which can be scaled individually. For example, let's say, you know, you have five processes, right and you don't want to scale the particular process, but you want to scale up the are the processes. Well, you can definitely do that apart from this Alexia. Also, make sure that you know, the application never goes down by providing the supervisors. So basically the supervisors How different parts of the system can be restarted if something goes wrong and that is the main objective of microservices. Right? So our main objective is basically that you know, even if a particular service is gone down that doesn't mean that you know, the application will go down instead the bug in that particular service has to be resolved and then the service has to be restarted and finally coming to the last feature that you know, this programming language comes with its own build tools to create projects manage tasks and run the required tests. So Guys, these were the two programming languages which are very popular. In the field of microservices next in the session. Let's look into the different tools used for API management and testing now while you start building applications using micro Services. You also have to make sure that you know, all the Individual Services communicate with each other using apis. So each microservice can have its own API to communicate with the other servers. So this is where basically the API management and testing comes into the picture where all the apis are present in the system and must be properly managed and It to get the desired results. So if you want to know more about micro services and apis and how apis and microservices collaborate with each other. You can refer to my session on micro Services versus API. Now the top tools used in API management and testing are basically the postman and the API Fortress. So starting with Postman supposed. Where is basically an API development suit, which allows you to easily run UI driven API test with the help of Postman the exploration of restful API the sources Comes very easy. So what I mean by that is that you know with the help of Postman you can basically pass HTTP request to test develop and get the required results. Now few features of Postman are as you can see on my screen Postman basically integrates with your software development life cycle in he's it provides features to design apis and maintain multiple versions of API with support this tool can work for small applications to Big application and it also supports collaboration of work by allowing you to save related API. High end points into a collection now, once that is done. What you can do is you can go forward and share the entire collection to the other developers. So Guys, these are the few features of Postman next. Let's move forward with the next tool. That is API Fortress Now API Fortress Is both an API test and help tool which automates the process of load testing Health monitoring and functional testing. The stool is basically a code free and is built around modern APA architectural patterns and practices. So if I have to mention few features of API Artists for you, then this tool is highly interoperable with any platform that you choose in your tool chain and validates apis built in API management platforms. It also simplifies API test creation and execution by providing a drag-and-drop gy the store also aims to simplify the end-to-end testing by providing easy generation of functional tests and also focuses to simplify the collaboration by storing the tests and reports in a collaborative environment to make sure that you know teams can validate their own apis if it Sighs the business case. So Guys these with a few features of API Fortress now once you know the tools for a pain management and testing the next thing that comes into a micro service system is basically how the services communicate with each other while these Services communicate with each other using the messaging system. So the different tools available for messaging our Apache Kafka and rabbitmq. So talk about Apache Kafka first this tool is a distributed publish/subscribe beseeching system originally developed at LinkedIn and On became a part of the Apache project Kafka is scalable and agile and is distributed by Design. So Apache Kafka is a distributed stream processing platform, which can be used for data processing or API calls. So few features of Apache Kafka or as you can see on my screen Kafka has high throughput for publishing and subscribing messages to maintain stable performance. This tool guarantee is zero downtime and zero data loss in a pasture Kafka message is purses on the desk as fast as possible and many applications. Can plug in and make use of this tool as it offers new right connectors. So Guys. These are the ways features of Kafka. Let's move forward with the next tool. That is rabbitmq. Now this tool utilizes patterns to communicate between micro services and also scale application simultaneously with the help of this tools. You can basically connect microservices with each other to solve problems of various distributed systems. Not only this but you can also use this tool to exchange events between individual microservices now the Just of rabbitmq are as you can see on my screen this tool basically offers a variety of features such as reliability delivery acknowledgements, including persistence publisher confirms and higher availability by using this tool messages are routed through exchanges before arriving at the q's rabbitmq comes with the Federation model and allows the service that need to be more Loosely and unreliably connected and also supports messaging over multiple messaging protocols. So Guys, these were few features of rabbitmq now, Once you know you're done with your API management and messaging the next thing is basically that comes on to everybody's mind is toolkits. What do you understand by toolkits? What toolkits in layman terms is a set of tools used for a specific purpose. So in microservice architecture also, you can build various kinds of application using different tool kits that are available in the market. So the most popular tool kits available in the market are fabricate and Seneca. So talk about fabricate first. So fabricate is a I saw was tool which helps with developers provide configuration management system true get it is an open source tool which handles Port mapping and IP addresses complexity. So this tool basically holds the responsibility to load balance services with high availability and scalability. Now the features of this tool are as you can see on my screen it provides a set of wizards to create application fasters and set up continuous delivery pipeline fabricate also comes with on-premise Git repository hosting this tool provides me with the positive. Manager promoted releases along with the mirror of Central Maine with repositories and provides the developer console to create build manage microservices with deep visualization into the projects applications and environments now talk about Seneca first. Seneca is used for building message-based microservices processes. And thus the toolkit for node.js so this toolkit helps you to write clean and organize code which systematic business logic of the application so few features of cynical as you can see on my screen says Uh provides plugins which look after the foundation of the application. You do not have to worry about which database has to be used and how to structure your components with Seneca in Seneca. Everything is written as a command and these commands get called whenever they match a set of properties and the code that you call does not know which command is calling it. So guys, this was all about Seneca now since you have understood about toolkits also, the next thing that I would like to talk about is the different architectural Frameworks. So architecture framework is an important factor while building applications using microservices and top to architecture Frameworks used Argo and conch talk about go first. So basically go a is an architectural framework which provides a way to build rest apis and microservices using go line with the help of this architecture framework. You can design apis along with this required dependencies and this framework runs on top of the Google Cloud platform few features of go are as you can see on my screen this tool also lets you generate Structures validation of code and handlers once the design of API set it has a decoupled engine and provides plugins which can Implement custom dsls and also generate arbitrary outputs. So that was about going guys moving onto cam Congress used for ready to deploy plugins for enhancing the development and deployment of microservices with the help of this tool. You can leverage the container and microservices design patterns to quickly build API Centric applications. Now I've used this term microservices design patterns, right? So if you have to understand this term, it's basically a pattern or you can say or software pattern through which a company follows based on which the application is built. So if you want to know more about Microsoft's is design pattern, you can refer to my session on microservices design pattern. But until then moving back to this particular session, if you ask me the features of Kang then congruence plugins to extend and connect Services across hybrid and multi-cloud environments it analyzes real-time data and leverages ecosystems to deploy Kong with kubernetes. Kang connects with automation tools to improve efficiency and reduce errors and provides role-based access control and encrypts end-to-end to comply with the industry regulations. So guys that was about the different architectural Frameworks present in the world of microservices. Now, once you build an application using Microsoft versus the next thing that comes into our mind is to how to scale the application will to scale this application you have to use an orchestration system as microservices work with respect to containers and so container orchestration. Comes an important aspect that has to be considered. So in today's market, there are various tools regarding the container orchestration for microservices, but the top tools available in today's market our communities and sto so talking about communities first communities is an open source container management or you can understand as an orchestration tool this tool basically owns the responsibilities of container deployment scaling and descaling of containers and container load balancing. So if you ask me if your features of communities and I would say Of these can help you to deploy an update secrets and application configuration without rebuilding your image and without exposing secrets in your stack configuration. In addition to managing Services communities can also manage your batch and CI workloads. Thus replacing containers that fail if desired not only this but Cuban it is only needs one command to scale up the containers or two scales in down whenever you're using CLI as scaling can also be done by using the community stash food, right? So if you want to know about dashboard also, You can defer to my session on Cuban piece dashboard and finally coming to the last feature that is with kubernetes. You can mount the storage system of your choice what I mean by that is that you know, you can either opt for a local storage or choose a public cloud provider like gcp or AWS or perhaps use a shared network storage system like NFS or iSCSI. So that was about Commodities guys. Let's move forward with the next to that is STO now this tool support service deployment on communities. So it basically provides features. As for manageability security and reliability to microservices communication now if you ask me, how is it done? Well, the answer is quite simple. It is basically done by the service mesh technology which allows you to improve the relationships and interactions between applications and microservices so few pages of sto as you can see on my screen it performs automatic tracing monitoring and logging of the services this tool automatically secure services to manage authorization authentication and encryption of communication between In Services, it also controls the flow of traffic and API calls between Services conducts a range of tests and upgrades with red or black deployments and finally also applies policies and ensures that their infos and resources are fairly distributed among the consumers. So that was about is two guys now once API management is done, you know messaging system is done and then you have your tools for orchestration. Also, the next thing is to monitor your application. So to monitor your application the top tools Can be used as Prometheus and locks - so talk about Prometheus. First Prometheus is a monitoring tool which basically allows visualizing monitoring information and supports time based tracking for anomalous patterns, which have to be detected. Also. This is an open source tool which basically gathers monitoring information. So the features for Prometheus are as you can see on my screen, it provides a flexible query language, it comes with distributed storage and single server nodes, which are autonomous it. Uber's targets wire service Discovery or static configuration and provides dashboarding and graphing support now talk about the next monitoring tool. That is logstash. Logstash is also an open source tool through which you can check the logs this tool basically lets you stash centralized and transform data. So the features of logstash are as you can see on my screen, it supports a variety of inputs Which pull in events from multitude of common sources all at the same time the stool aims to transform and prepare data. Let's of its complexity. It also allows you to choose your own stash and transport data. And finally it is a pluggable framework consisting of over 200 plugins to create and configure pipeline as you want. So that was about logstash guys the finally moving on to the last part of today's session that is Sir will is tools now these tools are part of micro Services which optimize the methodology of breaking stuff into small functions. So few surveillance tools that are very popular Claudia dot Chase and AWS Lambda. Talking about Claudia first Claudia is a surveillance tool used for deployments for a double s Lambda and API Gateway this tool automate error-prone deployment and configuration tasks and also contains tools such as Claudia bot Builder and Claudia a pi Builder. So features of Claudia are as you can see on my screen it lets you deploy an update using a single command. It reduces the boilerplate code with the help of this tool. You can also manage multiple versions and you can use standard npm packages and do not have to learn. Either the so that was about Claudia now moving forward to the last tool that is a double is Lambda. Theta plus Lambda is basically a tool which provides infrastructure less servers for your microservices bills. And the user is charged based on the paper usage rate. This tool can be used in combination with the AWS API Gateway to host a rest API service and with the help of this you can serve any requests made by the users. So if you ask me few features of a double s Lambda, then I would say this tool enables you to run your code in response to the events and automatically managed to dependent compute resources. It lets you run the code without managing the server. So it pays as you use the service and you only pay for the compute time consumed this tools case an application automatically by running a code for each trigger. And finally I would say this tool can be used to build a server as back in for processing mobile apin web request. So guys, this was all about a double s Lambda. I hope you've understood all the tools that are discussed here. Was just a short introduction to all these tools in today's market Will Industries are using various software architectures and applications. It's almost next to impossible to feel that your data is completely secure. So while building these applications using Microsoft's has architecture security issues become more significant as Individual Services communicate with each other and the client. So in the session guys will mainly discuss the various. Ways you can implement the secure your services? So on that note, let's get started with today's session. So the topic for today's session are as you can see on my screen will start this session by understanding the problems faced in microservices. After that. I'll tell you the best practices to secure microservices. Well guys the methods that I tell you are not the only method well, I would say in Microsoft's architecture. You have the complete freedom to secure your services based on the application or the architecture that you have right? So on that Note before I start with the session I would like to request all of you to subscribe to our a Dirac our YouTube channel to get daily notified on the top trending Technologies. So let's get started with the recession. Let's understand the problems faced in microservices. Well, the problems faced in microservices are as you can see on my screen starting with the first problem consider the scenario where a user needs to login to access a resource now in micro service architecture, the user login details have to be saved in such a manner that the user Not ask for verification each and every time he or she tries to access that particular resource right now. This creates a problem as user details might not be secure and also could be access by Third parties now obviously guys to anybody use a credentials are the most important credentials which have to be secured right now in a scenario where a client is looking to an application to access a resource. The application gets the complete credentials of the user. Now if the credentials are not secured by those services, and that's definitely a A problem because anybody can exploit it. So that is one problem that I clearly see problem. Number two is basically I would say when a client sends a request then the client details need to be verified and also the permissions given to the client needs to be checked. Right? So when you use Microsoft versus it may happen that you know for each and every service you have to authenticate and authorize the client. So authenticate is basically to check what permissions are given to you and authorize the client is basically to check who are you right? So basically the user credentials are checked now, too. Devon oppose might use the same code for each and every service, right? So what I mean by that is when a client is trying to access to data from different Services. It may happen that you know, the plan details have to be checked to make sure if the data has to be sent to that person or not right now to check that maybe a specific code is used in all these services for a specific application like service ABCDE can all use the same code to check the authenticity of the client, but don't you think relying on a specific code reduces the You of microservices. Well, obviously, that's a yes, right. So this is one of the major problems. Also. I see in the micro service architecture that the complete application having various Services is based on a single code base and let's say you build an application now with that particular code in all the services to check the authenticity of declined but let's say after 10 years that particular code doesn't work. Now you have to change the code for all these services and in the same time. You also have to make sure that you know, nobody is exploiting the data from the services because there will be no security layer then right? So this is one major problem that I see that you know that has to be catered. So the next problem that is very prominent in this particular architecture is basically the security of each individual microservice. Now what I mean by that is basically in this architecture all the Microsoft is communicate with each other simultaneously in addition to the third-party applications, right? So when a client logs in from a third-party application, you have to make sure that you know, the client does not get the access to the data. Services in a way that you know, he or she might exploit them right so it obviously makes sense because he's logging from a third-party application. Now maybe that particular application is not that secure so maybe instead of the client the third party application is basically trying to access the data. So we have to make sure that you know, the data is secure and not every application is given access to the data in the services. Right? So Guys, these are few problems that I see very much prominent in Microsoft's architecture. Well, there could be lot of other problems based on secure. Aditi of microservices, so these are few problems that I thought would be very prominent right now obviously seeing so many problems. We have to figure out a way to secure our services right now to secure our services. All we can do is we can put up security layers firewalls and you know use some methods to make sure our services are secure right? So on that note next in the session, let's see the best practices for microservices security what the best practices for microservices security a lot. I would not say the ones that I mentioned are the only ones there are a lot of ways to which you can secure your services, but I would say these are few methods, you know to which you can start at least securing your services or maybe you can figure out a way to at least make sure your data is secured. Right? So let's start with the first one that is defense-in-depth mechanism. Now as microservices are known to adopt any mechanism on a granular level, you can apply the defense in-depth mechanism to make sure that you know, the services are more secure now what I mean? By that is that defense-in-depth mechanism is basically a technique through which you can apply layers of security countermeasures to protect the sensitive services. So as a developer, you just have to identify the services with the most sensitive information and then apply a number of security layers to protect them. So in this way, you can make sure that you know, any potential attacker cannot crack the security on a single goal and has to go forward and try to crack the other layers in the defense mechanism, right? So basically if you say No, so it was B is the most sensitive service which has, you know, a lot of information which has to be secured. Right? So what you can do is you can basically have layers of security and maybe if some attacker cracks the security of the first layer he or she has to still go and crack the other layers, but by that time you'll definitely understand that, you know, there's some problem in security happening and then you'll again secure Services right also since in the micro service architecture, you can Implement different layers of security on different services and attacker who is successful in exploiting In a particular service might not be able to crack the defense mechanism of the other services. For example, let's say you have service a and service B and let's say, you know, you have few layers of security and service a and few different layers of security and service speed now, maybe an attacker who has attacked service a and has cracked the security might not be able to do the same with super speed. Right? So that was about the defense-in-depth mechanism guys. Let's take a look at the second best practice that is usage of tokens and API Gateway now often when you open an application. You see a dialog box thing accept the license agreement and permission for cookies right now. What does this message signify? Well, once you accept it, your user credentials will be stored and a session will be created. Now. The next time you go on the same page, what will happen is that you know, the complete page will not be loaded from the server but will be loaded from the cashier memory, right? So I hope that's clear. So for example, let's say, you know, you open book my show.com. So now the first time that you open and then you accept the license agreements on the cookie permissions It would happen is that your user credentials will be stored and a session will be created. Now the next time again, maybe sometime later you open book my show again that particular page will be retrieved from the cache memory rather than the service itself right now before this concept came. It is picture sessions with stored on a server side. Centrally. Now. This was one of the major problems as you know, storing the session centrally was being a barrier to horizontally scaling the application. So to overcome that what people started doing is basically everybody started using tokens. NEPA gateways to secure the services right? So what would happen with tokens statue? No tokens would be used to record the user credentials. So basically you can understand that you have to conserve used to store the user credentials. So these tokens are used to easily identify the user and are stored in the form of cookies. Now each time a client requests a web page. The request is forwarded to the server and then the server determines whether the user has access to the requested resource or not. Right now the main problem which is prominent in tokens is That the user information is toward right? So the date of the tokens needs to be encrypted to avoid any other exploitation of from third-party resources and I would say JWT or most commonly known as Json Web format is an open standard which defines the token format to provide libraries for various languages and also encrypt the user details, right? So guys just to avoid storing sessions centrally what people started using is tokens now tokens are used to store the user credentials and since the user credentials. Stored into tokens tokens have to be encrypted themselves. So you can go forward and use JWT to encrypt the respective tokens right coming to API gateways. API Gateway is adds an extra element to secure the services to token authentication. So the API Gateway acts as an entry point to all the clients request and efficiently hides the micro services from the client. So the client basically has no direct access to the services and thus in that way no client can exploit any of these microservices, right? So what happens is that you have You have a client and then you have a pi Gateway Now API gate we will communicate with all the apis present in the microservices. Right? So basically a we are if you visualize the client has no direct access to the services instead. It's just the API Gateway and it's completely the responsibility of the API Gateway to forward the request of the respective microservice. So guys that was about tokens in API Gateway. Let's move forward with the third best practice that is distributed processing and session management the talking about Distributed raising all of you might be observing that you know, while you use microservices, you have to monitor all these Services continuously, right? But when you have to monitor humongous amount of services simultaneously that definitely becomes a problem, right? For example, if you just have to monitor fire Services then maybe that's an easy task but in a scenario, maybe if you have to monitor fifty or hundred tasks simultaneously and 24/7, then that's a problem right now to avoid such challenges. What you can do is you can use the method of distribution. Debated tracing so distributed facing is basically a method to pinpoint the failures and identify the reason behind it. Not only this but you can also identify the place at which the failure is happening. So basically with that you can easily track down which micro service is facing a security issue. Like for example, let's say, you know, you have five services and then there's some error happening at service be right so you can directly go and pinpoint that it is because of service be there's some failure and maybe then you can directly go and figure out that you know, Some security issue at service be rather than to check all the services and the complete application, right? So that's what distributed tracing helps you guys with makes you identify. Where is the failure happening? Why is the failure happening and then bit servers? Is it affecting moving onto session management session management is an important parameter that you have to consider while securing microservices. Now what happens is that a session is basically created whenever a user comes onto the application. So what you can do is you can handle these sessions in many ways. I could figure out free ways. The first way is basically you can store the session date of a single user in a specific server what I mean by that is the session date of user a is maybe we stored on the server a the session date of user B is basically stored on server be and session date of user see is basically stored on servers see right? So in that way you can make sure that if there's some exploitation of services then you can track down which user is doing it directly without having to figure out what is happening in all you can allocate track down that you know, maybe use a Is exploiting or user be your user see right? But the only problem over here that I see is that you know, if the system is completely based on load balancing between the services and it meets only horizontal scaling rather than the vertical scaling. So for small applications, which let's say, you know have three to four Services maybe this kind of system can be used but if you want to use this scenario for a large application that I think that will create problem right coming to the second way. Well, what you can do is the complete session data can be stored on A single instance then what can happen is that you know, the data can be synchronized to the network and the requested responses can be generated and you can also make sure that you know, the data doesn't go anywhere, right? So what happens is that you know, you have a single instance and then through Network. The data is completely circulated between services and the climb now the problem if you think over here is basically the exhaustion of the network resources, right? For example, let's say you need a data from 10 Services rate and all the data is completely stored on the single in stairs now. These Services have to communicate with that particular instance get the requested response and then finally sent back to client right now. This is a little bit problematic when you have that Services again, but I would say for small Services you can move forward right now. Finally coming to the third method. What you can do is you can make sure that the user data can be obtained from the shared session storage. So as to ensure that all the services can read the same session data, so what I mean by that is if you have fire services and the fire Services need the user data, then the the user data is obtained from a shared session storage to which the data can be retrieved. Right but since the data is retrieved from a shared storage you need to make sure that you know, you have some security mekansm to access the data in a secure way. So basically you have to make sure that you know, you add another security layer Maybe by using the defense-in-depth mechanism to make sure that you know, the data is encrypted with the help of tokens, or maybe you know, you have a specific firewall that you know, not all of them can access the data and no third party applications can access and only a few. Admins can access right so you can use it the way that you want. So guys that was about distributed raising and session management. Let's move forward with the next practice that is first session and mutual assistance. Now, the ideal first session is really simple guys. What you can do is basically when the users log in for the first time into the application, then they can access all the services in the application. Right? So what you can do is whenever the user logins for the first time you can store his or her details in an encrypted format in a secured way, so that it Don't have to keep verifying their credentials each and every time there are trying to access different servers. For example, if you have 10 services and maybe the user needs to log into all the 10 Services. What you can do is you can have an initial login and when the user logs in for the first time maybe he or she gets access to all these services, but the only problem over here is that you know, you have to make sure that you know, the user who is trying to login is a client himself and maybe he or she is not an attacker then is not trying to exploit the resources right coming to Mutual SSL. Applications often face traffic from users third parties and also microservices communicating with each other right but since these services are accessed by the third parties, there's always a risk of attacks. Now the solution to such scenarios is by using Mutual SSL or Mutual authentication between microservices with this the data transferred between the services would be encrypted and the only problem with this method is that you know, when the number of micro Services increases then each and every service will have its own TLS certificate. It will be very tough for the developers to update the certificates else. If I would say the developers are ready to update the certificate and maybe they're not scaling the number of services then I think they can go forward with this particular method. As you know, each particular service will have its own TLS certificate and that particular certificate will Define which Microsoft was has what access and which data can be retrieved from each of these Services. Right? So mutual SSL sounds like a good option guys. I think you should go forward or not. But the only thing is that when you're scaling your service. You have to make sure that you know, you have to update all these TLS certificates on that note. Let's move forward with the final practice. That is the third party application axis. Now all of us access applications, which are third-party applications. Right? So the third party applications basically use an API token generated by the user in the application to access the required resources. So the third-party applications can access that particular users data and not the other user credentials. Well, this was with respect to a single user but If the applications need to access data from multiple users, how do you think such request is accommodated? Well, I think the solution to this is by using Earth. So when you use all the application prompts the user to authorize a third-party applications to use the required information and generate a token for it. So generally what happens is that an authorization code is used to request a token to make sure that you know, the users callback URL is not stolen right. So in this way the user of the client communicates with the authorization server one mentioning the access token and also the authorization server authorizes the client to prevent others from forging the clients identity. So when you use microservices with odd guys, the services act as a client in the odd architecture to simplify the security issues, right? So I would say guys all these methods that you know that have explained you are one of the best practices that I've observed to secure your microservices, but if you ask my personal opinion, I think I would always go for allthe with a collaboration of JWT that is basically generating client tokens. I know Bees follow the defense-in-depth mechanism to make sure that you know, there are a number of security layers to my services so that the data stored in my services is completely secure. Right? So if you're someone who is aspiring to build an application based on microservices, the remember that the security of the services is one important factor, which you need to be cautious about today. We are going to take a look at top microservices interview questions. And by the time we are done with the session, I'm sure that you all would be in a very good state to go ahead and crack any microservices interview. So let's not waste any time and quickly get started then so the first question is what are microservices now think of it as an approach towards software development. What do I mean by this? What this approach does is it aims at having small autonomous services that Focus towards a common business goal. Now as you can see in this image, what we have is we have a number of business domains and surrounding that are certain micro services. Not each of these micro Services they focus at a particular business functionality only that means if a particular business domain has a twenty functionalities, each of microservices should focus at one functionality only for 20 micro Services 20 corresponding functionalities. So that is how you simplify an architecture and this approach is called as microservices architecture as we move further. We would be understanding a lot more points and Concepts about microservices. So your have A lot more clearer picture as to what a micro service exactly is. Meanwhile, you just bear with me so that we can move further and discuss the other questions as well. So what are the advantages of microservices architecture the quite a few advantages to be honest. These are some of the important ones which we have jotted down. The first one is independent development. Now when you talk about microservices, you have to relate it to this point because we are talking about having an individual micro service for individual functionality. That means for each functionality. And develop a separate service and you can manage it and control it totally apart from that. We also ensure independent deployment. That means if you have developed a single service, you can go ahead and deploy that service you do not have to wait for the complete architecture or other services to be ready and up for deployment. Even if there is certain amount of change in a particular service. You have to make change only to that service and then deploy it again you do not have to deploy the complete. Architecture here fault isolation. Now, if a particular micro service goes down. It does not affect the functioning of other services. Now, what do I mean by this? Say, for example, I have an architecture where I have some 20 applications or 20 Services working parallely, if one of the application fails at times what happens is these applications are interdependent as it is in the case of a monolithic architecture basically, if one of the system fails or one of the services Fields, it takes the whole system down now, this is not true with Says if one service Fields, it does not affect the functioning of other services in any possible way mixed technology stack. Now, what do I mean by this? Well, since you have different micro services and you have an independent approach towards development, you can go ahead and pick the technology that suits the need of that service and accordingly. You can have a mixed technology stack for a complete architecture granular scaling on this is an important Point scaling can be a huge problem because again, you have to take into consideration the complete architecture but Since you're having small Services, you can actually go ahead and scale those independently again, these are some of the advantages which I just mentioned. So let us move further and take a look at the next question as well. What are the features of microservices? Well, the first feature is decoupling. That means your applications can be easily decoupled or rather separated to have individual functionality. And that means it assures easy development maintenance and deployment componentization. Now this point is similar to the first point. But it is little different what happens here is every micro service is treated as an individual component and it is responsible or manages all the intricacies as far as a particular Services concerned and it focuses only on that. It is Loosely coupled with other services. That is why each micro service can be thought of as a single component or a container business capabilities now business capabilities can be focused much better because why since you are setting up smaller goals as and you focus on individual functionalities, it becomes easier to go ahead and develop applications to meet these requirements. As far as the business is concerned autonomy. What happens is your developers are now free because you are talking about small clusters of teams and they're free to go ahead and develop the applications that means other teams and developers. They aren't interdependent on each other this, uh shows Speedy development of software basically continuous delivery now since you have so many features with Just discussed this ensures that you have constant and frequent releases of software's and a system can be continuously updated and basically modified as per the needs of a particular company or a particular business domain rather responsibility what happens in this approaches every domain or every project is treated as a product that means a team will take responsibility of that so-called product and they'll bring it to life and it is their responsibility to build. It tested and carry on with the whole life cycle. That means people are supposed to take in responsibilities of the micro service that is there. And this helps in a much better architecture other decentralized governance. Now, what happens is since you have individual applications, it is very important to have an independent approach towards the life cycles of each micro service since they are working independently. They should be managed independently as well. And this also brings in another concept into picture which is decentralized data management. As we move further we would be discussing that as well agility. Now what happens is since you have a decentralized architecture here, you can easily go ahead and build applications and also discard them if they are not needed so it gives you a lot of agility basically. So these are some of the features of microservices let us move further now, what are the characteristics of microservices now first few questions might sound a little repetitive because these concepts are kind of interlinked so we would be discussing quite a few Concepts again and Again, but as we move further, the breadth of questions are the type of questions would definitely very and we would be having much more new topics to discuss this question on the other hand might sound a little repetitive. So just bear with me. Let's quickly walk through it and let me just try to give him some answer to this question in a little different perspective other so firstly we have organized on business capabilities. Now, what do I mean by this? Basically what happens is since you have individual microservices here? What happens is you have an application? That works on its own. You also have a database that corresponds to individual microservice. That means if you have 10 Micro Services, you'll have 10 individual databases that are corresponding or answering only to that particular microservice. So this gives you a complete decentralized structure and this also means better organization because every micro service is very clear as to what it is supposed to do and it has all the resources in that single container as to this is what is to be done. And this is what we are. Ston and that is why this organization or better management comes into picture products are not projects know. What do I mean by this? Well, basically what happens is suppose you have against it then microservices and you'll be having small clusters of team who would be responsible for building up this application and also maintaining it now what Amazon things is you should have a tupiza team. Basically, what do they mean by this? Well, they mean is you should have such small team that can survive on too. Users and they should also be able to go ahead and maintain the software. So every responsibility as far as a software and application is concerned. It is given to that size of a team that is that can survive on to pieces this ensures modularity. That is why when you talk about microservices, basically you're talking about products when you talk about a team, they're focused on a particular functionality and that functionality is not as a project for them. It is more of a product for them smart endpoints and dumb pipes now, basically this means that you have different Equations and the quite decentralized and there has to be a way of communication basically, so you should have smart and points and good ways to integrate your applications with each other decentralized governance. We've already discussed this Poncho, I would just skip this point for now these centralized data management. We've also discussed this that means you're free to have an individual approach where you have your own database and your single database in a microservices treated as an individual entity or a container rather infrastructure automation. This is an important point now since you have so many microservices. It is important that there is proper automation. This ensures Speedy development and also maintenance design for failure. Now, this is another important point. Now your applications are such built that they do not hamper the progress of any other applications even when they feel but still you need to have a mechanism that takes care of failure as well. So you have real-time monitoring and Analysis here which ensures that if an application goes down the Possible action is taken. So that that application also comes back to running and also it does not hamper the working of any other applications in any possible way. So what are some of the best practices to design microservices now it is pretty evident. You can just go ahead and read these points and you'd understand what it means firstly you need to have a separate data store for each micro service, which we have already discussed this one because we have a database which corresponds to particular micro service basically keep code at a similar level of maturity. Now, what do I mean by this? It means yes. You have enough freedom to go ahead and build application the way you want to but each of these applications are at a similar level of understanding when you talk about a similar level of understanding you're talking about a similar level from the business domain perspective and what this means is all the teams are on a similar page even though they're working on different things. They all are on a very same level when they're working separate built for each microservice. Yes, we've discussed this already these micro Services they get deployed in containers as we Move further would be understanding what containers are and what they do exactly and it treats servers as stateless this helps in better communication. Basically, what is a DDD now? It stands for domain driven design again. It is an approach an approach that actually helps you collaborate all the teams together and it also helps you simplify the creation of complex applications. Now what this does is it focuses on codomain and core logic at times you let go of what is right for you rather you focus only on the business. Men, that means this is what the business domain needs and this is what we would include in this architecture. This kind of an approach is called as domain driven approach or a domain driven design. Basically now, what they do is that try to bring again every team on the very same page and you would be using something called as a ubiquitous language which helps you achieve this domain driven design approach. Now, what do you mean by a ubiquitous language to give you an example suppose? I have a ticket reservation system for flights now. here all the terminologies that are used would be related to maybe aeroplanes flight attendants customers and all those things now, even if a manager refers to this so-called architecture, you should be able to understand the terminology that are used here and also the developer that means we are bringing every team on the very same page and a language that does that for you is called as a ubiquitous language now again, a cubic lattice language would be designed in such a way that it focuses around a particular domain and Architects that is developed out of it is called as a domain driven architecture. What is a ubiquitous language? We just discussed that so why is there a need of a domain driven design? Yes, the quite a few reasons actually firstly we need to understand that here. The focus is on a particular domain. So if you take a look at the last point on the left bottom side of the slide, you would understand that. It is mapping to a domain that means we are mapping our architecture to a particular domain that means you're focusing on on that particular day. I mean now this helps you reduce complexity why because your concern is just that domain again testing the application also becomes easier and maintaining it also becomes easier because everybody is on the very same page knowledge design. Yes. This applications are very heavy on knowledge that is particular or that is very much focused on a particular domain it brings business and service together and it is very context focused. Plus it uses ubiquitous language. So, how does the architecture of Microsoft's work and when you talk about micro Services architecture now, there is no particular pattern for this kind of an architecture because it can be very complex at times. And if you have n number of micro Services, all of those will have different architectures, but you have to understand one thing the base Remains the Same that means no matter how complex or how big actually the architecture will never become complex. But yes, it might become big because we might think of having n number of micro Services maybe thousands and even laxatives. Required if the application is that big but let's say that you have an application which is huge in size. No matter how huge it is it would never get complicated because we are developing small applications here. And each of these small applications will have an architecture that is more or less like this or at least would be on these pages. So what do we have here? Basically, we have a client and identity provider. We have API Gateway static content CDN, which is nothing but content delivery networks we have Travis has a management and a service Discovery portal or a model rather and you have your servers and all those things and basically what happens is if a client wants to use a particular service the client would send in a request now it is the job of an identity provider to verify whether the user is valid or not. Once the identity provider authenticates a user the request is then forwarded to API Gateway because a client cannot directly communicate to a service that has to be an intermediary or something. Intermediate approach that lets us communicate with the micro Services as well. Now in this case. What happens is we have a pi Gateway. Now this API Gateway, it finds the right service that a client is looking for and the request is forwarded to that service the service does it basically communicate with other services and sees how a solution is generated for this so-called client. And once the solution is generated it is sent back to the client using Siri. And that is your content delivery Network. Now the static column basically what happens is whatever content that is generated and Is in the form of static it is basically held by a static content and the management and the service Discovery Porter 's they have a particular task as well. What they do is say for example, I have a number of services now the Management console or the portal places those services on respect your notes service discovery on the other hand keeps a track of all these Services makes note of services that have failed and all those things and this record is communicated back to the management portal and it is the job of this management portal to go ahead and resolved if there is any Failure in the corresponding architecture or any of the services. So these components all of them they work in Tandem and this is how they bring the architecture together apart from that there some other Concepts which are not there in this architecture say for example, the messaging module basically, so we have an approach where messaging also happens in case if the client is waiting for a particular reply from a service in that case. We have a way of communication and that we have communication is through synchronous message passing and if the One be waiting for a response from the service in that case. We have a synchronous way of communication. So yes, there are those little components which are not there in this diagram, but they do exist and as I've already mentioned based on every architecture it might be a little different but this is how the general idea is when you talk about a micro Services architecture. So let us move further and take a look at the next question as well. So what are the pros and cons of micro service architecture? Well, we've discussed most of these points already, especially the pros we've already discussed those. So I'm just going to read them quickly and switch to the con spot and discuss those as well freedom to use different Technologies discussed each microservice focuses on a single business capability discussed support individual Deployable units discussed allows frequent software releases ensures security of each service and multiple services are parallely developed and deployed. And what are the cons it increases troubleshooting challenges and increases delay due to remote calls? Yes. This can be a problem by because you're talking about a number of micro services and at times since they are so independently working that the whole system as an architecture when you talk about troubleshooting certain challenges, it can be a problem because we are talking about a complete decentralized governance, but that is something that can be managed. And as I mentioned we have different portals that take care of all the services and and these searches are since monitored in real-time. This does not become a huge issue increased effort for configuration and other operations. Yes configuring these applications can be a problem. But then we have something called as rest apis that ensure complete integration of these services. And again, this issue can be taken care of difficult to maintain transaction safety security can be an issue and that is a concern that affects almost every software and you cannot be hundred percent secure. Any possible way but this approach gives room for security as well tough to track data across various service boundaries. Yes, again individuality may not be always good. So this can be a drawback and difficult to move code between services but that is not needed in most of the cases. So that is not a problem here again. So these were some of the cons and the pros which we've already discussed. So let us move further and take a look at the next question. What is the difference between monolithic SOA and a Service architecture. Now when you go back in time, the first architecture that we had was a monolithic architecture. That means you had a single container that had the complete architecture all your services all your databases not all our databases. Basically you had a single database that corresponded to all these services and yes, all the interdependencies those were inside one single container now all the advantages that we discussed about microservices become a disadvantage here because since you had a single container or a Architecture deploying was a huge issue a single failure would mean that you would have to go ahead and work on the application and then deploy the complete architecture. There was no fault isolation because if something failed everything depended on it and then you had to go ahead and repair that part and the other services had to wait for that thing to mend and then go back to working again. So yeah monolithic architecture had quite a few other problems scaling was a problem as I mentioned fault isolation was a problem. Then there was no individual development. It and deployment was a huge issue. So this architecture to simple to build actually it wasn't even simple to build to be honest because you're talking about a complete application development. And since you do not have individual applications that are being developed the whole team had to work in together and bringing up such huge teams can be a problem. Plus there is too much dependency on each other. So this also affects the functioning or basically development of a software so it wasn't even condition or easy for development in any possible. By the way, so these are some of the disadvantages when you talk about a monolithic or a single unit architecture when you take a look at the next approach that is SOA. It is similar to Microsoft versus but here the differences. Your monolithic architecture is basically divided into smaller units, but these smaller units will also have some subunits and that means you do not have complete modularity you do have modularity, but that is to a smaller extent not to the best possible extent when you I want complete modularity. You have to go ahead and choose microservices where if you take a look at monolithic it is a single architecture SOA. It will have say four features in this case. And each of these features will have individual modules that is not the case with microservices will have individual models directly or the complete modularity that we are looking for when you talk about features features are just for the reference shake and all of these modules would be able to go ahead and refer these features. So that is the difference between SOA and microservices. These two a little close to each other so we can just go ahead and discuss those but when you talk about monolithic architecture, it is completely different from these two architectures. And there you go. We have the same question that is what are the key differences between SOA and microservices to be honest the quite a few differences. That means the approach is very different when you talk about SOA the focus on sharing almost everything with other modules, but when you talk about microservices here the aim is share a As less as possible. So the approach is completely different apart from that as I've mentioned you have modular applications in SOA. But there are still a lot of interdependencies that is not the case with microservices. Basically. The other thing is when you talk about intercommunication between services in SOA, you need a middle way for communication but microservices that completely independent and you do not need a middleware the directly communicate through rest apis if you take a look at this architecture or Image what you see here is it is nothing but a shopping application. Now, these are the three common things that you need you have a user account application a shopping cart application and a product catalog application. Now what happens is inside these applications should be having - Alice's. So what microservices does is it just goes ahead and has three features not as a shopping cart feature product catalog feature and a user account feature. Now this feature will have nothing but those policies or are those functionalities that would be needed by the individual models that your essay is hiding. So you have these three features and apart from that you have the modules that are independent of all these features and they can just go ahead and use these features if required say, for example, you need something like display product service or update your display service. Now, you have various other things like check inventory service product rating service now all these are terms related to your chopping application. But as you can see that this architecture is completely independent and it is Modular compared to what you have in an SOA kind of an architecture. So these are some of the key differences when you talk about SOA and microservices. Let us move further and take a look at the next question as well. What are the challenges with micro service architecture. Now when you talk about challenges first thing that should come to your mind is automating the components. Yes, you can go ahead and automate all the components but maintaining these components is a used task and automation is working smoothly something that needs. It's constant attention configuration management and possibility perceptibility. Basically now when you talk about positivity and configuration management, you need to understand that this is nothing but an approach that deals with the complete design that you're talking about and configuring these mini micro services and having clear architecture for it can be a problem at times debugging now debugging is another issue here because we have fault isolation and if some application fails, it does not affect the working of any other application, but that also means That you also have to be continuously monitoring. These applications are individual monitoring is something that has to be done. And that is why when you talk about system failures dealing with such failures can be a problem in the overall architecture, even if it does not affect the functioning of other applications still that application has gone down and it needs to go up. So monitoring becomes a problem here plus troubleshooting so many errors for individual microservices can be a problem at times. So the next question that we have is cohesion. And now when you talk about micro Services architecture, you need to understand it is a designing pattern of when you talk about a designing pattern two points that should come to a head as cohesion and coupling because a good design will always have high cohesion and low coupling to understand this we need to understand these two terms as a know. What is cohesion and Waters coupling cohesion is nothing but the bond between an application or an intra Bond within an application to give you an example. We have a molecule. Inside a molecule will be having atoms now these atoms how closely are they bonded to each other? This bond is something that is called as cohesion now cohesion should be high when you talk about a micro service that means we are referring to the fact that the interdependencies inside a container the database and the service that is running how closely or how well gelled up are these with each other if they are very closely bonded that is good for the Crow service now when you take a look at it from a bigger picture, you're talking about different microservices the bond between these micro Services should be low. I mean, if one fails it should not affect the other one if one is being developed the others one should still work smoothly that means inter bond between two applications on microservices. It should be loose. That is why we are talking about low coupling and this inter bond is nothing but coupling in trabant inside. Container it is cohesion in Te bond between two different applications or two different containers is coupling. That is why when you want a good design you need High cohesion and low coupling. The next question is what is rest and restful and what are its uses now, these are nothing but apis that means application protocol interfaces now rest stands for representational State transfer. These are more or less used for integrating with the applications much better. Now, you're talking about a decentralized. Picture and to bring up such an architecture. You need to have a medium through which you can communicate with all these services in a much better way and your rest or restful apis basically help you do that. What is an actuator in a spring boot. Now? This is something that would give you real-time analysis or rather it would give you or let you monitor your application when it is in its production State. Now what it does is it just goes ahead and gives you all the information about a particular application. That means you can go ahead. And monitor all of its metrics that is what in actuator does it gives you information about an application is running State. What is spring boot now for that? You need to understand what spring is now when you talk about spring the first thing that should come to your mind is it is nothing but an approach towards software development or not software development basically web services development. It gives you all the ingredients that are needed as far as a web application is concerned think of it as a shop where you get all the ingredients for. Or web development when you talk about spring boot it is the customized version of your string to give you an analogy think of this approach or related with something called as cooking and eating food. Now when you have spring here, you'll have all the ingredients but you'll have to go ahead and cook your own food and eat it when you talk about spring boot. It is a customized approach. We have Ready-to-Eat food, right? So ready to eat food all ready to cook food is something that is your spring boot. That means all your ingredients spices would be Next all you have to do is you have to put that foot inside the oven heat it and eat it as simple as that so that is what spring boot is. What is a spring Cloud now when you talk about a spring Cloud again, it is something that lets you get real-time analysis and perform finite amount of data processing. It is nothing but an API that is provided to you by Spring and it helps you get rid of various complexities as far as an architecture is concerned. So what are the problems that are solved by a spring Cloud will firstly what it does is it It reduces the complexity with distributed systems or the complexity that is associated with distributed systems service Discovery becomes very easy. And it also helps in load balancing. It takes care of redundant code and application development and does help in improving performance. So what is the difference between rest and microservices now, you need to understand this point that micro Service as I've already mentioned is an approach towards software development rest on the other hand. It uses this approach and helps you develop applications. Plus microservices when you talk about these small individual applications, they work very well or function very well. Plus it becomes very easy to develop microservices when rest is used for developing these micro services. So these two are kind of interdependent, but you need to understand this basic difference micro service is an approach rest is a way of building microservices. What are the different types of tests for micro services and the quite a few tests. I mean if you ever heard or learned And testing to any extent, I believe since you all are here for the session you might have heard about basic testing that is manual testing and automation testing and what those things are or at least read about it a little if not do not worry. I would be talking about these as well. But these are very common terminologies and they're used in almost any kind of testing. So let's go ahead and try to understand them a little more. So when you talk about micro Services architecture, it follows the pyramid law as we move further, we will be discussing this as well. So when you talk about pyramid law Certain tests. They are actually performed at almost every Stitch and those are at the highest priority of the pyramids that forms the testing parameters what I'm talking about so certain tests as I mentioned, they have higher priority or not higher priority rather. They are implemented lot more times than the other tests. Those tests are your unit tests basically and to some extent atoms performance testing as well. But to just to some extent not completely then you have at the second level. You'll be having your Your exploratory tests where these tests are also happening or happened frequently, but not as frequently as your unit test and then you have your acceptance test and performance tests. Now these tests are for the stakeholders. That means when you're presenting or giving your end product, so these are superficial not superficial but they actually go ahead and just test the end working off an application. So they happen very less compared to the other two tests. So these are some of the different tests that are used as far as your This is a concern what is coupling? I believe we've already discussed this point. So just let us move further. What is a distributed transaction. Now, you're talking about a number of applications or services. So all of these services will commit changes. So when you commit changes to a particular client request what happens is you need to make sure that all the applications are on a similar page. So we have something called as think of it as a managing entity that ensures that there is a commitment for a particular service. From all the applications are all the services and when that commitment arrives it is then that a transaction is completed and this kind of a transaction is called as distributed Transaction. What is an Indian potent? Slaw and where is it used? Exactly. Now when you talk about an Indian potential you have to understand one thing there are certain results where you would want uniformity. That means if there would be a particular application that would execute 10 times, but that should not vary my end result. That means No matter how many times the application executes the end result should be same each time. So to ensure this we have something called as an Indian potential law or that is what it does. Basically it ensures that uniformity. What is a bonded context now, when you talk about bonded context you need to understand this point. We are talking about micro services and modularity to give you an example on the organizational level. We have different teams working on different things like like your marketing team focuses on marketing. Your product sales team has the job of selling your product. You have a development team that develops your product a maintenance team that maintains your product. So you'll be having different teams. They would be having different concerns and different interdependencies. So each of this team should exist in a single module now same as with the application development as well. Your each module should have its own independence. Now this kind of an approach is called. Does a bonded context or a bounded context that means your application is bounded Within These limits and these are the things you use and this is how you go ahead and proceed with the application or towards your functionality rather. What is a two-factor authentication? Well, you're talking about most of the transactions that we do these days. Yes, we use two-factor authentication, but we do not realize that we are using that to give you an example. I use a Motorola phone and it has as a finger scanner, but at times when I use or restart my phone or reboot my phone and I use the finger scanner to unlock my phone. It says enter in the password. That means I've given in a fingerprint as well, but it still needs a second level authentication just to verify that. I'm the very same person. So next time I enter in the four digit password, which I have set and it unlocks. This is in a little reverse order. Normally what we do is we enter in the credentials and then we All these Biometrics but this is an example of two Factor authentication. Another example would be your ATM transactions. When you give in your credit card details, you're actually putting in your credentials. That is a card number your name and you see we but when you do enter those details you are expected to also enter the OTP that means what your car does is it re verifies that the details that you've given are correct and you are the owner of this card and also the number which you've entered and it is this turd with your service. So this is where the second step of the authentication happens. So this kind of an authentication is called as a two-factor authentication what a client certificates now think of it as gateways or passes if you have to go for a movie you would be buying passes or if you have to go ahead and attend certain concert. Let me give you another example a bit example say for example, you visit certain restaurant or maybe some club now they're what you do is you pay in your cover. I just right so you are given a band or something, which says that for tonight. You can go ahead and you can use the services. So once you have that band on your wrist or whatever card or something, when you go in you have certain freedom to go ahead and use maybe the dance floor or consumed there whatever it is cocktails of food and all those things. So this is what a client certificate is. Like when you have a particular application when you have a client certificate, you have a digital certificate that tells you that you can go ahead and use a particular client system or your authenticated to go ahead and use following Services. Basically, what are the types of credentials of a two-factor authentication now, we just discussed it with few examples. Let us just walk through these points quickly. Now, what are the credentials that would be needed something that you know or in simple words it is nothing but your credentials your card details or your CVV number and all those things something you have here again a part of your credentials that you have and which you Enter and finally you have your something you are this is where they're referring to the fact that if you're using some Biometrics in the example, which I gave you where I used my finger basically for the scanning purpose not is what they mean, maybe our retina scan or all those things. So something you know is your credentials your password and all those things something you have is your OTP or the value that is generated back to you and something you are is nothing but your body scanning son all those things which you use for unlocking. So these are the credentials yells you might require when you talk about a two Factor authentication. Okay. So the next question is what is the use of packed in microservices architecture now you can think of it as a testing approach. What it does is it lets you test your contracts basically now not contracts since you have a provider in micro services and a client that is using these Services now both these teams are these people they come on terms or an agreement. Now when you talk about these agreements you're talking about communication between these two. And these communications are governed or rather tested by something called as a pact now, it is nothing but a testing approach and it is used for testing these communications, which I just discussed. What is an oauth. I mean you talk about oauth you're talking about open authorization protocol here. You can actually go ahead and use the Provider Services and to do that. You will have to go ahead and use some third-party tools which would let you access those Services. What is Conway's law now, this is something that helps you. Maintain the Integrity of an organization. Now when you talk about an organization, they would be having applications or a particular structure for the applications that are built now if a new system or a new application is to be built. It has to be on the similar lines or the guidelines that the organization has defined to give you an example. Coca-Cola makes cold drink ends. Now when you talk about these coding cans, they have fixed dimensions and those have been decided by the He's organization. Now if they're launching a particular product, they might not make the exact same can but what they would do is they would be having certain principles that need to be followed that keeps the other product or the newer product also on the similar lines. Now, this is what Conway's law preserves each time. You have a new system. It has to be constrained or it is constrained with the properties the organization follows. So this is what Conway's law is as you can see in this image. Image organization has a particular definition as far as a software development is concerned as you can see the organization has a particular approach what Conway's law does is it lets you have a system that follows a similar approach and that is what is reflected in the system that is being developed as well. So the next question is what is contract testing now contact testing is nothing but a superficial testing superficial again would be a wrong word, but it is a test that does not go. But our test the complete application and what do I mean by this? These are more or less the behavioral tests and these are done just to ensure that the system is working fine or the expected output. As far as the system is concerned is up to the mark to give you another example, we all appear for examinations suppose you need to prepare for a particular examination and you maybe prepare for it for say three months duration and then comes in your exam time and you revise it for two. Days, and then you go for the exam and on the day of exam. What you do is you just Overlook or walk through the concepts quickly of this kind of an approach when you bring it into testing. It is called as contract testing. What is n 2 N microservices testing now, this is completely opposite from what we just discussed to give you an example think of it as your bike servicing. Basically when you give you a bike for servicing there are certain issues that do not occur every time you give your bike for servicing say for example your break Failed completely and your brake wire needed replacement. Now, this is something that won't happen every month, but this was an issue this time but there are certain things that happen every month. Like you're always checking your bike washing tightening certain screws and all those things. So this kind of an approach that happens every now and then has to be done frequently or has to put an end to end. This kind of testing is called as end-to-end testing. Now when you talk about microservices, you would be having quite a few loose ends because you're talking about n number of Services bringing them together and fixing in the loopholes can be a problem and end-to-end testing fixes those loopholes and this is something that is little out of context to explain. This'll have to go into something else. So I would rather skip this question and move to the next one. What is the use of a container in microservices now this gives you modularity you have your code libraries in a single container your micro services and also the database now, this means your application it works independently. So this is what a container Does it gives you that modularity what is dry in microservices architecture since you're talking about too many applications and too many microservices. There might be a possibility of code redundancy. Now what happens when the code redundancy Yorkers will basically what it does is there might be a piece of code which everybody is writing instead. What you do is if you have a particular set of code, once you write it you kind of patent It Baton won't be a right word, but you would create a library out of it. Once you have that Library, it can be used by others as well. And that is what dry stands for don't repeat yourself. This ensures code reuse ability a code that has been created by someone and if it can be used by others, let them use it a consumer-driven contract. Now this kind of a context used to keep people on similar pages. That means your provider is allowed to set certain set of rules when he is deploying a particular application and the consumer who wants to consume that application when they have this contract. Basically try to be on the similar page that means client has a particular set of requests and when the client mentions those requests to the developer or the provider, he should adhere by those requests. So this kind of an contact is called as consumer-driven contract where consumer is made a priority and accordingly a software is deployed. Basically, what is the role of web restful apis in microservices again, rest plays a very important role, I believe we've already discussed. The point microservices you're talking about independent development. And for that rest is a very good approach of web services, which can be used and it also provides you with various apis that help you in various other things we discussed something like monitoring or getting real-time analysis and all those things. We discussed spring cloud and all those things, right? So what restful does is it gives you something on the similar lines it gives you apis that suit the need of your micro services. Accordingly you can go ahead and have your micro Services up and running. What is semantic monitoring in micro Services architecture know when you talk about semantics monitoring you're referring to the fact that okay. Let me give you an example again. You have your application which is up and running but you still do not know whether it gives you the best output or every module that is there in application is working in the best possible way. So what you do is you go ahead and generate a pseudo transaction. Now this transaction it runs through every module and generates. It's an output and when you assure our verify this output and find that all the readings are as you expect it to be then you actually go ahead and deploy that software. Now this sort of monitoring or testing is called as semantic monitoring. How can we do cross functional testing now when you talk about cross functional testing you need to understand what it is first. Well, it is nothing but an approach where let me give you the scenario again. First of all, you have a client who gives you certain requirements and then Enters in output and tries or expects an output from an application that you build for him. But there are certain parameters which the client might not think of or he might enter and you expect output for those inputs as well. Now while building an application, you might not consider every possible faucet as in what kind of an input the user is going to given so it is the responsibility of the Builder or the provider rather to ask for these requirements and then accordingly A test is taken care of to test our application for these kind of inputs as well. Now this kind of a test is called as your cross functional test. How do you eradicate non determinism in tests a basically, these are different approaches. First thing you need to understand is what are non deterministic tests. Now when you talk about non determinism, you're talking about a series of inputs for which you may not know what the exact output is. Now in this case what happens is when you're generating a Particular output the output might vary each time you enter in a particular input and there are certain outputs only that a correct not all of those. So what do you do in these situations? Because this is a very non deterministic situation where you do not know what is happening with you. So in that case, what you do is you take in various approaches. One of those approaches is current. I know what happens here is suppose you have maybe say a hundred outputs or results out of which there are 20, which are not not correct. So what you do you put the 18 one cluster and 20 in the other cluster and then you test them differently a synchronous approach. You might come across tests where a synchronous messaging is used. Now in this case the output that is generated may be different because a synchronous messaging is something that is little different here. The user does not wait for your reply and the output that is generated might be a little different. So again, what you do is you use sudo applications of Shooter in post-fire, so called a synchronous requests and those are dealt with differently remote services and isolation again here to you. Use something called as stub are those are predefined inputs are predefined models that can be used as we move further. We will be discussing that as well. So you would have a clear understanding of these terms as well. So yep remote Services an isolation again, they can be dealt with determinism or non determinism rather. But how do you deal with that? You use something called as your steps? So as we move further that's discuss steps and you can relate to these terms as well time. Now time can be a constraint because you're talking about applications that run four different times. But yes a pseudo time again is generated for certain applications. And the non determinism is something that can be taken care of. So what is the difference between mock or a stuff for microservices test as I've just mentioned we have something called as a stub and what happens in a stub. Basically, you need to understand this thing a stub is nothing but A dummy object now this is used for testing purposes. It would have a preset or a predefined set of behavior and that individual or particular behavior is something that it would Implement each time. It is used now in cases where you do not want to go away from normal behavior. You have this predefined stuff that can be used mock is similar to it. But it has a set of predefined rules. This is where it is different. It has a set of predefined rules that are set initially it goes ahead. Head and it functions accordingly. Okay. So the next question is what is my co Hans test pyramiden microservices. Now when you talk about the pyramid there are three levels in this pyramid. So first I will have unit tests. Now. These are tests that happen for individual units. You have service tests. Now these tests they test the complete service that is there. And then you have your end-to-end tests which are for the complete development or architecture now as per the law the tests in the first layer. This for unit tests. They are the maximum service tests are lesser than what unit tests are but more than what end-to-end tests are. And finally we have the end-to-end test now here. These are the least compared to the about to what is the purpose of a Docker now Docker is nothing but a container basically that means it gives you a containerized approach and it also ensures virtualization at the operating system level and it has three components. You have your darker client your day. One or your server basically and then you have your Docker containers and these containers would contain your complete micro service or your complete application to have your database there to have your interdependencies and also the complete functioning of that micro service. So when you need a containerization approach you can use something like a Docker which has a very wonderful and a popular technology to have what is Cannery releasing now you're talking about an application which might be used by lakhs of people are Maybe. Chef people in that case when there is a new version you cannot just go ahead and launch the complete version for everyone who is around what you do is you launch it for a certain set of people and when it works perfectly then it is launched to the entire segment and this kind of an approach is called as Cannery releasing that means you release a particular software update or version to a specific set of people. That's it. What do you mean by continuous integration? We read something about dry. That is new. Not repeat yourself. This is what continuous integration is also about first the code that is generated. It is saved in the form of libraries so that others can use it and there is a continuous integration of your system. That means even if there's an update it is recorded and it is released so that others can refer it if there's an improvement it is updated and it is released. That means throughout the life cycle of your software. There is a continuous integration and updation what is continuous monitoring. It is similar. Continuous integration, but this deals with monitoring when you talk about continuous monitoring you're talking about monitoring in every aspect of your application almost everything is monitored and taken care of. What is the role of an architect in a micro service architecture all the activities which we actually discussed are all the questions which we discussed. Now that is something an architect has to plan it is similar to building the house. Now there you have an architecture or an architect who takes care of the construction part here the architect needs to take care of this. A software development part is responsible for creating the blueprint or the design. He zones out all the components or plans where all the components should reside and how they should work whether they are mutually cohesive and how Loosely coupled are they is also responsible for deciding or helping plan what tools to use fair plus there's technical governance, which he needs to take care of. So, these are some of the roles that an architect takes care of. Can we create micro Services as state machines? Well, the answer is yes. Definitely, you can create State machines or microservices as state machines. Why because you're talking about individual applications. You have your individual databases. And since you have a single architecture or a uniquely defined architecture for each micro service and it is smaller in size. You can go ahead and have a state machine for each individual micro Service as well. So this brings us to the last question of today's session that is what is reactive extensions. Now when you talk about reactive extensions, these are inappropriately. Roach, which lets you collaborate your results. So what they do is they bring in or collect all the results by using multiple services and then they combine these results are compiled these results together to give you a combined effect. And there is a short abbreviation that is used for it which is called as our X. So as this is what a reactive extension is as far as the session goes. I believe we are done with 50 questions. And this is where we have to rest our session. I hope you all had something nice and And I hope to see you. All again. Thank you. Bye. I hope you have enjoyed listening to this video. Please be kind enough to like it and you can comment any of your doubts and queries and we will reply them at the earliest do look out for more videos in our playlist And subscribe to Edureka channel to learn more. Happy learning.