Understanding abstraction layers in platform engineering

"Abstraction" is a concept that's thrown around a lot in platform engineering, but its meaning can often get lost in translation. It's easy to fall into the trap of thinking that slapping a portal on top of your tangled tech stack solves everything. However, the reality is far more nuanced. There's a whole world of considerations beyond just a pretty interface.

Ultimately, the goal is to shield users from the complexities of the underlying systems, and there are a multitude of approaches to achieve this. Let's explore some of these strategies.

What is an abstraction layer?

According to Gregor Hohpe, at its core, an abstraction layer is a way of providing a higher-level vocabulary that shields users from the underlying complexity. A good abstraction generalizes or removes details to focus on what truly matters. 

In contrast, an illusion removes or generalizes essential things that can cause people to be misled. Platform engineering aims to build abstractions responsibly, which means only abstracting when the "why" is clear, and there is a legitimate impact from creating the abstraction.

Front-end vs. back-end abstractions

Abstraction layers can be broadly categorized into front-end and back-end abstractions.

Front-end abstractions focus on user experience and ease of use. They are designed to display information and handle multiple aspects of one thing simultaneously. Key design principles include:

• Visual interfaces such as charts and graphs, instead of tables
• Low-code or no-code interfaces, with simple commands and sane defaults
• Ease of use, making it a no-brainer for users to adopt the abstraction layer
• Collaboration, making one persona's input layer a multi-persona problem. For example, a developer interface might include cost information.

Examples of front-end abstractions include:

• Portals: User interfaces like Backstage, Cortex, or Port that present a lot of information in one context, making it easily accessible.
• CLIs: Command-line interfaces such as the Heroku CLI or GitHub CLI.
• Declarative configurations: Tools like Score, Radius, and Kubevela.
• Natural language interfaces (NLI): Using AI to generate human-readable responses to user requests.
• Data abstraction layers: Using portals to build dashboards to visualize data for financial, management, and executive stakeholders

Back-end abstractions, on the other hand, are about automation and standardization. They handle how to use something and its lifecycle. Back-end abstractions manage a single aspect of many things at once, using automation to handle a layer of standardization. Key concepts include:

• If developers are not required to supply configuration details, the platform needs to fill these gaps with standardization layers
• Avoid falling into “TicketOps” anti-patterns when possible; if it doesn’t need hands-on human intervention, find a way to standardize and automate
• Self-service fails without standardization
• Good automation is based on layers of standardization
• Standardization will not be impactful without automation built around it
• Fleet management fails without quality standardization and automation

Backend abstractions should also provide a logical abstraction layer for infrastructure, including an abstraction from Infrastructure as Code (IaC) itself. This means that the requests and specific pieces of infrastructure need to be decoupled from the IaC to prevent an increase in cognitive load.Examples of back-end abstractions include unified platform APIs or Platform Orchestrators like Humanitec, Kratix, or to a certain degree also Radius, which supply missing details and fill in the gaps. As Thoughtworks defines it, Platform Orchestrators are tools to “enforce organizational standards while granting developers self-service access to variations through configuration”.In summary, backend abstractions aim to reduce complexity for platform teams, I&O, and security by enforcing consistent configurations and processes and for developers by providing the layer that developer-facing interfaces can build upon.‍

The role of golden paths‍

Abstraction layers are also key components of implementing golden paths. A golden path is an ideal way for a developer to perform a task, with the platform taking care of the underlying complexity. For example, instead of having developers copy configuration files and provision infrastructure on their own, a platform should provide a self-service interface where a developer can simply request a Postgres database, without having to worry about the implementation details. The platform then resolves that request using predefined templates and rules.Golden paths must also consider how different teams within an organization use a platform. For instance, some parts of a platform team will focus on improving DevEX through good self-service flows, while other parts of the platform team will focus on making sure the platform works with existing infrastructure and operations.‍

Conclusion‍

Abstraction layers are a crucial part of platform engineering, providing a way to manage complexity and enable developers to focus on delivering value. By carefully distinguishing between responsible abstractions and misleading illusions, and by designing abstractions with user experience in mind, platform engineering teams can build internal developer platforms that are truly effective and that help developers adopt the golden path.If you want to learn more about best practices around abstraction layers for your own organization, take a look at the Platform Engineering Fundamentals course. Or upskill your whole team in one go with Trainings.