Concept: Collaboration in Radius

What we heard

As part of our research into cloud-native application management we talked to many enterprise application teams and IT operators about their desired approach. For some enterprises their current DevOps began to break down as they increased their adoption of the cloud. Every DevOps team was making different decisions about which cloud provider they’d use, how they’d store their code, how their build pipelines worked, what services they’d use for compute, how they’d maintain application state, how logging and observability worked, and more. Best practices for engineering and operations weren’t effectively shared. Also, DevOps teams made different decisions about the scale of their resources, making it challenging or impossible for enterprises to optimize the cost of using the cloud. Finally, without consistent, verifiable security practices, security mistakes were getting made which, at their worst resulted in a loss of business and customer trust. These issues in operations, cost, and security needed to be addressed consistently across the enterprise.

We learned that there weren’t great tools for collaboration between IT organizations and the developers they were supporting. Collaboration between developers and operators required detailed coordination, resulting in back-and-forth manual processes that slow down development velocity. Most organizations resorted to building custom pipelines or ticketing systems for infrastructure deployments, but these only ease part of the pain without addressing the underlying manual processes. Teams needed a better way to collaborate with each other.

An emerging group of enterprises have a created a platform engineering effort to define and build their internal developer platform. Platform engineering teams focus on streamlining the developer-experience for their organization by optimizing for developer productivity when following the enterprise’s chosen practices. Platform engineers define the set of recommended practices for application teams based on DevOps principles, and then provide self-service capabilities for application teams to use. When an organization adopts a platform engineering mindset, the internal developer platform is the product, and the application developers are the customer. Platform engineering is a large effort and will encompass many topics outside of the scope of application management.

A few common challenges emerged from our conversations. The platform engineering philosophy also aims to address these concerns:

• Developers benefit from paved-paths for best-practices: enterprises gain operational efficiency by standardizing how applications are deployed, report diagnostics, and provision cloud resources. When this is done well, developers find and use the recommended technologies with ease. When this is done poorly, developers struggle with many templates, dependencies, and other assets to manage over time.
• Developer velocity is improved by self-service for the cloud: Platform engineering efforts optimize the developer workflow with self-service tools that provide guardrails to drive adherence to best-practices. These guardrails help manage costs and increase an organization’s security posture by providing correctly configured tools and infrastructure. In addition, self-service minimizes inefficient manual workflows that add friction to the development process.

Introducing the Environment

Environments in Radius provide a landing-zone for Applications that is configured with the organization’s chosen best-practices, settings, and Recipes. Environments encapsulate and store configuration for the compute platform, networking configuration, diagnostics systems, and other operational concerns. Environments enable a separation of concerns between developers and the IT organizations supporting those developers. Environments allow the configuration to vary across different types of deployments (like a staging deployment), deployment regions or even different clouds.

Platform engineers and IT operators collaborate with application teams by managing the set of Environments developers can use. These Environments may be static and pre-configured, or may be created on-demand by infrastructure-as-code as part of an internal developer platform. Platform engineers can configure Environments to ease adoption of recommended practices, for example by configuring the recommended diagnostics systems. Application developers can deploy their Applications across multiple Environments and have assurance that the correct configuration is applied. Environments reduce the cognitive load for developers since the configuration was created by platform engineers and stored by Radius.

When an Application is deployed, Radius will bind the Application to the configuration of the target Environment and apply the relevant settings. Storing the operational configuration in the Environment increases developer velocity because the Application does not need to change when it is deployed across Environments configured for different purposes or leveraging different infrastructure.

Recipes as part of the Environment

Recipes use infrastructure-as-code templates stored in the Environment to create cloud resources on-demand when an Application is deployed. Since the Recipes are stored in the Environment, the set of available cloud resources and the configuration used for provisioning can be tightly controlled. Recipes use the credentials stored in the Environment when provisioning cloud resources to limit those who need access to cloud accounts. The Recipes configured in an Environment are versioned, and can be updated in a granular way to lower the risk of unforeseen changes. When a Recipe is executed, it automatically catalogs the infrastructure used as part of the Radius Application Graph where it is visible to the whole organization. Because Recipes are part of the Environment, they can also vary across environments. For example, a cache might need to be bigger in one cloud region, like Europe, than it was in a different cloud region, like North America. For a multi-cloud Application, an enterprise could create an Environment for an AWS region and a different Environment for an Azure region. The recipe to create a Redis cache in the AWS Environment might deploy Amazon Elasticache for Redis and the recipe in the Azure Environment might deploy Azure Cache for Redis. The Application would just use the Redis cache recipe, unaware of what underlying infrastructure was deployed to provide the cache. Lastly, the infrastructure created by Recipes is stored by Radius, so it can be automatically cleaned up to help manage costs.

Within an IT or platform engineering team, many organizations have defined specialized roles like SecOps, FinOps, and cloud centers-of-excellence to address their complex needs for using the cloud. Recipes are designed for these engineers to standardize and govern the organizations use of the cloud while still supporting self-service deployment. Since the Recipes are stored in the Environment they do not need to be shared directly with or understood and managed by application developers. By providing Recipes, platform engineers can streamline and simplify the interface to the cloud used by application developers. Since Recipes execute as part of Application deployment, the provisioning of cloud resources is part of an existing process rather than a manual step.

Applications use Recipes to create cloud infrastructure during deployment without describing how that infrastructure will be provisioned. For example a developer, might include a Redis Cache as part of an Application. When the Application is deployed, the Redis Cache will be created according to the Recipe, ensuring that it uses a supported configuration. Recipes make it easy for the Application to connect to the cloud resources by automatically configuring access-policies, networking, and connection settings for the Application code. Since that Application can rely on the recipe to provision the correct infrastructure and deliver the correct configuration, it is easy to deploy the same Application to different Environments without code changes.

Part of platform engineering

Platform engineering is a relatively new trend and so the exact set of tools and practices that will make organizations successful are still to be determined. We designed Radius to aid platform engineering efforts as part of the internal developer platform. Radius provides Environments and Recipes to help ensure that cloud resources meet enterprise requirements for operations, cost, and security. We also think that the Radius Application Graph, described elsewhere, will help everyone visualize and reason about their Applications. With these components we hope to help Platform Engineers build simple but powerful platforms for their developers to use while improving the collaboration between developers and the broader IT organization.

The Environment and Recipe model also works for DevOps teams. When we spoke with DevOps teams we learned that there were usually a small group of people with stronger expertise in creating and managing cloud resources. We’d expect these people to be the people creating Environments and Recipes for use by their team.