MICROSERVICES WITH SPRING CLOUD: FULL OVERVIEW!

Hello, welcome to another video here on the channel I'm Michelli Brito and this content today is very awesome I'll show you a complete overview of microservices architecture using Spring Cloud projects but before I start talking about microservices I want to talk to you a very important message today I am releasing the second edition of the Spring boot ebook from the REST API to microservices So if you want to check this ebook updated with the updated Spring versions and also the Spring projects, just you enter my website michellibrito. com or access the QR Code that is here on the screen and download this updated version of the e-book Just put your e-mail and I'll send you this updated version but before starting you got it your coffee if you don't get your coffee and we'll start with this really cool content and I'll do this complete overview so let's start with the microservices right, microservices today p because I like to bring this topic so much here on the channel And why I work so much in my daily life with microservices is because it is modern architecture today companies that are starting new projects companies that want to update their systems their applications they are increasingly adopting this architectural model because it has several advantages that I will show you when we compare it with a monolithic one, so microservices, right. This modern architecture is increasingly being used by companies and is also being demanded, right Companies with this use look for professionals who have this knowledge, who can then work in this style of architecture and that's what I want to show you the main bases to assemble and start this type of architecture and also the main Spring Cloud projects that it is already very easy to do the development and implementation.

So before From Spring Cloud I want to talk a little about the definition of microservices because for people who are already used to working with this type of architecture it is easier to understand but for those who are new to this subject, sometimes they get a little lost about it. concept definition of this architectural style then microservice is nothing more than an application it will work autonomously and independently so it is an application that has a very clear objective, it is a set of very clear processes and this application works autonomously and independent but a microservice it doesn't live right it doesn't run alone usually in microservice architecture you have several and several microservices working independently of each other But they communicate internally so they are not isolated they do this internal communication when necessary and now I would like to show you here on this slide two very simple schemes to be clear at once. z for all What are these microservices?

So imagine that we have an ERP application and this application has several modules? I like to bring this example of ERP because usually when companies use this type of system, corporations that are very large they are systems that involve several areas within the company. So imagine that we have an ERP application that has a sales module, it has finance, HR modules, among other things, when it comes to a monolithic architecture, how would this application be built in this case, all modules that involve this application would be within a large block of code, characterized by a single application with very high coupling and generally with a single database, which is this first scheme that we have here in the drawing, so in this format, right, with monolithic architecture, we have a high coupling because all modules Independent if they have different functions, right, sales is different from HR and HR it is different from purchases but they are in the same application now imagine that we have this same ERP being developed using the microservices architecture, in which case each of these modules can be disconnected from each other and be developed in parallel, right and so each of these modules can be built with an independent and separate microservice to work autonomously so in this case we would have the sales microservice, we would have a microservice of purchases for Finance and also for HR so we would have an architecture with these microservices right separately So we already reduce the coupling and also the ideal when we have this type of architecture is that each microservice has its own database.

So in this case the Finance microservice will have its own database given the HR microservice as well and so on This is the ideal scenario so in these two schemes it's visual look and what a monolithic application would be like and what would this same application look like if it were built using microservices architecture and when we use microservices then we can see that this style of architecture brings many advantages, especially when we compare it with monolithic architecture and the main advantage I've already mentioned here is the reduction in coupling. Because as we have separate services that work independently of each other, we have a very low coupling in our application, especially if we compare with architecture monolithic that has a high coupling and with this lower coupling we consequently have high availability in this type of architecture because Imagine in our microservices architecture that the sales module has a bug in production, so in this case the developers will act to fix this bug only in sales microservices so they will stop the microservice and they will make the necessary corrections, they will upload the updates and return everything to normal while this process happens, the other microservices will continue to run normally because the sales microservice even though it was stopped, it did not influence the microservice of purchases, for example, to continue being processed the requests, right? Now imagine that we have a monolithic architecture and need to make this same change in this case, as it is an application, we would only have to stop the system as a whole to make this change in the sales module and with that we would leave the application as a whole is unavailable, so in the monolithic architecture we have a low availability when we compare it to microservices architecture and the other point that is also a great advantage of this type of microservices architecture is the performance control, which is much higher when compared to monolithic architecture because like gen You have all the services separated, right Imagine that we currently have a high number A greater demand in the sales service In this case, to increase the performance of our application, we can scale a sales system horizontally so that it responds according to the high demand meanwhile the other microsserviços they will continue to function normally with their running instances and this control you can do it in a much more thorough way then you only scale those services that are experiencing more demand Now imagine a monolithic architecture that would be much more complex to do because to scale the sales module we would have to install the application as a whole so this performance control is much greater when we have the type of microservice architecture and as the best standard in microservice architecture is that each one of the services has its own database so a positive point is also with regard to o the data modeling that you can do in isolation so imagine that you need to change the data modeling of the sales service this will not affect any of the other services it will not influence the modeling of the others now imagine a monolithic architecture where all modules use the same database, so the probability of a failure there, especially in the modeling or data alteration is much higher because if you change the model, for example, from the sales module, this can end up affecting the other modules in some way.

