Are we there yet?
By: Betty Junod
Tags: Cloud Computing, Containers

On the journey to destination cloud…

In the last almost 20 years, cloud and containers have left an indelible mark on technology in a way that spans across all industries. During this time, these technologies transitioned from things that needed to be squashed or controlled like “shadow IT” and “something only developers want” to something that I now see on the “CIO Priorities” list across a range of analyst and technical media sites. As these technologies matured, they provided a richer set of services and integrations to attract traditional applications out of their terrestrial residence and monolithic nature.

The massive growth in cloud across all areas, including IaaS, PaaS, and SaaS is staggering. As reported by Gartner, cloud adoption in each the past two previous years are well over 30% growth from 2017–2018, to 2018–2019, and I expect 2020 will be no different. Already a force changing IT, the global pandemic has further changed the way people work, live, and use technology; putting greater pressure on businesses to provide remote access and cloud-based services to their employees and customers.

But the question remains: In almost two decades, why hasn’t there been a wholesale migration of all business applications to the cloud? Why are we still talking about datacenter?

The gravitational pull of legacy applications in the datacenter is strong, the effort to refactor applications to work natively in the cloud is significant, and there aren’t enough skilled cloud infrastructure engineers available for the amount of work the industry wants to get done. Separately, not every workload is worth this effort in time and budget to move. While some applications may never move to the cloud for any number of reasons.

The problem itself is also two-fold. Not only does the migration team need to have a deep understanding of the know the cloud provider’s tooling, they also need an understanding of the application code in order to make the relevant changes so that application works as designed against the chosen cloud provider’s APIs. This work is non-trivial as many business applications were written years or even decades ago and the knowledge of the codebase may not be readily available. This reality often slows down migration and modernization efforts — years in some cases for organizations with portfolios of hundreds or thousands of applications. Then as teams look to go into production, they need to sort out new runbooks and processes for how their team will provision, deploy, change , and resolve issues — how do you pinpoint and troubleshoot problems in the cloud? What services are available from your cloud provider to help and how does that change your runbooks?

Now multiply that across every application, cloud provider, and region in which you need to operate your business.

I’ve been thinking about this a lot recently as I re-joined VMware in their Multi-Cloud solutions team after spending 7 years deep in the cloud-native ecosystem, including 4+ years at Docker where I watched containerization shift the IT conversation even further. I’ve spent the past 20+ years in enterprise software, specifically in infrastructure software — starting from systems management, virtualization, containerization, to service mesh, and now back to a different VMware than the one I left. The commonality is abstraction and the opportunities that they provide us.

What the engineers love about cloud and containers, is not how many availability zones or which vendor backs the upstream project — what we all love about those technologies is what they give us: choice, speed, self-service, and elasticity. The new applications that we build are made of the best components for their discreet jobs, are as big or small as we need them be, almost internally automate, and are dynamic.

These technologies removed the complexities of infrastructure from the builders so they could focus on building. These technologies also disrupted the way operators could govern the systems to guarantee SLAs and compliance.

There is no going back to the way things were with rigid and static environments with long provisioning times, difficulties in scaling and reliability, and inefficiencies in the environment and processes. Freedom and speed for the sake of innovation will win over every time.

Can you be fast and secure? Can you automate and operationalize choice without ballooning the budget?

I believe the answer is “Yes.”

The cloud is not a singular destination, location, or a specific vendor. Cloud is really an operational mindset of how an environment is built, operated, and consumed by developers and operators of an application. From the platform resources (compute, network, storage, security) to the workload orchestration, financial model (OPEX, chargeback), lifecycle management, policies, and governance.

The cloud is a state of mind and cloud transformation is not a linear journey. The paths are many and divergent and cloud strategies need to focus on maintaining operational and financial governance without sacrificing choice and speed.

** Caveat — This isn’t a vendor pitch (yet), but this is why I re-joined VMware.

There is a lot of exciting work happening at VMware Multi-Cloud to build, run, manage, connect, and secure with an integrated platform that is application and cloud-agnostic. Looking forward to learning more about what you are doing and comparing notes.

P.S. I think “The cloud is a state of mind” may need to be a t-shirt.