Summary:

There is a dirty little secret lurking in this otherwise charming world of modern cloud based software: PaaS based solutions are not immune from poor software architecture. In this series we discuss the growing presence of inappropriate monolith architecture creeping into PaaS solutions and outline strategies to help you avoid in your own projects.

Dirty Secrets…

As an industry we love to look forward. For example, right now it is often all AI today, quantum tomorrow, and to hell with the past. Yet, we’d be remiss not to learn from the hard earned mistakes of our predecessors.

Over the recent years DMS Group consultants have had the opportunity to work on many projects leveraging Azure Functions. Like their other peers in the PaaS space, e.g. AWS Lamda, they serve as a powerful tool, enabling developers code level control of a cloud apps execution. Along with the bonus of a quick deploy, sans infrastructure, it is easy to see the attraction. However buyer beware: There is a dirty little secret lurking in this otherwise charming world of modern cloud based software: PaaS based solutions are not immune from poor software architecture. On the contrary the moment you unleash your inner developer there is a good chance you maybe walking into the same traps our industry has witnessed over a generation plus.

How monolith got its bad rap

The word monolith acquired its bad connotation as the software industry began to look back at the product of its endeavors during the hey days of mainframe. To be fair hardware was more limited then and modularity wasn’t always practical, but this led to developers putting more and more into a single code base. The outcome became large sprawling code bases that became hard to manage and even harder to maintain.

Few of these problems will ever emerge with a few lines of code. Even a few hundred… but once a code base gets up there into the 10s of thousands of lines, if it has not been architected with extreme care, you will hit them. PaaS based code is not immune from this.

Symptoms

As time progresses and cloud first has become more mainstream, we notice ourselves being requested to come fix/help more client with their PaaS codebases. Some of these have sadly morphed into monoliths. A familiar theme with these is that the intent was always good and the excuses heart warming but results almost always the same. Notably:

1. Extensibility challenges – tight coupling, low modularity in large code bases making it harder to adapt and change. Frequently a minor change in one part of the code has unintended consequences elsewhere. That new feature request suddenly got a heap more expensive.
2. Scale challenges – the absence of useful partitioning means that scaling the application becomes an all or nothing proposition. That means more resources to replicate (e.g. in dev/qa) and more resources to scale. In the worst example solutions can outgrow the available sizes in a chosen vendor’s host plan to grow. So even if you can afford to pay for the inefficiency you just can’t get it. You’re hit a self-imposed scalability wall.
3. Upgrade challenges – that little NuGet package update suddenly blew up some other unrelated part of the code base. Now a five minute developer job becomes 5 hours, or worse.
4. Maintenance challenges – it has become increasingly hard to detect & trace bugs and even more complex to fix.

If you recognize any of the above traits with your own PaaS solution, it may be that you’ve inadvertently created a PaaS monolith. Ironically if we review the above points you’d be correct in recognizing that many of these bad aspects were ones our industry once gleefully accused older mainframe architectures of.

What to do about it?

In his book ‘7 Things Every Software Architect Should Know‘, Richard Monson-Haefal is quoted as stating that “Over 80% of an application’s life-cycle is spent in maintenance” hence, “you should pay a lot of attention to the problems of support and maintenance when you’re designing.” Sadly this does require some investment and effort, preferably up front. Regardless of whether you are setting out on new code or have already inherited a monolith. Bringing out lucky charms and praying at the altar of your recently discovered monolith is not going to help.

So how can you avoid this? That will be the focus of our next blog post in this series. If you cannot wait and need input and guidance on this now, reach out to us, its part of what we do. Otherwise, keep well and stay tuned for Part II.