Lattice.Hub
GitHub

WHY POLE / PRODUCT LANDSCAPE

Before comparing products,separate the layers they occupy.

Not every project labeled “service governance” solves the same problem. Pole unifies resources, permissions, and release; other systems may be protocol entry points, peer control planes, full Mesh stacks, or data planes that execute traffic.

View six relationshipsRead technical comparison

01 / LAYERS, NOT LOGOS

Start with responsibility layers, then feature lists.

A flat logo grid mixes control planes, Mesh, and data planes. The three layers below show each product’s real system boundary.

01

Registry, configuration, and governance control plane

Nacos · Apollo · Consul · PolarisMesh · Pole

Decides which resources are managed, how authorization works, and when change enters runtime.

02

Full Service Mesh ecosystem

Istio

Owns Mesh control plane, data plane, security, and telemetry together.

03

Service Mesh data plane

Kmesh

Executes load balancing, security, and governance on the business traffic path.

READ THE RELATIONSHIP

Current protocol compatibilityPeer control-plane comparisonCapability overlap / domain splitComposition direction / not yet direct

02 / SIX RELATIONSHIPS

Not who replaces whom—but who owns what.

Each item states the current relationship and boundaries that must not be crossed. Protocol compatibility proves an access path exists—it does not inherit the other product’s full behavior.

01

Registration / configuration

Nacos

Current protocol compatibility

Keep clients; converge the control plane gradually.

Pole provides Nacos v1 / v2 protocol entry to serve existing registration, discovery, and configuration clients.

BOUNDARY

Not equivalent to replicating all Nacos Console, SDK, and ecosystem extensions.Official source
02

Configuration center

Apollo

Current protocol compatibility

Bring configuration into one service change chain.

Pole supports Apollo configuration client access and places configuration with services and governance in one runtime environment.

BOUNDARY

Protocol access is not item-by-item equivalence with Apollo’s full management plane and Open API.Official source
03

Registration / basic KV / Mesh

Consul

Capability comparison / no direct protocol yet

Registration reference; configuration needs layered judgment.

Consul natively covers Catalog, health checks, DNS/HTTP discovery, and basic KV; Pole emphasizes versioned configuration and unified governance release.

BOUNDARY

Pole has no Consul-compatible entry today; basic KV is not equivalent to a full configuration release center.Official source
04

Integrated governance control plane

PolarisMesh

Peer comparison

The closest peer control-plane reference to Pole.

Both cover discovery, configuration, and governance; Pole further strengthens unified release semantics, AI capability catalogs, and multi-runtime boundaries.

BOUNDARY

Polaris protocol compatibility does not mean all Polaris SDK, Sidecar, and Controller pieces are equivalently replaced.Official source
05

Full Service Mesh

Istio

Capability overlap / splittable domains

Full Mesh vs unified control plane—divide ownership.

Istio owns Mesh traffic, security, and telemetry; Pole targets services, configuration, governance, and multi-protocol entry.

BOUNDARY

Pole’s Envoy xDS does not replace Istiod or fully support Istio API and ambient modes.Official source
06

eBPF Mesh data plane

Kmesh

Composition direction / not yet direct

Data-path candidate—not a control-plane replacement.

Kmesh enforces governance on node eBPF and Waypoint; Pole may study serving as its upper resource and release control plane.

BOUNDARY

Mutual xDS support does not imply out-of-the-box integration—resource adaptation and E2E validation are still required.Official source

03 / START FROM TODAY

Start from the system you already run.

Migration order should follow each system’s authoritative responsibilities—not a feature checklist.

  1. 01Running Nacos

    Keep client protocols first; validate registration, configuration, and canary semantics before gradually migrating the management plane.

  2. 02Running Apollo

    Start with configuration access; then decide whether to converge discovery and governance into Pole.

  3. 03Running Consul

    Separate DNS/HTTP discovery, basic KV, and Consul Mesh; Pole has no direct Consul protocol today.

  4. 04Running PolarisMesh

    Verify SDK, rules, Controller, and data plane item by item—this is control-plane migration, not a URL change.

  5. 05Running Istio

    Decide who owns routing and security policy authority; avoid Pole and Istiod controlling the same data plane.

  6. 06Evaluating Kmesh

    Treat it as a data-plane technology choice; direct Pole–Kmesh integration remains a direction to validate.

POLE OWNS THE CHANGE MODEL

Entry points may stay; change must stay explainable.

01Multi-protocol access

Keep familiar client entry points

02Unified resource model

Environment, services, configuration, governance

03Deterministic release

Draft, version, canary, and rollback

04Multi-runtime consumption

SDK, Proxy, and Gateway

VERIFY BEFORE YOU MIGRATE

Confirm ownership before designing the migration path.

Read full technical comparison View Pole architecture