[MUSIC] Hello and welcome to this lesson on microservices architecture overview. Let's start by understanding what are microservices? The term microservices is generally meant to describe an approach to software development that involves decomposing application functionality into individual components that can be deployed separately from each other and typically communicate by application programming interfaces or APIs. Microservices basically utilize integration, API management and Cloud deployment technologies which gives developers the freedom to independently develop and deploy services as per their requirement. Microservices are used to design an application that is multilingual. This helps teams which work somewhat independently of each other. This allows developers to use different programming languages and technologies without affecting the overall architectural structure of the software development. One developer might use no Js to quote specific app feature and the other might use python that's absolutely fine. Loosely coupled with other services. In a loosely coupled environment, you can easily work with the least elastic component to address any slowdowns or performance gaps. Loose couplings, animals the isolation of microservices that lead to better productivity. Easy to maintain and independently deployable. Following code is easier since the services are isolated and less dependent, which also makes it easier to deploy them in literal pieces without affecting other services. So when a change is required in certain part of the application, only the related services can be modified and redeployed. There is no need to modify and redeploy the entire application. Easily scalable and highly available. Microservices are easy to scale and integrate without third party services. Although not a simple task but maintaining high availability with microservices can be done using replication methods like load balancing techniques and using API Gateways. Failure resistant. You can build resilient microservices by including fault tolerance policies in your code. For example, in a movie ticket application, different microservices might support scheduling, purchasing and customer preferences. If one service fails fault dalton's policies help limit the error and keep it from taking down the whole application. Let's take a look at a microservices architecture for a sample E-commerce application. The API layer is the entry point for all the client requests to a micro service. The API layer also enables microservices to communicate with each other using the SCDP TRPC and other TCP UDP protocols. The logic layer focuses on a single business task, minimizing the dependencies on the other micro service. This layer can be written in different language for each micro service. As you can see this E-commerce application makes use of three microservices. One is quoted in Java, the other one in Python and the third one in Go, which makes it multilingual. The data store layer provides a persistence mechanism such as a database storage engine, log files and so on. Developers can consider using separate persistent data store for each microservice. As you can see over here, there is a separate data store for container two and there's a separate data store for container three that is using Go. Typically each micro service runs in a container that provides a lightweight runtime environment and this can be scaled up or down as per the user requirements and managed using the orchestration tools like Kubernetes. Let's understand the difference between a microservices architecture and a monolithic architecture. In a monolithic architecture, the entire application is built as a single unit which contains the business logic, user interface and data access layer. These three services are defined within the application as a single instance. So basically these three services will share the same resources and database, which makes them dependent on each other. Problem here is if one service within a monolithic application stops working, then the entire application will stop. On the other side in the micro service architecture, the business logic is organized as multiple loosely coupled services where each service has their own resources which make them independent autonomous services. So even if a single service crushes, it will not affect the other services running within the application. Let's take a detailed look at how microservices differ from monolithic architectures. So when it comes to unit design, microservices architecture are loosely coupled services, whereas monolithic architectures are designed, developed and deployed as a single instance. When it comes to functionality reuse, microservices define APIs that expose their functionality to any other client. Whereas in case of monolithic architecture, the functionality reuse is very limited. When it comes to communication within the application, microservices makes use of rest API calls based on SCP protocol. Whereas monolithic architectures make use of internal procedures and function calls. Talking about technological flexibility, microservices architecture offer better flexibility as the show support for multiple programming languages and framework that best suits the problem. Whereas in monolithic architecture, you have to write the entire application using a single programming language. Talking about data management. Within microservices architecture, every micro service can manage their own data store, hence making it decentralized. Whereas in monolithic architecture you must maintain a centralized database. When it comes to deployment, microservices architecture can be deployed independently. Every microservice can be coded and deployed independently of each other. Whereas in monolithic architecture, you'll have to write the entire code at once and then deploy it. And again, if you have to make some changes then you have to redeploy the entire application. Which is also why maintainability is easier in microservices architecture as you are managing small piece of codes at a time. Whereas in monolithic architecture, it's very complex to maintain the entire piece of code. Talking about resiliency and fault tolerance, microservices architecture show high resilience whereas monolithic architecture show low resilience. And at the end talking about scalability, you can easily scale each micro service independently of the other services. Whereas in monolithic architecture, you must scale the entire application. Communication mechanism in microservices architecture. As we all know, microservices are distributed in nature. So to communicate with one another, they make use of inter service communication on network level. Each microservice has its own instance and processes. Therefore, services must interact using an inter service communication protocol like SGDP GRPC or message brokers like AMQP protocol. Before we design our microservices communication, we should understand about communication styles. In general, there are two criteria to classify these communication systems. Based on the type of protocol that is either synchronous or asynchronous, and based on the number of receivers which can be single or multiple. Synchronous communication is using SGDP SGDPS or GRPC protocol for returning synchronized responses. The client usually sends a request and wait for a response from the service,. Which means client code blocks their thread until they receive response from the service. Talking about asynchronous communication. In this case these sub processes are not logged and protocols that are compatible with many operating systems and Cloud environments are used. The most popular protocol for this. Asynchronous communication is AM QP protocol. That is advanced message queuing protocol. So when using SMTP protocol's the client sends the message using message broker systems, the popular ones are Kafka and Rabbit Mq. Remember inter service communication can result in a lot of network traffic for that reason civilization, speed and payload sites becomes more important. So if we are communicating between services internally within our microservices cluster, we might also use binary format communication mechanism like G R P C G R P C is one of the best ways to communicate for internal micro service communication. The second classification criteria of micro service communication protocol is the number of receivers distinguishing between one or many receivers. In case of a single receiver, each request must be processed by a receiver or a service. One example of this type of communication is the command pattern and a good example in case of many receiver is the event driven microservices architecture which is based on a messaging agent or even bus interface that broadcast the data updates among different microservices using events. Normally microservices based applications use system that combine different communication styles. The most common type is a single receiver communication via an a synchronous protocol with S GDP and GDP as being one of the most used. Alright to wrap up our discussion on this lesson, we covered what microservices are, we covered the differences between microservices and monolithic architecture. We also saw the different communication mechanisms used by microservices architecture. I hope you found a lesson useful. See you in the next one. Thanks for watching
