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

The role of golden paths

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.

This article was written by Mallory Haigh at Humanitec on Platformengineering.org