Empower Developers through self-service with guardrails
Self-service with guardrails is the principle of empowering development teams to make their own decisions within a set of well-defined parameters, or guardrails, that are established and agreed to by key stakeholders. Stakeholders can include security, operations, architecture teams across the organization.
The idea behind self-service with guardrails is that development teams can retain the desired level of autonomy to independently make development decisions, while automation and policy help stakeholders ensure that security, compliance, operations, standards, and costs are properly managed. Enabling this automation requires collaboration across team lines so that developers, operators, and specialists can do more, without sacrificing the needed governance. Combined with improved discovery and reuse within organization defined guardrails, developers can focus on delivering business value as quickly as possible.
[We tell developers,] don't worry a thing about how it all works, just toggle them on or off, fill it in, put a string in whatever you need to do and it's basically self-service in that regard where they have a readme file and they have inputs, outputs and they can put in whatever they like. - Daniel, Cloud Engineer, Fortune 500 Media Company
The goal of providing a self-service experience for your paved paths is to reduce developer toil while also providing visibility to development teams, operations, and management. The idea is that you create an experience for a given task that has a minimal learning curve, thanks in part to its underlying automation and data aggregation capabilities. Beyond activities like infrastructure provisioning these experiences can provide access to critical capabilities for observability, policy, incident management, and more. The idea extends into discovery and sharing of internal APIs, SDKs, along with shared tools and services. These experiences reduce overhead so development teams can focus on getting things done.
The time it takes to get started with a project or a task is another motivating factor for self-service experiences. An analogy often used for an internal developer platform is that it provides similar capabilities to business-to-business digital storefronts. Digital stores are inherently designed to help their customers self-serve. They can handle more throughput than traditional store fronts because they provide ways to discover and fulfill items that are interesting without having to talk to anyone. Using this analogy, developers are the customer and the internal developer platform provides similar self-service experiences. Much like a retailer, operators, platform engineers, and other roles then set up a catalog of items developers can request that are designed to accommodate organizational guardrails.
For example, you can think about a developer requesting access to a new tool as if they were making a digital storefront order. Like an order, once the request is submitted, the developer wants to be able to keep track of progress and know when it's complete. Behind the scenes, the request should automatically be routed to the correct fulfillment provider to meet the need. You can think of one of your continuous integration and delivery (CI/CD) systems as one fulfillment provider, a GitOps tool or a prescriptive application platform as a second, and a workflow automation tool for manual processes as a third. In all cases, the developer can self-serve items from a well-defined catalog in the same way.
To learn more about implementing these concepts, see Apply software engineering systems and Design a developer self-service foundation.
Use the everything as code pattern
Using infrastructure as code (IaC) through continuous delivery (CD) pipelines and GitOps tools is an important part of enabling self-service. These can allow you to use Bicep, Terraform, Helm charts, and other tools to create and destroy cloud resources on demand. Because the configuration of your cloud infrastructure is managed just like code in a source code repository, you can inherently apply all the benefits of a git repository like security and auditability.
Platform engineering teams can take advantage of IaC when provisioning common infrastructure and tools but that’s not the only advantage of an IaC approach. You can adapt the “as code” pattern for other scenarios, including security as code and policy as code (via tools like Azure Policy and Open Policy Agent). Following this technique, a configuration file, typically YAML or JSON, is pushed into the repository, at which point, a workflow is triggered that processes the file. These files might be an app repository like dependabot.yml or CODEOWNERS, or they may be maintained in a separate central repository. You can even extend this into your own scenarios to truly make everything as code (EaC) a reality.
Developers can reference each of these EaC templates with a central catalog that powers your self-service experiences and encourages best practices by default.
Learn more about the everything as code pattern.
Create start right templates & establish stay right governance
We will build out modules for our [developers]… so instead of having to write or worry about any of the back end themselves, all they need to do is worry about their application code. - Daniel, Cloud Engineer, Fortune 500 Media Company
In software development we aim for encapsulation, modularity, and composability when designing applications. You should apply this same line of thinking to platform engineering through templating. For example, you can create and use a set of centrally secured, reusable IaC templates as building blocks for infrastructure.
These can be combined into a tailor-made application template that refers to these and other everything as code (EaC) building blocks and extends to other activities like creating a source code repository, seeding sample code, or providing configuration and sample code for recommended observability tools. These IaC, EaC, and application templates can then be stored or referenced from a central, secured location such as a repository, the catalog in Azure Deployment Environments (ADE), or Azure Container Registry (ACR) for cloud native.
When start right templates are combined with automated governance, scanning, and policy configuration, they can help developers stay right from the day one.
Start right templates
Application templates can be used to bootstrap your defined paved paths for several key decisions and actions that developers take over the course of a project. These start right templates should establish secure, governed development practices, and enable developers to get started quickly by enabling automation that provides access to the tools they need, configures CI/CD pipelines, provisions the infrastructure and application stack, and configuring a repository complete with boiler plate source code that includes needed SDKs or references to APIs.
By having these application templates reference other centralized templates (for example, IaC templates), each of these individual building blocks can become start right templates of their own to streamline use in existing applications. These templates are central to enabling self-service experiences since they not only define outputs, but also available options developers choose from.
Stay right governance
However, templates should do more than just bootstrapping a development effort. They should also establish the control and governance through policy and security scanning necessary to stay right over the course of the project lifecycle. As another example, templates can set up branch protection rules preventing unauthorized merges into production. Because templates capture best practices and common configurations, they're one of the key techniques for optimizing costs across tools, vendors, and teams.
Get right campaigns
Finally, as your confidence in your paved paths increase, you can use the underlying individual building blocks you assembled into your application templates to move existing applications onto a paved path. Since your internal customers will already see the value of your piloted paved paths, you can run an internal get right campaign to create a two-way dialog with other application teams. Developers can learn how to migrate their application while the platform engineering team simultaneously learns more about how to improve the platform for them.
Learn more about start right templates with stay right governance.
Chart your own journey
Given the breadth of experiences that your self-service capabilities could cover, it’s an important focus for your investment efforts and Plan and prioritize so that your internal developer platform deliver value incrementally. Each organization's journey in creating their internal developer platform will be different, and following a product mindset will help you target the most critical places that need self-service experiences first.
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for