top of page
Business & Enterprise
Cloud Technology
Cloud Infrastructure
VMware Tanzu
Converted VMware’s enterprise virtualization base into a Kubernetes application platform by combining Pivotal, Spring, Cloud Foundry, and vSphere integration, despite hyperscalers, Red Hat OpenShift, and managed Kubernetes services controlling much of the cloud-native runtime.
1
MODEL
BUSINESS MODEL
SaaS
- Sold enterprise subscriptions and term licenses for Kubernetes runtime, application platform, registry, observability, and developer tooling. - Built Tanzu on Kubernetes as the common substrate across vSphere, public clouds, and edge environments. - Integrated Pivotal’s Spring framework, Cloud Foundry-derived Tanzu Application Service, and developer workflows into the platform. - Used VMware’s enterprise sales force, channel partners, and installed vSphere base to reach regulated and hybrid-cloud customers. - Packaged capabilities into Standard, Advanced, and Tanzu Platform editions, with self-managed and managed deployment options.
1. Identify an enterprise workflow where an existing infrastructure vendor can extend into the next architectural layer. 2. Acquire or integrate the missing developer, runtime, and operations capabilities rather than rebuilding them from zero. 3. Standardize on an open abstraction—in this case Kubernetes—while retaining enterprise control, security, and support. 4. Sell to the platform, security, and application teams through the incumbent infrastructure relationship. 5. Package the product so the customer can adopt incrementally without abandoning existing virtualization investments. The common mis-build is acquiring technology without integrating it into the incumbent’s sales motion, support model, and customer workflow.
DISTRIBUTION MODEL
VMware launched Tanzu in 2019 around Project Pacific, then acquired Pivotal for $2.7 billion in December 2019, adding Spring, Cloud Foundry, Pivotal Application Service, and Kubernetes capabilities. The strategic question was whether VMware could turn its on-premises virtualization franchise into recurring cloud-native platform revenue across private, public, and hybrid clouds.
HOW THEY BUILT IT
HOW TO ARCHITECT IT
Enterprise Sales, Channel Partners, Direct Sales, Marketplace/Platform Distribution
HOW THEY OPERATIONALIZED
HOW TO REPLICATE WHAT WORKED
dm
- VMware’s enterprise sales organization sold Tanzu to existing vSphere, NSX, and vSAN customers. - Channel partners, systems integrators, and resellers delivered implementation, migration, and managed services. - AWS Marketplace and Azure VMware Solution made Tanzu available through cloud procurement channels. - VMware Tanzu Labs provided consulting-led transformation engagements that created implementation demand. - Kubernetes, Spring, and Cloud Foundry open-source communities created developer awareness and technical credibility.
What worked: selling through an existing enterprise infrastructure relationship reduced the cost of reaching platform and security buyers who would otherwise evaluate hyperscaler-native tools. Trap if copied blindly: enterprise distribution cannot compensate for unclear product packaging or weak developer adoption; the vendor must prove that the platform reduces operational complexity rather than adding another layer.
| PATTERNS OF THIS MODEL
PATTERNS IN ENTERPRISE PLATFORM EXTENSION: 1. INCUMBENT DISTRIBUTION ACCELERATES A NEW CATEGORY. An installed base creates a route to buyers who already trust the vendor for mission-critical infrastructure. 2. ACQUISITION BUYS TIME-TO-MARKET, NOT PRODUCT-MARKET FIT. Pivotal brought Spring, Cloud Foundry, and Kubernetes assets, but VMware still had to integrate them into a coherent platform. 3. OPEN-SOURCE ABSTRACTIONS CREATE PORTABILITY CLAIMS. Kubernetes lets the vendor sell across clouds while retaining enterprise support and management value. THE WEAKNESS: Platform bundles can become too broad, making it hard for buyers to understand what to purchase or which workflow the product improves.
What companies with this model reveal
| OPPORTUNITY INTELLIGENCE
GOLDMINE 1 — PLATFORM ENGINEERING AS A PRODUCT. Enterprises need internal developer platforms with paved paths, golden paths, security policy, and self-service environments—not merely Kubernetes clusters. GOLDMINE 2 — AI-READY APPLICATION PLATFORMS. The opportunity is packaging model serving, vector data, governance, and observability into the same enterprise platform that runs conventional applications. GOLDMINE 3 — MODERNIZATION-TO-RUN OPERATIONS. The durable opportunity is connecting legacy migration, application inventory, refactoring, deployment, and ongoing operations into one accountable workflow. THE PIT — KUBERNETES AS THE PRODUCT. Kubernetes is increasingly commoditized by managed services; the durable value is developer productivity, governance, and operational reliability. THE SECOND PIT — PORTFOLIO COMPLEXITY. Too many Tanzu-branded products can create evaluation friction and make the platform feel like a collection of acquisitions. MOVE WITH CAUTION — Do not acquire developer-platform assets without a clear integration thesis; an acquisition that does not change the incumbent’s go-to-market or product architecture becomes a cost center.
Untapped Business Model / Gaps / Goldmines / Pits
Patterns & Insights
2
MARKET
mkt mt es
VMware Tanzu competed against AWS EKS, Azure AKS, Google GKE, Red Hat OpenShift, Rancher, and Cloud Foundry-based platforms. Its advantage was VMware’s enterprise virtualization base and hybrid-cloud presence; its constraint was that hyperscalers controlled managed Kubernetes and developer-native cloud platforms.
MARKET TYPE
Consolidated Market
ENTRY STRATEGY
Acquisition
WHY THEY WON
The market is a Consolidated Market: Kubernetes, cloud infrastructure, and enterprise application platforms are dominated by hyperscalers, Red Hat, and VMware itself. Tanzu’s opening was that large enterprises with VMware estates needed a path to containers without abandoning vSphere, security controls, or on-premises operations. By integrating Kubernetes into vSphere and combining it with Pivotal’s developer platform, VMware changed the comparison from “which Kubernetes distribution?” to “which platform lets us modernize applications without splitting infrastructure and developer operations?” The transferable lesson is that an incumbent can enter an adjacent consolidated market by making the new abstraction compatible with the customer’s existing control plane.
EXECUTION
VMware entered cloud-native application platforms through Project Pacific and the $2.7 billion acquisition of Pivotal in 2019, after earlier acquisitions of Heptio and Bitnami. The initial bet was that enterprise customers would adopt Kubernetes if VMware could embed it into vSphere and pair it with developer frameworks and application services. This required integration of Pivotal, Heptio, Bitnami, Spring, Cloud Foundry, and VMware infrastructure. The approach was viable because VMware already owned the enterprise infrastructure relationship; it would fail if the acquired products remained disconnected or if hyperscaler-native Kubernetes proved simpler for developers.
FOOTHOLD STRATEGY
Lighthouse Customer Strategy
Tanzu first targeted large VMware customers with substantial virtualization estates, regulated workloads, and application-modernization mandates. These buyers were reachable through VMware account teams and partners; they could pay because Kubernetes adoption threatened to fragment their infrastructure and security operations. The path outward was from vSphere-integrated Kubernetes into developer platforms, public-cloud deployments, and application modernization services.
GROWTH CAMPAIGN
CAMPAIGNS THAT WORKED
SO WHAT: Tanzu’s vSphere integration and Pivotal acquisition gave VMware a credible enterprise narrative for modernizing applications without abandoning existing infrastructure. KEY LEARNING: The strongest incumbent expansion message is continuity: adopt the new architecture without losing existing security, operations, or procurement control. HOW TO USE: Position the new product as the bridge between the customer’s current system of record and the next architectural layer, rather than as a replacement.
KEY LEARNING
THE STANDARD: In a Consolidated Market, the entrant must exploit an existing trust position or control point rather than compete on feature breadth. RULE 1 — START FROM THE INSTALLED BASE: Existing infrastructure relationships create a route to platform and security buyers. RULE 2 — OWN A CONTROL POINT: vSphere, identity, database, or endpoint control can become the wedge into an adjacent platform layer. RULE 3 — STANDARDIZE ON THE OPEN ABSTRACTION: Kubernetes, Linux, or SQL compatibility reduces switching fear. RULE 4 — BROAD PORTFOLIOS FAIL WITHOUT A CLEAR JOB: Buyers reject platforms that cannot explain the workflow they improve. MARKET TYPE: Consolidated Market (category).
gc
Market Context
| MARKET INTELLIGENCE
PATTERNS IN ENTERPRISE PLATFORM SALES: 1. ACCOUNT EXPANSION BEATS NET-NEW LOGO ACQUISITION. Existing infrastructure customers already have budget, security review, and procurement pathways. 2. CONSULTING CREATES IMPLEMENTATION DEMAND. Services-led engagements can establish architecture and create software expansion, but can also mask weak product-led adoption. 3. HYBRID-CLOUD POSITIONING APPEALS TO REGULATED BUYERS. Enterprises with data residency, compliance, and legacy constraints need a bridge rather than a pure public-cloud migration. 4. THE WEAKNESS: Services-heavy GTM can reduce scalability and make revenue dependent on implementation capacity.
| MARKET ENTRY PLAYBOOK
THE STANDARD: Acquisition-led entry is appropriate when time-to-market, talent, technology, or customer relationships cannot be built quickly enough organically. RULE 1 — Acquire only when the target adds a capability the incumbent cannot build or buy separately in time. RULE 2 — Define the integration thesis before closing: shared sales motion, product architecture, and customer workflow. RULE 3 — Retain the acquired technology’s developer and community credibility while simplifying commercial packaging. RULE 4 — Reject acquisition when the target’s technology is easily replicated or its customer base does not overlap with the acquirer’s distribution. Example: Salesforce acquired Slack to extend its workflow layer; failure occurs when acquirers buy technology but leave the acquired product operationally separate.
How to enter
| FOOTHOLD STRATEGY PLAYBOOK
THE STANDARD: A lighthouse customer is a large, credible buyer whose implementation proves the platform can handle enterprise complexity. RULE 1 — Choose a customer with a high-stakes modernization mandate and existing trust in the vendor. RULE 2 — Use the engagement to create reusable architecture, security, and operational patterns. RULE 3 — Convert the lighthouse into referenceable proof for similar regulated or hybrid-cloud buyers. RULE 4 — A lighthouse fails when the deployment is bespoke and cannot be productized. Example: Snowflake used marquee enterprise customers to validate cloud data warehousing; failure occurs when vendors chase logo customers without repeatable implementation.
How to get the first strong position
MARKET PATTERNS & PLAYBOOK
3
MONEY
money rev pri
VMware monetized Tanzu through enterprise subscriptions, term licenses, support, and consulting-led services. Tanzu Standard, Advanced, and Tanzu Platform editions package Kubernetes runtime, developer tooling, registry, observability, and application services into recurring enterprise agreements.
REVENUE MODEL
Subscription, Licensing Fees, Service Fee
PRICING MODEL
Custom Enterprise Pricing, Tiered Pricing, Flat Rate Pricing
WHY THEY WON
Enterprises pay recurring subscription or term-license fees for platform software, support, and entitlements, while Tanzu Labs and partners generate implementation and modernization services revenue. Revenue expands through more clusters, CPU cores, users, environments, and adoption of application-platform capabilities; margin depends on support intensity, services mix, and infrastructure integration complexity.
VMware Tanzu uses Custom Enterprise Pricing and Tiered Pricing across Standard, Advanced, and Tanzu Platform editions, with term licenses and subscription agreements. AWS Marketplace lists Tanzu Platform Self-Managed as a 12-month term license with a minimum 50-pack quantity, reflecting enterprise procurement rather than self-serve pricing.
TARGET AUDIENCE
Large VMware customers (Standard/Advanced; run Kubernetes alongside vSphere estates); Regulated enterprises (Tanzu Platform; security, compliance, and hybrid-cloud control); Platform-engineering teams (Tanzu Application Platform; developer self-service and golden paths); Systems integrators and managed service providers (partner motion; implementation, migration, and managed operations).
CUSTOMER BUYING BEHAVIOUR
A cloud-migration mandate, application-modernization program, Kubernetes standardization effort, or security requirement triggers evaluation. Infrastructure, platform, security, and application leaders evaluate Tanzu through proofs of concept, partner-led assessments, and enterprise procurement; adoption expands as more teams and clusters move onto the platform.
| PRICING INTELLIGENCE
What makes this model effective & make customers pay
Customers are buying continuity through architectural change, not Kubernetes software. RULE 1 — PRICE THE CONTROL PLANE. Enterprises pay for consistent security, operations, and governance across hybrid environments. RULE 2 — PRICE DEVELOPER THROUGHPUT. Paved paths, build services, and self-service environments reduce platform-team bottlenecks. RULE 3 — SELL MODERNIZATION RISK REDUCTION. The platform competes with failed migrations, fragmented tooling, and security exceptions. RULE 4 — VENDOR TRAP: Services-led modernization can create revenue but hide weak product-led adoption and low software expansion. The buyer is really buying an enterprise platform-engineering budget, proven by clusters, environments, developer seats, and supported workloads.
PRICE & REVENUE
| Revenue Risk - The biggest threat to revenue stability
Product-complexity risk is high because Tanzu combines Kubernetes, developer tooling, application services, observability, and modernization services into a broad portfolio. Competitive displacement risk comes from AWS EKS, Azure AKS, Google GKE, and Red Hat OpenShift, which can offer simpler managed or developer-native paths. Hyperscaler dependency risk arises because many workloads run on AWS, Azure, or Google Cloud, where the cloud provider controls the underlying platform and procurement relationship. Services dependence can reduce scalability if modernization revenue relies on consulting capacity rather than repeatable software adoption. Churn and contraction risk occurs when enterprises standardize on a cloud provider’s native platform or reduce infrastructure spend. Funding/valuation: VMware acquired Pivotal for $2.7 billion in 2019; Tanzu is part of Broadcom-owned VMware following Broadcom’s 2023 acquisition, and standalone Tanzu ARR is not publicly disclosed.
Where the model can break
4
MOTION
motion ge cs
Tanzu was sold through VMware’s enterprise sales organization, channel partners, systems integrators, and Tanzu Labs consulting engagements. The buyer committee included infrastructure, platform engineering, security, application development, and procurement leaders, with proofs of concept and multi-year enterprise agreements.
GROWTH EXPANSION MODEL
Acquisition-Led Growth, Platform Expansion
HOW THEY EXPAND
VMware expanded into cloud-native platforms through acquisitions of Heptio, Bitnami, and Pivotal, then integrated those assets into the Tanzu portfolio. Platform expansion added Kubernetes runtime, application services, registry, observability, developer tooling, and multicloud deployment options. The dependency is that each addition must reinforce the enterprise platform workflow; disconnected acquisitions would create portfolio complexity without improving adoption.
COMPETITIVE STRATEGY
Encirclement Attack
HOW THEY COMPETE
Against AWS EKS, Azure AKS, Google GKE, and Red Hat OpenShift, VMware used an Encirclement Attack by combining infrastructure, Kubernetes, developer tooling, security, and services around the customer’s existing VMware estate. Its sequence moved from vSphere-native Kubernetes to application platforms and multicloud operations. The viable resource was the installed enterprise base and hybrid-cloud control point; the constraint was that hyperscalers owned the public-cloud runtime and developer experience.
GROWTH ENGINE
GTM
Content Flywheel
VMware account teams identify Tanzu opportunities inside existing vSphere, NSX, and vSAN accounts. A modernization or Kubernetes initiative activates a proof of concept; Tanzu Labs and partners deliver implementation; successful adoption expands into more clusters, teams, and environments. Platform standardization creates expansion revenue through additional entitlements and application-platform capabilities. The repeatable trigger is a modernization mandate, cloud migration, or platform-engineering initiative. The engine requires enterprise sales capacity, credible reference architectures, and partner delivery; it breaks when product complexity rises, hyperscaler-native alternatives simplify adoption, or services capacity constrains implementation. A founder can reproduce this by selling an architectural bridge to buyers who already trust the incumbent control point.
VMware Tanzu runs an enterprise-sales-led GTM supported by partners, marketplace distribution, and consulting. Existing VMware accounts create discovery; proofs of concept and reference architectures convert interest; Tanzu Labs and systems integrators drive implementation; additional clusters, users, and platform capabilities expand revenue. The primary motion is enterprise sales, with partner-led delivery and marketplace procurement as supporting motions. The transferable components are incumbent account expansion, an architectural bridge, and services-to-software conversion; they require strong integration, enterprise support, and disciplined product packaging.
SUSTAINING MOATS
High Customer Lock-In
moat
The moat is High Customer Lock-In: Tanzu sits on top of VMware’s virtualization, networking, security, and operations estate. Once enterprises standardize Kubernetes, developer workflows, policy, observability, and application services on Tanzu, migration requires re-architecting infrastructure, security, and platform operations.
| MOAT INTELLIGENCE
THE STANDARD: Enterprise platform lock-in lasts when the vendor controls the underlying infrastructure and the operational workflow above it. RULE 1 — INFRASTRUCTURE DEPENDENCE: vSphere integration ties Tanzu to VMware’s existing enterprise estate. RULE 2 — PLATFORM CONFIGURATION DEPTH: Clusters, policies, pipelines, registries, and observability create migration cost. RULE 3 — MULTI-TEAM STANDARDIZATION: Platform engineering, security, and application teams align on one internal operating model. THE SIGNAL: VMware combined Project Pacific, Pivotal, Heptio, Bitnami, Spring, and Cloud Foundry assets into Tanzu, then distributed it through enterprise sales, partners, AWS Marketplace, and Azure VMware Solution. The moat does not protect against customers standardizing on hyperscaler-native Kubernetes or reducing VMware infrastructure spend.
Why this company remains defensible
ARR & TAKEAWAY
ARR Journey - what to do at each stage
PRE-$1M ARR — ASSEMBLE THE CLOUD-NATIVE STACK: In 2019 VMware launched Project Pacific and Tanzu, then acquired Heptio, Bitnami, and Pivotal to add Kubernetes, developer tooling, Spring, and Cloud Foundry capabilities. WATCH: Product integration and portfolio complexity. $1–5M ARR — ESTABLISH THE ENTERPRISE BRIDGE: VMware positioned Tanzu as Kubernetes native to vSphere, giving existing enterprise customers a path to containers without abandoning virtualization. $5–10M ARR — PRODUCTIZE THE DEVELOPER PLATFORM: Tanzu Standard, Advanced, and Tanzu Application Platform packaged developer productivity, build services, registry, observability, and application services. $10–50M ARR — SCALE HYBRID AND MULTICLOUD DISTRIBUTION: VMware expanded through enterprise sales, channel partners, Tanzu Labs, AWS Marketplace, Azure VMware Solution, and Google Cloud partnerships. WATCH: Hyperscaler competition and services dependence. $50–100M ARR — CONSOLIDATE UNDER BROADER PLATFORM STRATEGY: After Broadcom acquired VMware in 2023, Tanzu became part of a broader infrastructure and subscription portfolio, with emphasis shifting toward simplified enterprise packaging. $100M+ ARR — NOT REACHED as a publicly disclosed standalone business; Tanzu-specific ARR is not publicly disclosed. Rule: Use an incumbent control point to enter an adjacent platform layer, then convert acquisition-led capability into a repeatable enterprise product and expansion motion.
COPY PLAYBOOK : What Worked → What Failed → What to Replicate → What to Avoid
THE STANDARD: Enter an adjacent enterprise platform by combining an incumbent control point with acquired capabilities, then convert services-led adoption into repeatable software expansion. SEQUENCE: 1. First, identify the control point—infrastructure, identity, data, or endpoint—that gives trusted access to the buyer; prerequisite: an installed base with platform or security authority. 2. Next, acquire or integrate the missing capabilities and define one integrated workflow; gate expansion on productized deployment, not logo wins. 3. Then, use services and partners to establish reference architectures, then convert adoption into recurring software expansion; prerequisite: repeatable implementation and clear platform packaging. WORKED: VMware’s vSphere integration and Pivotal acquisition gave Tanzu enterprise credibility and a credible hybrid-cloud modernization story. CAUTION: Do not acquire technology without an integration thesis; disconnected products create portfolio complexity and dilute the sales narrative. CAUTION: Do not let consulting become the primary growth engine; services-heavy revenue can hide weak product-led adoption and constrain scalability. LIMITATION: VMware does not publicly disclose standalone Tanzu ARR, churn, gross margin, or customer concentration; acquisition and product milestones demonstrate strategic intent but not verified revenue quality.
bottom of page