DevOps Architecture: Engineering Platforms

Platforms help to minimize engineering friction which, in turn, enables rapid delivery of value to customers. Successful platform architectures occur at an intersection between Engineering, Business and People balancing the priorities of each in service of supporting rapid delivery of value to clients. Platform Engineering is very much closely aligned with software delivery and can be though of as “DevOps Architecture”. Platforms rapid iteration, the enforcement of organizational best practices and within policy and cost constraints. This is a collection of articles focused on Platform Engineering, covering: Strategies, Patterns, Goals, and Implementation. This first article covers what a platform is, why it’s essential and some of the most common components in platform architecture.

What is a platform?

Platforms enable an organization to deliver software. Platforms are composed of the technical capabilities of an organization to deliver value to its customers. The key aspect here is delivery this is a very active process which includes all the technical steps of turning an idea into something useable by clients:

The platform is a portfolio of capabilities in order to minimize the time a team spends in delivering non-differentiating value to clients. A platform is not Kubernetes, Docker, Functions as a Service or any other specific technology. Each of these are implementations are specific pieces of a platform, which an organization may employee to better meet their software delivery needs.

Platforms encode organizational policies and best practices and minimize the friction involved with compliance, security and other essential non-functional requirements during the delivery of software. The platform is how an organization develops and ships software.

Why a Platform?

Platforms are necessary in order to make software usable by clients. In order to illustrate the value of a platform, first consider what engineering at an organization without an explicit platform might be like: There are many ways of doing things. Each team may have its own way to deploy, develop or maintain their solutions. There is a fractured ecosystem which incurs a huge cost to switch between projects, maintain services and develop software. A missing platform is often characterized by duplication. It’s difficult to update, develop, or deploy software. There may be numerous different ways or patterns to develop and deploy code.

Contrast this with an explicit platform; where there are a handful of approved ways to deploy, and develop. Common requirements are abstracted and available to be incorporated in projects with minimal effort. Common elements shared between services (storage, compute, networking, testing) are available for all teams. Creating a new service has a clear pattern with tooling to minimize the time from idea to delivery. Because there is an explicit platform it’s easy to find resources. Teams spend minimal time having to develop non-feature code.

If you can’t identify your organizations platform it’s inherited. As long as software is being developed and delivered their is a a platform. The issue with inheriting a platform is that the provider is most likely not aligned with your business or structure. For example consider a cloud provider such as AWS or GCP. If no explicit platform is provided teams could end up with vastly different deployment, security, testing, and build environments. It’s the responsible of an organizations Platform to impose order on top of this, and to provide teams with simple, low-effort ways of delivering value to their clients.

Platforms enable continuous delivery. Curating and carefully planning a platform can enable huge speedups and massive cost savings. In essence platforms support:

• Standardization
• Velocity — Through Minimizing Non-differentiating Work
• Codify/Enforce Policies
• Abstraction/Encapsulation at the Team Level

An intentional platform is composed of carefully curated primitives and services that teams can orchestrate to deliver business/client value. Platforms can minimize overhead and duplication and providers default actions that enable teams do things the right way without any extra effort. Platforms can maximize the amount of time team spend creating business logic by minimizing all other non-business related actions and requirements.

An Analogy

Software platform is very similar to a train (which even extends to sharing terminology! ie “platform”).

Cost

Cost of a train is objective and well understood. Similarly a software platform aims to provide the business with a well understood cost for how much software will deliver, a good platform will make software delivery costs predictable in terms of both money and time (effort).

Boarding/Train Platform

Trains provide very explicit rules around where a user engages with the train. In many metropolitan areas, these are enforced through fences or physical barriers. This makes the engagement point between a client (rider) and the platform (train) explicit. Boarding and engagement with the train happens and very explicit places. Similarly a platform should provide explicit clear engagement points for its consumers.

Conductors

