Innovation and new technology are driving our shift to the cloud, but the cultural transformation that we must go through to allow this transition to occur is more profound and impactful. The root of why we move software and technology to the cloud is to better serve individuals and solve cool problems. With that in mind, please enjoy my second post on how we think about cloud optimization and adoption within Microsoft (catch up by reading my first post and our case study).
Let’s talk about virtual machines (VMs), something most every IT pro feels very comfortable with. Servers, and specifically VMs, have been the name of the IT game for several decades. Many consider the move from mainframes, thin clients, and punch cards to individual, highly configurable servers one of the most monumental shifts the IT industry has ever made. In almost every IT shop around the world, you can find professionals with wistful stories about Fortran punch cards, root access pranks, and ponytails. OK, maybe not everyone had a ponytail. For me, it was growing up watching “Hackers,” dreaming about hacking The Gibson with a Pentium 386 and a 14.4k modem (never mind that my childhood bank account could only afford AMD parts).
The cloud can be scary because the vast expertise and knowledge we’ve all built our careers around for the last few decades can quickly become obsolete. You might think, “I won’t manage or have full control over the operating system for each individual server, so what will I do once we make the move to the cloud?” Or maybe it’s, “I don’t manage the network hardware or the SAN array, what if something goes wrong?”
Although I wasn’t in the workforce during the time of the mainframe-to-server transition, I can imagine it was strikingly like what we’re going through today. And just like it was then, the opportunity today is immense—you can tell it’s a growth opportunity, not a shrink opportunity, just by looking at the new cloud jobs popping up all over your LinkedIn feed. While there are those who fear losing their day job of managing operating system versions, patches, and images, there are also those who are glad to cast that kind of work aside, so they can do bigger, more impactful things.
Honestly, I haven’t had to troubleshoot an operating system in three years (even though that was a core job function for the first decade of my career). Part of me misses it, and part of me is gleefully enjoying the ability to build out a few dozen servers in a couple minutes, all pre-configured to my heart’s content. Embrace the change and you will easily stay out in front of the wave. It’s a textbook exercise on growth mindset.
Using infrastructure as a Service (IaaS) is an easy way to get your foot in the door on cloud, and it really is a pretty good starting point.
Building cloud expertise in your organization is imperative. Your engineers are going to be able to do the IaaS thing without a huge investment in skills. There are a couple of things to be mindful of. When you manage datacenters and VM hosts, the general planning concepts are well known—you buy your hosts for a five-year lifespan, you provision your servers for the application’s three- to five-year growth plan, and you buy multiple environments for feature testing, development, performance testing, and reproducing bugs. I used to be the build engineer that ordered the environments and set them up… and it was tiresome, building out six or seven environments for each application, and then rebuilding them each release. This led to generally very large servers that were sized for “what-if” scenarios, just so no one got caught with performance issues or the need to buy new hardware during peak load times. It made sense, too—the price difference between servers was small when you considered that they have five-year lifespans. Back then, it was a small price to pay for insurance.
We can see the fruits of this logic when you look at average CPU utilization across distinct datacenters—usually in the single digit percentages. Imagine starting a new project: You need a few machines to get it off the ground. You hand a corporate credit card to your lead engineer and tell them to go down to Fry’s and get a few machines. Mr. or Ms. Lead Engineer is going to buy hardware that is larger than the job requires pretty much every time. Their job depends on it! Commitments and job success is focused on how well something works, and you never want hardware to be your bottleneck. Cost accountability is generally a non-factor in these purchase decisions.
Guess what—these well-intentioned strategies will cause you to overspend once you move to the cloud. Do you recognize them? Do they happen in your company? Do you have some of these same concerns? If allowed to run unchecked, they lead to costs many times more than necessary.
Before you run your first production application in the cloud, throw out your datacenter thinking. Provision small, and provision less than enough. Only provision an environment when it’s needed, and then turn it off when you’re done! Expecting a huge spike in application use? Turn the server sizes up. Don’t guess what sizes you need. Instead, use one size less than you would reasonably select, and only turn it up when you have seen a real hardware bottleneck. The compute power in an Azure datacenter is often many generations newer than the hardware you are migrating from, in addition to the general “oversized” state of your old servers. Try it out on your next IaaS project, and then ask for a raise when your infrastructure costs plummet.
When I start cost savings conversations with a team (both inside and outside of Microsoft), I like to lead in with a rather over the top sales pitch. I start by saying “What if you can save 70 percent of your entire non-production infrastructure cost?” Then I go about explaining the “snooze” concept, turning off development servers on the evenings and weekends, and show them the cost charts within our IT organization with its cliff-like drops in spending. The reality is, with Azure it’s possible to cut your costs significantly, and it’s not all that complicated to get there.