Principal Product Manager at Pivotal

At Pivotal Software, I established the product vision and strategy for expanding the capabilities of the Pivotal Cloud Foundry platform to enable the company to address the .NET enterprise software market, eventually serving 30+ enterprise customers.

In my time there, I…

The Pivotal Cloud Foundry platform was a technically complex system comprised of the efforts of over 40 teams, 75+ product and program managers at Pivotal, and the OSS Cloud Foundry community.

Now called VMware Tanzu Application service, Pivotal Application Service (for PCF) enabled enterprise developers to deploy and run their apps on the cloud without needing to manage the underlying infrastructure or build process. DevOps teams could also scale their applications out with simple commands, bind to services (like databases), and even manage security capabilities (like network traffic isolation). It’s essentially Heroku for enterprises.

The Markets

Large enterprises are roughly equally split between their adoption of Java and .NET (with a small growing segment of Node.js applications mixed in). With Java-based customers, Pivotal gained traction via its Spring Framework, but a number of hybrid customers (with Java and .NET application footprints), started asking for PAS to support their entire portfolios. In addition, many customers in Pivotal’s main verticals were .NET shops, so the ability to service .NET and Windows-based workloads (and thus expand Pivotal’s addressable market) became a strategic opportunity.

The Technology

The platform’s stack orchestrated the lifecycles of Linux and Windows virtual machines on AWS, Azure, Google Cloud, OpenStack, and VMware’s vSphere. It also orchestrated the lifecycle and networking of containerization technologies on those operating systems and created consistent and reliable application executables directly from developers’ code. Eventually, Pivotal started incorporating the work from Cloud Foundry’s Eirini project to enable the container orchestration and networking with Kubernetes.

Whiteboard drawing showing software architecture diagram of fundamental components for deploying apps on Cloud Foundry

Enabling PAS to run Windows-based workloads was a complicated effort, as the ecosystem powered by Windows Server and Active Directory was built on a different set of foundational assumptions from the Java ecosystem. Customers’ workloads (from major companies in banking, finance, retail, insurance, etc) ranged from Windows-native applications using features like the global assembly cache (GAC) and Integrated Windows Authentication (IWA) to future-forward, cloud-native applications built with early versions of .NET Core. We had to account for these differences and formulate a larger view of how to move workloads from traditionally managed Windows Server instances to automated, disposable Windows VMs with a pseudo-containerization runtime.

A major pillar of our product’s strategy was to first service applications that didn’t have deep dependencies on these Windows-native capabilities, or conversely, that already fit a critical subset of the 12 factors of cloud-native applications. Our .NET Developer Experience team (which I helped create), in partnership with our .NET Application Transformation (AppTx) organization, would expand the capabilities of the platform over time to service more and more of our customers’ workloads. However, we also knew a significant subset of Windows-based workloads could never be hosted on the platform, so we guided our customers along a digital transformation journey that accounted for this. Ideally, the oldest mission-critical workloads could eventually be replaced by newer, greenfield .NET Core applications to be hosted on Kubernetes.