[Misc] website: Documentation update

Update docu

Change-Id: If750e70f6c9a3266e976a71f52dbb82c0297483d

website/content/en/_index.md

@@ -1,17 +1,17 @@
 ---
 title: CAP Operator
 linkTitle: CAP Operator
-description: A Kubernetes Operator for managing the lifecycle of multi-tenant CAP applications
+description: A Kubernetes operator for managing the lifecycle of multi-tenant SAP Cloud Application Programming Model applications
 ---
 
-{{% blocks/cover title="Welcome to CAP Operator !" image_anchor="top" height="full" color="primary" %}}
+{{% blocks/cover title="Welcome to CAP Operator" image_anchor="top" height="full" color="primary" %}}
 <div class="mx-auto">
-	<span class="font-weight-bold">A Kubernetes Operator for managing the lifecycle of multi-tenant CAP applications</span><br><br><br>
+	<span class="font-weight-bold">A Kubernetes operator for managing the lifecycle of multi-tenant CAP applications</span><br><br><br>
 	<a class="btn btn-lg btn-outline-info mr-3 mb-4" href="docs/">
-		Documentation <i class="fas fa-arrow-alt-circle-right ml-2"></i>
+		Learn more <i class="fas fa-arrow-alt-circle-right ml-2"></i>
 	</a>
 	<a class="btn btn-lg btn-outline-info mr-3 mb-4" href="https://github.com/sap/cap-operator">
-		Source Repository <i class="fab fa-github ml-2 "></i>
+		Go to the source repository <i class="fab fa-github ml-2 "></i>
 	</a>
  	<br><br><br><p>
 		<img src="https://img.shields.io/github/go-mod/go-version/SAP/cap-operator" alt="go.mod Go Version">

website/content/en/docs/_index.md

@@ -8,17 +8,17 @@ menu:
     pre: "<i class='fas fa-book pr-2'></i>"
 ---
 
