Replace ASCII topology diagram with Red Hat branded images

maximilianoPizarro · cursoragent · maximilianoPizarro · commit 1cae51f595f6 · 2026-06-15T20:27:40.000-03:00
- Remove ASCII art diagram from architecture.md (Red Hat branded images already exist)
- Use workshop-hybrid-mesh-arch.png + arch-hub-spoke-flow.png as visual topology
- Expand "Comparison" section to full "Relationship to VP patterns" with MCP/Lightspeed detail
- Add Red Hat Device Edge + MicroShift extension path in architecture.md and ideas-for-customization.md
- Update _index.md summary and Goal framing to include Device Edge extension path

Co-authored-by: Cursor &lt;cursoragent@cursor.com&gt;
diff --git a/content/patterns/hybrid-mesh-platform/_index.md b/content/patterns/hybrid-mesh-platform/_index.md
@@ -2,7 +2,7 @@
 title: Hybrid Mesh Platform
 date: 2026-06-15
 tier: sandbox
-summary: Hub-spoke multi-cluster GitOps on OpenShift with ACM, ambient Service Mesh, Skupper, Industrial Edge, and centralized observability.
+summary: Hub-spoke multi-cluster GitOps on OpenShift combining Service Mesh, AI-assisted operations (OpenShift Lightspeed + MCP), Industrial Edge, and a Red Hat Device Edge extension path via MicroShift.
 rh_products:
   - Red Hat OpenShift Container Platform
   - Red Hat Advanced Cluster Management
@@ -54,7 +54,7 @@ Operating a multi-cluster OpenShift fleet creates three compounding challenges t
 | **Fleet governance drift** | Each cluster managed independently; configurations diverge over time | Single `main` branch drives hub + east + west via ACM + dual GitOps (PUSH ApplicationSet + PULL clustergroup) |
 | **AI-assisted operations** | Operators react to incidents by parsing dashboards and YAML | OpenShift Lightspeed + MCP Gateway let operators act on platform state in natural language, reducing MTTA on infrastructure incidents |
 
-**Goal:** This pattern combines Red Hat Service Mesh for secure inter-service connectivity with OpenShift AI (MaaS + vLLM) and OpenShift Lightspeed + MCP for natural-language platform operations — giving teams centralized GitOps governance, secure cross-cluster communication, and AI-assisted incident response in a single deployable reference architecture.
+**Goal:** This pattern combines Red Hat Service Mesh for secure inter-service connectivity with OpenShift AI (MaaS + vLLM) and OpenShift Lightspeed + MCP for natural-language platform operations — giving teams centralized GitOps governance, secure cross-cluster communication, and AI-assisted incident response in a single deployable reference architecture. For physically constrained factory devices, the architecture extends naturally to **Red Hat Device Edge** with **MicroShift**, managed by the same ACM placement rules without hub-side changes.
 
 > **Your journey:** Install via the Validated Patterns framework (`./pattern.sh install`), connect three OpenShift clusters (hub + east + west) through ACM `managedClusterGroups`, and observe IoT sensor data across Grafana and Developer Hub. The pages below follow one continuous story — concept, install, operate, scaffold.
 
diff --git a/content/patterns/hybrid-mesh-platform/architecture.md b/content/patterns/hybrid-mesh-platform/architecture.md
@@ -23,32 +23,15 @@ Spokes remain the execution venues for application namespaces, data-plane compon
 
 ## Multi-cluster topology: three required clusters
 