of microservice, you can have this isolation of data modeling and this brings a much greater guarantee and avoids many problems that you would have when you put together, right when you unify all the data in a single database. Another very interesting point also in this type of architecture is the ease of being able to dynamically use different technologies on the same architecture because but we have separate microservices that work independently, you can build these services, we can build these services using those technologies that are most suitable for them according to the processing according to business rules because the microservices beyond them communicate with each other. others, right.

They don't need to know how one was done than the other was done. They need to have a standard to communicate now about how they are implemented and with that we already have this much greater dynamic when we work with microservices So if we use a more appropriate technology in microservice, it does not mean that we will have to use it in others, we can then control and make these choices and more assertive ways where each microservice can be built according to the best technology that will fit better in the business rules or in the process, this microservice it will execute And with that the we have a great advantage, which is to always use modern technologies from the market. So if new technologies arise, new tools and you want to use them in your architecture, when the agent has a microservice architecture, this becomes something much simpler, for example, you can start the team you can start testing a new technology in secondary services, right, that are not the main core, for example of the application and after they validate.

So this new technology in these secondary services, then the team can start to disseminate this technology to the others, now imagine if we had one monolithic architecture and wanted to have this dynamic of different technologies technologies in the same application and also be able to innovate when it exits new tools on the market and this would be a much more complicated thing because the monolithic architecture often you work with a single technology and a unique single Framework language and make a change when we have a high coupling, this becomes very laborious and very susceptible to failures so it's something much more complicated now when it comes to microservice we can have this much greater dynamization and this much greater freedom to work with different technologies, both modern technologies, more modern tools and to achieve So, reconcile and always keep your architecture more up-to-date according to the market, so now I've talked a lot about the advantages, right, I'll talk a little bit about the disadvantages of working with this type of architecture, so when we have microservices, some points have to be mentioned here because it really is an architecture a little more laborious, mainly to start, why? Because before starting with the microservices of the business rules, it is necessary to have a preparation, right, a base of the architecture with configuration microservices, such as with the service of Gateway that I'm going to talk to you now a little later so it's necessary from the beginning to unite several different technologies already to make the microservices talk to each other So it's a little more complex, right, but nowadays we have platform tools that help a lot in this start-up this type of application that makes it all more easy so it's not such a negative point because we have these tools that help. And the other point that is a little more cautious, let's say, is with regard to monitoring and management.

Because as it is microservice to perform certain processes, microservices they will have to communicate with each other or communicate with external application systems and this generates many points of failure. So in this type of case, right in this type of architecture, we have to have much more careful monitoring and management than we do would have a monolithic application so it is a point of great attention when designing and also developing this type of architecture. the one you have to put as a priority And another point that is a little more laborious than monolithic architecture is when it comes to Deploy, so Deploy in microservices architecture is more laborious because we usually have tens and even hundreds of services or be a microservice to be deployed and this is a little more complex than when it comes to a monolithic architecture that is usually a single application with a single database so Deploy, as it deals with multiple services and multiple databases, is something more complex, but today we have several and many cloud tools that help, right, and automate it all for us.

And then it becomes something very natural, for example, pipeline automation, among other things, so we now have tools that help in this Deploy that also facilitate the use of this type of architecture and I can't say it's such a negative point because we now have many facilities. ties And another point I mentioned at the time I was commenting on the advantages and disadvantages of the definition of microservice as well, these microservices work independently and autonomously but they communicate with each other and how this communication is done as we defined what will the communication be? So today we have two main communications, two main types of communications between microservices, but this will depend a lot on the type of process you will have.

