ESKİ SİSTEM GEÇİŞ SİMÜLATÖRÜ
Strangler Fig
Kurgusal bir monolitin iş akışlarını bir yönlendirme katmanının arkasında tek tek yeni sisteme taşı. Tek hamlede her şeyi değiştirdiğin bir hafta sonu yok: her adımın bir bedeli ve bir riski var.
- Yönlendirme katmanını kur.
- Her sprintte ekibin kapasitesini harca: modülleri geliştir, paralel çalıştır, yönlendir.
- Eski kodu kaldır; destek taleplerini, tutarsızlığı ve bakım yükünü izle.
- Sprint
- 0 / 12
- Yeni sistemde
- %0
- Destek talepleri
- 0bu sprintte 0
- Tutarsız veri
- 0kayıt
- Sonraki sprint kapasitesi
- 10 / 12 puan
- İlk taşınan kullanıcılar
- Henüz yok
Sistem haritası
0. sprint- Yıldız boyu: günlük kullanım
- Renk: risk (turkuaz düşük, turuncu orta, mercan yüksek)
- Mor halka: eski oturum kodunu kullanıyor (oturum köprüsü kurulana kadar kesikli, sonra düz)
- Çizgi: ortak tablolar (kesikli turuncu: tutarsızlaşıyor)
- Kesikli turkuaz: senkron köprüsüyle eşzamanlı tutuluyor
- Soluk iz: eski kod hâlâ duruyor, yani geri dönüş yolu
- Mercan renkli nabız: gösterilen sprintte destek talebi var
Sprint günlüğü
0. sprintNeler olduğunu görmek için bir sprint çalıştır.
Rehber ve duyurular
Personel rehberi
MonolitteBir çalışma arkadaşının masasını, telefonunu ve ekibini bul.
- Günlük kullanım
- 10 / 10
- Geliştirme emeği
- 2 puan
- Risk
- Düşük risk
- Veri
- Yalnızca okuyor
- Oturum
- Ortak oturum koduna bağlı değil
- Tablo paylaştığı modüller
- Duyurular
Kullanıcılara monolit yanıt veriyor.
Bu modül için adımlar
Yeni sürümü geliştir
2 puanKazanç Sonraki sprintte paralel çalıştırılabilir ya da yönlendirilebilir. Henüz hiçbir kullanıcı görmez.
Risk Trafik ona geçene kadar hiçbir değer üretmez.
1. sprint planı
10 puanın 0 puanı planlandı- Monolit bakımı
- 2
- Paralel çalıştırma incelemesi
- 0
- Çift bakım
- 0
- Acil düzeltmeler
- 0
Henüz bir şey planlanmadı. Bir modül seç ya da sprinti öneriyle doldur.
Öneriler yalnızca senin görebildiklerini kullanır; gizli hataları asla kullanmaz.
Geçiş mimarisi
Yönlendirme katmanı
3 puanKazanç Her istek, kontrolü sende olan tek bir yönlendiriciden geçer. O olmadan hiçbir modül taşınamaz.
Risk Geçiş mimarisi: sonunda kaldırılmak üzere kurulur ve tek hata noktasına ya da darboğaza dönüşmemelidir. Bu model yalnızca kurulum bedelini sayar.
Oturum köprüsü
2 puanKazanç Hâlâ monolitin oturum koduna bağlı modüller paralel çalıştırılabilir ve yönlendirilebilir.
Risk Çalışır tutulması ve sonra kaldırılması gereken bir geçici parça daha. Bu model yalnızca kurulum bedelini sayar.
Senkron köprüleri, her ortak tablo grubu için bir tane
Kazanç İki yönlü senkron: ilk yükleme ve iki yönde değişiklik yakalama (CDC), eski ortak tablolarla yeni veri depolarını eşzamanlı tutar. Biriken tutarsızlığı giderir, yenisini önler ve paralel çalıştırmanın yazmaları da karşılaştırmasını sağlar.
Risk Gerçekte kümenin tamamı taşınana kadar bakım ister ve değişiklik yakalamada gecikme olur. Bu model yalnızca kurulum bedelini sayar ve onu anlık kabul eder.
- İdari işler
- Varlık ve erişim
- Finans
- İnsan kaynakları
Aynı sistem, tek seferde yeniden yazılsaydı
- Senin geçişin
- Tek seferde yeniden yazım
| Senin geçişin | Tek seferde yeniden yazım | |
|---|---|---|
| İlk taşınan kullanıcılar | — | 4. sprint |
| Şimdiye kadarki talepler | 0 | 255 |
| En kötü sprint | 0 | 180 |
| Monolit kapatıldı | — | 8. sprint |
| Yeni sistemdeki ortalama pay | — | — |
Yeniden yazım aynı ekibi, aynı geliştirme emeğini, aynı bakım yükünü ve aynı gizli hataları alıyor; her ortak tablo grubu için bir kez toplu kopyalama bedeli ödüyor. Yönlendirme katmanı ya da köprü kurmuyor, paralel çalıştırma yapmıyor. Üstelik en iyimser senaryo: kapsamı baştan tamamen biliniyor ve yazılırken hiçbir şey değişmiyor. Bu yüzden bu modelde daha erken bitebilir, hatta on iki sprintin ortalamasında yeni sistemde daha fazla trafik taşıyabilir. Karşılığında vazgeçtikleri: 4. sprintten önce kullanıcıya hiçbir fayda yok, gizli hataların hepsi aynı sprintte kullanıcılara ulaşıyor ve tek geri dönüş yolu sistemin tamamı.
Sprint sprint
| Sprint | Senin geçişin: Yeni sistemde | Senin geçişin: Destek talepleri | Tek seferde yeniden yazım: Yeni sistemde | Tek seferde yeniden yazım: Destek talepleri |
|---|---|---|---|---|
| 1 | — | — | %0 | 0 |
| 2 | — | — | %0 | 0 |
| 3 | — | — | %0 | 0 |
| 4 | — | — | %100 | 180 |
| 5 | — | — | %100 | 75 |
| 6 | — | — | %100 | 0 |
| 7 | — | — | %100 | 0 |
| 8 | — | — | %100 | 0 |
| 9 | — | — | %100 | 0 |
| 10 | — | — | %100 | 0 |
| 11 | — | — | %100 | 0 |
| 12 | — | — | %100 | 0 |
Dalga planı
Modülleri hangi sırayla taşıdığın, nedeni, her birinin nasıl doğrulandığı ve nasıl geri alınacağı. Senin denemenden üretilir.
Bu bir model, gerçeğin kendisi değil
Buradaki her şey öğretmek için kurgulandı. Monolit, on iki iş akışı, kullanım rakamları, gizli hatalar, destek talepleri ve kayıt sayıları uydurmadır; hiçbiri gerçek bir sistemden ya da işverenden gelmiyor. Yönlendirme her modül için ya hep ya hiç çalışıyor; gerçek bir yönlendirme katmanı trafiğin bir yüzdesini taşıyabilir. Yönlendirme katmanı ve köprüler burada yalnızca kurulum bedeli taşıyor; gerçek geçiş mimarisinin bakımı da yapılmalı, sonunda da kaldırılmalı. Senkron köprüsü iki yönlü ve anlık çalışıyor; gerçek değişiklik yakalamada gecikme olur. Şema değişikliği yok; insanlar, bütçeler ve kurum içi dengeler hesaba katılmıyor. Bedeller, boyutu sabit hayali bir ekibin puanları. Bir projeyi tahmin etmek için değil, sıralamayı ve ödünleşimleri düşünmek için kullan.
Lab’de daha derine inSCHEMA SHIFTExpand/contract adımları, backfill ve uyumluluk kapılarıyla sıfır kesintili bir migrasyon planla. (yeni sekmede açılır)Kurallar nereden geliyor
- Martin Fowler, “Strangler Fig Application” (2024 güncellemesi) (yeni sekmede açılır)
Adı ve fikri: yeni sistemi eskisinin etrafında küçük parçalarla büyütmek. Geçiş mimarisi israf gibi görünebilir, ama daha düşük risk ve daha erken değer bedelinden ağır basar.
- Microsoft Azure Architecture Center, “Strangler Fig pattern” (yeni sekmede açılır)
Her isteği eskiye ya da yeniye yönlendiren, tek hata noktasına ya da darboğaza dönüşmemesi gereken katman. İki sistemin aynı anda kullandığı veri depoları; ortak bir tablo grubu senkron olmadan bölününce tutarsızlığın nedeni bu. Eski nesneler kaldırılana kadar geri dönülebilir; sonrasında onları geri getirip veri değişikliklerini yeniden işlemek gerekir. Eski veritabanından yenisine ilk yükleme ve değişiklik yakalama.
- Cartwright, Horn ve Lewis, “Transitional Architecture” (2022) (yeni sekmede açılır)
Yönlendirme katmanı, köprüler ve senkron, atılacağı bilinerek yazılan geçici yazılımlardır.
- Cartwright, Horn ve Lewis, “Feature Parity” (2021) (yeni sekmede açılır)
Tek seferde yeniden yazım karşılaştırmasının neden en iyimser senaryo olduğu: eski sistemin yaptığı her şeyi karşılamanın emeği çoğu zaman fazlasıyla küçümsenir ve mevcut davranış belgelendikçe yeniden yazılacak yeni şeyler çıkar. Buradaki yeniden yazım böyle sürprizlerle karşılaşmıyor.
- GitHub, Scientist (kütüphane README’si) (yeni sekmede açılır)
Paralel çalıştırma: yeni yol karşılaştırılırken her zaman eski yolun sonucu döner; veriyi değiştiren kodu sarmalamak güvenli değildir. Yazmalar için README iki sisteme birden yazıp okuma sırasında kontrol etmeyi öneriyor. Bu model bunu basitleştiriyor: senkron köprüsü yokken yalnızca okumalar, köprü varken yazmalar da karşılaştırılır.
- Zalando Engineering, “Parallel Run Pattern” (2021) (yeni sekmede açılır)
Paralel çalıştırma ek yük ve emek getirir, idempotent olmayan yazmalarda dikkat ister ve uç noktaları tutarlı hâle geldikçe birer birer taşır.
- Pete Hodgson, “Feature Toggles” (2017) (yeni sekmede açılır)
Hızla geri çevrilebilen bir yönlendirme acil durdurma anahtarı gibi çalışır; yerinde bırakılan her anahtarın bir taşıma bedeli vardır.
- Microsoft Azure Architecture Center, “Implement the Transactional Outbox Pattern by Using Azure Cosmos DB” (yeni sekmede açılır)
Bir değişikliği kaydedip başka bir sisteme ortak bir işlem (transaction) olmadan haber vermek olayların kaybolmasına, kaybolan olaylar da verinin tutarsızlaşmasına yol açabilir. Bu modeldeki tutarsızlık daha kaba bir durum: öteki depoya hiç haber verilmiyor.