-This pattern requires **three OpenShift clusters** — not a single-cluster deployment. The topology follows the Validated Patterns hub-spoke model:
-
-```
-              ┌──────────────────────────────────────┐
-              │  Hub cluster (OpenShift on AWS)       │
-              │  ACM · Argo CD · Developer Hub · RHOAI│
-              │  ACS Central · Grafana · Skupper ·    │
-              │  Kuadrant · OpenShift Lightspeed · MCP│
-              └──────┬─────────────────┬──────────────┘
-          ACM push   │                 │  ACM push
-           GitOps    │                 │  GitOps
-              ┌──────▼───────┐  ┌──────▼───────┐
-              │ East spoke   │  │ West spoke   │
-              │ Industrial   │  │ Industrial   │
-              │ Edge · Kafka │  │ Edge · Kafka │
-              │ Camel K · ML │  │ MirrorMaker  │
-              │ DevSpaces    │  │ Skupper      │
-              └──────────────┘  └──────────────┘
-       ◄────────── Skupper VAN (mTLS, outbound-only) ──────────►
-```
-
-Hub and spokes communicate over a **Skupper Virtual Application Network** — outbound-only mTLS tunnels, no inbound firewall rule changes needed. The hub's `ApplicationSet` pushes spoke charts; each spoke's local Argo CD pulls its `clusterGroup` from Git autonomously.
+This pattern requires **three OpenShift clusters** — not a single-cluster deployment. The topology follows the Validated Patterns hub-spoke model: one **hub** for fleet governance and two **spokes** for factory workloads. Hub and spokes communicate over a **Skupper Virtual Application Network** (outbound-only mTLS — no inbound firewall rule changes needed). The hub's `ApplicationSet` pushes spoke charts; each spoke's local Argo CD pulls its `clusterGroup` from Git autonomously.
+
+[![Hybrid Mesh Platform — hub-spoke component map](/images/hybrid-mesh-platform/workshop-hybrid-mesh-arch.png)](/images/hybrid-mesh-platform/workshop-hybrid-mesh-arch.png)
+
+_Platform component map: hub hosts fleet governance and AI services; east and west spokes host Industrial Edge workloads. Skupper VAN bridges cross-cluster service traffic without VPN._
 
 ## Platform architecture overview
 
-![Hub-spoke platform — Git paths, ApplicationSet, Skupper VAN, and per-cluster components](/images/hybrid-mesh-platform/arch-hub-spoke-flow.png)
+[![Hub-spoke platform — Git paths, ApplicationSet, Skupper VAN, and per-cluster components](/images/hybrid-mesh-platform/arch-hub-spoke-flow.png)](/images/hybrid-mesh-platform/arch-hub-spoke-flow.png)
 
 *Single `main` branch: hub at `charts/region/hub`, spokes at `charts/region/east` and `charts/region/west`, shared charts under `charts/all/`.*
 
@@ -129,11 +112,34 @@ Each spoke runs a **Gateway API gateway** that fronts all Industrial Edge servic
 
 ![Industrial Edge data flow — sensors through MQTT, Camel, Kafka to Grafana and data lake](/images/hybrid-mesh-platform/arch-data-flow.png)
 *Telemetry path on each spoke; MirrorMaker replicates to the hub-centralized MinIO data lake.*
