Applications running like clunkers in the cloud? 3 options to consider

If your applications running on public clouds are not meeting expectations, you’re not alone. These are typically applications that were lifted and shifted to the cloud with little or no modernization or refactoring. This means they are not leveraging cloud-native services, such as infrastructure as code, serverless compute, cloud-native security, and cloud-native operations services.

During the massive push to the cloud in recent years, especially during the pandemic, thinking and planning went out the window. Moving fast was the order of the day, generally with the perception that just shifting apps to a public cloud provider would make many of the application issues go away. On the contrary, they mostly just amplified problems we had on-premises.

So, we are here. Our applications are costing three times as much as expected to operate. Performance is an issue with some, security and governance are issues with others. Many of these lifted and shifted applications now must be retrofitted with the security and governance features that emerging regulations will soon require. So, what are your options?

Do nothing. Doing nothing means we’re kicking the can down the road because doing something about these applications means incurring additional cost and risk. So why not delay?

While many will pick this path, this is not being responsible. The end state will be millions of dollars you’ll need to spend, with absolutely no value being returned to the business in the meantime.

Partial modernization. This means that we will only upgrade and update some of the applications’ capabilities to leverage the services within a public cloud much better than they are doing now. For example, we could convert some systems to cloud-native architecture approaches, such as containers and container orchestration (Kubernetes). 

The pros are many here since you can focus on fixing the most annoying and expensive problems, such as overuse of cloud resources, inadequate I/O systems, and lousy application behaviors that have existed for many years. 

The cons would be the cost and the risk. You will need some expensive human resources to figure out how to do this correctly. Each application will have unique issues that must be addressed differently. There is no one-size-fixes-all approach to be found here.

However, I’ve found that partial modernization is often the best approach given that we’re still attempting to “cheap out” but are doing so with the maximum positive effect. We’re spending money but getting a great deal back for the money we’re spending.  

Full modernization. This is setting up remote offices for a large set of developers working off-site, hiring the best cloud architects, and working on redoing the applications from the frame up. Of course, each group of applications is different, but this typically means rebuilding using containers and container orchestration, and taking advantage of serverless, cloud-native security, cloud-native operations services, etc. In other words, leveraging the cloud platform to an optimal effect and putting in the work needed to accomplish this. 

The downside, of course, is cost. It’s huge. Indeed, I would say that I may advise some enterprises not to take this path, considering that the value returned to the business from this investment would likely be less beneficial than many partial modernization projects. But, again, you may have unique goals or requirements that make a full modernization more optimal.

All of these options have huge downsides that need to be considered with the upsides. But every day you allow sub-optimized applications to run on a platform that charges for the resources they waste is a day you’re not serving the business as well as you should be. You won’t be in business long doing that. 

Happy 4th of July!