Something is Odd About the Monolithic Application Discussion
In this post, App Dev Manager Mark Eisenberg takes a look back at the origin of monolithic applications and sets up a discussion about what needs to change.
A few weeks ago I recorded a podcast which was a free-flowing discussion about monolithic applications, the problems therewith and why they are still with us some 50+ years after their arrival on the scene. For those that have the time and prefer something less structured you can head over to my friend Bryan Hogan’s site at Breaking the Monolith and check it out. This post is meant to be a more structured discussion on the same topic.
Monolithic applications are with us today because they either do the job (Etsy) or because successive applications of new paradigms have failed to yield a different result. Inevitably, the paradigm is blamed rather than the application of it. We need to address the real problem which is resistance to change rather than settling for the status quo.
I’m putting a stake in the ground marking the birth of monolithic applications in April of 1965 when the first IBM 360 mainframe was shipped. It might be earlier than that, but for the purposes of this discussion that is far enough down the geologic strata to make the point. It’s more than 50 years. And for most of those 50 years we have been introducing wave after wave of solutions to the challenges that seem to be inherent in monolithic architectures. Mainly large applications that are brittle and resistant to any level of significant improvement.
If these challenges were simply technical problems we could just leave them alone, but it is the impact to “The Business” that compels us to keep trying. The Business says they need new functionality, we say we can’t because that would impact other critical functions. The Business says we need to reduce cost, we say we can’t because we are tied to a legacy platform and it would cost millions and take years to “replatform”. The Business says security is a top priority. We say, umm, we’re stuck with a business critical application on an out of support platform.
On that last point, did I mention that monolithic applications only started with the mainframe. The skills learned building them turned out to be almost infinitely transferable. College kids today are quite well versed in this architecture pattern. A large part of that is because companies need developers with the skills to maintain these aging beasts and the drumbeat of retirement requires fresh talent.
The Business is constrained by an architectural pattern that was born over 50 years ago. An incomplete list of proposed solutions would contain procedural programming, modular programming, object-oriented programming, service-oriented architecture, web services and microservices. The last being the current darling that has not delivered on the promise of software that runs at the pace of business. I happen to be a fan of microservices, but that is not the point here.
The point is that any of these ideas could have improved the challenges presented by monolithic applications. They have not delivered because they tend to be poorly understood and thus poorly applied. Discussions of changing paradigms are littered with phrases that start with the word “can’t”. Can’t do that because of security. Can’t do that because the database… Can’t do that because, and this is my favorite, we don’t have the skills. The bottom line is we can’t change.
But of course we can change. And the first thing we need to change is our concept of the solution. This came to me as a sort of epiphany when it occurred to me that I have decades of experience and yet we are still talking about the same problem. That has to mean we are going about this the wrong way. First, we need to drop the search for a magic wand solution in the form yet another new technology paradigm (Yes, I like the word paradigm. Just because a bunch of people turned it in to a cliché in the 90s does not mean it is not still a useful word.) and start figuring out how to implement change.
How? That will have to come with my next post.
Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality. Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.
Light
Dark
0 comments