Outdated Calculus of Cloud Cost Containment

Cost would seem to underpin almost every decision IT teams make. Sure, business requirements drive overall operations budgets, but it'’s always in tension with decades-old certainties about cost. It’s long been the unyielding constant of IT equations. In particular, IT pros migrating application infrastructures out of the data center have discovered the on-premises math of cost containment no longer works. Cost-focused migration projects can stall resources and become underprovisioned, and user experiences can become poor. Remember early on when sales reps ended their pitches with “…and cloud is cheaper”? Yeah, about that…

It’s easy to wax nostalgic remembering the relative simplicity of bare metal cost control. Physical devices bolted into racks were earmarked by application. Even well into the era of virtualization, it’s still easy to think bottom-up with Layer 1, then switch and routing, and finally NICs on servers as the “consumers” of the network. However, infrastructure has actually been top-down, with applications defining more versatile and reusable infrastructure spending for nearly a decade. Welcome cloud, which vastly multiplies options for all factors for consideration, including cost.

However long-serving and storied classic budget approaches may be, it’s time to stop relying on cost as the basis for technology decision-making. This is already true for cloud projects and increasingly true for on-prem in a world transitioning to OpEx and subscriptions in the data center. The urgency to change the way we think about IT cost can’t be overstated. IT’s ability to continue its tradition of delivering amazing user experiences depends on it.

Burn the Witch!

Hey, hey, hold on a sec. There’s no need for pitchforks and torches—I’m not suggesting organizations shouldn’t consider cost for migration or operation of cloud resources. If you’re lucky enough to have a blank check for innovation, celebrate your good fortune! Create amazing things! The rest of us still have to continue squeezing in more services, data, and users than the budget technically allows. The trick is to transform our math, making cost just another variable along with team resources, platform costs, business transformation value, ongoing support, and everything else.

“Sure, Patrick,” you might think, “I’ll just swing by the CIO’s office right quick and casually mention we’re just not going to worry so much about cost. They’ll love that. Instant promotion for me!” This is a natural reaction, and you wouldn’t be alone. It does, however, highlight the scope of culture change many teams face when transitioning to cloud and OpEx, especially migration projects.

Migrations are filled with one-off unknowns determined by the nature of the business and each migrated resource. But this is also why migration projects can be effective vehicles for education and dialog. Unlike net new cloud application development, there are rarely minimum viable product redeployments of critical on-prem services. Post-migration, they must perform not only as well as before but better or more usefully to meet the business expectations driving the migration in the first place. So how do teams not fall into the cloud migration traps of overspending, under-innovating, quality reduction, under-securing, or overworking IT pros?

Shaking Change Out of the Cost Couch

If modern web retail teaches us anything, stop expecting the customer to do complex calculations before they can buy.

You’ll notice two tricks help.

  1. When you present project options to leadership, bundle cost into the cloud project’s transformation benefits, one-time dev and ops costs, risk, and timeline.
  2. Resist requests to customize bundles where the math works out. This approach works well for the Tesla online ordering site and can work well with IT decision makers, too.  

Traditional cost conversations are like car ordering of old, with an accessory book of options and hours of research and haggling. In a far busier world, however, humans make faster and better decisions, picking from “good,” “better,” and “best.” When complexity is high, freedom from choice can be freedom indeed. Tesla offers the same comparative variables set side by side so users can quickly choose based on their individual feature focus. Do they select based on range, acceleration, motor count, or price? It doesn’t matter to Tesla. There are no wrong answers because they’ve done the math in advance based on their intimate understanding of all production variables, especially cost.

The IT example would be precomputing resource requirements and expected benefits for a handful of options and presenting them together. Instead of range and acceleration, they’d list resiliency, performance, adaptability, and initial and ongoing cost juxtaposed across all options. This would allow the business to select the migration/transformation package based on their needs, the details of which IT often can’t see. Final selection doesn’t really matter because they’re selecting from a limited catalog of choices you’ve already confirmed will provide workable and cost-managed combinations of resources based on the details of your unique operations.

There’s just one challenge to this approach—there always is. To break free from deeply ingrained notions of cost as the fulcrum on which IT pivots, teams must be able to assure management their new approach and its calculations are based on empirical, reliable operations performance data. Otherwise, the perceived risks of budget-draining surprise OpEx cost may be too great to overcome. They’ll want to verify cost to performance before, during, and after migration.

Furthermore, cloud’s dynamic resource allocation requires ongoing post-deployment reporting for performance, user experience quality, and infrastructure inventory along with associated actual billing. The business will be taking a bet with a different cost containment approach, especially at the beginning. The easiest way to do this is by arming the team with performance monitoring that’s easy to apply to all elements of modern applications, free from the restraints of observability and visibility limits.

Cost Kingmakers and APM

One of the most interesting effects of cloud migration is applications themselves are becoming less and less the infrastructure kingmakers they were under virtualization. Look no further than VMware’s pivot from hypervisor management to orchestration. User’s experiences—nebulous though they may seem—are increasingly the top concern for CIOs. The ability to transform while still managing cost over time is what allows businesses to differentiate their services from competitors.

This digital experience focus is perhaps the primary reason so many IT teams are turning to application performance monitoring (APM) to keep an eye on cost. IT pros still monitor the nuance of infrastructure directly—it remains a foundation. Increasingly, however, it’s to support troubleshooting and capacity planning and less to extrapolate user satisfaction. To assure the business all is well, IT must answer a new final big “C” cost question:

“Are we delighting—not simply satisfying—users relative to what we’re spending?”

The answer lies in their ability to monitor and visualize ever more complex and dynamic application architectures just as the humans they ultimately serve do. What’s happening at the service end? This is APM’s sweet spot.

Perhaps the following questions are familiar. Does an underperforming service need additional compute? Is another overprovisioned and wasting valuable and limited spending? Should VM or cloud instance sizes be expanded or horizontally scaled out, or would adding bandwidth be a less expensive option to improve performance? Are managed services the best approach, or would new investment in internal development teams improve custom applications’ performance and reduce costs for cloud resources?

In exactly none of these examples is traditional cost analysis helpful in selecting the best choices from the enormous cafeteria of options currently marketed to IT teams. The interdependence of specific technologies, how they’re deployed, reclassification of risk from availability to business impact, and head count vs. managed service outsourcing all matter. It’s understandable to miss the days when IT pros could simply monitor the CPU, memory, and IOPS of a VM and aim for the lowest utilization and greatest headroom cost allowed.

The magic of APM is its ability to provide the critical details to support changing enterprise objectives. It breaks down seemingly monolithic cost accounting and provides real, usable knowledge to bypass the “impossible” barrier of cost-dominant planning. “Cost” has always been the first discussion point to hamstring application delivery and puts the kibosh on business-led transformation. To keep users and management both happy, step one is changing our math.

Anonymous