Monoliths

[00:00:00]
>> Steve Kinney: Kind of as promised, first we're going to talk about these various different architecture patterns, and I will ruin some of the surprise early on, which is you think you have a choice, but you don't really have a choice, right? If you are getting a knitting something right now, you should just start small, right? If you work at any company of any size of any codebase that exists, then you probably have inherited one of these, right?

[00:00:31]
And you've probably inherited a somewhat outdated bad version of it, right, and so we will at least figure out how to make it a good version of that thing, right? But we'll also talk about, if you are at the very beginning and you're like, OK, I'm going to start small and simple, because that's what you should do, right, that whole you ain't going to need it like paradigm, you should at least be thinking about maybe how this manifests, and some of that will be under your control as an engineering leader, some of that will be kind of like dictated by the situation, and some of that will also boil down into fields, right?

[00:01:07]
Like some of the architectural decisions that I have quote unquote made have been because somebody with a like C-level title had feelings, right? As a front-end developer, I often have to explain to backend developers that there's no privacy in JavaScript, right? All of that code is getting sent over the wire to the browser, and there's a lot of feels about breaking stuff into many private repos when it doesn't really matter, and stuff along those lines.

[00:01:35]
So some of it will, there's trade-offs the whole way through, and we'll spend lots of time discussing all of them and how to make the best of the various trade-offs that we work with. But we have to start off with the monolith, right, which, to be clear, a lot of times is a pejorative term, but also like the monolith has a lot going for it, right? It is simple. Simple is good, right? If you only cared about simplicity, like you could get really far.

[00:02:15]
One of my big pet peeves is when you see something and you're like, that looks, and then you pause, and then you realize that you're talking to the person who made it, and you realize you can't complete the sentence, right? And then they go, well listen, it had to be this way because typically, I have found that it almost never has to be that way. The first company I worked at about 10 years ago, they had a Docker setup where they could recreate the entire company in a bunch of Docker containers, which is so big that it had to, the Docker containers had to run from the data center and you connected to them remotely.

[00:02:59]
And if that at any point went down, you could not make a CSS change. And it was like, well, it has to be this way because, right? Almost never does it. And if you ask somebody why about 7 times, you'll find out that it doesn't actually have to be that way. So the monolith has what's going for it is that it is simple, it is easy, it is good, and you should probably start with the monolith. The monolith is, as we'll see in another slide that I already know is coming, but I feel like saying it now, effectively what you get when you type in the command get a knit, right?

[00:03:32]
It is a folder and you do npm init. Welcome to the monolith, right? And the monolith has a lot going for it. It is one codebase with one deploy process, there's no like coordinating across many different, oh the API's got to get released first, and then with that we'll have actually like a migration period, we'll have the old code running and then we'll swap over to the new one, then we'll deprecate it.

[00:03:56]
You don't necessarily have to do that with the monolith because all of it is in one codebase, all of it gets committed at the same time, it all gets deployed. And if you think about it for a second, there is, you know, a lot of our industry is cyclical, right? On that, like you hear a lot of times like convention versus configuration, right? You have, you know, you have a period of time where something like Ruby on Rails, it's all about convention, right?

[00:04:20]
And then, you know, things like Ember and Angular where there's a lot of ceremony and convention, but there's a way to do it. And then over time you see something like Node or React come in where it's all about configuration and the Unix philosophy, you snap together lots of small parts, and now you spend your days figuring out, do you want underscore or Lodash or Moment or date functions, and you play that game all day, right?

[00:04:43]
And you can see that like a lot of the paradigm right now, if you look at something like Next.js, right? Next.js is almost trying to push you into, and I don't know that the Next team would agree with this, but the next, you know, things like Next.js or SvelteKit or what have you, or, you know, where they bundle your server code and your front-end code together into one repo with one deploy. You know, there is a kind of, there's an elegance to that.

[00:05:14]
And you know, when I, when we say that routing state styles test dependencies are all tightly coupled, that, you know, that we, when we think about tightly coupled, we usually think that's a bad thing, but it also means that they are one CI/CD process can make sure everything works, right, versus, you know, you might just work on the front-end and if the backend team breaks something, then your front-end goes down.

[00:05:37]
We're going to look at tools for having multiple kind of moving pieces that you can deploy either in tandem or separately. But if you think about that, what is GitHub truly set up for out of the box? One repo, right? Most tooling is set up for the repo is the thing you get pushed the repo. You deploy, right? And so if you don't know what you should do, you're like, I have an idea for a project, you should just start at the simplest thing and then like make those decisions as it grows.

[00:06:14]
You should not over optimize an engineer too early. There is, you know, this really great blog post from, I don't like the fact that I just re-remembered that it is now almost 11 years old, called Monolith First, right? And you know, we're going to talk about this a lot in the kind of day one together, but I gotta zoom in to this kind of piece of wisdom right at the top, right? And I will repeat it verbatim cause I think it bears repeating, which is almost all of the successful microservice stories have started with a monolith that got too big and was broken up.

[00:06:52]
And almost all of the cases I've heard of a system where it was built as a microsystem from scratch has ended up in serious trouble. Right, you don't necessarily know early on where those boundaries are, right? And sometimes those boundaries, we talk about like something like Conway's law, which is like when your code takes the shape of the organization. We generally like to think about that as a bad thing, but sometimes like that is a good thing if teams need to move independently, right?

[00:07:23]
And you don't necessarily know the shape of the teams early on, right? And I think one of the problems that front-end architecture has had over the years is, you know, I think the existence of what is now called backend engineering has just been around longer, so there's this idea of like, oh, we should like apply those concepts and that is great when we think about microservices, for instance, which still involves a lot of different problems, but like when you think about like microservices on the backend of a distributed system, we're thinking a lot about how they are these kind of independent isolated services that maybe have an API and then communicate with each other, and they shouldn't know anything about each other, and they should be totally separate and isolated from each other.

[00:08:13]
The problem is, and I had to explain this to somebody who was way smarter than me and had been like doing this for like 30 years, I'm like, my job as a front-end engineer is to hide that from our users that you've broken this up into very many small pieces that don't know anything about each other because our users don't want to know that detail. Our users would like to see one consistent interface and not have like different UI paradigms and like all sorts of different ways that you interact with everything.

[00:08:42]
So our job is to then, some of that stuff is really, I think, insightful and philosophical strong until you realize that your goal is to create a consistent user interface for your customers, right? And so as front-end engineers, we have an extra layer of complexity that we have to deal with that I, you know, it all kind of comes together, all that like separation of state across the microservices, who ends up having to deal with that at the end of the day, it's typically the front-end.