DevEx is a Primary Goal of Platform Engineering
At Liatrio, we're all about elevating the Developer Experience (DevEx). We work with enterprise platform teams to provide DevEx capabilities through purpose built platforms and self-service products. With Internal Developer Platforms (IDPs) and APIs playing a crucial role in modern Developer Experience, let’s look at how Platform Engineering, through solutions like Backstage by Spotify and other internal platforms, not only enhance DevEx but also act as accelerators for software delivery.
Platform Engineering, carrying the torch of DevOps, is about removing barriers between developers and production, providing a paved path from idea to prod deployment. The goal is to significantly improve Developer Experience by automating and abstracting away repetitive tasks, allowing developers to focus on what they do best: building software.
The Critical Role of Internal Developer Platforms
Internal Developer Platforms (IDPs) have become a focus of Platform Engineering because they have a daily impact on developers. IDPs are designed to support developers by providing a unified and streamlined environment for software development and deployment. By centralizing tools and services, IDPs minimize the cognitive load on developers, enabling them to operate more effectively and efficiently.
Backstage by Spotify is a prime example of an IDP that dramatically enhances DevEx. It empowers teams by organizing software components, managing projects, and facilitating easy access to internal tooling, all in one place. This consolidation accelerates the development process, encourages best practices, and enables a more collaborative work environment.
Backstage gives teams a catalog of self-service Templates that provide access to environments and tooling, starter-kits for new applications, and paved-paths to production. This image below has just a few examples of what we have at Liatrio to help our engineers get started on a new project. Our team spends a good amount of time automating a number of things and Backstage gives us a “single pane of glass” (ok I hate using that term but it applies here…) to help ensure once we’ve got a standard in place, it gets used. That’s huge in an organization where we support dozens or hundreds of customers.
If we can save time and quickly build POCs, iterate on new ideas, maintain existing projects, or help accelerate onboarding within our team or with our customers, these templates often pay for themselves the first time they’re used.
Building Products for Development Teams
Platform Engineering focuses on bridging the gap between what developers need and what the organization requires for delivery. IDPs are purpose-built products for each organization’s delivery process with the understanding that developers are the customer. It's not just about having tools; it's about making those tools accessible, understandable, and effective for the teams that use them. IDPs and platforms like Backstage are built to be accelerators for delivery, enabling rapid iteration and reducing time-to-market for new features or products.
For example, a large majority of enterprise platform and delivery teams manage access and secrets for a number of things. IT organizations often see this done a number of ways, contributing to “secret sprawl” or other configuration challenges. When there is a common need like this that needs to be offered “as a service”, we can build standards into the Backstage template that ensure it’s done the right way. Our team uses HashiCorp Vault to manage secrets so we’ve built a template that integrates Backstage with Vault and our internal Kubernetes environment to provide teams with everything they need to manage their application’s secrets securely in every environment, without separate tickets or the need for additional access to production environments.
By bringing the important security features, governance and compliance capabilities required in many enterprise organizations to the platform, we are able to help teams adopt standards much earlier than they would have otherwise. The attention to shifting these capabilities left allows developers to rely on their platform to offer a safe and secure path to production for their applications.
APIs: The Backbone of Internal Platforms
APIs Drive Collaboration
IDPs are a great way to provide a user-friendly entrypoint to the capabilities and services your teams provide, but they’re not the only platforms that need to be built. APIs (Application Programming Interfaces) are the lifeblood of internal platforms, enabling components to interact easily and data to flow freely between tools and services. They support a culture of self-service, allowing teams to adopt and integrate tools without extensive setup or configuration efforts. Platform teams establish APIs as service contracts for their products and provide their customers - developers and other platform teams - with first-class user experience.
APIs play a crucial role in facilitating collaboration on internal platforms by enabling ease of interactions among various tools, services, and teams within an organization. The capabilities like security, observability, governance, and CI/CD these platforms provide are all integrated via APIs. They allow these different systems and services to communicate with each other, regardless of their underlying technology. This interoperability is essential for building integrated platforms where different components work together seamlessly, sharing data and functionality without compatibility issues.
Documentation is a Must
A prerequisite to APIs is providing documentation to support your platform. Regardless of the maturity of the platform, creating useful documentation is a fundamental need. Platform engineers must provide documentation and keep it up to date. One of the biggest needs of a platform is ease of use and documentation is part of the product.
The “Thinnest Viable Platform” may be a wiki page or a repository of markdown files that explain how to access platform capabilities. Some tools don’t offer an easily accessible wiki page or API documentation, and if that’s you, go to the end of the line. If you don’t make sure your documentation is easily accessible, and better yet open for pull request recommendations or changes, you aren’t supporting a positive Developer Experience.
API Documentation Examples
Here is a quick list of examples of API documentation from several popular DevOps platform tools. This is how they make key functionality available, from continuous integration and deployment to monitoring and configuration management. These functions provide access to various operations that can be performed programmatically, enhancing automation and integration capabilities. API documents like these provide comprehensive guidance on how to use the respective APIs, including details on endpoints, parameters, authentication methods, and examples:
- Backstage API Docs - This page provides information on how to interact with the catalog entities, including listing, creating, and managing components.
- GitHub Actions API Docs - Detailed API references for managing GitHub Actions, including workflows and runs.
- GitLab CI/CD API Docs - This section of the GitLab documentation covers the API for pipelines, jobs, and other CI/CD capabilities.
- Kubernetes API Docs - Provides comprehensive API documentation for all Kubernetes resources, including pods and services.
- Terraform Cloud API Docs - Official documentation for the Terraform Cloud API, detailing workspace management, runs, and more.
- Datadog API Docs - Full documentation for all Datadog APIs, including creating monitors and querying timeseries data.
- Snyk API Docs - The official API reference for Snyk, covering project management and vulnerability reports.
- SonarQube Web API Docs - SonarQube's Web API documentation, useful for automation and integration with other tools.
Building Platforms Into the Culture
Self-Service Features and Innersourcing
A huge advantage of internally built and managed platforms is their self-service capabilities. Self-service features empower developers by providing them with immediate access to resources, tools, and environments without the need to go through lengthy approval processes. This autonomy enables developers to innovate and experiment independently. Innersourcing complements this by offering a framework where developers can contribute to and leverage each other's projects and solutions. When developers are not only given the tools they need but also the freedom to explore and contribute to a broader range of projects, it significantly boosts their engagement and overall sense of ownership.
Team Topologies for Platforms
Platform Engineering won’t be successful if we don’t also look at aligning the team and org structure for this new way of working. Team Topologies offers guidance around organizing platforms and improving flow for development teams. By defining clear team interactions and minimizing cognitive load, moving toward a Team Topologies model ensures that platform efforts are focused, impactful, and aligned with the broader goals of the organization while improving Developer Experience.
Conclusion
Platform Engineering, supported by IDPs and exemplified by tools like Backstage, is a game-changer for Developer Experience. Through the use of APIs, self-service features, and organizing our teams for improved flow of value, these platforms are not just tools but accelerators for delivery, enabling teams to innovate quicker, with higher quality, and with greater satisfaction in their work. At Liatrio, we're passionate about bringing these benefits to your organization, transforming the way digital products and services are delivered.
