radius-project · PalmEmanuel · Nov 19, 2023 · Nov 19, 2023 · Nov 19, 2023 · Nov 19, 2023
@@ -122,12 +122,12 @@
             text-rendering: auto;
             -webkit-font-smoothing: antialiased;
             font-family: "Font Awesome 5 Free";
-            font-weight: 900; 
+            font-weight: 900;
             content: "\f0d9";
             padding-left: 0.5em;
             padding-right: 0.5em;
         }
-    }  
+    }
 }
 
 // Foldable sidebar menu
@@ -136,18 +136,18 @@ nav.foldable-nav {
     &#td-section-nav {
         position: relative;
     }
-    
+
     &#td-section-nav label {
         margin-bottom: 0;
         width: 100%;
     }
-    
+
     .td-sidebar-nav__section, .with-child ul {
         list-style: none;
         padding: 0;
         margin: 0;
     }
-    
+
     .ul-1 > li {
         padding-left: 1.5em;
     }
@@ -165,8 +165,8 @@ nav.foldable-nav {
 
     input[type=checkbox] { display: none; }
 
-    .with-child, .without-child { 
-        position: relative; 
+    .with-child, .without-child {
+        position: relative;
         padding-left: 1.3em;
     }
 
@@ -189,30 +189,29 @@ nav.foldable-nav {
         }
     }
 
-    .ul-1 .with-child > input:checked ~ label:before { 
+    .ul-1 .with-child > input:checked ~ label:before {
         color: $primary;
         transform: rotate(90deg);
-        transition: transform 0.5s; 
+        transition: transform 0.5s;
     }
 
     .with-child ul { margin-top: 0.1em; }
-
-}    
+}
 
 @media (hover: hover) and (pointer: fine) {
-    
+
     nav.foldable-nav {
 
-        .ul-1 .with-child > label:hover:before { 
+        .ul-1 .with-child > label:hover:before {
             color: $primary;
             transform: rotate(30deg);
-            transition: transform 0.5s; 
+            transition: transform 0.5s;
         }
 
-        .ul-1 .with-child > input:checked ~ label:hover:before { 
+        .ul-1 .with-child > input:checked ~ label:hover:before {
             color: $primary;
             transform: rotate(60deg) !important;
-            transition: transform 0.5s; 
+            transition: transform 0.5s;
         }
     }
 }
@@ -344,7 +344,6 @@ resource app 'radius.dev/Application@v1alpha1' = {
       //BINDINGS
       connections: {
         backend: {
-
           source: other.id
         }
       }
@@ -591,7 +590,7 @@ By default, buttons are padded with new lines below the button. To remove these
 {{< button text="Previous" link="https://example.com" newline="false" >}}
 {{< button text="Next" link="https://example.com" >}}
 
-#### Categorize content 
+#### Categorize content
 
 You can use the `categorizeby` shortcode to pull and organize content by either categories and tags. This is useful when you want to categorize content by tags and the type of the document
 

@@ -62,7 +62,7 @@ The common structure of a resource id is the following:
 {rootScope}/{resourceNamespace}/{resourceType}/{resourceName}
 ```
 
-### Root scope 
+### Root scope
 
 A hierarchical set of key-value pairs that identify the origin of the resource. Root scopes answer questions like: 
 

@@ -35,7 +35,7 @@ When an Application is deployed, Radius will *bind* the Application to the confi
 
 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.  
+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.
 

@@ -86,18 +86,16 @@ Radius leverages Kubernetes in two ways:
 1. As a hosting platform for the Radius control-plane
 2. As a runtime for containerized workloads
 
-While Radius only supports Kubernetes today, it is architected to support other hosting platforms in the future, including serverless platforms. Radius is not a Kubernetes controller and the primary user experience is not through CRDs. Instead, Radius Applications are an abstraction layer on top of Kubernetes and other cloud platforms.
+While Radius only supports Kubernetes today, it is architected to support other hosting platforms in the future, including serverless platforms. Radius is not a Kubernetes controller and the primary user experience is not through custom resources (CRDs). Instead, Radius Applications are an abstraction layer on top of Kubernetes and other cloud platforms.
 
 ### How does Radius compare to Helm?
 
 [Helm](https://helm.sh/) is a package manager for Kubernetes that allows you to define, install, and upgrade Kubernetes applications. Helm is a great tool for deploying Kubernetes objects, but doesn't provide a way to model dependencies between services and infrastructure, or to define and manage infrastructure-as-code. It also only supports Kubernetes as a targeted platform.
 
-Radius was built to provide a platform for modeling and deploying an entire application, as cloud-native applications are more than just Kubernetes. They include cloud infrastructure, running services, the underlying platforms, and all the connections between them.
+Radius is built to provide a platform for modeling and deploying an entire application, as cloud-native applications are more than just Kubernetes. They include cloud infrastructure, running services, the underlying platforms, and all the connections between them.
 
 Teams looking to leverage existing Helm charts can use the [Radius annotations and Recipe CRD](#TODO) to add Radius capabilities to their existing application. With just a few annotations, you can add the power of the Radius app graph, connections, and Recipes to your existing Helm chart.
 
-Teams building or migrating applications on Radius can use Bicep to model their application and deploy to Kubernetes today, as well as future platforms, including serverless platforms.
-
 ### How does Radius compare to Bicep?
 
 [Bicep](https://github.com/Azure/bicep) is a Domain Specific Language (DSL) for deploying infrastructure declaratively. Radius leverages Bicep as one of its supported languages for defining applications and Recipes.
@@ -106,6 +104,8 @@ Similar to how you can define Azure resources in Bicep, you can define Radius re
 
 Radius currently uses a temporary fork of Bicep to add support for the Radius resources, but work is underway to merge extensibility support into the main Bicep repo and eliminate the need for a fork.
 
+Teams building or migrating applications on Radius can use Bicep to model their application and deploy to Kubernetes today, as well as future platforms, including serverless platforms.
+
 ### How does Radius compare to Terraform?
 
 [Terraform](https://www.terraform.io/) is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform is a great tool for deploying infrastructure, but doesn't provide a way to model an entire application and the dependencies between services and infrastructure, or act as an abstraction layer for multiple cloud providers.
@@ -126,7 +126,7 @@ Radius is an open-source project that allows you to model, deploy, and manage ap
 
 ### How does Radius compare to Crossplane?
 
-[Crossplane](https://crossplane.io/) is an open source Kubernetes add-on that extends any cluster with the ability to provision and manage cloud infrastructure, services, and applications using kubectl, GitOps, or any tool that works with the Kubernetes API. As Radius is unopinionated about how infrastructure is deployed through Recipes, Crossplane could be used within a Recipe. Both Bicep and Terraform modules are able to include Kubernetes resources and Crossplane CRDs.
+[Crossplane](https://crossplane.io/) is an open-source Kubernetes add-on that extends any cluster with the ability to provision and manage cloud infrastructure, services, and applications using kubectl, GitOps, or any tool that works with the Kubernetes API. As Radius is unopinionated about how infrastructure is deployed through Recipes, Crossplane could be used within a Recipe. Both Bicep and Terraform modules are able to include Kubernetes resources and Crossplane CRDs.
 
 Once deployed, Crossplane-managed infrastructure can be included in a Radius application and queried via the Radius application graph.
 

@@ -46,6 +46,6 @@ Radius was designed from the start to support enterprises in implementing their
 ## Open-source
 Many enterprises use open-source technologies as a way of *achieving* their multi-cloud strategy. Kubernetes adoption is a great example of this trend. Customers building on Kubernetes can leverage their Kubernetes experience, tools, and practices with any cloud provider and they're confident Kubernetes, with it's broad community, will continue to be a multi-cloud technology. 
 
-Radius was designed to be an open-source project from the start as part of the way Radius would support enterprise multi-cloud strategies. Open-source can mean different things to different people. For Radius, open-source means that our source code is publicly available under an OSI-approved permissive license. It also means that the Radius project uses an neutral and open governance model to continue the evolution of Radius as a multi-cloud technology going forward. Anyone should be able to contribute to Radius, extend the platform, self-host Radius for internal use, or use it to build a business hosting other people's applications.
+Radius was designed to be an open-source project from the start, since Radius would support enterprise multi-cloud strategies. Open-source can mean different things to different people. For Radius, open-source means that our source code is publicly available under an OSI-approved permissive license. It also means that the Radius project uses an neutral and open governance model to continue the evolution of Radius as a multi-cloud technology going forward. Anyone should be able to contribute to Radius, extend the platform, self-host Radius for internal use, or use it to build a business hosting other people's applications.
 
 The Radius team has worked with the Cloud Native Computing Foundation (CNCF) to bring Radius into the CNCF as a new CNCF project. The Radius team is optimistic that Radius will be a success, both in helping enterprises achieve their multi-cloud strategies as well as in bringing powerful concepts, like Environments, Recipes, and the Application Graph, to the broader cloud native community.
@@ -1,6 +1,6 @@
 ---
 type: docs
-title: Overview for Radius 
+title: Overview for Radius
 linkTitle: Overview
 description: Learn how Radius fits into the app development landscape and it's long-term vision
 weight: 100
@@ -11,7 +11,7 @@ toc_hide: true
 
 App teams today struggle to model and deploy their applications. Complex architectures, cross-platform portability requirements, and org-level best-practices all make it difficult to not only model and deploy, but also maintain and troubleshoot large applications.
 
-Apps today are modeled and deployed with Dockerfiles, Kubernetes CRDs, Helm charts, and infrastructure-as-code templates, with scripts to glue it all together. Plus, the range of infrastructure types (cloud, on-premises, serverless) can double or triple the work as teams figure out how to move apps between platforms.
+Apps today are modeled and deployed with Dockerfiles, Kubernetes custom resources (CRDs), Helm charts, and infrastructure-as-code templates, with scripts to glue it all together. Plus, the range of infrastructure types (cloud, on-premises, serverless) can double or triple the work as teams figure out how to move apps between platforms.
 
 {{< image alt="Diagram showing all of the technologies needed to model an application today" src="cloud-apps-today.png" width="600px" >}}
 

@@ -31,7 +31,7 @@ resource frontend 'Applications.Core/containers@2023-10-01-preview' = {
       }
     }
     //CONTAINER
-    // Connect container to database 
+    // Connect container to database
     connections: {
       itemstore: {
         source: databaseId

@@ -9,7 +9,7 @@ categories: "Concept"
 
 ## Our starting point
 
-We started Radius to simplify and improve upon tools application developers use to deploy and manage applications. Our initial goal was just to create a platform for deployment that developers would love but, as we talked to more cloud customers, we realized almost every enterprise is creating a custom internal developer platform to standardize the way they deploy and manage cloud-native applications
+We started Radius to simplify and improve upon tools application developers use to deploy and manage applications. Our initial goal was just to create a platform for deployment that developers would love but, as we talked to more cloud customers, we realized almost every enterprise is creating a custom internal developer platform to standardize the way they deploy and manage cloud-native applications.
 
 Most enterprises are not dev-tools experts and as a result they struggle with the cost and complexity of building a home-grown solution. If we could provide an open-source solution that solved these problems for enterprises we could have a big impact.
 
@@ -29,7 +29,7 @@ Our philosophy is to be inclusive when considering what is *part of the applicat
 
 ## Developers and platform engineers need to collaborate
 
-Enterprises are creating specialized roles and initiatives to improve their speed, efficiency, and security when adopting the cloud. Platform engineering is an emerging discipline that's combining a product mindset with learnings from DevOps and DevSecOps teams to create internal development platforms. When successful, platform engineers deliver a set of tools that provide sufficient automation, tracking, governance, and observability that guide development teams naturally fall “into the pit of success.” Often these endeavors can come up a little short, looking like a set of repository templates, cloud resource templates, and a software catalog for application developers to use. Unfortunately, the tools and assets that are frequently used don't encourage collaboration between developers and the platform engineers supporting those developers. Platform engineering is new as a discipline, and the patterns that will make enterprises successful long-term are still emerging.
+Enterprises are creating specialized roles and initiatives to improve their speed, efficiency, and security when adopting the cloud. Platform engineering is an emerging discipline that's combining a product mindset with learnings from DevOps and DevSecOps teams to create internal development platforms. When successful, platform engineers deliver a set of tools that provide sufficient automation, tracking, governance, and observability that guide development teams to naturally fall into "the pit of success.” Often these endeavors can come up a little short, looking like a set of repository templates, cloud resource templates, and a software catalog for application developers to use. Unfortunately, the tools and assets that are frequently used don't encourage collaboration between developers and the platform engineers supporting those developers. Platform engineering is new as a discipline, and the patterns that will make enterprises successful long-term are still emerging.
 
 Radius provides concepts like Environments and Recipes that support a separation of concerns. Platform engineers can create repository templates with CI/CD pipelines and starter code for deployment. IT operators can deploy and govern the Environments where those pipelines deploy applications. Cloud and security experts can provide the Recipes used to create and update cloud resources. Developers are only responsible for describing the requirements and architecture of the application, understanding which environments to use, and choosing dependencies from the supported set of Recipes.
 

@@ -55,16 +55,16 @@ rad init
 Example output:
 
 ```
-Initializing Radius...                     
-
-✅ Install Radius {{< param version >}}               
-    - Kubernetes cluster: k3d-k3s-default   
-    - Kubernetes namespace: radius-system   
-✅ Create new environment default          
-    - Kubernetes namespace: default 
-    - Recipe pack: local-dev        
-✅ Scaffold application docs            
-✅ Update local configuration              
+Initializing Radius...
+
+✅ Install Radius {{< param version >}}
+    - Kubernetes cluster: k3d-k3s-default
+    - Kubernetes namespace: radius-system
+✅ Create new environment default
+    - Kubernetes namespace: default
+    - Recipe pack: local-dev
+✅ Scaffold application docs
+✅ Update local configuration
 
 Initialization complete! Have a RAD time 😎
 ```