A Monolith, Perhaps?

In the context of this article, the word “monolith” is used to represent monolithic development: a software or environment that lives in one source code repository and has one versioning scheme. This does not necessarily mean a single binary executable, or even a system that runs on a single computer.

Almost every project starts as a monolith. Perhaps you had a quick idea – or started writing from a detailed spec from a client, but at the time that first line is written, every project has at least a brief monolithic stage. Should a project stay that way? What are the advantages and disadvantages of keeping a project monolithic? Is it possible for a team of developers to work efficiently on a monolith? This article will try to answer these questions.

Pros and Cons

Advantages

Monoliths are great if you work alone. They’re also great if a project is relatively small. Some low-level environments, such as kernels or IOT projects may necessitate at least a partial monolith design to maintain efficiency.

The first two real advantages that aren’t born out of necessity are related: Monolithic design forces you to keep all related changes in sync. It also immediately exposes the full architecture, the big picture, to any developer working on it. This is also a disadvantage, I’ll get back to that in a moment.

When working on a monolith as a team, project management overhead is minimal. Independent of which platform you’re on, issue tracking, branching and code review can be kept in a single project. This means cross-referencing issues, managing access and deployment pipelines is easier than if the components were scattered across multiple projects. This also prevents a massive backlog of ignored issues from developing unevenly in one part of the project, as all issues can be seen in the same view. It should be noted, though, that some of the complex project tracking systems can address this when working across multiple codebases.

Disadvantages

Context matters. Even as a starting point, monoliths may be a complete no-go in a large corporate environment. If a company has a range of shared core components but maintains a line of separate products that uses them, a monolith may not be the right choice at all, as parts of even a smaller project need to be kept modular.

Some of the other significant disadvantages include:

• Fragility: One fault can break the whole project. This is not a problem limited to monoliths by any means, but they are especially vulnerable.
• Onboarding: It is vastly harder to onboard someone on a monolithic project than to bring them in to work on a small self-contained component and then gradually have them learn the intricacies of the rest of the big picture.
• Structure: Keeping everything together can be a challenge as the project grows.
• Time: Especially if the whole project is behind one build command, or a single container definition, compile times can grow even to the point where they hurt deployment.

Setup

In the past, many monolith setups have comprised of massive build scripts or repositories with binaries for different platforms. But in today’s computing landscape, containerization has stepped in. You can have a full environment set up, compiled, all the way to a usable set of sample data, in a development container that automatically builds itself when you open a project for the first time.

There are still use cases where containerization either isn’t possible or produces an unreasonable obstacle:

• Desktop applications. There was a short slice of time where dev containers existed and X11 was still relevant, making that an option. Also, a native experience on the development platform wouldn’t be possible outside of Linux/X11
• Direct hardware communication, i. e. software written to interface with a hardware component, either internal to the system or over a bus that can’t be translated to a container.

Teamwork

Monolith doesn’t mean you can’t work efficiently as a team. If you tried it 20 years ago, you may want to give it another shot. Why?

Since the birth of Git, it’s been much easier for multiple people to work on the same codebase, sometimes even the same parts of the codebase. This used to be one of the major frustrations with earlier versioning systems like CVS and SVN. Also, it’s easy to even work on larger bits of a software using branches.

Here’s some things that make teamwork easier when working on a monolith. It should be noted, though, that these would make any project easier, but in the case of a monolithic project these are especially important.

• Contracts – this is no different than working in separate projects. If you’re working on one part of a project, you should maintain interfaces with the rest of the project intact. It’s essential there are unit tests that run after each commit that specifically test the communication between different parts of the project. This will happen as it does with multi-project setups, but monoliths provide a simple way to catch that immediately.
• Git flow, GitLab flow, GitHub flow, etc – an additional benefit of using a flavor of git flow provided by the hosting service is that their tools for merge requests and code review help name branches consistently and communicate observations and potential issues with ease.
• Consistent releases or deployments. Even if the monolith has multiple pieces, being able to refer to a release when talking about a change or a problem is great.

Goodbye, monolith

In many cases, monolithic projects can’t live as such forever. The inevitable happens: business picks up, scope creep picks up, development teams bloat and there’s a whole floor of people doing marketing.

Keep in mind that you should have a really good reason before splitting a codebase into multiple repositories. Here’s some examples – they don’t necessarily mean you have to do it, but no one would blame you if you did:

• Client / server side code has been separated to be worked on by different teams
• You find out one day that what you’re actually doing is microservices
• Any sort of membrane that separates parts of the project completely, like a flexible, self-declaring API
• Parts of the project have become products that are sold separately

A great rule of thumb could be, that if you go to your workplace (or join a meeting if working from home) and run into a person that you’ve never met or even heard of and you find out they’re working on the same project as you, you’re probably way past the point of splitting the monolith.