As a Solutions Architect here at Broadcom who talks to our customer engineers on the daily, the biggest feedback I get about VMware Cloud Foundation (VCF) 9.0 is a fear (we’ll call it) about having less control with a self service model:

“If you want something done right, you have to do it yourself.”

First of all, you will be doing it yourself through the enforcement of boundaries and policies at the onset. You don’t lose control: it is just front-loaded and implemented by applying the policies and boundaries at provisioning. With this approach you actually have more control with less administrative overhead.

Second of all, if you are an infrastructure engineer, you are part of “self” in “self service”: in a cloud operating model, you will create infrastructure resources the same way everyone else does: using VCF Automation and Operations where your boundaries and restrictions are imposed in a standard and uniform way.

Before we dive in, I would be remiss if I didn’t at least mention that VMware infrastructure as a private cloud is not new. Most of the components mentioned below have been around for more than a decade, and they are in the driver’s seat with VCF.

If you are a cloud engineer of any sort, you will find yourself right at home with VCF: that’s the whole point.

Diving Deeper into Self Service

I have talked about this before, albeit indirectly, but like it or not, you provide infrastructure as a service to the people who consume your infrastructure.

When you provision a VM, for example, you are providing a virtual machine and everything that goes with it. If it takes days or weeks for that VM to work its way through approvals, or it’s delayed because “we’re waiting on Derek to get back from vacation,” then you’ve already lost.

VCF 9.0 provides a cloud native self service model which gives you more control and more security with less effort.

You meet the need for infrastructure in a fast and proactive (and therefore automated) way instead of in a reactive (and therefore manual) way. The added benefit is that the business practices and technical standards are built into the platform and enforced at the onset.

Need defense-in-depth? Apply your security policies at provision time, day 1. Need to ensure a virtual machine is part of a backup and DR recovery plan? Define a policy that gets imposed on the VM at rollout.

VCF Boundaries

With defined boundaries (and I don’t mean just physical or network boundaries here), the usual vCenter concerns are obfuscated away. You specify what vSphere clusters are part of a Region and Availability Zone and implement the VPCs, tags, and policies that are imposed onto them.

Sure, you know what is in that zone, but you don’t see it as “this thing in vCenter” anymore. It’s a full set of infrastructure strictly defined that will impose security boundaries and the like.

Of course, this allows for multitenancy. If you’re a “smaller shop” you can have one Region with one Zone and be done with it.

This makes automation easier because rather than stringing together a bunch of loosely defined things, you can simply have a secure-by-default landing zone for VMs and Kubernetes. If you are doing full multitenancy, then you can do showback, chargeback, customized reporting, etc.

All of these things become available in the VCF UI everywhere. Some examples of the objects you define:

1. Organizations, Regions, and Availability Zones – Each VCF Domain, Management or otherwise, has its own SSO boundary and software-defined infrastructure. You control who does what to which objects and how. Once configured, these objects show up in the VCF UI. Need to ensure that a team only has access to one Availability Zone? You are ready to provide that limited access.
2. VMware Cloud Networking Virtual Private Clouds – VPCs, a well-known cloud construct, is part of VCF 9.0. By default, VPCs are self-contained with no connections: you have to open them up. This is how it is done on most cloud platforms, so this should be a very straightforward concept:
   
3. VCF Management and Workload Domains – Here you have SSO Boundaries and other security boundaries implemented in a defense-in-depth fashion. These are very granular, but keep in mind that the idea would be to ensure that policies are implemented from day one.

VCF Policies

Policy-based management (from here on out, “PBM”) is everywhere in VCF: The most blatant examples are Storage Policies and Tagging.

Think about this: If you are running vSAN with Data Protection and/or VMware Live Recovery, then you can have virtual machines protected at creation time by applying the policies at provisioning.

Yes, this has been around for some time, but the difference with VCF is that these all bubble up into VCF Operations and Automation and become available on the full platform.

Furthermore, VCF Operations has policies you can define for analysis and workflow decisions.

I would also be remiss if I didn’t mention configuration drift detection for vCenter and Clusters across your entire environment.

This is all “tip of the iceberg”, but email me for more details or questions.

VCF Automation Policies

Finally, this entire process would be for nothing without the self service engine that rolls out the infrastructure needed by your consumers.

Once you are up and running with VCF Automation and the VM Service, everything so far has been a prelude, because VCF Automation is where all of these objects converge and give you the control you have sought.

You provide an image that has all of your standard OS security and software on it and let VCF Automation do the rest:

You create a Project that defines which availability zones, VPCs, and policies are available, then grant access to Consumers by groups.

The infrastructure basically runs itself while you as the engineer provide innovation for the organization rather than just keeping the lights on.