How we enjoy our own champagne with CAVA@Swisscom

What is CAVA

End of last year we started a close collaboration with VMware to productize their project “CAVA”. Bryan Halter delivered a blueprint together with setup instruction to our Cloud DevOps & Lab Manager Beni Eugster at Swisscom’s Cloudlab in Palo Alto, US.

Beni tested the setup and helped to tune it to make it self-contained and thus usable in any environment.
Here’s how the VMware team is introducing CAVA in a brand-new video:

How we use CAVA by now

Once the blueprint was successfully tested & deployed and the prerequisites were known, we started to use it on our lab environment:

As you can see in the picture above, here we have two deployments of Cava. One is a vRA 7.2 installation and the other one is using vRA 7.3. Let me show you how we can login to these installations and express my gratitude towards our joint team in the following video:

How we plan to drink even more of our champagne

We plan to use Cava in the following use cases

  • in our CICD pipeline for comprehensive test cases with a full test base line
  • as a sandbox environment for developers that need to do changes that could affect other tenants in the shared vRA environment
  • in order to evaluate new versions of vRA for regression testing
  • as an offer for our customers to test upcoming releases in a preproduction environment

This diagram depicts the concept for our development environment that is organized basically with a  tenant per development squad. The column at left hand side is the integration tenant that serves as deployment target for the continuous integration: every time a developer is checking in new changes that have been successfully tested they get deployed to the integration tenant. If the integration tests are all successful these changes get continuously deployed to all other tenants as a common baseline for our further deployment pipeline. The two arrows are depicting only 2 processes the full integration and deployment process is much more complex because every component is versioned and might have dependencies to other components.
In order to have strictly isolated environments per squad or even per developer we want to support the following levels in the future:

  • additional external vRO (OVF deploying blueprint) per tenant
  • tenant and external vRO per developer
  • CAVA blueprint with a fresh and dedicated vRA/vRO.

In the column of squad 5 a deployed Cava blueprint is depicted (vRA/vRO) whereas squad 6 is our target architecture for a full nested environment with virtualized ESXi hosts and NSX nodes in a nested vCenter environment.
The configuration management and the continuous deployment of such complex scenarios are quite demanding for a standardized deployment pipeline. In addition we have to enrich the base installation of project CAVA with automated tenant and business group onboarding with creation of reservations, adding IDPs and mapping roles, a bunch of reference data and last but not least catalog items in order to define a proper test base line. Please find some of the requirements we have defined so far in my blog post A Wish List for Configuration Management with the vRealize Suite.

Wanna see more?

We ‘ll be at the VMworld Barcelona – save the date and visit us at the VMworld Barcelona booth: ¿Qué tal un poco de champán? ¡Salud!