Another pass on a manaual page

docs/self-managed/reference-architecture/manual/manual-overview.md

@@ -1,7 +1,8 @@
 ---
 id: manual-overview
-title: "Manual Overview"
+title: "Manual Deployment option overview"
 sidebar_label: "Overview"
+description: "Camunda 8 Manual (Java) deployment Reference architecture home "
 ---
 
 <!-- Could also be called manual? -->
@@ -11,15 +12,24 @@ sidebar_label: "Overview"
 <!-- Day 1 vs Day 2 operations? -->
 <!-- Installation vs Operations -->
 
-## Preface
+# Reference Architectures Overview: Manual Deployment
 
-The Single JAR deployment option allows you to run Camunda Platform as a standalone Java application. This method is particularly suited for users who prefer manual deployment on bare metal servers or virtual machines (VMs). It provides full control over the environment and configuration, making it ideal for scenarios where custom setups or specific infrastructure requirements are necessary.
+This section of the Camunda Deployment Reference Architectures provides guidance on deploying Camunda Platform as a standalone Java application. This deployment method is ideal for users who prefer manual deployment on bare metal servers or virtual machines (VMs), offering full control over the environment and configuration. It is particularly suited for scenarios with specific infrastructure requirements or highly customized setups.
 
-With the Single JAR approach, all necessary components are bundled into a single executable JAR file. This simplifies the deployment process, as you only need to manage one artifact. However, it also means that you are responsible for handling all aspects of the deployment, including installation, configuration, scaling, and maintenance.
+## Key Features
 
-Other deployment options, such as containerized deployments or managed services, might offer more convenience and automation. However, the Single JAR method gives you the flexibility to tailor the deployment to your exact needs, which can be beneficial for complex or highly customized environments.
+- **Single application JAR**: Starting from Camunda 8.7, all core components (Zeebe, Tasklist, Operate, Optimize, and Identity) are bundled into a single JAR file. This simplifies deployment by reducing the number of artifacts to manage.
+- **Full Control**: Users are responsible for all aspects of deployment, including installation, configuration, scaling, and maintenance. This offers maximum flexibility for custom environments.
 