Between these microservices, so when we have synchronous processing, we usually use the HTTP protocol with REST API to make these internal communications Between these microservices and when we already have asynchronous processes in this case, we use messaging, right like Apache Kafka RabbitMQ, among other brokers to do this communication between these microservices, right, to ensure delivery So you can define what the communication will be, yes you have to have an understanding of what the processing of these microservices is like, how will the exchange between them be? What is the type of process and after you identify it, you can visualize which will be the best type of communication that will fit in each case Now talking a little about the microservices architecture itself here I put a very macro view to explain a little about this architectural base that often defines the degree of maturity of our application of our architecture, because it is not just microservices of business rules constituted the microservices architecture we need to create services that are base services to complement the architecture to raise the level of maturity such as monitoring services, log management, configuration service, discovery logging services, gateway to centralize all the entries in our architecture among other things so here I put a very macro example for you If you can identify these main bases in these base services that are also microservices, but they are not business rule microservices, they are configuration microservices, discovery service, among other things that I'm going to talk about here. So here, imagine that we have the our microservices architecture on the backend and it is communicating with the frontend which can be an Angular application or a React application and the first thing we need to do on the backend part is create an API Gateway But what is it this API Gateway, right?

This is a microservice that will centralize all the entries of our application because we cannot leave the microservices open, right for Angular application, for example, it needs a certain data, then it chooses any microservice that it will communicate and communicate with it directly This can't happen, we have to centralize all the inputs, right to guarantee security too, and for that the gen you initially need a Gateway and then hereafter we have a series of microservices, using for example Spring boot and down here we have the logs we have the databases and each microservice will have its own database And then we also have services that are microservices but they are, let's say, the configuration part of the base of the architecture such as service registry as the circuit-breaker the config server And also Sleuth But now I'm going to go through each one of them to show Why is it so important for these services to be present in our architecture For each of these services, let's say they are base services to compose our microservices architecture , we can use Spring Cloud projects to build to develop so we don't will do this all by hand. We already have a series of facilities with these Spring Cloud projects and have already implemented the best standards in large part for we use and guarantee that we will ensure that each of our base services will be developed in the best standards to compose our architecture so here now I will start talking about the Spring projects that we can use to create these basic services of our microservices architecture The first of them, as I said earlier, is a Gateway, so we need to create the service that will be the gateway to our application. The Gateway is often called API Gateway first, it will serve to centralize all the inputs, right, it will create, it will unify our application in a single gateway and we will also be able to make routing and filters at the gateway, it also has this role and the gateway will internally carry out load balancing, often internally it will communicate with the service that has this responsibility, which I will also talk about on the next slide and will also integrate with the service of discovery and in the gateway itself and this goes a lot from the definition and planning of the architecture but it can also contain the security authentication part or it can communicate with another service that does the authentication and security so it can also communicate to do these authentications so here we have a very simple scheme showing what is the main role of a gateway in case we have a client, this client can be an interface built using some Framework and it sends a request to our backend.

it sends this request who will initially receive this request is the gateway and internally it will load balance it will find out which service the instances are running and it will route it to the specific microservice to answer that request so here I put in the case the client sends the request to the gateway and the gateway it will redirect to the respective micros ervice then respond to this processing and send a response to the client and when do we implement a gateway in our microservices architecture, right then as I said if we are already using Spring projects they have several and several projects that we can use in our Architecture and one of them is the Spring Cloud Gateway Project which is specific for us to implement this gateway within our application and the Spring Cloud Gateway was created together with the Spring Framework version five so it already has the support, right. the Reactor project, which is that support that came with Spring version 5 and allows us to work reactively within this Framework and also in a non-blocking way, so it also has a Netty server internally that allows us to work with asynchronous times and not blocking so for example Imagine that one of our microservices we have an API but not a simple web API using MVC, a g we have an API using webflux, right, it works reactively, so in this case the gateway will already be prepared to work reactively and not blocking. And so we will be able to have a reactive and non-blocking end-to-end flow.

