3 Reasons to Build Monolithic Systems

And yes, I mean on purpose.

Recommending a monolithic architecture these days sounds a bit like prescribing bloodletting for a fever, but hear me out. Long term, to ensure scalability, serviceability, agility, and all the other positive -ities (including sanity) you’ll likely want to develop and deploy your application on a microservices architecture. But if you are building a new application, your company and your development team may not yet be ready for the ironic complexity involved in breaking a system down into simple services. Speed and time to market may trump elegance…and that’s ok!

The first reason to build a monolithic system is to help tame the unknowns. Pick up any book or article on getting started with microservices, and it will describe a process for breaking down a system into component services. But if you are just starting out, you don’t yet have a system to break down. It can be quite difficult to just figure out what requirements you need in the system at all, much less to try and decompose these requirements into a set of loosely-coupled services with well-defined interfaces. With the level of unknowns at a typical start, the likelihood of getting this analysis even close to right is very small.

The main premise behind the rise of agile-style methodologies is to allow requirements to be discovered in increments because it is nearly impossible to know everything in advance. Similarly, it is much easier to discern a system’s component services when you have a tangible release or two at hand. So first, just start! Build the initial system without worrying about whether you are doing it right…there is no “right” at this stage. The art is in finding the balance between continuing to bolt on functionality and starting to separate out defined services as the fog clears, ideally before accumulating an abundance of technical debt. Approached with thought and intent, this incremental approach to architecture will be faster and more successful than trying to get it all right before you know anything.

A second reason to consider a monolithic architecture is if the team is not ready. Even once the system is fairly well defined, breaking a system down into component services is not always straightforward. Is it worth the risk to bust up that one enormous java routine (every system has one) that got out of hand? When considering a service, how small is small enough? While the normal recommendation is to continue until the service only logically does one thing, in the high velocity, big data world, for example, too small can have severe performance implications.

The main point is that there are always trade-offs to consider, and the team needs the right skillset to balance these decisions successfully. If your team is new to microservices, it makes sense to invest in training, in time for the team to explore, and perhaps in hiring new skills into the mix. As few companies can afford to bring development to a halt to retrain, the team will likely need to keep building using their traditional practices in the meantime. While this will necessitate some rework later, you’ll still probably end up with a better outcome than if the team marches forward totally unprepared. Trust me, there is a lot of rework in untrained, early-version microservices attempts as well.

Finally, a monolithic system may be your fastest path to market, and in many cases this speed is more important than the perfect architecture. For many companies, especially startups working with limited funding, getting to sales is paramount to survival. While microservices will ultimately make life easier, this ease comes with an upfront cost that you may need more maturity to bear. A good microservices architecture is elegantly simple, but it is not easy, fast, or accidental. There are many great, mature, large-scale microservices examples out there today — including Twitter, Amazon, Spotify, LinkedIn— but there is a reason they all started out as monolithic applications and later evolved. Never let pursuit of technical perfection get in the way of business success. Pragmatic architecture means that technology choices should be in support of the business needs, not the other way around.

While it should go without saying, having the opposite of each of these scenarios is a great reason to NOT build a monolithic architecture. If your application is already fairly well-defined, your team is conversant in microservices, and your company has the time and money to spend on development cycles, then you absolutely should invest in a microservices architecture. The long term benefits of this path are well known and well documented at this point. But if you are not there yet, it’s ok. Acknowledge your current state, plan your path, and iterate with intent — you’ll still improve your situation, and in time, you’ll end up with a tech-talk worthy architecture ready to keep up with whatever pivots your business demands.

Follow Here for More Awesome Content