Continuing Patterns - Microservices

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We're continuing our season where we're talking about software architecture patterns and anti-patterns. In this episode, we're continuing patterns. We're going to continue a thought of micro. We looked at microkernel last time. We're going to look at microservices this time. I have to say that microservices are one of the best distributed solutions that's out there, at least as far as patterns are concerned. It is a way to almost by definition break up a big problem into smaller problems, solve those and then roll up all of those into whatever your solution needs to be. The way microservices work is that you have requests that go through, come from your clients as you usually see. This then gets these requests then get handled by an interface layer. Now, this is not to be considered like a user interface, but this is an interface into the microservices themselves. The microservices are in the back end of this pattern. What they are is all of these little micro, little services that are out there that do tasks. You send them some information, they do some work, they send you a result back. In most cases, very simple, very straightforward and thus, hopefully very simple to create at least that core microservice piece. For example, we could have a microservice that adds a couple of numbers. We could have a microservice that parses a line of input from a file, things like that. We're taking these larger tasks that we have, we break it down into steps. Always a good idea. Break it down into the smaller steps or component pieces that need to roll up to that solution. Then we code out slash implement each of those little steps. Those are the microservices. A bonus here is that when we have a request for a specific type of service, we could technically have multiple servers out there. Think of actually a restaurant. If you have a request for filling your glass with water, there are potentially multiple people, multiple servers there that could handle that. That means that if there are multiple people that request to have their water filled at a given point, then you can have multiple servers deal with that. Each of them would know basically as a service, they would be able to take a jug of water poured in until the glass is full. Similar sort of thing occurs when you're dealing with services from a software point of view. You have something, for example, let's say you need to, you're reading in a stream of data and you've got to parse that. It could be a file, could be some other string. Instead of you doing that individually, and maybe it takes a little while to do it. Maybe it's a long string of text or something like that. Then what you want to do is you want to parse that and then have some structure sent back. That's not a very, typically it's not a very complicated thing. You parse through it. You've got that piece that walks through it. Particularly, let's say it's delimited or fixed length or something like that. All the service does is it marches through that, breaks it into its component parts, shoves that into a class or whatever it is, and then sends it back to you. Not terribly complicated, but it's something that could be done or requested at least a lot of times during the life of an application or during just normal processes for an application. In which case, you don't want your parse service to get bogged down. You don't want it to be the one thing that slows everything else down. Particularly, let's say that you're parsing or you're working through multiple file sources at the same time. You're constantly having to do this call to this parse. You could spawn these file readers all over the place, or since you know this is a very simple piece of work, then you can create this little microservice. It gets sent something, gets sent a line of text, sends something back. It's very small, can be spun up. Technically, you could spin up hundreds or thousands or more of those old services that are getting requests, doing the work, sending everything back. This could even be a way to handle bursts. Maybe normally you only need one or two of these parsers alive and kicking up and working on a regular basis. Every so often, say after hours, you get a whole burst of information that's coming through from midnight to 1 a.m. Well, you can spawn a whole bunch of extra services, take care of that, and then they can go away. They don't have to be there because you don't have the load for them to be there, which is one of the other benefits of microservices. It's built in a way or it's designed in a way that you should be able to handle ebb flow of your application needs by expanding the number of services available or contracting those. You get a just in time type of solution. Because these things are small, the startup and shutdown time, the cost of starting and stopping that should also be very small. There are obviously considerations such as, do you want to stop and start this service on a regular basis? Or do you maybe start it and then leave it alive until it hasn't been requested anything for a minute or five minutes and then it shuts itself down? You can make smarts around this. But the other bonus is that these things by design technically should be generic types of solutions. Another service that, for example, another great one would be an address validation service. You send it an address, it sends back whether that's valid or not. Or maybe it sends back the recommended valid format of it. Sometimes you'll see, like you send a five digit zip code, it sends back a nine digit zip code, something like that. This works out really good because now we can build this service. It can be very tight, very highly tested, high quality and used by all sorts of different things because the service is a standalone little mini application, micro application. It can be spun up, send some information, it does its work, gives you the result back and it can go away. Or it can stick around and wait for other requests. That is entirely up to the service itself. That's the nice thing is it doesn't matter. Whatever is calling it, they just know that that service is out there. And particularly because it's a microservice, if one goes down, then you can spawn another somewhere else very quickly. Or you can have a request go in that says, hey, I need to spawn another service. It does it, connects you, you're off and running. So you have these nice, small, well-defined problems that you can solve and you can really tweak them. You can really performance tune those things to be as good as possible because you have such limited input and limited output. You have such a well-defined interface that you should be able to really highly refine that solution. And now you get a sort of a best of breed approach to your application itself is that you say, I've got all these little problems I've got to solve. I'm going to take these expert problem solvers in each of those little areas. I'm going to build those. I'm going to make the calls out to them. I'm going to combine up my solution and the results and provide my solution. That makes it real easy also to plug and play enhancements to any one of those microservices because there's such a small thing. It's just it doesn't have a long life. So you don't have to worry about installations. You don't have to worry about for the most part, you don't have to worry about like cached information or things that are long running processes that are dealing with that. You can basically make that call and then the next time they call it, they may get a different version. They can get the new version of the service. That's OK. As long as it's signatures don't change, then bam, you've got an update. Nobody's the wiser. You see this in a larger scale with VMs and some of those things that get spawned to go do some work. They do it and then they disappear. Well, now if you shrink that VM, that virtual machine down to a process with hopefully a small amount of resource requirements, memory, processing time, things like that, and particularly in a world where we have these shared multi-channel processors that allow us to do all kinds of threading and that within it. Now we've got a solution that we can spin up and down low cost that we can move around as needed and grow scale to whatever we need to. And of course, spawn that across multiple solutions. Multiple problems can still access these very, these high quality, high performing pieces of our solution. It also allows us to do these in whatever we want to as far as languages are concerned. So we could actually farm out the microservice part of our architecture to whoever and however it needs to be done. If it needs to be done in raw C code, so be it. If it has to be done in, if it's best done in C sharp or Java or Python or JavaScript or whatever, then go for it. Go do it. And you see this in a lot of the cloud providers now. You can see ways to build these little Lambda constructs in Amazon and Google and out in Azure that you've got these micro pieces that are available for you to put a solution on, call it, get your solution back, get your result back, and then you're off and running. So it's really almost the epitome of a distributed solution where we take the big problem, break it down into these smaller pieces, and then you basically cast out for all of the requests. It's almost the idea of, if you look at like software, the idea of the bizarre kind of thing where there's just all these different workers out there, there's all these different shops. They provide different things. You go where you need to go, call what you need to call, wrap up your solution or roll up your solution, the results, and then offer that to whoever your users are. And you can pick and choose your way along them. You can do updates. You can do whatever you need to. So it's very flexible. You're very much building a solution where you're not, you're really not putting a stake in the ground very often and saying, okay, this is a chunk of code that I've got to have. It's always going to be there. It's always going to work. Instead, you're just saying, I'm making these calls to this interface. And as long as there's something behind it that's doing the right work, then I'm happy. Other downsides, of course, you can overdo it. Always. It seems like we can overdo it. We can break it down too far, too many pieces, so that the overhead of talking to all of these different microservices, of gathering all that information, of spinning up and spinning them down and things like that can be too much. It also may be that your problem is just not big enough where a microservice solution makes sense. You don't want to break a calculator app into a bunch of microservices that add number, do add, subtract, multiply, divide numbers, things like that. I guess you could, but you're probably not. You're probably over-architecting the solution. You also can run into network-related, communication-related issues where you're having to call too many things and then get responses back from too many things. So now you're flooding a network. You have a storm of data going back and forth that maybe crushes the network itself. Your application is just doing so much, calling out, getting results back that it brings itself to its knees. So as always, moderation, everything is good in moderation, including our patterns. And that wraps it up for microservices. So we will continue digging into all these various patterns and looking for ways to help you with your software architecture solutions. But for now, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go. Develop-a-Nor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.