Monolith. The ominous name signifies something big, unmovable, and difficult to deal with.
And that’s exactly what a monolithic application is. At least in the long run.
A mountain. An iceberg. Something you can’t really change, move, and constantly must work around. Meanwhile, it’s casting a shadow on your day-to-day life, maybe eve n a threat, always in the background, like the Mountains of Moria.
Who wants that? Not this guy.
How to recognize monoliths
How do you recognize a monolithic application?
You probably recognize it subconsciously in the way you feel about an application when it’s brought up. It’s that application you internally cringe towards when someone mentions rolling out the next version. Perhaps it’s been around since the end of the third age (~6,000 years ago for you non-LOTR fans), nobody has dared touch it in 10 years, yet it’s performing a critical business function.
Maybe it’s that application your semi-technical business user built on their own, ran from their desk for a while before IT recognized it’s significance, and now its running in a container on your cloud environment. But you don’t dare touch it. The Jenga tower may fall.
Then there’s the application that always introduces cost and quality problems. Every time you ask for the simplest of changes, the development team comes back with higher-than-expected cost projections.
Or worse, you must do a significant amount of regression testing across the application, the testing cycle takes forever, and you can always count on a few production bugs infesting the build rolled out.
All these scenarios can indicate you have a monolithic application. Yuck. Now what?
You’re stuck in that endless consideration to blow it up and start over somehow, spend a lot per tweak, or live with its current state, none of which are enjoyable processes for you to consider. At some point, the application becomes a legacy application you no longer upgrade, limiting your users to the feature set it contains, or spend a lot more than you want to keep evolving it for them. Unpleasant options all.
In a nutshell, the same characteristics that make a mountain so intimidating are the same reasons a big, monolithic application is painful.
How’d we get here?
Let’s time warp back to CS101 – Principles of Software Engineering with Dr. Brown-Jacket-With-Patches at State U. They taught you that tightly coupled designs were not as good as loosely coupled designs. What happened? You traded loosely coupled design and its long-term benefits for some short term business value.
Maybe you needed that app TOMORROW. Maybe you had staff with limited experience. Maybe you rushed it through production. Or maybe it was death by a thousand paper cuts over time – enhancement by enhancement.
“This is just for a few months” turned into business critical and it is still around, years later. Maybe the system designer wasn’t the best choice for the job. Whoops! Should have hired that consultant. It’s ok, we’ve all been there.
This all sounds familiar
Regardless of the ‘how’, you’ve ended up with a ginormous mass of tightly-coupled components over time.
Years ago, loosely coupled designs were accomplished by building more modular, reusable components – like functions or classes in object-oriented programming languages and platforms in the late 90s.
Maybe you encapsulated some business logic in a COM component referenced by ASP pages.
Then, things gravitated to more segmented, decoupled components like XML web services wrapping reusable logic called from frameworks that focused on messaging or user interfaces.
We all did the best we could with the tools we had.
A modern approach – a true advantage
These modern platforms enable your business to have greater agility, flexibility, and speed – the real value of the cloud.
Now, if you want to fix a bug, you can fix a microservice that can be tested at the building block level. You can pull that component out and plug a new one in, much like swapping a hard disk in your disk array. And with modern DevOps and testing tools, that single component can be tested independently and replaced with much less impact and risk to the overall systems.
That’s the power of a well-architected, decoupled system – the antithesis of a giant mass of spaghetti code.
So, how can you migrate away from monolithic applications? How can you leverage the cloud and well-architected principles to achieve speed and flexibility? How can you increase the speed of delivery and improve quality? Are you ready to slay that monolithic dragon?
Contact us to learn more – we’re happy to discuss and design a path away from the dreaded monolith.
Nathan Hiscock is the Client Innovation Director at CleanSlate. He has an extensive background in helping clients fix their problems with innovative value driven technology solutions and collaborative vendor partnerships. Nathan is heavily involved with community engagements and strives to help others overcome adversities. CleanSlate is very fortunate to have Nathan on our team and for the great work that he provides.