Fix typos

rfcs/1-jhipster-rfc-k8s-operator.md

@@ -76,7 +76,7 @@ After deploying your applications to a Kubernetes environment you can deploy the
 Once the Operator is running you will be able to:
 
 1. Interact with the Kubernetes API to get JHipster specific resources, such as Applications, MicroServices, Gateways and Registries and see the relationships between them. You will be able to describe each of the resources to obtain more details about the services that are related to the application
-2. Automatically expose applications based on the healthyness of all the services belonging to that application, if a service is failing the application might be automatically hidden from the end users. This can be achieved by creating new Ingress or new Gateway Routes for Istio
+2. Automatically expose applications based on the healthiness of all the services belonging to that application, if a service is failing the application might be automatically hidden from the end users. This can be achieved by creating new Ingress or new Gateway Routes for Istio
 3. Manage multiple applications deployed in the same cluster
 4. Control the applications topology and isolation with other Applications
 5. Share infrastructure (Registry, SSO, maybe datastores) between different applications
@@ -108,13 +108,13 @@ The Operator will expose a set of APIs to fine tune the default behaviour and al
 - Delete an application (a whole set of services)
 - Expose / Hide an application (by integrating with a component that can route traffic)
 
-Because we are using CRDs we will be able to ask to the Kubernetes APIs about our JHipster Resources using for example the `kubectl` command.
+Because we are using CRDs we will be able to ask the Kubernetes APIs about our JHipster Resources using for example the `kubectl` command.
 
-An important aspect of the Operator is that it will not be in charge of deploying applications. Deployment should be done by standard tools such as HELM or the default Kubernetes APIs that we use after generatign the Kubernetes Manifests. The Operator responsability is to monitor and manage applications, not to deploy them.
+An important aspect of the Operator is that it will not be in charge of deploying applications. Deployment should be done by standard tools such as HELM, or the default Kubernetes APIs that we use after generating the Kubernetes Manifests. The Operator's responsibility is to monitor and manage applications, not to deploy them.
 
-The JHipster Kubernetes Operator can be built as a Spring Boot Starter meaning that it doesn't nesseraly needs to be it is own independent container it can be attached to an existing service if it is required.
+The JHipster Kubernetes Operator can be built as a Spring Boot Starter meaning that it doesn't necessarily need to be its own independent container it can be attached to an existing service if it is required.
 
-The Operator will provide an excelent entry point for domain specific extensions and integrations with other platform wide services such as Istio, KNative, Jenkins X (Tekton Pipelines), etc. It will provide the entry point for a Developer Workflow on top of Kubernetes.
+The Operator will provide an excellent entry point for domain specific extensions and integrations with another platform wide services such as Istio, KNative, Jenkins X (Tekton Pipelines), etc. It will provide the entry point for a Developer Workflow on top of Kubernetes.
 
 # Drawbacks
 

rfcs/2-jhipster-rfc-jhipster-control-center.md

@@ -137,6 +137,6 @@ Some existing similar or related solutions :
 Possible future evolutions:
 
 - Provide a plugin mechanism to let organizations customize the **JHipster Control Center** with custom features without forking
-- Seamlessly integrate with observablility tools such as ELK, Grafana and Zipkin
+- Seamlessly integrate with observability tools such as ELK, Grafana and Zipkin
 - Plug into service mesh telemetry services such as those provided by Istio
 - Integrate with the [JHipster Kubernetes Operator](https://github.com/jhipster/jhipster-operator)