Monoliths to Microservices: Building a Solid Back-End Architecture
Superthread founder David explains the shift from monolithic systems to independent microservices, why you should avoid gRPC, and the 2-week development rule
Mar 28, 2021
|
David Hasovic
From One Machine to Many: The Evolution of Architecture
The way things used to be done in the past is normally you'd have one machine running Linux or Windows. On that machine, you’d be running your app, like a shopping cart, and your database as well. Everything was in one place. If that machine flaked out or crashed, your whole site would go down.
Eventually, people started separating databases onto different machines to make things more reliable, but it still wasn't quite enough. This is what we call a typical monolithic architecture: one app where everything runs inside one process with all the endpoints in one place.
The Problem with the 'Distributed Monolith'
People then started thinking about how to take an app and separate it into different bits. The idea is that if one part of the app goes down, say, your search service, the rest still works. You could still register, log in, and edit your profile even if you couldn't search for items.
But early on, people still used a single database. If that flaked out, the whole thing went down. It was more 'microservicy' than a monolith, but it still had a single point of failure. What we do now is separate each microservice into its own app and its own database. If the search database goes down, only search goes down.
However, this creates a communication problem. Google invented a protocol called gRPC for this, but when microservices talk to each other too much, the dependencies become very complex and flaky. You end up with a distributed monolith, which isn't ideal.
The Superthread Way: Radical Independence
At Superthread, we architect everything so that each microservice is as independent as possible. It has to talk to other microservices as little as possible. This makes the system more stable and solid.
The more your services talk to each other, the more you're heading back toward that distributed monolith. A proper microservice architecture means:
Independence: It does its own thing.
Isolated Data: It has its own database.
No Chatting: It doesn’t talk to other services unless absolutely necessary.
The Cognitive Advantage
The real advantage of microservices is separating code into smaller components. For a human being, it’s easier to cognitively comprehend a smaller chunk of code than a massive project where everything is interconnected.
I have a few strict rules at Superthread to keep us on track:
The Two-Week Rule: A microservice shouldn't take longer than two weeks to develop. If it takes longer, it’s too big and we need to break it apart.
The Rule of 10: Don't have too many microservices. Once you get above 10, it becomes difficult for people to understand the system holistically.
The 'One Developer' Test: One developer should be able to get in and understand exactly what is going to happen very quickly.
Orchestration: Kubernetes and Beyond
These days, orchestration is much easier. In the past, people measured load manually and spun up new instances. Now we have Kubernetes, which measures load and automatically adds more instances to the load balancer pool.
Kubernetes is the most popular way to orchestrate, but in my experience, when it goes down, it’s very difficult to determine what’s going on. I’d recommend looking into Amazon’s own offerings (like ECS or Fargate), they seem to be a little simpler. Either way, you need a system where you have visibility so that if things flake out, you can quickly fix them.
A strong, solid back-end architecture is built on independent services and clear visibility. That is the only way to serve a high-performance app.
Experience a workspace built on high-performance architecture.
Superthread isn't just fast on the front end, our back end is engineered for radical stability. Sign up for Superthread for free today.
