Operations | Monitoring | ITSM | DevOps | Cloud

The first person to coin the term “Artificial Intelligence” predicted that someday people would buy software as a utility. The year was 1961 and that person was Professor John McCarthy, a computer scientist at Stanford University. After Salesforce began selling software programs this way in the late-1990s, the good professor witnessed his prophecy come true for over 12 years before his passing in 2011. Yet this is only one aspect of computing in the cloud as we know it today.

As we were planning “Cloud Atlas,” our primary goal was to talk with someone who was “in the room” during the genesis of the cloud. Allan Vermeulen, who worked for Amazon from 1999-2021, and who proposed Amazon Simple Storage Service (S3), became that source. Allan is a born engineer. He has always enjoyed building things — whether “out of bits and software or boards and lumber,” Allan takes pleasure in creating useful things.

It’s almost impossible to create an optimized cloud system out of the gate and keep it running at a perfect balance over the long term. There’s almost always something that could benefit from some tweaks and adjustments. Cloud costs have a way of creeping up slowly while you’re not paying attention. And if you’re not careful, they can spiral out of control before you realize anything is happening.

Just about everything you interact with digitally is enabled by the cloud. Whether you’re doom-scrolling on Instagram, binge-watching on Netflix, ride-hailing on Uber, or downloading super-cool cloud podcasts (hint, hint) on Spotify, you’re using the cloud. But most people don’t have any idea what the cloud is, where it came from, or what we, as a species, spend on it.

For Amazon to survive, they needed the cloud. But they had to invent it — and creating the cloud meant overcoming obstacles fundamental to the nature of software development at the time.

An easy way to understand what the early cloud did is to think of it like a public utility. The same way buildings depend on a common set of utilities — gas, electricity, and water — software projects depend on a common set of services: compute, storage, and database. “Compute” refers to the power it takes to run the software.

Every time your company onboards a new client or releases a new product, your cloud bill will grow. In fact, it doesn’t take a large event at all to see a spike. Whenever your company changes direction even slightly, it can affect the bottom line. Add to that factors such as economic inflation and increased demand for high-speed, high-power cloud services, and it may seem like each month’s cloud bill is higher than it was before. If that’s the case for you, you’re not alone.

Kubernetes has been described as everything from “awesome!” to “I regret my life choices,” and with 84% of all Kubernetes cloud workloads running on Amazon Web Services (AWS), it should come as no surprise that AWS created Amazon Elastic Kubernetes Service (EKS) to eliminate much of the undifferentiated heavy lifting it often takes to manage. What do companies like about Amazon EKS?

DevOps doesn’t necessarily look like it used to. Engineers used to build software designed for on-prem hardware; they had a specific methodology for efficient production and distribution schedules; and they didn’t interface very much with non-engineers, if at all. Today, all that has been flipped upside-down. Cloud-era DevOps engineers now must possess wildly different skill sets, and some previously non-negotiable skills have faded into the past.

Both CloudHealth and Cost Explorer have recently rebranded to different degrees. CloudHealth is now VMware Aria Cost Powered by CloudHealth. AWS Cost Explorer received a fresh coat of paint for its user interface. But do these traditional cloud financial management tools offer additional features now? And can the help provide the cost visibility you need to reduce cloud spending and improve profitability?