What is microservices architecture?

i know what you're doing or at least i can guess what you're doing and what you're doing is that you're faking it you're pretending that you are designing your applications to be microservices i might be wrong maybe you are really doing it but let's first explore what microservices are and then you tell me whether what you're doing is really microservices [Applause] let's start with an obvious question what are microservices we can explain microservices through five points or five important aspects that they all have to have they are highly maintainably testable what that means is that you can maintain a microservice in isolation and that's relatively easy simply because it's small and it is easy to test it again because it is small now in your case that might not be true because you are not really doing micro services but we are going to get there so bear with me a bit more they are loosely coupled and this is important that means that one micro service is not coupled with other micro services micro services do not depend on each other they communicate in whichever way they communicate they have their lives and those lives are independent from each other that does not mean that there is no coupling at all but that it is very loose they are organized around business capabilities we do not split monoliths into microservices based on technical aspects we do not create a microservice that is communicating with a database and another one that is doing a front and then a third one that is maybe a back end and a fourth one that is ipi no that would be dividing services based on technical aspects that's the same thing as three tier or fourteen architecture that we had in the past that's not what we're doing we are organizing microservices around business needs or business capabilities and they have nothing to do with technical aspects of our code of our architecture or whatsoever they are owned by a small team and this could be the most important aspect and the reason behind microservices we cannot work in large teams and there are tens or hundreds of people working on an application you know the big monolith those are not teams like 100 people cannot work in a team that's a soccer match or a school reunion that's not a team a team is a small number of people that can work well together independently from other teams that's what a team is and small number means five six maybe ten people but 10 people would be a maximum number of people that can be considered a team and that team needs to be autonomous that team needs to be self-sufficient what that means is that such a team needs to have full control of a service those five six ten people gather requirements write code of applications they write code for testing they test they run ci cd pipelines they deploy applications they monitor applications they are fully in charge of an application or we call it microservice and now comes the part that will allow you to distinguish whether something is really a micro service or not i mean you need to fulfill all the previous points that i mentioned but this one is the most important one a micro service needs to be independently deployable from all other micro services or any other part of the system that's the part where i usually catch people and tell them hey no you're not doing micro microservices these are not microservices this is a distributed monolith if you need to coordinate releases across multiple microservices and deploy them all together that's not a microservice based architecture that's distributed monolith and that's what most people are doing they come back to me and ask me hey victor how do we coordinate release of multiple microservices when i ask them why would you want to do that and then they explain how they're making changes to multiple services and that they need to deploy them all together because the feature is split across multiple ones and there are interdependencies you know they're not loosely coupled and so on and so forth that's what happens when you take a monolith you split it into random pieces you do not understand what you're doing and you now say hey i broke it into multiple applications therefore it's micro services and they still need to be deployed all together and guess what that's the same as what you had if you split a monolith in a way that all the pieces are still required to be deployed at the same time whenever we need to create a new release then you're not having any benefit remember loosely coupled independently deployable managed by a small team that does not depend on other teams i get passionate about this because i argue with people a lot about their architecture and what they're doing and what they're not doing so i will come down okay this is now calm version of me let me continue this video in a calm fashion why do we want to use microservices no i cannot do it i cannot be calm why do we want to use microservices the three main benefits behind microservices are continuous delivery deployment velocity and self-sufficient things now to be honest you can do all three of those things without microservices but if you adopt microservices if your applications are small easy to manage have a dedicated team and independently deployable from each other then your continuous delivery is going to be so much easier because you can focus on a single small application you can manage that focus with a single team and that theme can create continuous delivery or continuous integration or whatever other type of pipelines that does whatever it needs to do and what that pipeline needs to do is usually relatively simple and straightforward because you're not dealing with a huge monster you're dealing with a cute little bunny deployment velocity is going to increase greatly because to coordinate 100 people working on a huge application takes a lot of time and delivering all the disparate pieces that are done by different people in that huge application is very complex and it is normal that it takes months or weeks sometimes days if you're very lucky to make a new release of a huge application when it's small you can release it multiple times a day it's easy it's not really problematic you can release every single change you make relatively easy and fast as a result of that your users will be getting benefits or new features that you're providing with high frequency finally you can have self-sufficient teams there is no need to open jira ticket and request something from team a and then team a request something from team b and team b goes to team c and then you're handing over from one person to another from one team to another and you're trying to coordinate the madness behind having tens or hundreds of people working on the same thing you have a small application and you can manage it with a single team if there is a single benefit i would point out that's that being able to manage something with only a few people that can work in isolation from other people because they do not depend on each other everybody can run at their own speed and deliver value as soon as they can and then we get to the popular subject of how do microservices talk to each other that was problematic in the past because figuring out where microservices are trying to discover versions of their apis and locate them somewhere across the cluster was difficult but it is not difficult anymore we have service discovery if you're using kubernetes or some other advanced platform you can easily find microservices and you can talk to them directly through http rpc or whichever protocol you prefer or you can do something even better you can design your microservices to talk to each other indirectly you can use message brokers events pub subs or what's or not and that tends to be difficult for people to grasp even though we are using asynchronous communication in our daily lives all the time what that really means is that services would be sending messages or creating events without worrying who is listening to those messages to those events we can avoid designing services that need to communicate with other services but just create a message create an event and stop worrying about who will listen to those events and then you have some other services that are listening to events and doing whatever they want to do with those events or messages it's not a responsibility of a service to figure out what somebody wants to do a responsibility of a service could be to just announce hey i just added this to a shopping cart if somebody wants to do something with it great if nobody wants to do anything with it again great i said what i have to say and i'm finished so communication can be direct or indirect you can go with a more traditional approach and just configure services to speak directly to each other or you can use events message brokers pub subs or whatever else you want to use depending on your use cases and then usually people come to me hey but how do we test microservices and that tends to be tricky or easy depending on how proficient you are with the things that were happening for the last 20 years or even more we are supposed to have clear contracts of the apis of each of the service and that's not even directly related in microservices or not microservices monoliths or whatsoever every api should have a clear contract that is probably potentially hopefully created in advance once we have those contracts once we know what each api is we can easily create stubs or mocks or other methods to provide simulations of those apis once we have mocks or stubs or whatever we are using we can test our services in isolation without having any other service running in a system now that will not get us to the finish line we can write unit tests and functional tests that run in resolution and validate a service without really having the rest of the services up and running however sooner or later we get to the part of running integration tests or system level tests or whatever type of tests we are running at the very end of the process that's maybe 10 or 20 actually more likely 5 of our tests we still need to have them and to run such types of tests we can run our service wherever we want it can be even on our laptop as long as it is connected to production services for all its dependencies and then you would say hey it cannot be production because my service depends on some other service and it has to have a newer release of that dependent service because i created my service to depend on that service and you get my point that's wrong that means that they are not loosely coupled every single service should be designed in a way that it communicates with the production release of all other services it needs to communicate with you cannot assume that you depend on something that does not exist and it does not exist until it is running in production that's why we version our apis and make sure that we are speaking with a specific version of a specific api of a specific service instead of depending on some pending work then we are not independent then we are not loosely coupled and then we do not yet understand how important it is to version apis now to be honest there are problems with microservices as well one of the problems is that there is potential duplication of effort if each team is working on one or more microservices and it is fully responsible for those services there might be duplication of work across multiple teams when then right that's not the big duplication and the benefits behind microservices outweigh the potential downsides of having duplicated work as long as that duplication is small now if you find out that there is a lot that is duplicated then we probably split our micro services in a wrong way we should probably try to understand what is that big duplication across services and create a new service that will be used by multiple services to accomplish something whatever that something is integration tests can be slightly more complicated as well but that's not such a big deal today anymore because we adopted containers we are running schedulers we have githubs it's very easy to replicate an environment it is relatively easy today to create a system where everything is set up just as it should be so integration tests are not as big of a deal or a problem with microservices as it was before the biggest one is operational complexity that was horribly difficult five years ago and now it is just difficult without the word horribly we advanced a lot we have containers we have service discovery we have schedulers we have a bunch of things that we didn't have a few years ago so operational complexity is now less complex than it was before nevertheless it is still complex and that's normal because if you're managing hundreds of something instead of one thing it is to be expected that operational complexity will increase the real question is whether that increase in operational complexity is higher or lower than the benefits we are getting with microservices and you need to evaluate that for yourself because it really depends on the experience operational complexity downsides could be here and the benefits of microservices here or it could be the other way around if it's the other way around then microservices might not be the best fit for you maybe your system is small so why would you break things into small pieces if the whole is already small maybe you do not have enough expertise in operations maybe you don't have sres maybe you don't this maybe you don't that there are many reasons why microservices might not be a good thing for you there are reasons why you shouldn't use microservices in the first place but there is no good reason for you to say that you're doing something you're not if you're having monolith that's okay if you're having distributed monolith that's okay as well if you're having microservices that's great but you shouldn't say that you're doing microservices if you're doing distributed monolith and the other way around so let's do a quick test with three questions that you should ask yourself is each of the services owned by a single small independent self-sufficient team are your micro services loosely coupled with other microservices or other parts of the system are you deploying new releases of your services independently from any other parts of your system if the answer to all those questions is yes then well done you are really doing micro services or maybe you're not you're probably doing micro services there are other things to consider but hey you are my hero well done my friend otherwise if you said no to any of those three questions then you're not doing micro you probably broke your monolith in a way that now you have a distributed monolith i mean monolith split into pieces running across your cluster with all those pieces coupled together developed together and deployed together that is a distributed monolith and if that's what you're doing then you are faking it and one more thing don't go just yet keep sending me questions and suggestions what to do next you asked me what microservices are this is what i'm giving you keep your questions and suggestions flowing in the comments of my videos and i will go through them sooner or later i promise you

Channel: DevOps Toolkit by Viktor Farcic

Views: 3,500

Rating: 4.9629631 out of 5

Keywords: microservices, microservices architecture, microservices tutorial, microservices explained, 20 minutes, devops, devops toolkit, viktor farcic, microservices archetecture, microservices explained youtube, microservices explained simply, microservices explained for dummies

Id: F-37_gV2tMs

Length: 16min 20sec (980 seconds)

Published: Mon Apr 26 2021