Cloud Migration: The only path to Digital Transformation?

butterfly transforming

As the end-of-year conference dust settles, it’s becoming clear that we’re finally experiencing the long-heralded digital transformation. We have cloud, we have hybrid cloud, we have edge, but the technologies have improved to the point that it’s possible now to choose how to implement what has become known as “the cloud”.  As always, my question is what does this all mean for ops?

The Amazon Web Service conference re:Invent is this week in Las Vegas. I’ll be there to chat with people, trying to figure out if what I think is happening matches the reality of what’s happening in organizations. As part of my prep, I wrote this blog post. It is meant to be a bit controversial. My end goal is to find the reality of our current situation, find ways to acknowledge the hype and with real community building move past it. Who’s with me?

Simplified (and slightly dramatized) cloud history

The original target market for the public cloud providers was developers. Public cloud providers understood that developers were stifled by tedious IT rules that many times seemed like process for process’ sake. And if we’re honest as ops people, we hated having to enforce these arcane rules just as much as the developers hated dealing with them.

The cloud providers were smart. They built the scalable architectures that ops couldn’t (or wouldn’t, or weren’t allowed to) build. Then they went after the developers, whispering in their ears saying “we know your IT team is difficult, we know they suck, come build with us. We will give you the environment you want. No more putting in ticket requests with a 4 week SLA, or having to wait forever to be assigned more resources. Come to our cloud, and you can just build your code, run it and as you need resources, we will provide them. We got you.

Devops is born

Development teams building out cloud native applications (perhaps containerized applications) figured out pretty quickly that they needed operational expertise to get the job done.  And devops was born. They needed someone who understood networking, vms, containers, security, as well as the application itself. So a new flavor of sysadmin was born: the SRE. Or maybe you call them a Platform engineer. Whatever you call them, they are a ninja that understands how to build and manage a cloud environment that hosts the new applications being built by develoers. Also, they are able to collaborate and work with developers.

These folks bring all the on-prem ops knowledge and lessons learned from managing traditional apps, but with a twist: they can no longer touch the infrastructure, many times they can’t even manage the VMs. Think about the pressure there: they must deeply understand what the cloud provider is offering and match it to their application’s requirements. And those services (including infrastructure) can be changed or even cancelled by the cloud providers change at any time. These ninjas must understand the architecture of the application and be able to adjust that design if the cloud provider changes up the offering.

Oh they are also saddled with all of the data hygiene requirements of traditional applications: backups, restores, security, access, archiving.

What devs want vs what they need

When we think about why IT teams were notoriously so hard to deal with, part of the reason is because supporting enterprise apps is really hard. It turns out maintaining data, protecting it, backing it up having it always available takes real strategy and work. Add in dealing with latency issues and dealing with privacy regulation issues and the complexity only increases.

Not that we needed the crazy process we’ve seen over the last several years. Our charter as ops is to more than just keeping keep the datacenter lights on, it is to provide devs with the tools they need to create apps that support the business. Somehow that got lost, and the cloud providers pounced on the opportunity to grab all of those workloads.

Reality of running workloads sets in

In addition to the complexities of datacenter hygiene, there is the question of whether all workloads belong in the cloud. Some reasons to consider keeping applications on premises are privacy, latency, and data gravity.

The principle of data gravity proves true here: as data grows in mass, it is more likely that applications will be created close to where the data physically resides. And while it is true that cloud applications and even IoT devices are creating masses of new data, in many cases it is augmenting and/or blending with data from 30 – 40 years ago, and that data resides in big metal storage arrays and even mainframes.

So the question becomes: do all applications belong in the cloud? Can a flexible, elastic (cloud-like) environment be built on-premises? Is this an either-or decision, or can IT ops use all of the available options to build and maintain the best infrastructure for any given application?

Digital Transformation is here

The digital transformation that we’ve heard about from analysts and marketers for the last several years is finally here. It’s real, we’re in the midst of it, and we’re starting to see some real battle lines being drawn between traditional on-premises vendors and cloud providers.

Can cloud providers figure out how to deal with the latency issue? I’m sure we’ll hear about that this week when AWS reveals their progress on Outposts. Will the cloud providers find a way to get around security regulations?

Can traditional on-premises vendors figure out how to help organizations build true cloud-like environments on-premises? VMware seems to have taken a step in this direction with Project Pacific, and making Kubernetes the control plane for vSphere. They also have a data-center-as-a-service offering with Dell EMC in VMware Cloud on Dell EMC. But will orgs grasp what these offerings mean and buy into it?

And we haven’t even touched on edge and what that could mean in the scope of digital transformation.  If you think of all the data centers that were evacuated, could they turn into edge locations for cloud? What if you build out an infrastructure that devs can drop their environments onto to take advantage of low latency to your data, or to extend their cloud infrastructure into areas traditionally underserved by the public cloud?

Maybe most importantly, will cloud vendors and traditional infrastructure vendors stop the arms war and start working together?

The future is now

We are in the middle of a digital transformation that will reset computing probably for the remainder of my career. What are you experiencing? I’d love to hear about it! If you’ll be in at re:invent ping me on twitter [ @gminks ], let’s chat! Otherwise respond in the comments, I’d love to hear if I’m way off-base.

Please follow and like us:
error0

Comment (1)

  • What Can On-Premises Ops Teams Learn from Dev Processes? · Digital Sunshine Solutions| 03/06/2020

    […] is a foundational pillar of digital transformation, but is it possible for on-premises ops teams to automate bare metal? Can ops teams adopt public […]

  • Leave a Reply

    Your email address will not be published. Required fields are marked *