FinOps, Cloud Costs, Repatriation, and most recently the in-depth post by Martin Casado and Sarah Wang from a16z on the cloud/cost paradox are all topics in the news reflecting that we have reached the “Holy Cow, I am spending a ton on cloud!” inflection point.

As I discussed in previous posts there are key distinctions between running “in the cloud” and “on the cloud”; the ability to tune, tweak and manage costs are some of these distinctions. At the end of the day the Cloud Service Providers are businesses out to maximize revenue, not missionaries proselytizing a new design center. Yes, cloud is the newest, and increasingly dominant design center, but never forget cloud service providers are businesses out to maximize revenue.

They are experts at presenting to their customers the “economically defined architecture”. Through their documentation, training, certifications, sku-ing, and feature segmentation they guide the cloud customer to acceptable, best-practice recognizable, deployment architectures. In fact, due to the consistency of the aforementioned assets (training, docs, etc..) they have most likely raised the bar in terms of overall deployment quality for many enterprises. All that said, the amalgam of capabilities and the manner deployed ALSO maximize their revenue. This is not surprising.

When you create a deployment architecture guided by cloud service provider user interface wizards and devops automation template best practices, it is quite possible you are getting a number of constructs your application doesn’t need, despite the fact that some applications might need them. Is this a global scale application and you hope to be the new Netflix? Or is this a supply chain application shared by 12 partners in the midwestern automated sprinkler space?

The cloud service providers are making specific architectural recommendations, that easily convert to IT deployment decisions, that are integrated to their pricing strategies. It is a level of alignment probably not seen in the previous design cycle where you would hire a consultancy to help with a data center deployment of vendor product XYZ.

Cohesive has provided cloud connectivity and security, helping customers get to, through and across the clouds since 2008, as such we have seen a lot of both customer migrations and greenfield development. There are an array of capabilities many of these applications do NOT need. To put it another way “not all of them need all of” cloud vendor-provided autoscale, load balancers, direct connects, transit gateways, nat-gateways, BGP, complex service roles/permissions, global network funnels, lambdas, etc.. Yet, due to a combination of the path of least resistance, peer conformity and even “cool kid behavior”, your team might feel reticence to dispense with any of these constructs. Practically speaking, there is a strong chance that declining default practices and recommendations could create personal risk for them. What if there is an issue, and the initial blowback narrative of an outage is “well Bob said we didn’t need a cloud load balancer”? Even if the root cause analysis shows it wasn’t the load balancing or lack thereof that caused issues – does “Bob” ever get truly “cleared of the charges”.

At the end of the day cloud service providers are extracting billions with a “B” from their customers for what is without argument high quality deployment architectures. But those architectures have some of their own complexity in that they are possibly more complex than what many customers need. Even if you set aside the runtime costs of those components, and some of the inherent complexity, there is another “gotcha”, which is “data taxes”. Increasingly newer offerings have both runtime (price per hour or price per invocation costs for usage) but also added on data taxes on top of the existing cloud egress charges. This is where 3rd party offerings from vendors like Cohesive, (certainly not limited to us) can make a substantial cost difference. Our view on the data taxes is that they are an awful lot of icing on some pretty thin pieces of cake.

I do want to note that our whole business has been built around cloud, and we ourselves use a lot of it, in fact too much of it from a pure costing point of view. We trade off speed for $$$, and while sometimes hard to quantify, we believe in the payoff. Cloud lets us move fast, and when you do so you leave bits of cost lying about via both neglect and opportunism. For the most part we do this with eyes wide open.

That to us is the crux of it. Controlling cloud costs requires a clear headed view by IT management of what their options are. What is the cost of conformity to cloud service provider economically defined architecture? What is the cost of non-conformity? If you are trying to save money, increase your non-conformity. If you are trying to reduce a measure of both actual and perceived risk increase your conformity. BUT, when you are trying to figure out how to cut cloud spend by seven figures (or a multiple of that), understand the structure of the tradeoffs you need to make.