Why companies build their own cloud control planes

Many companies end up creating their own cloud management control planes on top of their cloud provider's management APIs.  These homegrown management systems provide a central location for provisioning cloud services, for configuring SaaS offerings. They also interact with corporate compliance and control systems like artifact inventories and data catalogs.

What drives companies to this effort and expense?

Video Walkthrough

Self Created Cloud Control Plane

Companies create their own API and Web UI-driven control planes as proxies for their cloud provider, their SaaS provider, and any internal providers that must be communicated with as part of infrastructure provisioning and deployments.  
  • Manages the company's cloud resources
  • Categorize those resources for compliance and budget
  • Coordinates unified deployments and configurations across other control planes
  • Logs configuration and deployment activities
  • Enforces infrastructure and code deployment standards
  • Provides for a central reporting and audit location

The cloud democratizes access to capabilities

  • Access makes it possible for any team to use any capability without requiring expertise in installation and configuration.
  • Rapid prototyping and development is possible. 
    • This tends to make everything a one-off making it harder to know-how things work across systems.
  • Uncontrolled _you build it you own_ it means confident teams can accelerate.
    • This can result in you built it you left it where there is a raft of projects that are all one-offs with respect to infrastructure configuration and management techniques.
  • Teams can use services without having to learn all the subtleties of a particular product configuration. It breaks the product guru stranglehold
  • Auditing and compliance costs increase because each product has to be learned by the audit and compliance teams.

The enterprise control plane response

Companies create a choke point for all cloud configuration invocations.
  • It provides a one-stop-shop to find resources.
    • People can't use a service if it hasn't been wrapped into the control plane catalog.
  • Cloud, third party and compliance functions can be orchestrated without much caller intervention.
  • Complex multi-component deployments can be wrapped and radically simplified.
    • A standard invocation can create compute, storage, monitoring, and networking that meet the company standards with a single call.
  • Every application can have the same standard cross-cutting concerts, monitoring, metrics, data protection, security, and routing, etc.
  • The control plane acts as a simplifying proxy.
    • Users have to wait while the control/plane adds new services or new parts of services to its catalog
    • Catalog developers can be reticent to support many paradigms that are supported by the underlying technology.

Protect the Sandbox

The company still needs to innovate.  Development still needs a place to learn and evaluate.  There should be a sandbox environment that its outside the usual SDLC and controls.

Create 9/2021


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs