Monolithic Architectures

[00:00:00]
>> Erik Reinert: So I think now we're gonna go into the part where a lot of people were really like, what about model this? What about distributed [SOUND], right? Again, I really hope that this meme, if anything, can kind of show you now what I mean by you don't just pick something and run with it, right?

[00:00:19]
There's a lot of validity of using a one architecture for a long time, just because, again, it works, it serves the purpose of the company. It's solving problems, right? There is no like, well, I work at a company and they use monoliths. Nobody should judge you on that.

[00:00:37]
If it's a multimillion dollar company, then they're making money that at the end of the day, that's what wins. So again, one does not simply choose backend architectures, it's something that you craft. And so we're gonna talk about common backend system architectures really with everything that we just had in mind and everything that we just talked about.

[00:00:58]
So we are going to talk about three commonly used architectures, all right? Now, there are tons of architectures out there, because, again, there are tons of problems being solved in the technology space. And it does not even mean that you should use only one of these. Everything that I'm about to go through is only showing you three different approaches and how you can use them in different situations.

[00:01:29]
However, it does not mean that you can have monoliths with distributed or not with distributed, or with serverless or not with serverless. It's really about solving the problems that you need. There might be one team that's really good at working on monoliths and so a monolith architecture works well for them.

[00:01:48]
There might be another team that works really well with distributed services, and so maybe that's a better solution for that team. Before I go forward, again, I really want you to take away that this is not a one-size-fits-all solution, right? One particular way of doing things doesn't mean that it's the only way of doing things or it doesn't mean that that's the only approach you have to do to do things as well.

[00:02:16]
So let's get into the first one, monolith. Has anyone seen Hitchhiker's Guide, by the way? Okay, so if you don't know, this is deep thought. It's really funny to me at least because in the story, they have this huge supercomputer that's supposed to solve life's answers, and it says that the answer of life is 42.

[00:02:38]
And so I feel like sometimes that's how monoliths feel. You've got this huge, massive thing and then it just gives you this one little result. So I felt this fit really well for monoliths. So let's define a monolithic architecture. So monolithic architecture is a model where all the necessary code and components for a software application are combined into a single unit, right?

[00:03:06]
Just out of curiosity, how many here uses monoliths where you work? Yeah, it's probably one of the most common architectures that you would start with at a company or even at a project or things like that. Monoliths are very powerful in their own right, by the problems that they solve, how they solve those problems, and how they can help growth of a company.

[00:03:34]
So this is really what a monolith looks like. It's very simple. You have users, they get sent to a specific monolith. It can normally be the frontend and backend combined into one, right? And then maybe there's a database instance that's behind that or something like that. But at the end of the day, most projects, most companies start with a system like this.

[00:03:58]
And as I said before, it's normally completely coupled. Meaning that your frontend and your backend are the same thing. Something like Next.js, for example, that technically could be considered as a monolith because you're doing your frontend logic and your backend logic all in one place. And there's a lot of reasons why Next.js and other frameworks like this are becoming really popular, because you can move fast, right?

[00:04:23]
The idea is that in this kind of architecture, everybody's in the same seat. We're all working together. We're all modifying or working on the same code. There's not tons of changes with regards to the languages that are being used or the definitions or the libraries or whatever. We're all basically cooking in the same kitchen.

[00:04:43]
And so this is what a monolith can look like if you're working on something like that at a company. So, again, monolithic architecture basically has all functionalities tightly coupled, running in the same system. So again, if we go back to this monolithic chart, we'll see that the frontend and the backend are joined together.

[00:05:06]
And that means that they can be worked on in the same sense. If they need to be updated, they can be updated together and you don't have to worry about going to different places to do so. Why is monolithic architecture so valuable? Well, it's simple to develop, test, and deploy due to its unified system, right?

[00:05:25]
You're developing in the same location, all of your tests exist in the same location, and what you're deploying is the same thing, right, over and over and over again. It's a small, tightly coupled architecture that allows you to iterate quickly and not worry about complications, abstractions, things like that.

[00:05:46]
>> Erik Reinert: So the pros, again, simplicity, it's easy to develop, test, and deploy, right? It makes it so that that simple architecture allows you to move fast. If a project comes in, everyone's got a unified understanding of the system and so that they don't really need to be asking questions even as well as like, how do you do something?

[00:06:05]
It's already there. Normally, nine times out of ten, it's already been defined and there's a good pathway of how to work on the thing that you're trying to work on. Monoliths are also really great for new hires. You don't have to talk about tons of complexity or things like that.

