Today’s developer expects friction-free access to infrastructure. In the public cloud, if a developer needs a Kubernetes cluster, a virtual machine, or a database, they simply press a button or an API call and the resources are ready in minutes.
But what happens when data sovereignty, compliance, or cost predictability dictates that these workloads run on-premises?
Historically, on-prem infrastructure meant submitting IT tickets and waiting days or weeks for provisioning. This delay often creates a major bottleneck for time to market. Frustrated by the queue, developers sometimes spin up their own “shadow IT” databases on unmanaged VMs just to move faster. The result? A massive headache of database sprawl, configuration drift, lack of governance, and significant security risks.
Today, platform engineering on VMware Cloud Foundation (VCF) has changed the game. By leveraging the VCF private cloud platform, organizations can bridge the gap between IT operations and development teams. VCF delivers a true “platform-to-data” self-service experience equivalent to public cloud, giving developers the speed they crave and platform engineers the centralized fleet management they require.
To understand the power of VCF as a private cloud platform, it helps to map its capabilities to the public cloud services developers already know. If you are familiar with how to build on AWS, the on-prem VCF equivalents will look like this:
By combining these three pillars, platform teams can offer a comprehensive, API-driven catalog of services directly from their own data centers.
The magic of this architecture lies in the persona-based governance. As a system administrator or platform engineer, you define the “guardrails” and maintain control, while the developer consumes the resources within those boundaries.
Here is how the workflow operates.
1. Creating the boundary
The infrastructure admin creates a vSphere namespace in VCF. This namespace acts as the tenancy boundary, binding compute, memory, and storage limits to a specific project or development team.
2. Defining the infrastructure and policy
On this namespace, the platform engineer defines the rules of engagement:
Once the admin has set the policies, the platform engineering can deploy these services and from there the developer experience is seamless. The platform engineer hands access over to the development team via a secure API token. From this moment on, they are entirely self-sufficient.
No more waiting for tickets to be cleared. Using standard Kubernetes tooling (like kubectl), the DSM portal or API, or their own Terraform pipelines, developers can:
Crucially, these self-provisioned resources automatically comply with corporate backup, networking, and security policies established by the admin.
Automation and Infrastructure-as-Code Integration
This entire environment setup can be automated using Infrastructure as Code (IaC). The platform team can consume these namespaces and service configurations via multiple options based on the preference of the teams. It could be deployed through Kubernetes CRDs, a Terraform manifest, or an enterprise blueprint that can conclude comprehensive set of resources like a VKS cluster with a set of VMs, data services from DSM, and even ArgoCD to push apps to the VKS clusters all within one set of API calls.
Here is an example of a CRD to deploy a database in the namespace declaratively to show how simple it is. This CRD can be used as part of a GitOps operation:
Perhaps one of the most significant advantages of this platform approach, specifically with Data Services Manager, is that it doesn’t stop at the initial “push button” deployment. It automates critical Day 2 operations once the application needs to hit production. Operations that typically drain DBA resources are now done in a simple click of declarative parameter change in a CRD:
Creating a self-service catalog from platform to data doesn’t require moving everything to public cloud. By utilizing VCF, VKS, and DSM, organizations get the agility of the public cloud with the security and control of their own private infrastructure.
With these features, platform engineers transform from IT gatekeepers into enablers – providing developers with the API endpoints, Kubernetes clusters, and managed databases they need to build software faster, more securely, and be ready for production.
Subscribe to get the latest posts sent to your email.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。