Hello, everybody. Welcome to another article. So in today's article, 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. Now, one thing I do need to note here is that I'm absolutely no expert when it comes to microservices. And that is why for this video, I have teamed up with a company called blazed path. Not only are they the sponsor of this video, but they've helped me come up with a lot of the content I'm going to share with you right now. So let's quickly have a word from them because they are actually a company that helps you implement microservices and scale your applications.
This video is sponsored by blazed path. Blazed path is a proven low code platform that can help you build applications with ease. You can start with a simple application and the platform integrates all of the tools you need to grow scale and turn it into a big enterprise grade project inside blase path. You design build and deploy distributed microservices in the cloud with the help of a lot of integrated tools, standard technologies, embedded security, consistency, and integrity validations. Your team can be hyper-productive and get the job done 10 times faster than with traditional development. The best part of blazed path is that there are no vendor lock-ins and it produces human readable code. That means that you can deploy your application anywhere you want. And there's nothing that keeps your project captive in the platform. Blazed path, lets you manage the end to end life cycle of your project. Microservices.
It handles security, scalability, logging, API APIs, message queues and cash blazed path handles the continuous delivery of microservices features considering all of these and more critical aspects of distributed architectures that we will touch on. In this video, you can try blaze path for free with the link down in the description, create your free account, download your local studio and get additional credits using this link. The one in the description, thanks Blaise path for sponsoring this video and now let's dive into it. All right. So I've said the word microservice about a hundred times. So it's probably important that I define that. So how about we feel free to do that at this point. 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.
king 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. Presently how about we continue on to the following 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 just pretty much as solid as its most vulnerable connection. 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. All right. 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? All right. 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.
No comments:
Post a Comment