What was the point of IT again? Why are we doing all of this? We’re doing all of this work, in order to get applications, software, code in the hands of our customers.

That’s ultimately what IT shops are all about, and what this vendor ecosystem is all about. What partners do is help get software running, and put that functionality into the hands of our customers’ customers, so that our customers can make money.

Software is becoming no longer, “This thing that is running in support of the business.” Now software is becoming the business, right?

It’s about getting changes to code (features, versions, patches) into the hands of our customers’, customers as quickly as possible. And we do this via this thing we draw in the middle of our architecture diagrams, the cloud. Which is the processes that we employ to get us there. Great. That’s the goal to get code into the hands of our customers.

Traditionally, we’ve had this sort of three tier application model: web servers running some sort of application code, application middleware. These things connect to a database, a system of record running on some sort of an environment. All this is what we need to deploy when we deploy an application.

We have standard tools and methodologies by which we roll out applications, and they’re fairly unidirectional. We’ve all been part of these IT projects before either indirectly in IT, or as partners working with our customers:

• creating a statement of work
• creating an environment
• standing up a POC if we have to, although those are expensive and time consuming, as we all know
• to deploy the thing we put the VMs in place
• We make configuration changes in the VMs, in the running application to get the configuration customized for our customer environment.
• We author a knowledge transfer document.
• We turn this over to the customer and walk away satisfied!

Perhaps we walk away at that point having established a new application inside of IT, and trained everyone how to deploy this application. Perhaps we go so far as to create backup and recovery / DR scenarios. Perhaps we create a snapshot or a clone or a gold image of some kind to allow the customer to redeploy the application if need be.

But God forbid that ever happens because we take care of that application, and we keep it alive for as long as possible.

And then change requires some sort of rigorous change control process because often these the changes are not automatic. This is very familiar to anyone growing up in IT over the past decade or so or more.

And it’s exactly the reason why software, our application architectures, are changing. Developers who merely want to get their code into the hands of their customers to make money really want to bypass this process! They want to minimize the time it takes to go through that. They don’t want to go through that.

And so from their point of view, they’re beginning to write applications and microservices. They’re decoupling these complex monolithic applications into discrete units, so that the changes that happen in one of these microservices can happen very quickly, very rapidly. And we don’t have to go through complex change control because we’re minimizing the blast radius of change. We’re only changing one small component, and the rest are loosely coupled through API calls.

This loose coupling is the point of what we’re trying to do with microservices architectures driving containerized workloads. This new, more dynamic application architecture is now a new world that we need to support through new tools, processes, and the cloud in order to get software into the hands of our customers faster and safer.

Microservices demand that the new contract with IT is the container. And in a container we don’t modify configurations anymore. It’s immutable. So the developer goes through the work of building the container, and then they deliver that container over to IT.

There’s nothing to customize inside the container for a given customer environment. The benefit of a container is that we don’t have to go through those config changes for every IaaS that I want to run on. They’re immediately portable, managed by externally injected configuration changes.

So where there are limited reasons to make a change to a running configuration, we make the changes to the image or external configuration, recreate the container, and then redeploy it. We destroy what’s old, redeploying what’s new. And so an update looks exactly like a deployment did in the beginning.

Therefore we have to get very good at deploying containers because that’s the one methodology that we’ve standardized on to get change into production. We deploy a new container, running a new image or configuration.

And so this creates a single process to get good at. And this is why we’ve begun to develop these patterns and recipes for building containers for running containers. This is why containers are on the rise and will be the representative of the next workload running on top of Kubernetes, which is the container orchestrator for running these containers. All of this makes it easier to connect developers to IT, to get code into the hands of our customers’ customers faster.

One of the manifestations, the reality that now happens, is we can’t just go in one direction. It’s no longer, I write an application. I pass it to the operator. They run it, and we walk away from a project. It’s not like that anymore. We don’t do one direction. We have these now virtuous cycles where developers and IT are working together.

In the partner community, this is every one of your dev ops practices. This is not new information. And so from a Tanzu point of view, how does VMware internalize and want to represent this? There are two loops that we want to go around as quickly as possible.

The inner loop defines a developer environment and CI workflow that looks and acts just like production. And that’s what these container-based solutions are. There is no difference really in the configuration. Developer creates a container. The container runs on the Kubernetes based IaaS anywhere, and it could be anywhere. Any of the public clouds or on vSphere with Tanzu Kubernetes.

And so developers want to run through this inner loop of testing, the CI process in the CI/CD pipeline… around the CI process as fast as possible. They get a trusted set of change ready for deployment. Then the outer loop is the continuous delivery or continuous deployment loop, where we take change and put it into production, and leverage IT and governance in order to make this happen safely.

This forms the generic devops and agile infinite loop of feedback and continuous change in the environment. Where through automation not rigorous change control, we make sure that the environment can be deployed, redeployed, updated, changed as fast as possible.

I really liken it to like a formula one race car or a Ferrari where the engine is running, you know, six, seven, 8,000 RPM. Well, my Ford gets a little squirrelly if I run my engine at 4,000 RPM. So sometimes when we want to go fast, we actually need more precision, more safety, more capability. If I want to go fast, I actually have to have a safer, better engineered environment to make that a reality.

So speed does not equal risk. In many cases, if I can do something quickly and repeatably, then I’ve actually de-risked my environment. And so we can move from a world of rigorous change control into a world of blue-green deployments and canary deployments. And actually testing with our real user base with the percentage of users running on the new code and crew get very good at continuous integration, continuous delivery in this process.

So that’s what Tanzu Advanced is all about. Tanzu Advanced is moving from the toil of developers creating containers, to IT delivering that process for them. This DevSecOps thing has been happening for a while now. I want to give all due respect to the last five to six, maybe 10 years of devops. The most advanced customers are actually trying to go through this. And the partner community has devops practices that we want to plug into. But we need to move now to the next generation of tools and technologies that will enable us to go that much faster. And we want to do it safely and securely.

We’re going to sit on this word of “DevSecOps” and make sure that security, and safety, and stability is part of the speed and savings that we get. So as Gartner says, it’s time to graduate technologies and practices in order to deliver real business value here with our customers to get code into the hands of our customers, customers as fast as possible… with VMware Tanzu Advanced edition.