Production-grade AWS architecture [Part 3]: Monoliths vs Microservices
1 min read

Production-grade AWS architecture [Part 3]: Monoliths vs Microservices

When you build your software, should you go for monolithic or microservices architecture? This is one of the hottest arguments in developer circles. There are advocates for either side and the argument is never-ending.

Before we get to it, let me start by saying that, by writing this article, I'm gonna ruffle a few feathers.

When you build your software, should you go for monolithic or microservices architecture? This is one of the hottest argument in developer circles. There are advocates for either sides and the argument is never ending. It's like tabs vs spaces. No one can make up their minds. And for good reason.

If you're not already familiar with these concepts, here's the short version of it. Monolithic architecture has a **single codebase** managing all the pieces of a software application. Microservices architecture is when you **split these pieces into separate code bases**.

Each architecture has it's own advantages and disadvantages. In recent times, microservices architecture has seen a surge in usage. Technologies like Docker and cloud functions have made it simple to build and deploy microservices.

## But which one should you use?

If you're starting out and not sure which one to pick, go with monolithic architecture.

## Why am I suggesting you go with monolithic architecture?

Well, because it's easy to get started. When you're in the early stages of product development, keep everything in one codebase. The first rule of distributed systems is **don't distribute your systems**. You want to simplify your setup while you build new features.

So it is completely fine if all your code lives in one codebase. It's fine if you split your frontend and backend. This will make things a little easier down the line but it's not wrong to put them together too. Any further split in your codebases, you're in for a ride.

At Rocketium, we use a combination, one monolith and a bunch of microservices. This was a recent change and for the longest time we only had the monolith, which worked really well. Basecamp, used by millions of users, still uses a monolith architecture. Their new email service, Hey, will also be using a monolith.

Using a monolith doesn't mean you can't scale. But it also doesn't mean you shouldn't use microservices. **When you have teams working on focused areas of your application, it makes sense to split them up.**

Well I guess that's your answer. Use monolithic architecture. And don't @ me.