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. Guardrails are established and agreed to by key stakeholders. Stakeholders can include security, operations, architecture teams across the organization.
With self-service with guardrails, development teams retain autonomy to independently make development decisions. 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. Developers can then 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.
Internal developer platforms empower developers to act like digital storefront customers
Internal developer platforms provide 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.
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. IaC with CD allows 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 apply all the benefits of a git repository like security and auditability.
Provisioning common infrastructure and tools isn't 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.
Create start right templates and establish stay right governance
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.
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
Combine IaC, EaC, and application templates into a tailor-made everything as code (EaC) solution that 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, developers stay right from the day one.
Templates streamline development with automated, secure practices
Use application templates to bootstrap your defined paved paths for several key decisions and actions that developers take over the course of a project. Start right templates 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 become start right templates of their own. These templates are central to enabling self-service experiences since they not only define outputs, but also available options developers choose from.
Templates ensure governance, security, and cost optimization
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.
Run get right campaigns to build two-way communication
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.
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 delivers value incrementally. Each organization's journey in creating their internal developer platform is different, and following a product mindset helps you target the most critical places that need self-service experiences first.