Podcast : Orchestration & Automation Between Public & Private Cloud

In the fourth episode of our Get IT: Finding Success with Hybrid Cloud in Canada podcast, KJBurke and Michael Traves from CDW and Parth Pandit from VMware discuss thelandscape of tools that are available to automate and orchestrate appportability, as well as containers, Kubernetes, GitOps and how to connecton-premises and multicloud environments. Here are some of the highlights oftheir conversation:

What shouldcustomers understand about orchestration and automation between public andprivate cloud?

A lot of customers come to us looking for a way tomove to cloud. They're looking to transition how they deploy workloads in theirenvironment, and at a director level or CXO level, someone has come down andsaid Thou shalt be cloud-first.

And then, we get involved to help them with thattransition. It's really about trying to understand what workloads are runningin an environment, what the dependencies are between various applications, whatmakes sense to move to cloud and how to actually restructure thoseapplications, whether it's a virtual machine or a container, to make it portable,so that it's easily transitioned to a public cloud environment but also, ableto transition to multiple clouds.

If we can look at a workload, break it down into itscomponents and start making those portable, such that they can run in multiplelocations, that is the goal.

Do containersand VMs work differently across public and private cloud?

Automation is the key to success when you need to growand scale. But it's a difficult problem to solve when it comes toinfrastructure automation, because there are different flavours of cloud, APIsand nomenclature.

We have tools like vRealize and Terraform trying tosolve this problem, but we really need a layer on top of all the differentclouds, which would provide uniform capabilities, uniform APIs, on which youcan put your automation. That's where VMware Cloud would come in, which hidesthe complexity in different instances ofdifferent public clouds.

When it comes to containers, there is a great tool inKubernetes, which would solve the container orchestration problem. If you havethe same version of Kubernetes, you can be confident your application wouldwork, no matter where the cluster is deployed. But you need to be careful thatwhatever Kubernetes platform you choose, it should be free from anyvendor-specific features that would tie you to that particular flavour ofKubernetes, which could be a problem for you when deploying applications acrossa multicloud environment.

How to evaluateyour multicloud environment

Some customers might think they're running amulticloud environment, when maybe their production workloads are running inAWS, and the account email runs in Office 365 as their second cloud. And it'snot really the same thing. Understanding what multicloud actually means is thefirst step.

Once you've gotten past that, the next question isDoes it make sense to have a multicloud environment? It certainly makes senseto put in that infrastructure layer that allows you to run your app in any ofthe clouds. Leveraging tools like Terraform, you can automate the deployment ofyour infrastructure in each of those clouds and deploy your application. And ifyou code all that upfront, it makes portability very easy, and that's really important.

But at the same time, do you want to runinfrastructure in the cloud, or do you want to run your application in thecloud? There's an important distinction there. Whether it's AWS, Google,Microsoft Azure or any public cloud vendor, they all have their strengths andweaknesses. It might make sense to run certain applications or certainworkloads in each of those clouds.

You'll also want to look at your own bench, at theskills you have in-house, and realize that if you go to your team and sayWe're going to put these apps in Azure, but we also want to put this other appin AWS, and we're thinking of GCP for something else, can you realisticallyexpect your staff to really be experts at three different clouds, let aloneone?

How doesVMware approach reducing that level of complexity?

VMware takes the multicloud as a step-by-step process,with different things that you're meant to consider at different levels.

The first thing is, how do you build your applicationcontainers using technologies that are cloud-agnostic? For example, using CloudNative Buildpacks, which is not provided by a particular cloud vendor.

Then, what packing services will you use for yourapplication? Perhaps you might use RDS instead of Aurora DB, which isAWS-specific.

Then, the next challenge would come when you need tomanage multiple clusters that are deployed across different environments. Atool that gives you the ability to manage all the different clusters acrossdifferent environments is the key to success.

The next step is, how do you monitor everythingtogether? You need a single tool that gives you the single point of visibilityfor all the different apps and infrastructure, which may be deployed anywhere.

And finally, how would you integrate these differentservices? These might be running on multiple public clouds, or even a privatecloud and public cloud model. In that case, technologies and tools like SpringCloud Gateway or Istio service mesh would come into the picture. VMware's Tanzuportfolio of products are also well suited for all these different concerns.

For more orchestrationand automation insights, listen to Episode 4 now. And tune in weekly for additional podcasts in thisseries!