Syntax, grammar and basic cleanup. (#4575)

Co-authored-by: 吴晟 Wu Sheng <wu.sheng@foxmail.com>

docs/en/concepts-and-designs/overview.md

 # Overview
-SkyWalking: an open source observability platform to collect, analyze, aggregate and visualize data from services and cloud native
-infrastructures. SkyWalking provides an easy way to keep you have a clear view of your distributed system, even across Cloud.
-It is more like a modern APM, specially designed for cloud native, container based and distributed system.
+SkyWalking: an open source observability platform used to collect, analyze, aggregate and visualize data from services and cloud native
+infrastructures. SkyWalking provides an easy way to maintain a clear view of your distributed systems, even across Clouds.
+It is a modern APM, specially designed for cloud native, container based distributed systems.
 
 ## Why use SkyWalking?
-SkyWalking provides solutions for observing and monitoring distributed system, in many different scenarios. First of all,
-like traditional ways, SkyWalking provides auto instrument agents for service, such as Java, C#
-and Node.js. At the same time, it provides manual instrument SDKs for Go(Not yet), C++(Not yet).
-Also with more languages required, risks in manipulating codes at runtime, cloud native infrastructures grow 
-more powerful, SkyWalking could use Service Mesher infra probes to collect data for understanding the whole distributed system.
-In general, it provides observability capabilities for **service**(s), **service instance**(s), **endpoint**(s).
-
-The concepts of Service, Instance and Endpoint are used everywhere today, so let's make it clear about what they mean in SkyWalking first.
-
-- **Service**. Represent a set/group of workloads to provide the same behaviours for incoming requests. You can define the service
-  name when you are using instrument agents or SDKs. Or SkyWalking uses the name you defined in platform such as Istio.
-- **Service Instance**. Each one workload in the Service group is named as an instance. Like `pods` in Kubernetes, it doesn't need
-  to be a single process in OS. Also if you are using instrument agents, an instance is actually a real process in OS.
-- **Endpoint**. It is a path in the certain service for incoming requests, such as HTTP URI path or gRPC service class + method
-signature. 
-
-By using SkyWalking, you can have the topology relationship between Services and Endpoints, metrics of every Service, Service
-Instance and Endpoint and set alarm rules.
-
-In addition to all these, you can have distributed tracing from SkyWalking native agents and SDKs, also by using Zipkin, Jaeger
+SkyWalking provides solutions for observing and monitoring distributed systems, in many different scenarios. First of all,
+like traditional approaches, SkyWalking provides auto instrument agents for services, such as Java, C#
+and Node.js. Skywalking also offers a community contributed manual instrument SDK for Go (with calls out for Python and 
+C++ SDK contributions). In multilanguage, continuously deployed environments, cloud native infrastructures grow more powerful
+but also more complex. SkyWalking's service mesh receiver allows SkyWalking to receive telemetry data from service mesh frameworks
+such as Istio/Envoy and Linkerd, allowing users to understanding the entire distributed system.
+
+SkyWalking provides observability capabilities for **service**(s), **service instance**(s), **endpoint**(s). The terms Service,
+Instance and Endpoint are used everywhere today, so it is worth defining their specific meanings in the context of SkyWalking:
+
+- **Service**. Represents a set/group of workloads which provide the same behaviours for incoming requests. You can define the service
+  name when you are using instrument agents or SDKs. SkyWalking can also use the name you define in platforms such as Istio.
+- **Service Instance**. Each individual workload in the Service group is known as an instance. Like `pods` in Kubernetes, it 
+  doesn't need to be a single OS process, however, if you are using instrument agents, an instance is actually a real OS process.
+- **Endpoint**. A path in a service for incoming requests, such as an HTTP URI path or a gRPC service class + method signature. 
+
+SkyWalking allows users to understand the topology relationship between Services and Endpoints, to view the metrics of every 
+Service/Service Instance/Endpoint and to set alarm rules.
+
+In addition, you can integrate distributed tracing useing SkyWalking native agents and SDKs with Zipkin, Jaeger
 and OpenCensus.
 
 ## Architecture
-The SkyWalking is logically split into four parts: Probes, Platform backend, Storage and UI.
+SkyWalking is logically split into four parts: Probes, Platform backend, Storage and UI.
 
 <img src="http://skywalking.apache.org/assets/frame.jpeg"/>
 
-- The **Probe**s are different based on different sources. They collect data and reformat them in SkyWalking requirements.
-- The **Platform backend** is a backend, supported cluster for sure. It is for aggregation, analysis and driving process flow
-from probe to UI. It also provides the pluggable capabilities for incoming formats(like Zipkin's), storage implementors and cluster
- management. You even can customize aggregation and analysis by using [Observability Analysis Language](oal.md).
-- The **Storage** is open. You can, either choose an existed implementor, such as ElasticSearch, H2 or MySQL cluster managed by 
-Sharding-Sphere, or implement your own. Of course, we are very appreciated to have your contributions for new storage implementors.
-- The **UI** is cool and very powerful for SkyWalking end users. It is also customizable to match your customized backend.
+- **Probe**s collect data and reformat them for SkyWalking requirements (different probes support different sources).
+- **Platform backend**, supports data aggregation, analysis and drives process flow from probes to the UI. It also provides 
+  the pluggable capabilities for incoming formats (like Zipkin's), storage implementors and cluster management. You even can 
+  customize aggregation and analysis by using [Observability Analysis Language](oal.md).
+- **Storage** houses SkyWalking data through an open/plugable interface. You can choose an existing implementation, such as
+  ElasticSearch, H2 or a MySQL cluster managed by Sharding-Sphere, or implement your own. Patches for new storage implementors 
+  welcome!
+- **UI** a highly customizale web based interface allowing SkyWalking end users to visualize and manage SkyWalking data.
 
 
 ## What is next?