After boarding the train the rider grants a level of control to someone else who is more knowledgeable in the operation of the train. This creates a clear and distinct separation of responsibilities and inverts control to a person/team who is more knowledgeable. Similarly a software platform should abstract complexity from its clients in order to enable them to focus on their specific business domains and the delivery of their software. Software platforms can achieve this through judicious application of encapsulation, abstraction and appropriate component boundaries and alignment.

Tracks

Tracks simplify operation and provide a clear path, they provide a default action, and helps to ease operation by minimizing choices. Like a train a software platform should optimize for ease of operation. A trains travel is explicit and easy to understand. Similarly a software platform should enable clear, explicit and easy to understand delivery of software. It should strive for correct by default. Like train tracks a platform should support rapid delivery of software, with constraints.

Ticket Kiosks

Self service kiosks allow for riders to travel great distances at known costs with minimal interaction from a train team. Outside of getting tickets checked (enforcing policy) a rider might not need any engagement or interaction from the trains employees! Similarly a platform should minimize intrusion and friction but still enable teams to largely deliver value on their own.

Platform Primitives

There are four common architectural primitives for building platforms:

• Libraries: Encapsulate/Abstract Language-level Functionality.
• Frameworks: Promote Application Level Structure
• Services: Encapsulate/Abstract Functionality with process (or stronger) isolation. The atomic unit of execution that a platform can provide.
• Substrates: Collection of heterogeneous services, exposes workflows that potentially involve orchestrating multiple services. These are things like: CloudFormation, Kubernetes, Terraform, etc. Substrates provide powerful abstractions, consider everything that needs to happen when a “simple” web service deploy takes place, health checks, process management, LB registration, Service Discovery entries, etc.

Each layer can be thought of as providing the organization with a higher level of abstraction. The higher the level the lower the integration cost relative to the scope of features that each level provides decreases at each level:

These are the four architectural primitives for platform engineering, The architectural primitives are in terms of integration costs with respect to the amount of features provided. A library may offer a feature team a thin slice of functionality, whereas a service may encapsulate a larger business function. Finally, the substrate may offer workflows across multiple services. Each one of these layers should provide the organization with an increasingly large functional offering.

The relationship of each component can be seen below:

Libraries and Frameworks are scoped to a service, and substrates are composed of (potentially) multiple services. Libraries may be utilized directly by a service or ship with frameworks. Service is the smallest unit of executable functionality available in a platform.

Contents

(This page will be updated as new posts are released)

Portfolio Of Capabilities

• Delivery
• Key Capabilities
• Key Performance Indicators

Platform Primitives

• Libraries
• Frameworks
• Services
• Substrates
• Scaffolding

Implementation Patterns

• Libraries
• Frameworks
• Services
• Substrates
• Scaffolding

Application Workload Patterns

• Service (Request/Response)
• Batch
• Streaming

Architectural Strategies

• One is better than n
• Invert dependencies with self service
• Evolutionary Design Through Shepherding

Architecture Examples

• Logging
• HTTP Service
• Streaming Service
• Self-Service CI
• Rampant Duplication
• Why go to the library when someone else can go for you?

About Me

My name is Danny and I love DevOps, lean, process efficiency and their intersection with people, clients, and technology. I have one successful org-wide platform architecture under my belt; resulting in $100’s of thousands of (positive :P) impact achieved through process efficiency savings. This was largely a result of 2 hour deploys -> 5 minute deploys for 20 services and a team of 30 distributed engineers. I really enjoyed the experience and these articles share some of the successes I had. I really appreciate your time! The whole process took about 3 months, by a team of 3, and was guided by the engineer experience and business capabilities. I found that it was much easier to compare options when orienting towards the business and internal clients instead of on any specific “platform” technology.

I try to characterize and describe this methodology here, in an easy to understand, implementation agnostic way. I hope that being open to implementation, by focusing on outcomes, will make your platform journey smoother, more effective and help to keep solutions pragmatic and open minded!