A bit of cleanup on the arch doc (#7323)

* A bit of cleanup on the arch doc

* Replaced the confusing goals section with a minimal section on app's design

* Removed trailing spaces

* Clarfified sentence

Co-authored-by: Adam Miller <1402860+adammil2000@users.noreply.github.com>

content/en/docs/ops/deployment/architecture/index.md

@@ -25,12 +25,6 @@ The following diagram shows the different components that make up each plane:
     caption="Istio Architecture"
     >}}
 
-Traffic in Istio is categorized as data plane traffic and control plane traffic.
-Data plane traffic refers to the messages that the business logic of the workloads
-send and receive. Control plane traffic refers to configuration and control messages sent
-between Istio components to program the behavior of the mesh. Traffic management
-in Istio refers exclusively to data plane traffic.
-
 ## Components
 
 The following sections provide a brief overview of each of Istio's core components.
@@ -82,94 +76,41 @@ Some of the Istio features and tasks enabled by Envoy proxies include:
 * Pluggable extensions model based on WebAssembly that allows for custom policy
   enforcement and telemetry generation for mesh traffic.
 
-### Pilot
+### Istiod
 
-Pilot provides
+Istiod provides service discovery, configuration and certificate management.
-service discovery for the Envoy sidecars, traffic management capabilities
-for intelligent routing (e.g., A/B tests, canary rollouts, etc.),
-and resiliency (timeouts, retries, circuit breakers, etc.).
 
-Pilot converts high level routing rules that control traffic behavior into
+Istiod converts high level routing rules that control traffic behavior into
 Envoy-specific configurations, and propagates them to the sidecars at runtime.
 Pilot abstracts platform-specific service discovery mechanisms and synthesizes
 them into a standard format that any sidecar conforming with the
 [Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api/api) can consume.
 
-The following diagram shows how the platform adapters and Envoy proxies
+Istio can support discovery for multiple environments such as Kubernetes,
-interact.
+Consul, or VMs.
-
-{{< image width="40%" link="./discovery.svg" caption="Service discovery" >}}
-
-1.  The platform starts a new instance of a service which notifies its platform
-    adapter.
-
-1.  The platform adapter registers the instance with the Pilot abstract model.
-
-1.  **Pilot** distributes traffic rules and configurations to the Envoy proxies
-    to account for the change.
-
-This loose coupling allows Istio to run on multiple environments such as Kubernetes,
-Consul, or Nomad, while maintaining the same operator interface for traffic
-management.
 
 You can use Istio's
 [Traffic Management API](/docs/concepts/traffic-management/#introducing-istio-traffic-management)
-to instruct Pilot to refine the Envoy configuration to exercise more granular control
+to instruct Istiod to refine the Envoy configuration to exercise more granular control
 over the traffic in your service mesh.
 
-### Citadel
+Istiod [security](/docs/concepts/security/) enables strong service-to-service and
-
-[Citadel](/docs/concepts/security/) enables strong service-to-service and
 end-user authentication with built-in identity and credential management. You
-can use Citadel to upgrade unencrypted traffic in the service mesh. Using
+can use Istio to upgrade unencrypted traffic in the service mesh. Using
-Citadel, operators can enforce policies based on service identity rather than
+Istio, operators can enforce policies based on service identity rather than
 on relatively unstable layer 3 or layer 4 network identifiers. Starting from
 release 0.5, you can use [Istio's authorization feature](/docs/concepts/security/#authorization)
 to control who can access your services.
 
-## Design goals
+Istiod maintains a CA and generates certificates to allow secure mTLS communication
+in the data plane.
 
-A few key design goals informed Istio’s architecture. These goals are essential
+## Application design
-to making the system capable of dealing with services at scale and with high
-performance.
 
-* **Maximize Transparency**: To adopt Istio, an operator or developer is
+A design goal for Istio is that the developer can do minimum work
-  required to do the minimum amount of work possible to get real value from the
+to get real value from the system. Istio can automatically inject itself into
-  system. To this end, Istio can automatically inject itself into all the
+the network paths between services and program the networking layer to
-  network paths between services. Istio uses sidecar proxies to capture traffic
+securely route traffic and extract telemetry. If the application code
-  and, where possible, automatically program the networking layer to route
+uses TLS and uses its own policy and telemetry, Istio can only get minimal
-  traffic through those proxies without any changes to the deployed application
+information from the encrypted communication between workloads.
-  code. In Kubernetes, the proxies are injected into {{<gloss pod>}}pods{{</gloss>}} and traffic is
-  captured by programming ``iptables`` rules. Once the sidecar proxies are
-  injected and traffic routing is programmed, Istio can mediate all traffic.
-  This principle also applies to performance. When applying Istio to a
-  deployment, operators see a minimal increase in resource costs for the
-  functionality being provided. Components and APIs must all be designed with
-  performance and scale in mind.
 
-* **Extensibility**: As operators and developers become more dependent on the
-  functionality that Istio provides, the system must grow with their needs.
-  While we continue to add new features, the greatest need is the ability to
-  extend the policy system, to integrate with other sources of policy and
-  control, and to propagate signals about mesh behavior to other systems for
-  analysis. The policy runtime supports a standard extension mechanism for
-  plugging in other services. In addition, it allows for the extension of its
-  vocabulary to allow policies to be enforced based on new signals that the
-  mesh produces.
-
-* **Portability**: The ecosystem in which Istio is used varies along many
-  dimensions. Istio must run on any cloud or on-premises environment with
-  minimal effort. The task of porting Istio-based services to new environments
-  must be trivial. Using Istio, you are able to operate a single service
-  deployed into multiple environments. For example, you can deploy on multiple
-  clouds for redundancy.
-
-* **Policy Uniformity**: The application of policy to API calls between
-  services provides a great deal of control over mesh behavior. However, it can
-  be equally important to apply policies to resources which are not necessarily
-  expressed at the API level. For example, applying a quota to the amount of
-  CPU consumed by an ML training task is more useful than applying a quota to
-  the call which initiated the work. To this end, Istio maintains the policy
-  system as a distinct service with its own API rather than the policy system
-  being baked into the proxy sidecar, allowing services to directly integrate
-  with it as needed.