How to use microservices properly ?
So in today’s topic, I’m going to be discussing microservices and specifically the micro service architecture. Now not only we’ll explain to you what this is, what is a microservice, what is a microservice architecture, but I will explain to you how you can actually implement these properly and effectively and some key points that you want to think about as you go about building out microservices for whatever program, application or system it is that you are building
What Are Microservices?
So specifically I’ll define what a microservice architecture is and then that will kind of explain to you the rest of it. So the micro service architecture is concerned with looking at a large system and splitting that system into a ton of small, independent components that are loosely coupled and not dependent on each other. Now they communicate with each other traditionally using a lightweight communication protocol that is not associated with a specific programming link. So when I say that part, what I’m talking about is using a protocol like HTTP or Jason or rest API APIs, something that it doesn’t matter what programming language you’re using.
You can communicate with these different microservices. So that is why they are called micro services because there’s a ton of very, very, very small services that make up one large system as a whole. And usually to group these services together, you would use something like an API that’s capable of kind of, you know, combining these services and um, just making them more easily available rather than having, you know, 500 different services you need to look at or manage or something like that. Anyways, the advantage of the microservice architecture is that scaling your application is much, much easier.
Development is usually simpler and just having independent components makes your life easier. Now I’ll give you an example of what happens when you have a very large system that is not split into smaller components. So let’s imagine we’re building like an online shopping platform. Now we take everything related to this online shop, shopping platform, you know, the transaction. So actually purchasing something, the inventory system, the recommendation system, the user’s profile, everything there, the vendors, all of that stuff. We throw that into one application, one kind of source code block. We put that on one server, whatever.
Now you can obviously imagine that different parts of these systems are going to have different performance requirements. Maybe your transaction parts. We’re actually buying something as is very easy. That doesn’t require a lot of resources. Maybe that doesn’t have a ton of requests being sent to it, whatever. Then maybe your machine learning recommendation model that needs a ton of different resources to work properly. Well now, if you want to make your system faster or more performant or scalable, you have to just provide more resources to this one thing. You don’t have options. You can’t just give more resources to your machine learning model.
You can’t just give more resources to the inventory system. All you have the option to do is give more resources to the one system as a whole. And that makes it very, very difficult to scale because it’s hard to distribute those resources evenly between what actually needs them.
Now on the same kind of note here, same kind of thought. It’s very difficult to go and modify anything in this system. If you want to go and change something, there’s a good chance that since everything is so deeply kind of wound together, that your change here is going to affect all of the different parts of the system. It’s really easy to break something.
And if you want to be able to modify something, usually you need an experienced engineer. Who’s worked in this code base before to actually know what you can and cannot do and where you would even look to go and change a specific part of the system.
So hopefully this is kind of illustrating to you why it’s usually a better idea to have your system split into small components that kind of fewer people are managing rather than having this large code base that just has a bunch of engineers that are trying to work on the exact same thing. So that’s kind of the advantage of microservices. And what I’m going to do is give you a real world example here of a company that transitioned to microservices because of this reason.
Real World Microservices Example
So the reason I’m going to give you here is Netflix. So Netflix, obviously very large company has to deal with scalability issues all the time. Right? We saw this in the pandemic they, uh, had, what is it way too much demand. And so you can only stream video in like for ADP or something for a few days, at least here in Canada, that that happened to us. So back in 2003, 2004, when Netflix was, I guess, still a large company, but a bit smaller, uh, they did not have their system in a bunch of different microservices.
They had maybe a few different components, but everything was deeply wound together. It was this very large system and they still had a ton of that were working on this. And so that meant every time they wanted to do something, add something, delete something. It was a huge hassle. They’re looking through millions of lines of code. And it was just really difficult to do something without potentially breaking another part of the system.
And what happened was at one point in time, they had three days of complete outage due to just too much demand and they weren’t able to scale their system because of the fact that they didn’t have these things, uh, kind of split into different separate components microservices. So what they had to do was rewrite the entire code base pretty much and implement a microservice architecture so that they could handle the demand that they were having.
And what they ended up doing was having very small microservices that were handled by small teams of developers, maybe, you know, eight to 10 people, which has actually proven to be like the most effective a team size, something around the eight to 10 people, mark, because those people can understand the code and the product they’re working on very, very well.
And then they can obviously make changes a lot faster than if they had to understand a super massive large code. So let’s just giving you an example there, a lot of other large companies have done this as well. Uber Facebook, Amazon, you name them any of these tech giants. One of the reasons they’re so successful is because they can scale everything up or down based on the volume that they have, and they can handle billions upon billions of users every day, based on the architecture that they’ve implemented. So a lot of companies will start out by not implementing a microservice architecture, then realize that, H
ey, I can’t scale this application to the level I needed to be at and then have to rewrite a lot of things and implement the microservice architecture to kind of handle all of the flaws that I stated with having this just kind of large code base raving is deeply, deeply connected together.
Microservice Architecture Example
So hopefully that gave me an idea of what microservices are and kind of the advantage of this infrastructure. So what I’m actually going to do now is explain to you some of the things we need to think about when you are trying to implement a microservice architecture, because I’m making it sound relatively simple, just split everything into these individual components, but how do these components connect to each other?
How do they communicate with each other? How is data going to be consistent across how is security enforced? How do you actually go about scaling these things and making sure you have good performance? That’s kind of what I’m going to briefly talk about now. So let’s go ahead and get into that part of the video. So the first thing you need to think about when you’re implementing a microservice, architecture is dependencies.
So the whole point of the microservice architecture is to have a bunch of independent components that can be hosted on their own, can be deployed on their own. And that are not highly dependent on the rest of the system. However, to have a system that works, your components do need to work together. And so the way in which your components communicate get with each other is extremely, extremely important.
And you really need to think about your communication protocol as you’re building out microservices, to ensure that your individual microservices are not highly dependent or linked to each other, if you have a bunch of microservices, but all of them rely on each other, all of them can not be hosted independently, a change in one microservices affecting the other one heavily. You’ve pretty much implemented the same problem you had before when you didn’t microservices. But now you just have a bunch of individual components that are kind of split up, but still highly reliant on each other.
So you want to make sure you avoid, you know, deep dependencies between your microservices and the way you do that is by thinking about the way in which these services communicate with each other. And that’s why at the beginning of the video, when I was explaining what microservices are, I said, you want to make sure you have a lightweight communication protocol, something like Jason or something like rest API, something like message streams.
Maybe you have publish and subscribe patterns, whatever it is, something like that. That’s relatively easy to keep consistent across most of your different microservices and where a change in communication between the microservices has relatively minor effects on other services. Obviously you’re going to have these services, they’re going to be communicating with each other. And well, if you change one, it will have some slight effects on the other one, but you want to minimize what that is.
And so you really have to think about the way in which you communicate. And that’s kind of what this first section is about. Again, I’m not an absolute expert on this. This stuff takes a lot of experience time and, you know, research to kind of figure out. But that’s one thing to think about is how these different services are dependent on each other.
So the next thing you need to think about as you are implementing the microservice architecture is consistency, specifically data consistency. So when you I’m a ton of small independent services, chances are they’re going to need to use the same data. And oftentimes they’re going to be storing copies of the same data. Now in one microservice though, you may modify the data. So how do you make sure that the data is going to be consistent across all of the microservices?
And you’re not going to have conflicts between, I mean, two of these different services where they have two different pieces of data and you don’t know which piece of data is correct. Well, I can’t really give you the exact answer to this question because it’s highly dependent on what exactly you are doing, but there’s a lot of design patterns and kind of architectural things that you can think about and implement to make sure this is the case now, to give you a real world example of where this actually becomes a problem thinking about YouTube, oftentimes you guys go and refresh my video. And the view count you see is not the actual view count of this video
And that is because YouTube has probably hundreds of thousands of servers running, constantly picking up and counting all of these. And it’s actually a very, very advanced algorithm. They use to determine what the correct number of views, but on my backend here on YouTube, I see a different view count than you guys see. And that is an example of, one of the problems with microservices is data consistency. And you have to make sure you’re thinking about this as you’re implementing it, because obviously that’s could be a huge, huge problem, especially if you’re talking about, you know, maybe different passwords or authentication and stuff.
That’s very, very sensitive data, right? Anyways, that’s what I want to talk about for this section. Now let’s move on to the next one. So the next thing you need to think about as you’re implementing this microservice architecture is performance.
Now of course, one of the core advantages of this architecture is that if anything is lagging behind is being slow, you can go and individually scale up that component. But how do you know which component is the slowest? And why does it actually matter to really kind of analyze your system, figure out what compute power you need, where well, your system is going to perform at the speed of the slowest component, right? Kind of that famous metaphor, a quote or whatever it is. Um, the chain is only as strong as its weakest link.
Same thing applies here to software development. If the rest of your system is blazing fast, but you have one part that’s really, really slow, well, your system is going to be slow. And so you need to make sure that you’re able to analyze and figure out which parts of your system need more resources and are more performance heavy. And then obviously kind of take care of that and scale the system up accordingly.
So just something to consider the performance of your system and making sure that each of your components are performing at the level they need to be. So that the whole system as a whole is not being bogged down by one individual component.
So the next thing to consider as you are implementing this architecture is scalability. Now of course, one of the main reasons you would have gone with this architecture is because you want to be able to scale your system relatively easily, but you still need to have a plan and understand how you’re actually going to scale it. And you need to design your system with that in mind, such that you are able to scale it vertically or horizontally.
Now there’s two kinds of common ways of scaling the vertical way simply means kind of making your server or your deployment deployment platforms or more powerful. So maybe you have a server with two CPU’s and you add two more on you, give it four CPU’s and boom, you’ve scaled it vertically. Now it has more power, but you also can scale horizontally where rather than just making your server more powerful, maybe you add more servers, right?
Maybe you have five instances of the same kind of API, whereas you could have one that’s just super, super powerful. So you need to kind of understand what is going to be the best way to actually go about scaling your system. Now, again, I’m not expert in this, I don’t claim to have all of the answers. Were there things that you want to consider as you are designing your system and implementing a microservice architecture?
So the last point I have for you to consider when you are implementing biz architecture is security. Now this is arguably the most important, but you have to imagine that your security does become a little bit more complex. When you have a ton of different individual components or services, you need to make sure that all of these are using the same standardized way of authenticating users, that you have some central way of actually authenticating and authorizing your users and distributing tokens and all of those kinds of things.
So to conclude here, I will quickly kind of summarize what we’ve talked about. The microservice architecture is concerned with splitting things up into individual components that are loosely, coupled, easy to work on and can be deployed independently of each other.
This is going to lead you to faster development times, just easier development. In general, you can have small teams working on individual components, which is what happens now at pretty much any successful large tech company. And the microservice architecture does have a lot of things you need to consider when you build it. But it is very advantageous. If you can design it in a way such that all of those concerns that I kind of listed can be mitigated and kind of can be handled by what it is that you’re doing.