The Cost Paradox Of The Cloud

Against all odds, some organizations are migrating back from the Cloud to their on-premises servers, as the Cloud turns out to be too expensive for them. We notice some of our clients migrate back too. This is unexpected because, theoretically, operating your landscape in the cloud ought to be cheaper.

Unexpected Cost Developments

Cost is an important factor when migrating to the cloud. Transitioning to the cloud requires time and effort Applications often need adjustments to be compatible with Cloud resources, a factor that is generally expected. But at some point, the migration should be completed and the financial benefits of it should start to materialize.

Theoretically, the effort spent on migrating to the cloud should create value. When the migration begins, there is no return on the investment yet. At some point, the efforts become proportionate. From that moment onwards, the migration effort should decrease, and the value should outweigh the effort, as depicted in this chart:

However, some organizations never reach that point where the effort and the value are proportional. On the contrary, their cost of ownership increases. Their cloud journey looks more like this:

Getting a Grip on Your Cloud Bill

Many organizations struggle to get a predictable and reasonable cloud bill at the end of the month. Hosting a test-environment for a straightforward application alone can, in some cases, result in costs running into hundreds if not thousands of euros.

At first glance, developing software for the cloud and developing software for an on-premises environment may seem the same, but make no mistake – there are some crucial differences.

For example, with on-premises software development, databases are added to a database-server until the maximum capacity of the server is utilized. And preferably, all applications use similar database-technologies. In the cloud, following a similar approach will result in high cost. Most cloud providers bill either the reserved capacity or actual consumption. The more advanced the resource, the higher the bill. So, having a database in a premium tier without using it extensively is very expensive. Also, using technology in other ways than intended has a negative impact on the costs.

Rehost, Re-platform, or Rearchitect?

The way an application is hosted has a significant impact on the bill. Cloud providers offer infrastructure-, platform-, and software-as-a-service. Services from these different categories have different pricing models.

Every application is unique. Consequently, they might all have different cloud migration strategies. The strategy materializes in the monthly hosting cost because each strategy depends on a different category of cloud services.

By leveraging the Infrastructure-as-a-Service offerings of a cloud vendor, with a so-called lift-and-shift approach, an organization can simply deploy virtual machines to the cloud and host their applications on them.

Alternatively, an organization may opt for a slimmer approach. Through re-platforming an application, minimal changes are made to enable it to run on platform components offered by the cloud vendor. For example, this involves containerizing a web application and running it in a container environment, while the Database-as-a-Service offering is used to host its database. Such an approach eliminates the need for virtual machines, the necessary compute to run these virtual machines, and their maintenance. This reduces costs significantly.

A common pitfall is approaching such decisions from an application-centric perspective. Various organizations embark on long, unpredictable, and expensive journeys to rebuild large, monolithic business-critical applications. Such rebuilds take years and increase the total cost of ownership drastically: now they’re maintaining two large applications without getting extra business value out of it.

Usually, not all parts of a monolith require similar architectural capabilities. Some parts may need to scale, whereas other parts may require advanced operability capabilities. Enabling all of these abilities in every part of the monolith can be quite expensive. That’s why, in some cases, it may be more sensible to re-architect the application and re-platform specific parts of the application only and identify the capabilities that are applicable to individual components. This reduces the costs of re-platforming and allows you to get the most out of the migration.

Deciding how to migrate an on-premises application to cloud isn’t always straight forward. What’s a sensible approach depends on the business-case. Sometimes the best option is to lift-and-shift, in other situations it’s more sensible to make minor changes to the application to make it compatible with the cloud, or, in other cases to re-architect the application.

Buy or build?

Another interesting aspect of software development in the Cloud is the type of resources being used. When working on on-premises software, an application typically comprises both an application and a database, with all functionalities programmed into either the database or the application.

Cloud vendors also provide Software as a Service, offering solutions for Identity and Access Management, eliminating the need to build authentication functionality, Business Intelligence solutions for creating dashboards, deployment infrastructure for software development, and more. Integrating business functionality may be available with just a click.

Software as a Service offerings are more expensive than Platform as a Service offerings. Thus, there’s always a trade-off to consider. The question is when to invest in business value.

“Pick your poison: high development costs and a lower monthly bill, or low development costs and a higher monthly bill?”

Depending on the optimal timing to deliver the software and the expected usage of it, there may or may not be a business case for choosing to develop business functionality in-house. It’s an entrepreneurial endeavor.

Give ownership and use common sense!

Several organizations are well on their way to applying all the above yet still struggle with high bills.

Given the nature of the cloud, developing software for it is more fast paced. Cost manifest immediately and a small change can have a high impact on the bill. It could be as small as writing a poor SQL query or choosing to implement functionality in a Lambda or an Azure Function when it should have been implemented in an API.

That’s why development teams must be given responsibility for their expenses. They need to be monitored by the development team regularly and proactively. When an unexpected cost development is forecasted, the team should respond to it. It may require choosing another technical solution to a problem.

Consequently, this requires a change in the organization. It begins by organizing cloud subscriptions in a way that allows monitoring expenses per team from in the first place. The team needs to be actively monitoring it. Additionally, the architects need to be closer to the team, if not integrated within it, enabling the team to modify a technical solution quickly if it proves to be too expensive.

Successful teams develop solutions while remaining conscious of the budget, incorporating considerations of business cases into the refinement and prioritization process.

Summary

Various organizations are reverting to their on-premises data centers because the cloud turns out to be too expensive. Simply migrating from on-premises to the Cloud did not result in cost reduction for them.

Cloud expenses, the time to market, technical design choices, and software usage go hand in hand. Therefore, the profitability of a feature has a place in every step of the software development lifecycle.

It’s all about autonomy. When teams and architects efficiently collaborate to create cost-efficient solutions, and when teams can proactively monitor it, they can drastically reduce cloud expenses and make a cloud migration very profitable.

Interesting reads:

This blog is part of our series "Holistic Horizons". Check out the previous entry – "Do I really need another tool" by Adnan Alshar.