-## Comparison with Red Hat Validated Patterns
+## Relationship to Red Hat Validated Patterns
+
+The **[Multicloud GitOps](https://validatedpatterns.io/patterns/multicloud-gitops)** validated pattern demonstrates fleet GitOps with OpenShift GitOps and ACM — a declarative root Application, cluster grouping, and progressive rollout. Hybrid Mesh Platform forks that foundation and extends it with:
+
+- **Industrial Edge** factory telemetry (MQTT → Kafka → ML → dashboards) on east/west spokes
+- **Service Mesh 3 ambient mode** — L4 encryption without sidecars
+- **Service Interconnect (Skupper)** — cross-cluster service exposure without VPN
+- **Connectivity Link (Kuadrant)** — API-aware Gateway API ingress with rate limits and API keys
+- **OpenShift AI (RHOAI)** — hub-resident MaaS inference (Qwen3 / Granite via vLLM) for factory AI pipelines
+- **OpenShift Lightspeed + MCP Gateway** — natural-language platform operations via `OLSConfig` and a dual MCP server (Quarkus 19 tools + Go SDK 21 tools), enabling operators to query and act on cluster state without raw YAML
+
+## Red Hat Device Edge extension path
+
+The current spokes run **full OpenShift clusters** (3 workers, cloud or bare-metal). For physically constrained factory devices — industrial controllers, single-board computers, ruggedized appliances — the natural extension is **Red Hat Device Edge** with **MicroShift**.
+
+[**Red Hat Device Edge**](https://www.redhat.com/en/technologies/device-edge) combines **Red Hat Enterprise Linux** with **MicroShift**, a minimal OpenShift-compatible Kubernetes runtime optimized for edge hardware with as little as 2 CPU cores and 2 GiB RAM. MicroShift exposes the same Kubernetes API surface as OpenShift, so ACM can manage it as a `ManagedCluster` alongside full OpenShift spokes.
+
+In a Hybrid Mesh Platform extension:
 
-The **[Multicloud GitOps](https://validatedpatterns.io/patterns/multicloud-gitops)** validated pattern demonstrates fleet GitOps with OpenShift GitOps and ACM patterns that resemble this repository's hub-push model: a declarative root Application, cluster grouping, and progressive rollout.
+| Layer | Current spokes | Far-edge extension |
+| --- | --- | --- |
+| Runtime | OpenShift 4.17+ (3 workers) | MicroShift on RHEL (single node) |
+| Management | ACM ManagedCluster | ACM ManagedCluster (same placement rules) |
+| Workloads | Industrial Edge — Kafka, Camel K, ML | Lightweight sensors, MQTT bridge, edge inference |
+| Connectivity | Skupper VAN (full) | Skupper VAN (single-pod footprint) |
+| GitOps | clusterGroup PULL via ACM | clusterGroup PULL via ACM |
 
-This platform extends that idea with **Industrial Edge** workloads, **Service Mesh ambient**, **Connectivity Link**, optional **OpenShift AI**, **ACS** depth, and **Service Interconnect** for cross-cluster service exposure -- tuned for factory-style telemetry and east-west observability rather than only infrastructure provisioning.
+This extension path is not deployed in the current sandbox tier implementation, but the ACM placement model and Skupper VAN are designed to accommodate MicroShift spokes with no hub-side changes.
 
 ---
 
@@ -142,6 +148,8 @@ This platform extends that idea with **Industrial Edge** workloads, **Service Me
 ## Official documentation
 
 - [ACM Architecture](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.16/html/about/welcome-to-red-hat-advanced-cluster-management-for-kubernetes)
+- [Red Hat Device Edge](https://www.redhat.com/en/technologies/device-edge)
+- [MicroShift documentation](https://docs.redhat.com/en/documentation/red_hat_build_of_microshift)
 - [Multicloud GitOps Pattern](https://validatedpatterns.io/patterns/multicloud-gitops)
 - [Red Hat Service Interconnect](https://docs.redhat.com/en/documentation/red_hat_service_interconnect/2.1)
 - [Kubernetes Gateway API](https://gateway-api.sigs.k8s.io/)
diff --git a/content/patterns/hybrid-mesh-platform/ideas-for-customization.md b/content/patterns/hybrid-mesh-platform/ideas-for-customization.md
@@ -81,6 +81,22 @@ Disables heavy subscriptions while preserving GitOps bootstrap and ApplicationSe
 | OpenShift version | Validate on 4.20+; align operator channels per release |
 | Developer Hub | Extend software templates under `docs/assets/backstage/software-templates/` |
 
+## Red Hat Device Edge with MicroShift
+
+The current spokes require full OpenShift clusters (3 workers, cloud or bare-metal). For physically constrained factory locations — industrial controllers, single-board computers, ruggedized appliances — the pattern extends to **Red Hat Device Edge** with **MicroShift**.
+
+[**Red Hat Device Edge**](https://www.redhat.com/en/technologies/device-edge) bundles RHEL with **MicroShift**, a minimal OpenShift-compatible runtime that runs on hardware with as little as 2 CPU cores and 2 GiB RAM. Because MicroShift exposes the Kubernetes API, ACM manages it as a `ManagedCluster` with the same placement rules used for full OpenShift spokes — no hub changes required.
+
+### Extending the pattern for MicroShift spokes
+
+1. Provision a RHEL device with MicroShift installed (`rpm-ostree install microshift`).
+2. Import the device into ACM as a `ManagedCluster` with labels `region=far-edge`.
+3. Add a new folder (for example `far-edge/`) in the pattern repo with a lightweight values profile — omit Kafka 3-replica and DevSpaces; keep MQTT bridge, Camel K lite, and Skupper.
+4. Register a Skupper `AccessToken` on the device (same outbound-only mTLS as cloud spokes).
+5. Hub Grafana aggregates metrics from the far-edge site the same way it does from east/west.
+
+This extension is documented as a future topology in [Architecture — Red Hat Device Edge extension path](architecture#red-hat-device-edge-extension-path). It is not deployed in the current sandbox tier.
+
 ## Related patterns
 
 - [Multicloud GitOps](/patterns/multicloud-gitops) — fleet GitOps and ACM placement patterns
