diff --git a/docs/content/concepts/collaboration-concept/index.md b/docs/content/concepts/collaboration-concept/index.md new file mode 100644 index 000000000..6b4a9250c --- /dev/null +++ b/docs/content/concepts/collaboration-concept/index.md @@ -0,0 +1,48 @@ +--- +type: docs +title: "Concept: Collaboration in Radius" +linkTitle: "Collaboration" +description: "Learn how Radius Environments and Recipes support collaboration between platform engineers, application developers, and IT operators." +weight: 300 +slug: collaboration +--- + +## 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 standarizing 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. Envrionments 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. + +{{< button text="Learn more about Environments" page="/guides/deploy-apps/environments/overview" newtab="true" >}} + +## 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 envrionments. 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. + +{{< button text="Learn more about Recipes" page="/guides/recipes/overview" newtab="true" >}} + +## 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 enginering 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. diff --git a/docs/content/concepts/environments-concept/env-with-apps-example.png b/docs/content/concepts/environments-concept/env-with-apps-example.png deleted file mode 100644 index 475040ba8..000000000 Binary files a/docs/content/concepts/environments-concept/env-with-apps-example.png and /dev/null differ diff --git a/docs/content/concepts/environments-concept/index.md b/docs/content/concepts/environments-concept/index.md deleted file mode 100644 index 751d57910..000000000 --- a/docs/content/concepts/environments-concept/index.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -type: docs -title: "Radius Environments" -linkTitle: "Environments" -description: "Learn about Radius Environments" -weight: 300 -slug: environment -toc_hide: true ---- - -## Introduction - -Radius Environments are a prepared landing zone for applications. They contain a prepared pool of compute, networking, and shared resources. s deployed to that environment "bind" to that infrastructure. Configuration on the environment allow for operators to enforce organizational requirements and best practices for app teams. - -Environments provide a grouping structure for applications and the resources they share. For example, an org might choose to setup separate Radius Environments for staging and production. When appropriate, multiple applications can be deployed into the same environment. - -Diagram of multiple Radius Environments deployed to Azure. One environment contains 1 app, the other environment contains multiple apps. - -## Concerns that environments manage - -### Separation of concerns - -In many small to medium-sized organizations, a full stack developer might write application code, author the Radius app definition, and create the Radius Environment. In larger orgs, there may be separate teams of central operations and developers, where the central teams build environment templates which development teams leverage and deploy to. The separation of an app from an environment makes a separation of concerns possible. - -With Radius Environments, central operations and IT teams can define and share environments with development teams for them to deploy applications into. Ops teams can focus on configuring the compute, dependencies, networking, and other infrastructure concerns through [Recipes]({{< ref "guides/recipes/overview">}}), while developers focus on the business and application concerns. This allows each team to focus on what matters most to them, without needing to become experts in every aspect of the infrastructure and application. - -### Developer productivity - -Once an environment template is defined, developers can get up and running with a prepared development, pre-production, or production environment in minutes. No more waiting for manual provisioning, configuration or inter-team coordination. Simply use the [Recipes]({{< ref "guides/recipes/overview" >}}) linked to your Radius Environment and deploy your application. - -### Replication and consistency - -When an application team needs to scale an application to additional regions or instances, environments can be "stamped out" in minutes and ready for app deployments. Integrations with CI/CD systems such as GitHub Actions allow this process to be automated and repeatable. - -### Organization best-practices - -Organizational best-practices such as cost-optimization, resource sharing, and logging can all be codified and enforced with a Radius Environment. - -## Environment features - -| Feature | Description | -|---------|-------------| -| **Compute runtime** | Define compute runtimes such as a Kubernetes cluster or Azure serverless compute *(coming soon)* where your application's services run. | -| **Shared infrastructure** | Deploy shared resources that are available to all applications deployed into the environment. -| **Diagnostics** *(coming soon)* | Configure and manage diagnostic configuration such as collection policies, retention periods, and archival settings. -| **Networking** *(coming soon)* | Define networking requirements such that applications are automatically configured with network isolation best-practices. -| **Identity & access** *(coming soon)* | Limit access to deployments, resources and capabilities based on user roles and assignments. -| **Dependencies** *(coming soon)* | Define environment requirements such as policy, packages, or other organization requirements. -| **Infrastructure provisioning** | Automatically provision infrastructure at deployment time through [Recipes]({{< ref "guides/recipes/overview" >}}). -| **Dependency management** *(coming soon)* | Manage dependencies and environment capabilities such as packages, frameworks, and other configuration. - -## Example: Handoff between teams - -In this example there are two teams within an organization: a central operations team and a development team. The central ops team is responsible for managing the environment and the central infrastructure resources, and the development team is responsible for the application definition and deployment. - -A typical workflow for this team structure would look like: - -1. The ops team initializes a new environment, configured with a compute runtime setup with networking, identity, diagnostics, and other configuration that matches their org's requirements. -1. The developer authors a Radius Application template, including containers for their services, portable resources for their infrastructure, and routes/gateways for their networking. -1. The developer deploys the app template to the Radius Environment - - The app's containers automatically run on the container runtime - - The resource automatically configures security best practices and injects connection information into the consuming container - -When the developer deploys their application, these org-level concerns are automatically wired up based on the environment. Developers don't have to think about credentials or how networking is configured, enabling them to focus on their applications instead. - -## Next step - -Now that you have an understanding of Radius Environments, learn more about the Radius API: - -{{< button text="Radius API" page="api-concept" size="btn-lg" color="success" >}} \ No newline at end of file