is already prepared to work with asynchronous time and not blocking the Spring Cloud Gateway We have other projects also within Spring Cloud such as spring-cloud-netflix-Zuul which has been used a lot to create gateways but some projects from the Netflix package they're stopping receiving updates right and Zuul is an example of this so that's why I didn't even put it here on the slides because now the most used is the Spring project itself, right, it's the Spring Cloud Gateway and now the second service that is very important of us to build is also a service registry Discovery But what is this server register Discovery? When I talked about the types of communication between microservices and when we have two microservices they will communicate synchronously via HTTP REST They need to know each other's URI and port to communicate but imagine that we have several running instances of each one. dynamic as we will implement this in the middle of people code can not put the door and people at fixed URIs have to have a way to be monitored right all running instances and to provide us with these properly address already balancing loads and for that, we use the Registry service, which is the registration service and also Discovery, which is the discovery service.

And what are these two services, right, for us to have this type of communication between the microservices we first need to implement a registration service in our microservices application and this registration service will monitor the other services, ports, URIs, instances in exec ution of all services that will make this type of communication they have to register, that is, they have to register with this registration service Because when they register Then yes, the registration service will start to monitor all of them as ports, URIs, number of instances and the services that will communicate with each other they have to register in this service registry So that's the role of the Service Registry So this service receives this name and everyone who registers in it receives the name of client service and how we implement this Registry Discover service in our application we can also count on Spring Cloud projects for this here in the case I put in this scheme here using Eureka which is one of the projects we can use is spring-cloud-netflix Eureka also has the Spring Cloud Consul option we can use then to implement this type of service in our architecture Looking now here for the scheme I put us there is a eureka server in case I used Eureka so all the services that will communicate will have to register initially with the eureka server so that the eureka server can monitor the instances, ports and also URIs dynamically. So here in this case, we have two services , grade control and student control. Imagine that these two services first have to register with Eureka Server, with that they become Eureka Client and now let's imagine a process flow and grade control receives a request to finish his processing he has to make an internal request for student control to get the Student data, for example, before sending it to the client how will he know which address he has to send this request internal then the grade control before sending anything to student control it goes to the Eureka server because the eureka server is monitoring all the services, right?

and subscribed to it so in this case it knows which instance is running and according to load balancing it knows which port with dynamic URI so it will pass the address correctly to grade control and thus grade control will be able to send the internal request for student control dynamically so that's what the service registry Discovery is for so that the microservices internally can communicate with each other via http rest protocol and with that they can, right Whenever they need to get these addresses from dynamically and also with load balancing. On the other hand, we also need to be concerned in this type of architecture with methods that have a high potential for failure. As I said before, this type of architecture, as we have several communications between these services we have many points that can fail and these points cannot be left untreated, we have to identify these These points make a treatment in the case of implementing the circuit breaker.

So whenever we define a microservices architecture when planning to identify these critical points, it is then necessary to mitigate these failures Mainly the cascading failures so that it does not affect the architecture as a whole and to We then use circuit Breakers, for example, fallback methods that are called when some failure happens. So if we have a service that, to finish processing, it needs to communicate internally with another service and this other service. It is showing some latency or it's out of thin air.

In this case, we'll have a failure both in the request and in the others that come later, so a very critical point that the agent has to implement, he has to mitigate this failure in this case, we need to implement a method that it's actually called the fallback method where we will define a default message and a processing default or we will define there some Measures that it will take not to stop the processing but also not to let this call to the system that is showing latency or that is failing, it harms the others and how do we do to implement it then these fallback methods in our services, especially in these critical points, we can also use spring-cloud projects Before the circuit Breaker pattern of Spring projects was Hystrix, but Hystrix is ​​part of those Netflix projects that are not receiving updates so now we there are other options such as Resilience4J, Sentinel mainly used today which is more updated is Resilience4J So we can use these Spring Cloud projects to implement So this circuit Breakers in our services mainly detecting those methods that have high potential for failures and this is very important to guarantee with our system in our application as a whole, even with failures in certain services, it does not affect the processing of others, so having this control to do this mitigation in these critical points is essential when we have this type of architecture to ensure that it is not affected, right when we have these interventions or these failures Following here another service that is also important to have in this base of our architecture is the config server What is config-server it is a service that centralizes all the configurations of the microservices, right, the services of the rules of business for example, so it will centralize this information for this, it uses the GIT to store these settings and it is interesting to use why. Because Imagine that we need to change these settings in certain microservices, for that we just change this config-server, we don't need to stop microservice by microservice so we have these unified settings, right? centralized and this makes development easier.

Here I put a scheme of how the config-server works in case we need to create a service that will be this one and it uses Git to store the configurations and the microservices. settings for it to manage then the config-server service it will be the server, right?