Image for post
Image for post

3 Reasons to Build Monolithic Systems

And yes, I mean on purpose.

Natalie Conklin
Mar 17, 2019 · 4 min read

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!

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

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

Design and Tech.Co

Ideas for the 21st Century Hustler. www.designandtech.co

Natalie Conklin

Written by

Fearless and forever curious — a life-long learner, explorer, cat-herder, and engineer, leading software projects for some of the world’s coolest companies.

Design and Tech.Co

Ideas for the 21st Century Hustler. www.designandtech.co

Natalie Conklin

Written by

Fearless and forever curious — a life-long learner, explorer, cat-herder, and engineer, leading software projects for some of the world’s coolest companies.

Design and Tech.Co

Ideas for the 21st Century Hustler. www.designandtech.co

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store