Why Ops Still Needs a Control Plane (Why Ops Still Needs A Control Plane)

Making everything a remote is not a strategy

Module Federation speeds auth and booking. Expedition maps, advert/document surfaces, and push admin often still want a broad, cross-cutting control plane.

Federated estate          Control plane (ops monolith)
 auth remote                 map / expeditions
 booking remote              CMS-like content
 snackbar remote             push admin + ERP edge

This series covers deliberate coexistence of control plane and MFE estate.

Concepts, defined where they first appear

📦 Control Plane
Broad surface where operational truths are managed together.

📦 Federated Estate
Independently shipped UI set of shell + remotes.

📦 Coexistence
Architecture where monolith and MFE live side by side on purpose.

📦 Cross-cutting Surface
UI that cuts many domains; expensive to split early.

A control plane is not 'legacy shame'; it is a surface too cross-cutting to remote yet.

Why not everything remotes

Map + warehouse + content + ERP edge do not migrate on one day.

What becomes a remote

Surfaces with clear bounded context and team cadence (auth, booking).

Clear boundary → remote candidate

What stays on the control plane

Cross reports, CMS-like content, push admin, heavy GIS.

The mappings that get confused most often

❌ Monolith = failed MFE
✓ Monolith can be a deliberate control plane

❌ Snackbar remote = push admin
✓ Different responsibilities

❌ ERP screen = core domain
✓ ERP is an edge, not the core

A checklist for auditing your own system

1. Which screens still share one pipeline?
2. Where does push admin live?
3. Which API edge does the map trust?
4. What is the next MFE migration candidate?
5. Is your coexistence diagram current?

What to take away from this part

1. A control plane is a deliberate boundary.
2. Snackbar and push admin are not the same thing.
3. Coexistence is part of the migration plan.

Turning every panel into a remote is haste, not architecture.