New to Platform Engineering? Try a Thin Self-Service Layer
As more companies evaluate whether they should jump into platform engineering, one of the biggest questions lies in where to get started. Setting out to build an internal development platform can be a daunting task: the Cloud Native Computing Foundation white paper on platforms identifies 13 capabilities ranging from development environments and APIs to observability and artifact storage. Therefore, understanding what to build is a task in itself.
That’s why thinking about your platform as a continuously evolving product rather than a project with an end-state is recommended. However, not everyone has the luxury of being able to put together a whole product team for an internal initiative right from the beginning. What to do then?
Relativity, a legal-tech scale-up, catapulted its platform into the big leagues starting with a single self-service action that reduced a process that had taken weeks to a few hours. Instead of re-architecting its infrastructure and services, the team created the internal developer portal as a thin layer on top of the existing platform.
Enabling self-service capabilities through a thin layer on top of what you already have is a great way to validate your platform potential and start generating value rapidly. The benefits of this lean approach are two-fold: You provide hard value to your developers, driving the adoption of your platform organically. And you can provide hard numbers to your stakeholders, opening the door to larger initiatives.
Self-Service and Golden Paths
Skipping the ticket dance between developers and DevOps when requesting infrastructure is at the core of the promises of platform engineering. But self-service capabilities go beyond granting access to resources. Self-service is often the perfect avenue to offer golden paths that can help consolidate practices and reduce the cognitive load on developers.
Providing developers autonomy to choose their own tools can boost their creativity and productivity. However, in a world that is continuously shifting left, this means that developers have to figure out how to integrate CI/CD, QA, security and other concerns into their code base. On the other end, this dynamic leads to DevOps and system admins that need to support fragmented stacks. Both sides end up re-inventing the wheel over and over, risking security and compliance slips, and eventually facing burnouts.
Self-service capabilities can mitigate this situation for developers and operators. Through golden paths, the development teams get access to bullet-proof ways of building apps and can focus on developing business value rather than rewriting deployment setups. Plus, it makes sense to focus on providing self-service capabilities that have best practices baked in or you run the risk of having to deal with underperforming apps and resources en masse.
Dev Portal: A Thin Layer on Top of Your Platform
In object-oriented programming, the facade pattern is used to abstract a more complex structure behind a class that exposes limited and scoped functionality. In a way, the ticket system used by devs and DevOps is an example of a facade pattern: the complexity of the platform is masked behind a passive-aggressive chat.
Instead, a Backstage-based developer portal can be used as a facade for the platform. A dev portal can offer several benefits, but I want to focus solely on what powers self-service: software templates.
Software templates in Backstage (also known as the scaffolder) are written with YAML using a GitHub Actions-like syntax. They let you define inputs that the user must fill in in order to run the template, and then specify the steps to be executed. Typically, you can start by copying a boilerplate repo or code fragment and then run actions across several cloud services, such as registering a service in PagerDuty or executing Terraform scripts.
Standing up Backstage to use its software templates only can be simple even if you self-host it, and trivial through a managed Backstage solution like Roadie.io. With the scaffolder, you can have a single point of entry for your developers to find self-service options, or even for DevOps to bring together their processes under a unified UI.
Self-Service Is About Politics
Putting together a unified portal to aggregate various tools through the scaffolder is a relatively low-effort initiative. You don’t need a massive budget or face complex technical problems to get started. Where you’ll find the most work and challenges is in defining and implementing specific self-service actions.
The first step is identifying the low-hanging fruits: Which processes are creating the most pain for your developers and operators? If you can’t do a formal UX study on your software delivery life cycle, take some time to talk with developers and figure out the friction points.
Once you’ve chosen an impactful use case for a software template, start negotiating with all the relevant parties. You’ll find yourself dealing with significant office politics at the beginning of your journey. After all, the “golden path” looks different for infrastructure, reliability, security, legal and any other applicable team.
It’s important to come up with a robust-enough self-service action; you don’t want people generating complicated apps or misconfigured resources. Establish sane standards and baseline policies that make teams smile and developers breathe with ease when deploying to production.
However, be wary of being over-prescriptive. If you try to push a too-restrictive template, developers might avoid it altogether. Also, it’s impossible for you to cover all use cases in your organization, so make sure there’s a way for developers to customize how they use your template.
Conclusion: Templates Are Alive
Setting up Backstage’s scaffolder as a thin layer to abstract the complexity of your infrastructure can be a resource-effective way of proving your platform value to your developers and stakeholders.
An example of this pattern can be found with Lunar Bank. The popular Scandinavian bank uses the scaffolder as the exclusive touchpoint for developers to request resources. Devs can’t even create GitHub repos at Lunar without using a software template that guarantees the strict compliance levels a financial institution needs.
A way of getting started with self-service is to identify a use case that reduces the friction for developers and operators. Then take a diplomatic role to draw agreement on what a golden standard means for the folks in security, operations, infrastructure and any other team that needs to give their thumbs-up for a production release.
Once you have everyone’s OK, implement that common decision as a software template in Backstage and offer it to your devs. A bit of internal developer advocacy will go a long way! Show them you know where they struggle and have worked on a solution for them. Keep in mind that getting self-service capabilities right is an iterative process, so make sure to listen to feedback from your developers.
