Microservices

[00:00:00]
>> Erik Reinert: All right, so now let's talk about microservices. So we talked about generic services, and to be clear, like, even at Hippo, where I work, we mostly have generic services. Microservices are something you really have to think about and why you're doing them the way that you are.

[00:00:17]
Also, microservices normally nine times out of ten have a coupling to a team, an ownership of some sort. For example, [LAUGH] why give a team ten microservices to manage when they only really need manage one generic service, right? And that's another architectural decision that you wanna think about.

[00:00:39]
Is there a reason why we're splitting these all into individual services, or is it because you have a lot of teams and you want this team to just handle payments. You want this team to just handle the outflow, right? And at a huge company that's why micro services work so well, is because that a company again like Google, Amazon, Netflix, whatever they have hundreds of teams, right?

[00:01:02]
And thousands of engineers potentially. And so that's when it becomes more micro where those teams, one team's off, one team's security, one team's, again, payments, right? Things like that. But each of these teams are handling these services that are potentially processing thousands of requests at a given time.

[00:01:22]
It's almost like, if you really think about it in the simplest of terms, it's still a service, but the scope of concern becomes much smaller. And that's why we call it a microservice. That's really the only reason why, is because the scope of the concern of the service is much smaller to the team.

[00:01:42]
So, microservices are a specific style of service-based architecture. In a microservice architecture, each service is small, independent, and loosely coupled. Then again, small being the real key word here. If you have a service that is handling multiple things, you do not have a microservice, you have a generic service.

[00:02:03]
If you have a service that is only solving one specific problem, then you potentially might have a micro service. Another thing about microservices are they run in their own process always. So, they'll normally always run in their own process as compared to generic services where you still might be able to couple them with a monolith or something like that.

[00:02:23]
Microservices run in their own process, and they communicate nine times out of ten with other services using protocols such as HTTP REST or messaging queues or gRPC or things like that. So, if you have services that are not talking to each other and don't have a small specific requirement, you're just dealing with services.

[00:02:47]
And so I would encourage everyone out there, whether you're working on a project by yourself or working at a company to look at your services and ask, am I actually using a microservice architecture? Or am I just using a service based architecture? I have had this at Hippo where we've had people be like, yeah, we have a microservice architecture.

[00:03:10]
And I'll be like, where? Tell me, where do we have a microservice architecture? And nine times out of ten, they can't because a lot of the times it's individual services being accessed directly instead of services being interconnected, talking to each other. Now, we do have microservices, we do, but it's not as many as I think people may think you have.

[00:03:34]
>> Speaker 2: When would you change from a monolithic architecture to microservices?
>> Erik Reinert: So, you probably would not go from monoliths to micro. That's a huge jump, that normally means that your company is scaled huge or gotten quite larger. That would mean that, a good way of looking at it is is that the specific component in your monoliths has grown so big that a specific team has to handle that one specific component, right?

[00:04:02]
That's really when a microservice becomes something that you need to separate like that. Normally, what you would do is you would split off into like, a service that handles a specific thing or something like that. But it still is coupled with other services in some way, which means that service has a dependency on other services which means it's not really a microservice.

[00:04:24]
A microservice, a good example of a microservice which we'll show here in a second, is only having one service with one database processing one specific thing. And then another service with another database processing another specific thing. But if you have services that are potentially sharing databases and stuff like that, those domains are technically crossing still.

[00:04:44]
So, you have to have a really good line in the sand of like, this is just this microservice and what it does and what it access, and it doesn't necessarily touch or need to touch anything else. But if you have that requirement where you can say like, okay, this one specific feature doesn't touch anything.

[00:05:04]
It can just exist on its own, then that's a good opportunity to create that into like a microservice. And again, I wanna note, messaging queues in this, we talked about HTTP wraps or messaging queues. Microservices can also be what I call, or what we call it, my workers, right?

[00:05:25]
Which is it's on a queue listening for one event, and that's all it does. That is a microservice. So if you have a scenario where, say, you're processing chat messages and you just wanna process Twitch chat messages. Then you would have a microservice that just processes the messaging from Twitch chat services.

[00:05:44]
That's all it does, it doesn't do anything. A good way of looking at microservices are kind of what we're gonna talk about in a little bit, which is also serverless or functions, where it just has one goal. And every time you hit that microservice, it basically just does the same thing, right?

[00:05:59]
And you can scale that individual function to end amount. So having a really good understanding of that logical separation and how big or small that impacts other systems is when you're gonna be in either a service or microservice.
>> Speaker 2: If you were to, I guess in your own example, if you want to grab that server that receives chat messages and he's gonna get messages from different providers at that point would that be called in?

