Platform engineering

As explained in Platform Engineering on Kubernetes

Platform engineering is the discipline of designing and operating internal platforms that provide reusable capabilities and streamlined workflows for software delivery teams.

Platform engineering designs and operates internal capabilities that help development teams deliver software efficiently. The platform team treats developers as internal customers: it selects and integrates tools, defines useful workflows, and automates the path from a code change to production. The aim is not to make every developer learn the tools and glue code behind that path. section 1.0 section 1.3 section 1.2.1

A practical platform takes shape through a sequence of decisions:

• Identify the workflows application teams need, then agree on a clear contract for what the platform provides. Expose that contract through APIs usable by automation, a dashboard, or other tools. section 1.2.1 section 9.5
• Select and integrate existing tools where they fit. Weigh glue code, extensions, and tailored implementations against the cost of maintaining custom tools. section 1.2.1 section 9.5
• Create a golden path that validates changes and moves them toward production. Automate the work after a developer makes a change, rather than leaving each team to assemble its own delivery process. section 1.3 section 2.5
• Measure whether new capabilities actually improve the experience, and revisit decisions as teams’ needs and available tools change. section 1.4.3 section 9.5

On Kubernetes, a platform can expose Kubernetes-style declarative APIs, an organization-specific API, or both. Reusing Kubernetes APIs gives compatible cloud-native tools an integration point; an additional API layer can follow company standards. How much Kubernetes detail developers should see is a design choice, not a requirement that every team work directly with Kubernetes. section 6.2 section 1.2.1

Walking-skeleton delivery path

Run a small, multi-service Conference application in a Kubernetes cluster and install it with Helm. Then trace the work needed to build service artifacts, promote versions through environments, and handle runtime failures. This exposes where the platform needs pipelines, safe working environments, and higher-level capabilities rather than another disconnected tool. section 1.0 section 1.4.3 section 2.5

Figure 6.7 Kubernetes-based platform APIs complemented by company-specific APIs

Compare a Kubernetes-based platform API with a complementary company-specific API layer; the two approaches need not be exclusive. section 6.2

How Platform Engineering on Kubernetes covers it

How deep it goes

Works through tool integration, API-layer trade-offs, and a walking-skeleton delivery path, but leaves custom Kubernetes controllers outside the treatment.

Examples

Uses a multi-service Conference application, Helm installation, service and environment pipelines, and an environment-request API design.

What it assumes

Assumes familiarity with Kubernetes, containers, and cloud-native applications; develops platform decisions around their delivery and operational challenges.

What you can do after

Build it from scratch by selecting reusable tools, defining platform APIs, automating delivery workflows, and measuring whether changes help teams.

How it connects

Connects platform APIs, Kubernetes, golden paths, continuous delivery, GitOps, and self-service capabilities.

liveBookmanning.com

Read Platform Engineering on Kubernetes on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Effective Platform EngineeringAn engineering platform is an internal development-oriented product that provides teams with self-service access to tools, infrastructure, and cross-functional capabilities while incorporating organizational requirements.

Compare how 2 books explain platform engineering →

Related concepts

• contractuses · An API contract is a specification of the operations, data, and behavioral expectations that govern interactions between software components.
• self-serve platformproduces · A self-service platform is an internal platform that enables users or teams to provision, deploy, operate, or consume capabilities without manual assistance from platform staff.
• domain-driven designuses · Domain-driven design is a software design approach that centers models, structure, and terminology on the concepts, behavior, and boundaries of a problem domain.
• internal developer platformincludes · An internal developer platform is an organization-provided system of self-service interfaces, automation, abstractions, and reusable capabilities that supports software development and operation.
• test environmentproduces · A test environment is a configured computing context, including relevant software, infrastructure, data, and settings, in which software is tested.

This explainer was generated by Manning's knowledge graph from the text of Platform Engineering on Kubernetes. The section links point to the parts of the book it draws on.