Evolution of Backend System Architectures

[00:00:00]
>> Erik Reinert: The next one is going to be Evolution of Backend System Architectures. And so, I really like this GIF because it really does kinda show the process of something over a period of time, and this is really how your architecture should grow. It should slowly become more defined, more understandable, and easier to look at, basically, as it grows.

[00:00:21]
And so what we're gonna do really quickly, is we're gonna go through the evolution of a backend system architecture from one to another. So, we're gonna start with a monolith, right? This is the most common scenario that a lot of people start with, right? We've already talked about this, we've already explained why.

[00:00:39]
So we don't really need to go into a lot of detail with this. But if you were at a company and you were wanting to start something from scratch, or you didn't know where to begin, a monolith is a great place to start because of, again, the simplicity, the consistency and the efficiency of being able to run that monolith.

[00:00:58]
You don't have to worry about the distributed, all the complexities of that. You don't have to worry about the limitations around serverless and things like that. You have a lot more control of running that thing locally, developing it, putting it in the cloud, and then letting that iterate over that time and time and time again until you get to something a bit further.

[00:01:16]
So, when we talk about that, again, here's our monolith, right? And this is where something like Next.js going back to that as Next.js as a monolith, this is why it's so powerful. This is why people are getting excited about it, is because it's so easy to have all of your components in one spot, drop it in as a monolith and off you go, right?

[00:01:37]
And this is most of the reasons why smaller companies, and I'm gonna be very clear when I say smaller companies, can do this, right? This is what makes Next.js so attractive, as well as why a lot of people are getting onto it because here's the truth about the software industry.

[00:01:53]
90% of the people that are doing huge crazy elaborate architecture are not 90 % of the rest of the industry, a lot of people are still running monoliths. Some people are still even running a co-located facilities and running their own servers. So, things like this are very attractive, right?

[00:02:12]
You get a really nice clean interface to build your monolith in, you can drag and drop it, it's all available to you, and you really don't have to think too much about doing it. So this is where you would start, you would start with a monolith and something like this.

[00:02:26]
Then what you would do is, you would start splitting to services, right? So we talk about having a monolith and having it all in one place. We've talked about microservices and services and how those approaches work. The idea here is that after a company or project grows, there begins the need to split out functional logic into units for the following benefits, again, independent development, independent deployment, fault isolation.

[00:02:53]
So independent development means you're hiring more people, right? That you have more teams, that you're growing, that's good. This is a very common approach for a company that's starting to grow, that's starting to accumulate more, not just users, but also employees. Again, when you accumulate more employees, you want those employees to be able to deploy things on their own and have their own fault isolation and things like that.

[00:03:16]
So again, you go from this microservice monolith approach where everybody's working together, everybody's drinking the same Kool-Aid. And then you say, okay, now that we have little cups of Kool-Aid for everyone, here's your cup, here's your cup, here's your cup, here's your cup, go work together and start splitting out the things that you need.

[00:03:36]
Also, when you get to this point, the idea is that you're also hiring for specific things, right? You want a team that handles user data, you want a team that handles, again, processing transactions or things like that. So, the split to services approach should be easier to identify once you get here.

[00:03:54]
If you start with this, it might be hard because you're one person, right? If you want person making a microservice or in a service based architecture, you might not even need to split it, so you don't know how to split it. You're like, I guess I could split this, but you don't know, you won't know until you're actually at scale.

[00:04:12]
Again, going back to the original slides, testing, monitoring and managing the system for a while to see what needs to scale and what doesn't. One last thing to note about splitting to services, you should only split to services when you need to, right? So if you're in a monolith architecture, stay in it, right?

[00:04:33]
And start looking at what are things that need to scale and only move those things first. Dip your toe into the distributed architecture, don't just dive in. If you dive in and do everything at once, it's gonna hurt, it's gonna be a bad experience, and it's basically gonna be like belly flopping into a pool, it's not gonna be fun.

[00:04:53]
So again, we're gonna go back to this, right? We start splitting to services, hopefully now this really encompasses everything that we've talked about today. And you understand why you can have a frontend team, you can have a backend team, those are two isolated and they're two working together.

[00:05:08]
Finally, saving with serverless, right? So we talked about monoliths, we talked about services, but then we also talked about the need of saving money in specific circumstances or saving operations cost, saving resource cost, saving scaling challenges. So again, after starting with a monolith than separating that logic with services, a system can further benefit from serverless for those things, right?

[00:05:34]
At this point, you should have a pretty good experience with distributed, at this point you should already kind of have your team separated, you should already have a good understanding of how these processes separate from each other. And maybe specific teams wanna start using server lists. It doesn't mean that all the infrastructure has to move to server lists.

[00:05:52]
It just means that maybe a specific team is taking up a lot of costs. Maybe they have a lot of management in infrastructure or scaling issues, right? This is where you could go to that specific team and say, okay, cool. Well why don't you guys start moving some of these things off to serverless and work with those as well.

[00:06:13]
And so again, this is where we see this slow creep to moving to more serverless approach, trying to save money, and again, we just kinda go back to the same diagram we saw this before. But now this encompasses everything, right? This now shows you the evolution in more detail why you go from one to another to another?

[00:06:36]
Does this mean as well that you can go from server list Back to server or back to monolith? Yeah, if you have a reason for it, right? I told you guys earlier that I'm at some point gonna have to put a service in front of Twitch chat messages, otherwise my cloud bill's gonna go through the roof, right?

[00:06:53]
So, it doesn't just mean that you're just gonna go in one direction. It could mean that you go in one direction, and then you move back, and then you move forward again, and then you move back again. These architectures are dynamic, they're alive, they're living creatures in some way.

[00:07:06]
And so it evolves it grows, it has pain points and then eventually solves those pain points.