Realism Around Cloud in Business

After getting a little experience of cloud management+ops with GCP and a lot with AWS, I have a few thoughts! I think these are worthwhile things to know that you won’t necessarily hear about much, perhaps because people focus on the technical part of public cloud even though it’s not a strictly technical journey. If you’re reading this and have a line to me, let me know what you think.

Infosec and finance/accounting are two very early calls on your cloud journey. And you’ll continue to talk to them. Most cloud security may seem easy to agree on, limiting native identities over access keys, limiting external assets, etc. But where the rubber meets the road working with most information security departments is typically compliance, even if it’s policy compliance in the name of security. Defining the rules for what “limiting” means and when to cross that “best practice” line is significantly stickier than public cloud providers would like you to believe. Take for instance AWS access keys, of which Scott Piper noted: “for on-prem applications, AWS doesn't have a good story for external identities so IAM user access keys are common for that use case, but there are alternatives”^[1], which gets to the deeper issue. Hybrid infrastructure, lift-and-shift, etc is a less desirable customer success story amongst cloud providers and thus demands less of a cohesive customer story from a product perspective. As for Finance, they’re faced with obvious challenges with what can turn into an endless IT wallet, but there are also discrete issues around codifying costs, whether it be by department, underlying product or client,, cost of goods sold vs something else such as top-line cost of revenue, as well as the more “boring” accounting-based distinctions (one of which is described below) . In AWS where projects/accounts aren’t quite as seamless, tag early and often.

Cloud product vendors gravitate towards modern concepts (such as Infrastructure-as-Code coverage or serverless visibility offerings), despite it not being reflective of the larger cloud consumer base. This isn’t wrong of them: It will age well as a product offering rather than tailing trends and disproportionately appeals to larger enterprises that can afford engineers, and, usually by extension, the vendor’s offering. However, if you’re in something like a smaller IT outfit, incident response or early auditing where you’ll see a variety of customers, you’ll find a significant number of them are simple lift-and-shift. There’s also less to be “learned” in a lift-and-shift environment, as it’s been around for so long. This is why I enjoy working on lower level concepts like EBS Direct APIs in AWS, where the consumer base is now largely neglected.

How your company treats operating expenses and capital expenses* (but mostly operating expenses) will have a significant impact on how your company treats the cloud. Back we go to talk about finance and accounting! When you buy servers off of eBay and rack them, that purchase is typically a capital expense - something you bought for the long term as a fixed asset. Some companies have a bias for or against operating expenses, mainly around how it’s reported and amortization. 99.99% of the time public cloud spend is operating expenses**, which can lead to cloud hesitancy. The relevant sections in US GAAP have changed, at a minimum, as recently as 2018 and 2019. For a biased but potentially sound take, AWS attacks the major arguments about CapEx vs OpEx here. Here’s a potentially more balanced take from PwC.

Cloud can lead to greater autonomy for IT operations and make execution of them faster, leaving you able to buy things in a click. the cloud won’t make your larger strategy or planning any more cohesive if your larger corporate IT strategy is a mess.

If you’re afraid to spend in advance, you’ll bleed in on-demand costs. If you’re a startup but not accelerator-aligned, you may be ineligible for certain credits, while those credits may very well backfire if you depend on them. If you’re a larger enterprise, and you can’t negotiate vendor contracts for the life of you, you’ll have the same problem with Google or AWS. If you’re unable to version, document, and coordinate resources on-premises, you’ll have similar problems in the cloud. The public cloud doesn’t solve much more than actual execution constraints.