Cloud cost-cutting is in vogue, but pitfalls abound

Companies, big and small, have recently become much more public in their drive to reduce cloud costs.

It's not like cost wasn't previously a concern: in the history of cloud use, there hasn't been a time when cloud-centric companies haven't been interested in the financial repercussions of their decisions.

But things have reached a crescendo in recent times.

Cloud finance management has rapidly risen as an internal discipline. Though it's often associated with installing a CFO for the tech function (or, more specifically, for cloud ops), something interesting is happening, and the way to think about this is: there's more than one way to skin the cloud costs problem.

Tacking it with a purely financial lens is one way. It may involve the "rightsizing" of cloud instances, clearing vestiges of legacy thinking about infrastructure that leads to over-specifying of cloud resources out of sync with actual usage or need. It also often sees non-prod environments turned off on weekends or holidays, greater use of spot instances or 'serverless': anything that can cut unnecessary spending and bring the organisation under a shrunken budget amount.

But there are other ways to achieve similar results that are much more technology team-driven.

Cloud repatriation is often touted as an alternative, albeit by more data centre-centric parts of the IT industry. IDC figures suggest 71% of firms are currently exploring cloud repatriation options, down from a high of 85% but nonetheless still significant. Cost is the top reason to pull back from public cloud and move to hybrid or more on-prem setups again (though other reasons are cited, including performance).

A third option gaining steam is the establishment of more granular visibility into application and workload requirements and end-user demands, such that you design and architect your application - and then continue to optimise it - based on how the users interact with it. The idea isn't just to lift-and-shift into cloud but instead to be able to make smarter architectural decisions that are cost and performance optimised from day one. Or, as a colleague says, to move from 'cloud-washed' to 'cloud-smart' applications and workloads.

These aren't mutually-exclusive options or models: it is likely that a combination of these models will lead organisations to achieve the best cost- and user-optimised cloud setup.

User-centricity, architectural simplicity

The interesting thing about models two and three - repatriation and visibility - is that they are much more technology or engineering-driven, as opposed to being run by more financially-minded parts of the technology organisation.

They make an important recognition: that even though the big driver of these initiatives is cost, the approach can't just be about cost-cutting alone.

Organisations, for example, cannot afford to take a backward step on performance to save a few dollars. Users expect fast performance from web-based applications and workloads, and that expectation will only increase. Organisations, in turn, have to become more thoughtful in terms of how they optimise their infrastructure spend while still maintaining their performance.

That lends itself to a more dynamic and user-centred approach to software engineering and application architecture. The most cost-effective and simultaneously performant way to serve users is to cache content via a Content Delivery Network (CDN) and host compute-intensive infrastructure as close as possible to the users accessing it.

An eCommerce store that operates on huge backend databases may benefit from a more distributed database structure that speeds up calls on the backend (fulfilling user requests for product) and reduces the cost-to-serve for each would-be purchaser.

Again, the emphasis is on architecting smarter, with cost-effectiveness coming in almost as a by-product of making smarter, more user-centric architectural decisions.

The 'long tail' of continuous improvement

It's easy to say organisations and their tech teams should architect for cloud smarter: the question is 'how'. The answer is by leveraging visualisation.

You don't know where you're going to get the biggest bang for your buck on optimisation until you actually look and visualise what's going on with your application or workload.

For example, you could spend hours and six-figure sums tuning a database, or you could have the same or deeper impact by stopping an underlying batch process or changing the way a large file indexes to it. You might determine that chasing a smaller performance gain is more worthwhile because it would lead to an order-of-magnitude decrease in running costs. Or, you might find that changing Internet Service Providers (ISPs) or CDNs that serve and relay queries to and from the database is a worthwhile cost- and performance-optimisation exercise.

The point is visibility and simulation of these decisions is what's required. All too often, tech and product teams spend time and resources finessing the part of the architecture they think is the biggest problem, only to later determine that it wasn't.

The real gains come from being able to pinpoint where the cost and performance bottlenecks are. From there, organisations can architect their applications and workloads for efficiency and set themselves on a path for an even longer tail of continuous improvement gains.