Ops Neden Hâlâ Bir Control Plane İster? (Ops Neden Hala Control Plane İster)

Her şeyi remote yapmak bir strateji değildir

Module Federation booking ve auth'u hızlandırır. Ama sefer haritası, ilan/doküman yüzeyleri ve push admin çoğu zaman geniş, çapraz kesen bir control plane ister.

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

Bu seri, control plane ile MFE estate'in bilinçli birlikteliğini anlatır.

Kavramlar ilk geçtiği yerde

📦 Control Plane
Operasyonel gerçeklerin bir arada yönetildiği geniş yüzey.

📦 Federated Estate
Shell + remote'lardan oluşan bağımsız yayınlanan UI seti.

📦 Coexistence
Monolit ve MFE'nin yan yana yaşadığı bilinçli mimari.

📦 Cross-cutting Surface
Birden fazla domaini kesen, erken parçalanması pahalı UI.

Control plane 'eski kod' değildir; henüz remote olmayacak kadar çapraz kesen yüzeydir.

Neden her şey remote olmaz

Harita + depo + içerik + ERP kenarı aynı günde migrate edilmez.

Ne remote olur

Net bounded context ve ayrı ekip ritmi olan yüzeyler (auth, booking).

Clear boundary → remote candidate

Ne control plane'de kalır

Çapraz rapor, CMS benzeri içerik, push admin, ağır GIS.

Bu bölümde en çok karışan eşleştirmeler

❌ Monolit = başarısız MFE
✓ Monolit = bilinçli control plane olabilir

❌ Snackbar remote = push admin
✓ İkisi farklı sorumluluklar

❌ ERP ekranı = iç domain
✓ ERP bir kenardır, çekirdek değil

Kendi sisteminizi denetleme listesi

1. Hangi ekranlar hâlâ tek pipeline'da?
2. Push admin hangi uygulamada yaşıyor?
3. Harita hangi API kenarına güveniyor?
4. MFE'ye taşınacak sonraki aday nedir?
5. Coexistence diyagramınız güncel mi?

Bu bölümden aklında kalması gerekenler

1. Control plane bilinçli bir sınırdır.
2. Snackbar ve push admin aynı şey değildir.
3. Coexistence, göç planının parçasıdır.

Her paneli remote yapmak, mimari değil aceleciliktir.