[00:06:21]
You could just say, well, here's the monolith and here's what we work on. And as you get more comfortable with it, you'll start to understand it more and more. Another pro is consistency, right? So there's a uniform approach to handling requests as every module uses the same set of procedures.

[00:06:40]
So, again, for example, if you're using the monolith frontend backend system, it's all gonna be HTTP. You don't have to think about services talking to each other. It's really just functional logic in your backend that you're modifying. There's no overhead of really anything else outside of the actual service Itself.

[00:07:05]
Again, efficiency is really important here, because all the functionalities are interconnected, it can be more efficient in terms of inter-process communication. So when we say efficiency, I wanna be clear in saying that I'm not talking about performance efficiency, right? Although, this can be a part of it. What I'm talking about is the fact that everything is in one place.

[00:07:26]
We do what's called vertical scaling effectively, right? It doesn't mean that I will potentially be creating replicas of this, but it means that I can just make it bigger, right? And when we talk about scaling for server or for companies, sometimes vertical scaling is the much easier approach.

[00:07:45]
Instead of having to worry about tons of replicas and how do you auto-scale those, and then how do you do round-robin requests and things like that. It's just make it bigger, [LAUGH] give it more memory, give it more CPUs, that's it. And so going back to the Fossabot example, I've talked to my friend, Aiden, about it, and one of the reasons why Fossabot is so powerful is because he vertically scales it.

[00:08:16]
He realized that basically instead of trying to handle routing requests and having multiple replicas and stuff like that, it made more sense just to make huge instances. And so most of the components in that system are just vertically scaled. There's not tons of replicas and thousands of instances processing hundreds of requests a second.

[00:08:39]
It's just one huge service processing all of these requests, again, kinda like a fire hose. So the efficiency there is that if you want to be able to scale vertically instead of horizontally, monolith architecture can actually be very valuable to what you're trying to achieve. The cons, however, right, are the limited scalability, right?

[00:09:07]
So scaling specific functions of a system is not possible, the entire system needs to be scaled, right? And so for example, in a monolith, say you have your frontend and your backend coupled together. But maybe you're just doing a lot of Vue rendering or processing requests to render something, but not necessarily needing to do a bunch of database requests or things like that.

[00:09:31]
That's where maybe it would be nicer to be able to scale the frontend services and not the backend services with them. If it's coupled together, you're scaling both, right? And so that's something to take away. With regards to monolithic, you're limited by the scope of the service and how it's implemented.

[00:09:50]
If everything's in one place, you have to scale everything.
>> Erik Reinert: So lack of flexibility, this also becomes a challenge with monoliths, right? Changes to a single component can require the entire system to be redeployed. This is actually a problem we deal with at my company today. We have one monolith called Pod.

[00:10:12]
And Pod, because it serves routes for everything of that service, if we update a lower-level route or lower-level logic, say like a middleware or something like that, we now have to test every single route again to make sure that everything is working. And this is a big reason earlier on in our discussion, when I talked about our testing resources versus our production resources, this was a big reason as to why.

[00:10:40]
Because every time we made a change, we were constantly retesting everything again. Even routes that weren't touched were still being retested because it's all part of the same monolith. So lack of flexibility is very challenging there. Complexity, now you might think that, okay, well, it's a monolith, how complex can it get?

[00:11:02]
I would really encourage you to look at a huge monolith over like two to three years. Monoliths can be complex in the sense that again, the file system for it can be huge. You might have tons of libraries, tons of implementations, even different design patterns that are mixed together.

[00:11:22]
As the monolith grows, it becomes harder to organize the components in the monolith, because at the end of the day, it's still all in the same place. So you have to have really good design or really good theory around, okay, well, how am I decoupling these components from these components?

[00:11:39]
A good example of this is we were doing a change to our monolith, and we were trying to restrict access to a given endpoint. However, the middleware was lower than the endpoint itself, and that's where the restriction was put in. And when they put that restriction in, it was done via an environment variable.

[00:12:00]
However, in production, that environment variable didn't get set, and so all of our routes stopped working because of that lower level change that was made without realizing the impact of how it could affect the rest of the routing. And so that's complexity, that's being able to say, I don't really know how this was made, right, and so because of that, I now don't know what I'm impacting.

[00:12:24]
And so that's when you have to kind of fully rely on tests. And if your testing isn't good, then that can lead to more complexity, more challenges. And again, monoliths are great, but it really needs to be considered how your monolith is scaling from a logical perspective.