Moving to the cloud & tech debt - a trap

I am thinking (or maybe I can see), that while more companies jump to the cloud, migrating their existing software solutions and services, things like tech-debt or architectural-debt are going to become a first class citizen and hot topic, again. Which is a good thing! Really!

I am very happy about it, because I do believe that tech debt, over-engineered solutions or hype driven development do actually contribute to an increase rate of mediocre software solutions and services, while we (the software engineers) think that we are doing just great.

But how tech debt is going to be again, a hot topic among meetings while migrating to the cloud? It is simple, the bill by the end of the month! Are you doing micro-services for no reason at all? Do you have a small monolith broken down to 1000 different pieces because this is the trend- for no good reason? Is your API chatty? Have you bundled a ton of libraries and features to your product that actually are not needed but it was just to play around with tech or your engineers to feel happy? Is your code spinning the CPU for no good reason? Is your code using the filesystem inefficiently?

Maybe you had a hint of these problems, but there were not so intense when you had full control or ownership of the deployment platform.

But now you don't control the hardware, you are being billed by individual operations.You PAY!

And at a certain point people will start to think about it again. Why our Google Cloud bill or AWS bill is so big? Maybe some will decide to go back. Who knows?

What I do suggest though is, spend some time and review your solution, your architecture and the quality of your code. There are for sure, great advantages offloading your infrastructure concerns to a more flexible - elastic world, but it is still YOUR software. And all the sins and mistakes of your software are not going to be hidden or auto-magically resolved because you moved to the cloud, there is a high chance they are going to get_ bigger'.

The cloud is great, but it wont make bad software great.