Part 1: How to Build the Fourth Cloud MVP — The Four Non-Negotiable Pillars

TL;DR: The Fourth Cloud isn’t a platform you buy; it’s an operating model you build by surgically adopting four non-negotiable pillars.

The request came on a Tuesday afternoon. I was running SAP infrastructure for one of the world’s largest pharma companies when a product team asked for a new SAP landscape to test a critical idea. The problem? Every environment meant $200,000 in new hardware and weeks of procurement, racking, and virtualization—before we even touched SAP itself.

That’s the core tension the Fourth Cloud exists to resolve.

The business demands cloud speed—minutes to provision a complex environment. IT is stuck delivering data center sprawl—months of CapEx budgeting, ticketing, and manual configuration.

Every enterprise wants the elasticity and developer experience of public cloud—the self-service APIs, the speed of iteration—without the loss of financial control and operational predictability that comes with handing the keys to a hyperscaler. Too often, the first move is to buy a massive vendor platform and call it “transformation.” It’s a familiar mistake: trying to purchase an operating model instead of building one.

That experience taught me something simple but profound: the bottleneck wasn’t infrastructure—it was our operating model. We didn’t need more hardware. We needed a platform.

The real journey begins with a Minimum Viable Platform (MVP) Core—the smallest integrated slice of technology that proves you can deliver a repeatable, cloud-native experience on your terms. It’s a working product that changes developer behavior and earns trust from operations.

The Four Non-Negotiable Pillars of the MVP Core

For the MVP, your most strategic move is to decouple the foundational components you must control from the undifferentiated heavy lifting you can buy. The goal is not just to replace the physical hardware, but to eliminate the manual, multi-week process it required.

The MVP is built on four non-negotiable foundational pillars that deliver the cloud operating model: Run-time API, IaC, IAM, and Observability.

Pillar 1: The Run-Time API (The Universal Control Plane)

The true power of the cloud is the self-service abstraction layer. Your run-time must provide a standard, extensible API for managing any resource.

• The Perspective: The run-time is not about containers; it is about the API and the control plane. Kubernetes isn’t your goal—it’s your grammar. The universal API is what lets virtual machines, containers, and future workloads speak the same operational language. This is the key to managing legacy (like your SAP VMs) and cloud-native workloads together.
• The MVP Tactic: Buy the Control Plane and its Abstraction—Surgically. The complexity is in managing the API layer itself. For this first step, strategically buy this API control plane:
  • The Lean Start: Use managed services like Amazon EKS, Azure Kubernetes Service (AKS), or Google Kubernetes Engine (GKE). This is the cleanest path to proving the API concept.
  • The Enterprise Trade-Off: Solutions like VMware Cloud Foundation 9 (VCF9) or Red Hat OpenShift package the necessary control plane components. But be warned: these are big, complex systems. Your MVP team’s job is to be surgical—identify the exact components that deliver the API abstraction and actively avoid the rest to prevent being crushed by complexity.

Pillar 2: Infrastructure as Code (IaC)

A platform without automation is just hardware. The point of IaC is to prevent that multi-week manual setup for your SAP landscape from ever happening again.

• The Perspective: Terraform is less about automation and more about accountability. It forces your infrastructure to live under the same version control discipline as your application code. This is how you gain an auditable, repeatable deployment process that takes minutes, not weeks.
• The MVP Tactic: Standardize on Terraform (or Tofu). Use HashiCorp Terraform to define your environment. The recent fork means OpenTofu (Tofu) is a viable, open-source alternative you may choose for long-term consistency. Regardless of which tool you select, your IaC must be tightly scoped to provision three things: the managed Kubernetes control plane, the underlying network, and the essential IAM roles. Anything not codified in Git is organizational debt.
• Governance Next Step: Tie this IaC process to your application deployment using GitOps (Argo CD or Flux). This ensures that the only way to deploy or change an application is by making a pull request—a workflow that delivers security and auditability by default.

Pillar 3: Identity and Access Management (IAM)

IAM is the critical intersection of security, compliance, and user experience.

• The Perspective: IAM is not just an integration problem—it’s a trust problem compounded by a capability gap. AWS IAM set the gold standard for granular, role-based ACLs for machine-to-machine communication. The challenge comes when you try to replicate that maturity inside your own walls. A ten-year-old application that ran perfectly in AWS often breaks in a private environment because it can’t assume the same fine-grained roles. Your MVP must explore and define that gap—and close what you realistically can.
• The MVP Tactic: Define a Repeatable Machine Identity. Your primary goal is to solve machine identity. Migration fails when a VM can no longer assume a granular role.
  • Federate, don’t reinvent. Manage who (humans) in your IdP; manage what (workloads) through the control plane’s RBAC.
• The Governance Win: This approach forces you to define a standardized, repeatable security posture for workloads.

Pillar 4: Observability

You cannot manage what you cannot see. The data streams from your platform are your only reliable source of truth.

• The Perspective: Observability closes the feedback loop—but only if you wear two hats. As a cloud consumer, you need to monitor application health and API call success rates. As a cloud provider, you need to track resource consumption and health (IOPs, network saturation). A mature platform delivers both views.
• The MVP Tactic: Start with Native Tools. For the MVP, prioritize function over feature. Leverage the native tools your platform offers (e.g., CloudWatch, or OpenShift/VCF built-in monitoring) to establish a baseline for foundational visibility.
• Evolve Strategically: Once your platform team masters the operational process, then you can graduate to a full open-source stack (Prometheus/Grafana) or a commercial platform, but only if the native tooling proves insufficient for your business needs. Don’t let an observability project sink the entire MVP.

Reflection: The Organizational Shift

The decision to adopt the Fourth Cloud is a decision to build a product. Your Platform Engineering Team is the team that manages that product. Their customer is your internal developer community. Their mandate is to build the “paved road”—the high-level abstractions and automated pipelines—that make it easier for developers to build and deploy applications on your terms than on a hyperscaler’s.

The MVP isn’t the finish line. It’s the first time your developer stops asking, “When will infra say yes?” and starts using your platform to provision a new environment in minutes, not months. That single moment of behavioral change is the true business value of the Fourth Cloud.

That’s the moment the Fourth Cloud stops being architecture—and starts becoming culture.

What’s Next in the Series?