Further Discussion on Multi-Cloud: A Strategy or Inevitable Outcome?
The most recent blog series on multi-cloud (original and then what VMware is doing) has generated a lot of great discussion. I appreciate people reaching out with their thoughts on Twitter, LinkedIn, and over email.
One email came from a VMware pre sales leader asking about the order of steps for cloud migration:
In your recent blogs you seem to insist on the need to migrate first before modernizing. While valuable, we do hear from customers that they want to modernize before they migrate. Other customers want to modernize on-prem without migrating to the cloud. Could you explain your thinking? Is this an evolution in the VMware position or strategy?
This is a great question and focuses on some rather subtle points – assumptions perhaps on my part. Let’s take this time to go more in depth.
First, in those blogs, “cloud” refers to public cloud. Because the multi-cloud concept is primarily focused on multiple public clouds, in this context, customers are wondering how best to get to public cloud and deal with multiple public clouds. (In my opinion, multi-cloud also includes cloud on-prem, but that’s a longer discussion for a separate time!)
The last two blogs focus on this specific transition vs all the other permutations. Yet cloud is more about a model than a particular place and indeed, many customers want to keep apps on-prem but also want to modernize them. While the “migrate and modernize” model is cited by customers as a key differentiator when moving to public cloud, is it also effective when staying on-prem? The short answer is yes!
How so? In this more general context, “migrate” refers to the transition from a traditional virtualized datacenter to a cloud model – whether that’s in the public cloud, datacenter, or at the edge. A traditional virtualized datacenter means a traditional datacenter operational model, where developers/users must file tickets to get access to resources and wait for a person to give them that access (e.g., provision a new VM, storage LUN, network VLAN). Cloud, by contrast, allows them to get access to resources immediately via self-service APIs. Because there are no humans in the loop, resources are provisioned in a fully automated manner and can be delivered in minutes or even seconds. So, in this definition, you’re migrating between two different models rather than necessarily between two different places (though of course that can happen!).
The importance of self-service API access to application modernization shouldn’t be understated here. Modern apps typically integrate with the API of the cloud they run on, allowing apps the ability to call the cloud API to monitor themselves, increase the number of instances running, provision additional storage, and much more. In a traditional app, there is no assumption of a cloud API that can manipulate or retrieve information from the infrastructure. Traditional apps must have human operators take care of this. Modern apps, by contrast, assume that the underlying infrastructure is dynamic and adaptable on the fly to the needs of the app. This requires a real cloud model. A traditional ticket-driven approach simply isn’t responsive or quick enough.
“Migrate” is also shorthand for a fundamental operational shift – from tickets to APIs. That property is just as important on-prem as it is in the public cloud. And because the reliance on the cloud API is so deeply ingrained in modern app design, it means it’s very difficult to modernize an app on an infrastructure without those APIs. That’s why app modernization on traditional infrastructure is so challenging – the infrastructure is lacking fundamental primitives of modern app behavior, making it very difficult to modernize!
The email above referred to VMware Cloud Foundation with Tanzu. VMware Cloud Foundation is VMware’s infrastructure building block composed of compute (vSphere), storage (vSAN), networking (NSX), and management (vRealize). Tanzu provides the application platform based on Kubernetes to accelerate your app modernization efforts. As you know, it’s all software-defined, meaning everything is accessed via an API. With the governance and automation capabilities of vRealize Automation, you can build a curated infrastructure catalog and interface for self-service access, whether on-prem or public cloud.
Do we really mean migrate then modernize, always? The answer is yes! VMware’s recommendation is still “migrate and then modernization”, even on-prem. For public cloud, this means migrate the apps to VMware-based public cloud infrastructure while for on-prem, it means migrate the infrastructure to support self-service APIs with VMware Cloud Foundation with Tanzu. In either case, the migration step sets you up for success with app modernization. And in both cases, the migration step is largely automatable, without the need for any app modification. This means you can quickly set yourself up for success with your modernization efforts.
Finally, please keep the comments, questions, and feedback coming. You can find me on Twitter (DMs open) and LinkedIn. (And for other internal VMware folks, you know how to find me on email and Slack.) I look forward to hearing your thoughts and suggestions.
