Day 12: Death To The Monolith

How many times have we seen it, where an application does HR, payroll, shipping, billing, makes coffee, sweeps the floors, etc.? Too many times to count for me. The truth is that applications like this, these monoliths, are too large for their own good. Development becomes difficult or impossible, and understanding them is usually relegated to the most experienced developers on the team. This leads us to our twelfth and final principle: modern applications are laser-focused on their specific business case.

The title of this post might lead some to conclude that I am directly endorsing microservices as a solution to problems with application development. That would be an inaccurate reading of my intent. Microservices are great in certain situations, but they don’t apply in each and every one. Let’s explore this a bit.

Microservices are narrowly tailored applications that serve a singular purpose. Think authentication, or sending out an invoice, or adding a person to a directory.

By contrast, the applications I am endorsing are compact monoliths: they do more than one function, and they are as large or small as they need to be to accomplish that specific function. They may or may not talk to other applications via an API (I recommend that they do), and they may or may not allow incoming API requests (again, I recommend that they do). Rather than simply handling authentication an application might authenticate a user, allow adding that user to the company directory, and permit storing information about that user. This is more tasks than a typical microservice.

What I am advocating we avoid is the large monolith, an application so big that it bloats and becomes unwieldy. An application that large is often unmaintainable. It’s often untested. If it is tested the tests are bogged down with extensive functional and acceptance tests that require more time to run than the developers are willing to wait. The experts on the application are usually the people who have been there the longest, and I don’t have enough fingers to count how many times that has been a single person. What happens if that person is sick, or wins the lottery and never comes back into the office?

Monoliths present deployment challenges, too. They’re difficult to build automatically (see lack of testing, above). And they’re difficult to deploy, meaning the deployment cycle is often very slow. Developers are often scared to deploy a monolith so they don’t; this only delays the inevitable, and the longer you go between deploys, the greater chance of bit rot. Bit rot happens because things left unattended always unravel, memories become spotty, and developers lose sight of what they learned in the past and must relearn it. All of this leads to poor business outcomes.

If your platform is customer facing and you have a huge monolith, this presents an incredible challenge, too. First, you’re unlikely to deliver the latest in features and benefits to your customers, and they may go elsewhere. Second, when you do deploy you’re more likely to ship bugs along with the new features, and these bugs may not be corrected for many days or weeks if your deployment process is slow. You may find yourself faced with challenging decisions to roll back or fix in place, which is a decision no CTO wants to make.

Smaller applications, even if they are monolithic in nature, typically don’t suffer from these problems. The reason why is that they are easier to test, simpler to deploy, faster to fix, smaller to understand and quicker to be fixed in place if problems are discovered. APIs allow the applications to communicate across clearly defined boundaries, ensuring that you get the benefits of microservices without the hassle of deploying dozens of services just to achieve one task.

So embrace the compact monolith. Shun the large monolith. Your applications will be better for it, and so will your application development process.

There are currently no comments.

Copyright © 2023 by Brandon Savage. All rights reserved.