[00:06:26]
Or will you consider a generic service or a generic service instead of a microservice?
>> Erik Reinert: So if it was processing both providers, yeah, it would become a generic service. Yeah, because it's doing more than one thing, you have to have more than one maintain it on it, you have to modify more than one thing with that.

[00:06:45]
And so, yeah, it would become more generic in that sense than saying this one thing does this one thing scale it to as much as you want, yeah. So this is actually a scenario of a service working with microservices, right? Now, when we first talked about the design we saw earlier, we saw our front end and our back end in two separate services, but they really kind of handle generic things, right?

[00:07:10]
In this scenario, what we're doing is just we're saying, well, you know what? We wanna front end to be a service because we know that that's going to handle all of our front end requests, but we wanna have a specific team handle the user's service or microservice in this case.

[00:07:25]
And it only has its own database, it has its own logical unit, you can see that users has no shared data with payments. What this also means is that the users database may have records inside of it that even relate to one or the other, but it's just a relational like ID potentially or no ID whatsoever, which could mean that the user's database only has user IDs in it.

[00:07:52]
And the payment database only has payment IDs in it, and then those are joined together somehow via lookups or other kinds of requests. But this type of logical separation makes it so that my team can own the users microservice, anything else with it, and then have that database ownership as well.

[00:08:11]
>> Speaker 2: Now, even users, in this case, is rough, because you could still kind of consider the user service as a generic service.
>> Erik Reinert: It could be doing a lot, right? So if you wanted to take this step further, you could even say that maybe this is the, update users or something like that, right?

[00:08:29]
But this is just to kinda give you that logical separation of, okay, this team manages this, this team manages this, and they don't really need to communicate or work, explicitly together. They can work separately, and then whenever a change is made from any one or the other they just update those teams of hey, we updated the scheme.

[00:08:48]
Hey, we did this and the other teams can work accordingly. Another thing about microservices and I didn't really include it in this design, but it's kind of shown which is the front end is used as almost like proxy to those services, right? So, the user themselves do not talk to the user's service or the payment service, right?

[00:09:12]
Those are being sent through the front end so that the front end then has its own standards of how it talks to these internal services or microservices. And we don't necessarily need to worry about, well, if we change something to users, does it need to be updated all the way to the user-facing side here, right?

[00:09:32]
It's just the coupling of these two segments here. And so this could be gRPC, for example, but then this could be HTTP, right? And honestly going back to like, languages and stuff like that. Go is a really great language to build services and microservices in. Go has a lot of really good tooling around.

[00:09:57]
I've said it a few times with gRPC, which is basically a really great protocol. And the reason why is because gRPC allows you to describe schemas and then share those schemas throughout your architecture as clients. And so, in the circumstance of having a user's microservice and a payment's microservice or anything like that, I could write it in Go, generate clients for the front end.

[00:10:22]
And I don't even have to write that request code. I don't have to go in and write like an HTTP request and a URL endpoint. The microservices should generate their own clients so that they can just be embedded into any upstream or downstream services easily. So if those clients get updated, they just get regenerated, and then the services around them can easily just pull in those changes and use those new clients.

[00:10:47]
This makes it really easy to maintain distributed services, because now there really isn't even much of a communication needed between the two teams. It's just saying, hey, we updated our schemas. Go run an update on your client code, get the latest version of the client and you're good to go, right?

[00:11:05]
This is very similar to services that exist outside of your architecture, right? A lot of STKs and things like that, these are basically your own internal STKs that become available that you can use and again goes really great at services and microservices. So, it is it is one I recommend, as a matter of fact, it's probably the only one I [LAUGH] recommend.

[00:11:29]
I built services and microservices in no JS. Don't recommend it, it's got its own overhead and challenges. Again Rust Is a great language, but I feel like, there's a really big reason to why you would use Rust. And most of the times it's not for building web [LAUGH] applications.

[00:11:48]
You normally have a much more specific need of like, memory, security, things like that, Go really checks off a lot of those boxes. So, if you were to ask me, what would I build a monolith in? Whatever you want, [LAUGH] it doesn't matter, whatever you want, whatever your team's comfortable with, like, genuinely do whatever you want with a monolith.

[00:12:09]
That's really, the monolith is there to really get you to move quick. But when you're talking about distribution and needing like, a standardized flow of updating things, Go really is great for creating services and microservices, because a lot of the tooling that's been built around it. And a lot of the stuff that exists in the world today, as a matter of fact, it's one of the reasons why it was created.

[00:12:30]
Google needed a better approach to creating safe systems, but also be able to make them really quickly. And so that's why we have gRPC, that's why we have Go, And those two are so tightly coupled because they work so well together