-We will later go into the details but be aware that not everything is part of this Single JAR. Have a look at [the documentation](/self-managed/reference-architecture/reference-architecture.md#orchestration-cluster-vs-web-modeler-and-console) on the orchestration and management cluster separation.
+Other deployment options, such as containerized deployments or managed services, might offer more convenience and automation. However, VM based deployment gives you the flexibility to tailor the deployment to your exact needs, which can be beneficial for regualted or highly customized environments.
+
+For documentation on the orchestration cluster, Web Modeler and Console separation, refer to  [the documentation](/self-managed/reference-architecture/reference-architecture.md#orchestration-cluster-vs-web-modeler-and-console)
+
+## Reference implementations
+
+This section includes deployment reference architectures for manual setups:
+
+- [Aamazon EC2 deployment](./aws-ec2.md) - is a standard production setups with support for high availability.
 
 ## Before You Start
 
@@ -28,30 +38,30 @@ Before you begin with the self-managed single JAR setup, please consider the com
 ## Limitations
 
 - The focus is on the orchestration cluster. This includes the single JAR compromised of Identity, Operate, Optimize, Tasklist, and Zeebe. AS well as the Connectors runtime.
-- General guidance and examples are with focus on **unix** users but can be adapted by Windows users with the use of e.g. [WSL](https://learn.microsoft.com/en-us/windows/wsl/install) or included `batch` files.
-- The `Optimize importer` is still based on the old architecture and is not suitable for high availability and needs to only run once.
+- General guidance and examples will focus on **unix** users but can be adapted by Windows users with the use of e.g. [WSL](https://learn.microsoft.com/en-us/windows/wsl/install) or included `batch` files.
+- The deployment of `Optimize` is still based on the old architecture and must run on a single node.
 
 ## Architecture
 
 <!-- TODO: switch placeholder pictures to the new miro approach of Léo -->
 
 ![Single JAR](./img/placeholder-manual-single.drawio.png)
 
-The above depiction showcases a simple use case of a single machine with a single Camunda deployment of the single JAR.
-
-The single jar and manual way of deploying Camunda can be used for either simple architectures or high availability setups. Be aware that maintaining such setups is a lot more work compared to a solution like Kubernetes.
+This above diagram illustrates a single-machine deployment using the single JAR package. While simple and effective for lightweight setups, scaling to multiple machines requires careful planning.
 
 Compared to the generalized architecture depicted in the [reference architecture](../reference-architecture.md#architecture), the `Optimize importer` can be enabled as part of the single JAR.
 
+### High Availability (HA)
+
 :::note
 When scaling from a single machine to multiple machine, ensure that the `Optimize importer` is enabled on only one machine and disabled on the others. Enabling it on multiple machines will cause data inconsistencies. This limitation is known and will be addressed in future updates.
 :::
 
-### High availability
+### High availability (HA)
 
 ![HA JAR](./img/placeholder-manual-ha.drawio.png)
 
-The above depiction showcases a minimum of three machines for a high availability setup. Two machines would be too little for high availability as no master can be elected in case of a machine failure. Consider having a read through the [clustering chapter](/components/zeebe/technical-concepts/clustering.md) to learn more about the raft protocol.
+For high availability, a minimum of three machines is recommended to ensure fault tolerance and enable master election in case of failures. Refer to the [clustering chapter](/components/zeebe/technical-concepts/clustering.md) to learn more about the raft protocol and clustering concepts.
 
 ### Components
 
@@ -70,7 +80,7 @@ The core facilitates:
 
 Both types of endpoints can be routed through a load balancer to maintain availability, ensuring that the system remains accessible even if a machine becomes unavailable. While using a load balancer is optional, it is recommended for enhanced availability and security. Alternatively, you can expose static machines, ports, and IPs directly. However, direct exposure is generally discouraged due to security concerns.
 
-Connectors expose additional HTTP endpoints for handling incoming webhooks, which can also be routed through the same http load balancer.
+Connectors expose additional HTTP(s) endpoints for handling incoming webhooks, which can also be routed through the same http load balancer.
 
 The orchestration components rely on **Elasticsearch** or **OpenSearch** as their data store.
 
@@ -86,17 +96,11 @@ Before implementing a reference architecture, review the requirements and guidan
 
 Any of the following are just suggestions for the minimum viable setup, the sizing heavily depends on your use cases and usage. It is recommended to understand the documentation on [sizing your environment](/components/best-practices/architecture/sizing-your-environment.md) and run benchmarking to confirm your required needs.
 
-#### Host
+#### Minimum Requirements Per Host
 
-- Variable amount of host systems
-  - **1** minimum and **3** minimum for high availability (HA)
-
-Per host:
-
-- Minimum of **4** CPU cores (**amd64** / **arm64**)
-- Minimum of **8** GB of Memory
-- **32** GB SSD disk (**1,000** IOPS)
-  - We advise against using "burstable" disk types because of their inconsistent performance.
+- CPU: 4 cores (amd64/arm64)
+- Memory: 8 GB RAM
+- Storage: 32 GB SSD (**1,000** IOPS recommended; avoid burstable disk types)
 
 #### Networking
 
@@ -123,9 +127,3 @@ Some ports can be overwritten and are not definitive, you may conduct the [docum
 - Elasticsearch / OpenSearch, see [supported environments](/reference/supported-environments.md) for version details.
 
 Our recommendation is to use an external managed offer as we will not go into detail on how to manage and maintain your database.
-
-## Reference implementations
-
-Designed and tested for default setups with the minimum required sizing in mind while supporting high availability.
-
-- [AWS EC2](./aws-ec2.md)