-The [**CAP Operator**](https://github.com/sap/cap-operator) deploys and manages the lifecycle of multi-tenant [SAP Cloud Application Programming Model (CAP)](https://cap.cloud.sap/docs) based applications and related components, within a Kubernetes cluster.
+[**CAP Operator**](https://github.com/sap/cap-operator) deploys and manages the lifecycle of multi-tenant [SAP Cloud Application Programming Model](https://cap.cloud.sap/docs) based applications and related components, within a Kubernetes cluster.
 
-Main features of the CAP Operator:
+What are the main features of CAP Operator?
 
-- Quick and easy deployment of CAP application backends, router and related networking components.
-- Integrates with BTP SaaS Provisioning to handle asynchronous tenant subscription requests, executing provisioning / deprovisioning tasks as Kubernetes jobs.
-- Automatically upgrades known tenants when newer application versions are available.
-- Supports deployment of service specific content / configuration as a Kubernetes job with with every application version (e.g. HTML5 application content to HTML5 Repository Service).
-- Manages TLS certificates and DNS entries related to the deployed application, with support for customer specific domains.
+- Quick and easy deployment of CAP application back ends, router, and related networking components.
+- Integration with SAP Software-as-a-Service Provisioning service to handle asynchronous tenant subscription requests, executing provisioning / deprovisioning tasks as Kubernetes jobs.
+- Automated upgrades of known tenants as soon as new application versions are available.
+- Support of deployment of service-specific content / configuration as a Kubernetes job with every application version (for example, HTML5 application content to SAP HTML5 Application Repository service).
+- Management of TLS certificates and DNS entries related to the deployed application, with support of customer-specific domains.
 
-The following picture provides an overview of the major automation steps handled by the Operator during application deployment.
+Here's an overview of the major automation steps handled by CAP Operator during the deployment of the application:
 
 ![workflow](/cap-operator/img/workflow.png)
 

website/content/en/docs/concepts/_index.md

@@ -7,10 +7,10 @@ description: >
   Motivation and overview of components
 ---
 
-Provisioning and operating a CAP Application on a Kubernetes cluster requires deployment of various components in addition to the CAP application server (see [a list of typical components]({{< ref "/cap-application-components.md" >}})). Some of these components can be created at the time of system provisioning, while others need to be created (or updated) at different points during the lifecycle of the application (DAY 2 operational tasks).
+Provisioning and operating an SAP Cloud Application Programming Model application on a Kubernetes cluster requires the deployment of various components in addition to the CAP application server (see [a list of typical components]({{< ref "/cap-application-components.md" >}})). Some of these components can be created at the time of system provisioning, while others need to be created (or updated) at different points during the lifecycle of the application (DAY 2 operational tasks).
 
-Using helm charts to manage a CAP Application deployment can support the initial system provisioning, but further lifecycle operations like tenant provisioning, which are initiated from external components (SAP BTP), will require manual adjustment of the deployed resources. An example of such an instance would be the creation of `VirtualServices` (part of Istio service mesh) during tenant provisioning to route application (HTTP) requests submitted on the new tenant subdomain to the application server. Another limitation of using helm charts is the lack of control over the order in which resources are created.
+Using Helm charts to manage the deployment of a CAP application can support the initial system provisioning, but further lifecycle operations (such as tenant provisioning) that are initiated from external components (SAP BTP) require manual adjustment of the deployed resources. An example of such an instance would be the creation of `VirtualServices` (part of Istio service mesh) during tenant provisioning to route application (HTTP) requests submitted on the new tenant subdomain to the application server. Another limitation of using helm charts is the lack of control over the order in which resources are created.
 
-More control over the deployment and further automation of lifecycle operations can be achieved by extending the Kubernetes API with custom resources, which describe the components and configuration of CAP applications, and controllers to reconcile them. Similar to standard controllers of Kubernetes the custom controllers watch for changes in the custom resource objects and work towards moving the cluster state to the desired state.
+You can get more control over the deployment and further automation of lifecycle operations by extending the Kubernetes API with custom resources that describe the components and the configuration of CAP applications, and controllers to reconcile them. Similar to standard controllers of Kubernetes, the custom controllers watch for changes in the custom resource objects and work towards moving the cluster state to the desired state.
 
-The [CAP Operator](https://github.com/sap/cap-operator) comprises of Custom Resource Definitions which describe the CAP application components, the controller to reconcile these resources, and other components which support the lifecycle management.
+[CAP Operator](https://github.com/sap/cap-operator) comprises of custom resource definitions that describe the CAP application components, the controller to reconcile these resources, and other components that support the lifecycle management.

website/content/en/docs/concepts/cap-application-components.md

@@ -4,27 +4,28 @@ linkTitle: "CAP Application Components"
 weight: 20
 type: "docs"
 description: >
-  A typical multi-tenant CAP application
+  A typical multi-tenant SAP Cloud Application Programming Model application
 ---
 
-A full stack application built using the CAP programming model will have the following components
+A full-stack application built with the SAP Cloud Application Programming Model has the following components:
 
 ### SAP BTP Service Instances
 
-Multi-tenant CAP based applications need to consume services from SAP BTP like XSUAA, SaaS Provisioning etc. These service instances need to be created within a BTP Provider Account. Service keys (bindings) need to be created for these instances which generate the credentials used by the application for accessing these services.
+Multi-tenant CAP-based applications consume services from SAP BTP such as [SAP Authorization and Trust Management Service](https://help.sap.com/docs/authorization-and-trust-management-service?locale=en-US), SAP Software-as-a-Service Provisioning service, and so on. You need to create these service instances within an SAP BTP provider account as well as service keys (bindings) for these instances, which generate the credentials used by the application for accessing these services.
 
-### CAP application server
+### CAP Application Server
 
-The application provides data models which will be deployed to the connected database. An HTTP server exposes defined services and handles server side application logic. For more details check out [CAP documentation](https://cap.cloud.sap/docs). It is also possible that the application is split into multiple servers (services) which work together.
+The application provides data models that will be deployed to the connected database. An HTTP server exposes defined services and handles server-side application logic. For more details, check out [the documentation of SAP Cloud Application Programming Model](https://cap.cloud.sap/docs). It's also possible to split the application into multiple servers (services) that work together.
 
-### CAP components to support Multi-tenancy
+### CAP Components to Support Multitenancy
 
-CAP provides the module `@sap/cds-mtxs` which can be operated as a sidecar (component running independently from the application server). This component is then responsible for handling requests related to tenant management like onboarding which then creates the required schema in the connected database. This module also supports triggering tenant management tasks as CLI commands.
+CAP provides the module `@sap/cds-mtxs`, which can be operated as a sidecar (component running independently from the application server). This component is responsible for handling requests related to tenant management such as onboarding, which then creates the required schema in the connected database. This module also supports triggering tenant management tasks as CLI commands.
 
-### AppRouter
+### Approuter
 
-The [AppRouter](https://www.npmjs.com/package/@sap/approuter), or an extended version of it, takes care of authenticating requests (using the XSUAA service) and routes the requests to the application servers or related services (e.g. HTML5 Application Repository Service).
+The [Approuter](https://www.npmjs.com/package/@sap/approuter), or an extended version of it, takes care of authenticating requests (using the [SAP Authorization and Trust Management Service](https://help.sap.com/docs/authorization-and-trust-management-service?locale=en-US)) and routes the requests to the application servers or related services (for example, 
+SAP HTML5 Application Repository service for SAP BTP).
 
-### SAP Fiori applications
+### SAP Fiori Applications
 
-Multiple SAP Fiori frontend applications may connect to the CAP application backend. These UI5 applications are deployed to the HTML5 Application Repository Service and served from there. Similarly, the application may have content specific to other services which need to be deployed, like the Portal Service.
+Multiple SAP Fiori front-end applications can connect to the CAP application back end. These UI5 applications are deployed to the SAP HTML5 Application Repository service for SAP BTP and served from there. Similarly, the application can have content specific to other services that need to be deployed, such as the SAP Cloud Portal service.

website/content/en/docs/concepts/operator-components/_index.md

@@ -7,17 +7,17 @@ description: >
   An overview of the architecture
 ---
 
-The CAP Operator is comprised of the following components
+CAP Operator is comprised of the following components:
 
-1. **CAP Controller**: a native Kubernetes controller that reconciles custom resources which are defined as part of the operator
-2. **Web-hooks**: validating web-hooks to ensure consistency of custom resource objects submitted to kubernetes API server
-3. **Subscription Server**: web server for handling HTTP requests submitted by the BTP `saas-registry` service instances during tenant subscription (and unsubscribe)
-4. **MTX Job** _[DEPRECATED]_: wrapper component which enables execution of tenant lifecycle operations using `cds/mtx` module provided by CAP, as kubernetes Jobs. _This module is no longer required for applications using the newer `@sap/cds-mtxs` module._
+1. **CAP Controller**: a native Kubernetes controller that reconciles custom resources defined as part of the operator
+2. **Webhooks**: validating webhooks to ensure consistency of custom resource objects submitted to the Kubernetes API server
+3. **Subscription Server**: web server for handling HTTP requests submitted by the SAP BTP `saas-registry` service instances during tenant subscription (and unsubscribe)
+4. **MTX Job** _[DEPRECATED]_: wrapper component that enables the execution of tenant lifecycle operations using the `cds/mtx` module provided by CAP, as Kubernetes jobs. _This module is no longer required for applications using the newer `@sap/cds-mtxs` module._
 
-> Note: [`@sap/cds-mtx` is no longer supported with CDS 7](https://cap.cloud.sap/docs/releases/jun23#migration-from-old-mtx). The MTX Job component will be removed once support for older CDS version ends.
+> Note: [`@sap/cds-mtx` is no longer supported with CDS 7](https://cap.cloud.sap/docs/releases/jun23#migration-from-old-mtx). The multitenancy and extensibility tool job component will be removed once support for older CDS versions ends.
 
-The following diagram depicts how the main components interact when deployed to a cluster.
+The following diagram depicts how the main components interact when deployed to a cluster:
 
 ![cluster-components](/cap-operator/img/block-cluster.png)
 
-The following pages provide further details about the CAP Operator components.
+Looking for more details about the CAP Operator components? Go to the next pages. 

website/content/en/docs/concepts/operator-components/controller.md

@@ -4,19 +4,19 @@ linkTitle: "Controller"
 weight: 10
 type: "docs"
 description: >
-  Reconciliation of Custom Resource Objects
+  Reconciliation of custom resource objects
 ---
 
-The CAP Controller is implemented using the [client-go](https://github.com/kubernetes/client-go) from Kubernetes, which provides the required tools and utilities to interact with the Kubernetes API server. It manages custom resources which are included with the operator.
+To implement the CAP controller, you use the [client-go](https://github.com/kubernetes/client-go) from Kubernetes, which provides the required tools and utilities to interact with the Kubernetes API server. It manages custom resources that are included in CAP Operator.
 
-The controller uses `Informers` to watch certain resources and invokes registered event handlers when these resources are modified. To streamline the processing of such notifications, rate limiting queues are implemented which store the changes and allow processing of these items in independent reconciliation threads (go routines). Such a design allows sequential processing of the changed items and avoids conflicts.
+The controller uses `Informers` to watch certain resources and invokes registered event handlers when these resources are modified. To streamline the processing of such notifications, rate limiting queues are implemented, which store the changes and allow the processing of these items in independent reconciliation threads (go routines). Such a design allows sequential processing of the changed items and avoids conflicts.
 
-The following _namespaced_ Custom Resources have been defined to be reconciled by the CAP controller:
+The following _namespaced_ custom resources have been defined to be reconciled by the CAP controller:
 
-- `CAPApplication`: defines a high level application, its domains and consumed BTP services
-- `CAPApplicationVersion`: defines a child resource of the `CAPApplication` which contains container images which will be used to deploy application components (workloads) of a specific version
-- `CAPTenant`: represents a child resource of the `CAPApplication` which corresponds to a BTP sub-account which has subscribed to the application
-- `CAPTenantOperation`: represents a provisioning, deprovisioning or upgrade operation on a tenant which is scheduled as a child resource of a `CAPTenant` and executed as a sequence of specified steps.
+- `CAPApplication`: defines a high-level application, its domains, and the consumed SAP BTP services
+- `CAPApplicationVersion`: defines a child resource of the `CAPApplication`, which contains container images that will be used to deploy application components (workloads) of a specific version
+- `CAPTenant`: represents a child resource of the `CAPApplication` which corresponds to an SAP BTP subaccount subscribed to the application
+- `CAPTenantOperation`: represents a provisioning, deprovisioning, or upgrade operation on a tenant that is scheduled as a child resource of a `CAPTenant` and executed as a sequence of specified steps.
 
 > Parent-child relationships between custom resources are established by defining owner references for the children.