I have had the privilege to begin to work with the Cloud Native Apps team at VMware a bit over the past couple months, and I am becoming more and more convinced that this is a topic and a trend that will be come more and more impactful as time passes.
There is much to be said (written) about the rise of Continuous Integration and Continuous Deployment (CI/CD), how DevOps is changing the way our customers go about the business of IT, and how applications are being written in new ways with new tools (think ‘microservices’). However, without getting bogged down by the noise created by everything that’s going on in the market, there are some fundamental truths we have to come to grips with…
1 – Containers (not virtual machines) are the new deployment targets.
Developers prefer containers:
- As a development environment, because Docker has made it dead simple to wrap up dependencies in a configuration file, allowing one to focus on coding, rather than worrying about infrastructure and waiting for operations teams to provide an environment.
- As a deployment target, because they can spin them up on their laptop(s) without much fuss… there is no operating system to install, as a container is essentially a construct of the operating system.
- For portability, for the two reasons above…. Containers an be spun up on any Linux distribution, the proper dependencies injected into the container, and application code downloaded to run from Github (or someplace else) far faster than waiting for IT to spin up an approved VM.
Unfortunately, too often the ‘usual suspects’ (infrastructure teams) don’t always see this, or aren’t aware of it, and if they are they might be struggling to understand what, if anything, they need to do about it.
VMware needs to help them understand why containers are important, and how we can continue to support them, offering containers as first class citizens of the datacenter both now and in the future (think vSphere Integrated Containers).
2 – Clusters are the new application architecture.
These are not your Oracle / Microsoft clusters. Think of Hadoop as an example – a ‘master’ node, with multiple ‘minions.’ The master handles scheduling and assigning tasks to its minions… of which there could be hundreds, or thousands. When we talk about building ‘cloud native applications’ – whether brand new applications, or decomposing a legacy application into smaller pieces – frequently these new applications are built as microservices scheduled and managed by a cluster technology. You might have heard of Google Kubernetes, Docker Swarm, and Apache Mesos – of the three, Mesos is the most mature and widely used. Twitter, Netflix, Apple, and many other companies that we equate with ‘cloud native’ all leverage Mesos for instantiating, managing, restarting (etc) their workloads. As a matter of fact, Microsoft recently announced they plan to launch a Mesos service in Azure for managing Linux container clusters.
Unfortunately (again), while both containers and such clusters as Mesos run readily on vSphere (or in vCloud Air), our infrastructure customers are frequently ill-equipped to offer such services, as they have built their datacenters and operational practices around management of virtual machines and applications we tend to be more familiar with (Microsoft, ORCL, SAP, etc).
We need to help our customers understand why cluster architectures are important, and how we can continue to support them, offering cluster services both now and in the future (think Photon Platform).
3 – We Need to Meet our Developer Customers Where They Are…
During a cloud-native panel discussion at Tech Summit (an internal VMware event) last week, one of the audience members asked (and I am somewhat paraphrasing), “Why are we doing all this with containers and Photon platform? There are already Powershell scripts for Instant Clone in vSphere 6…”
It was a good question, and illustrates a significant point that we all need to grok (Robert A Heinlein, Stranger in a Strange Land) – developers aren’t using Powershell for development (on vSphere or anywhere else)… Powershell isn’t even targeted at developers. It is a scripting language targeted at system administrators for automation of infrastructure (initially for MSFT sysadmins, but VMware has leveraged it to great effect for vSphere administration). For that matter, not only aren’t developers not using Powershell – they aren’t using any VMware APIs for development of their applications. If they were, VMware wouldn’t have to worry about doing anything different!
Developers are building using an entire ecosystem of tools that VMware doesn’t currently play with, or at least only a little. Yes, there are some nice stories around Vagrant, Puppet and Chef, and yes, we would all love everyone to be using vRealize Automation for automated deployment of infrastructure. But that is not the case.
In many organizations, control of budgets is shifting away from infrastructure teams to lines of business and developers. To quote one of my customers from earlier this year (and this is verbatim) – “Anything that enables developer productivity gets funded.” Developers desire an effortless experience spinning up an environment in which they can build and test their code, and minimal friction getting their code to development (see point #1 above). We know this story… we have all heard this as part of the SDDC value proposition. But in many cases, developers are avoiding IT to spin up containers on their laptop and then in production because it represents an easier way to deploy than waiting for IT to build and ‘certify’ a new VM.
Therefore, I personally believe VMware needs to provide customers a great development experience:
- During development on the laptop (think AppCatalyst)
- Through test and dev (think vRealize Code Stream)
- Into Production (think vSphere Integrated Containers and Photon Platform).
Finally, we need to be embracing the open source movement to further enable the community at large, which is why VMware has started to contribute back to the community with Photon OS, Lightwave, AppCatalyst, and many other projects.
If VMware is to successfully navigate this next wave of innovation, they need to get out in front and yell from the rooftops. That is what the Cloud Native Apps group is all about at VMware, and I am proud to be a part of it!