Bir "büyük patlama" baştan yazımını yaşamış, tanıştığım her CTO aynı hikâyeyi biraz farklı bir yara iziyle anlatır. On sekiz aylık bütçe, otuz bir ayda teslim. Yeni sistem sonunda yayına girer ve bir hafta içinde biri, eskisinin hâlâ 2014'te kimsenin belgelemediği bir vergi uç durumunu işlediğini keşfeder. İşi özgürleştirmesi gereken baştan yazım, onun yerine işi iki yıl boyunca dondurur.
Daha iyi bir yol var ve yeni değil. Martin Fowler ona boğan incirin adını verdi — bir konak ağacın etrafında dal dal büyüyen, ta ki bir gün orijinali sessizce kaybolup incir kendi başına ayakta kalana kadar. Modernizasyonu da aynı şekilde yaparsınız: aşamalı olarak, üretim ortamında, eski sistem tüm süre boyunca çalışırken.
Büyük patlama neden sürekli başarısız oluyor
Tam bir baştan yazımın temel sorunu teknik beceri değildir. Sorun, yıllar boyunca birikmiş iş mantığını — büyük kısmı belgesiz, bir kısmı ise taşıyıcı nitelikte — hedef sürekli hareket ederken yeniden üretmenizin istenmesidir. İş, sizin baştan yazımınız için durmaz. Yeni düzenlemeler gelir, bir rakip bir özelliği zorunlu kılar, eski sistem yamalanır ve artık "dondurulmuş" şartnameniz çoktan yanlıştır.
Bir de acımasız bir nakit akışı gerçeği var. Büyük patlama tarzı bir baştan yazım, yayına girdiği güne kadar sıfır değer üretir. Tek bir kullanıcı bir fark fark etmeden önce on sekiz ay boyunca bütçe ve siyasi sermaye yakarsınız. O günden önce liderlik değişir ya da pazar kayarsa, proje yarı inşa hâlde ölür — ve bir yerine iki sistemi sürdürmek zorunda kalırsınız.
Boğan incir gerçekte nasıl çalışır
Her şeyi bir kerede değiştirmek yerine, eski sistemin önüne bir yönlendirme katmanı koyar ve her seferinde bir yeteneği soyup alırsınız. Her dilim yeni yığına taşınır, üretim ortamında doğrulanır ve gerçek trafiği taşımaya başlar. Eski monolit küçülür. Değer sürekli olarak üretilir.
Mekanizma genellikle bir cephe (façade) ya da vekil (proxy)'dir — bir API ağ geçidi, bir ters vekil (reverse proxy), bazen yalnızca ince bir yönlendirme servisi — ve istemcilerinizle eski sistem arasında durur. Nasıl ele alacağını henüz bilmediği istekler doğrudan eski arka uca geçer. Taşınmış yetenekler için gelen istekler yeni servise gider. Çağrı yapanlar farkı asla bilmez.
Herhangi bir ayın hedefi "baştan yazım bitti" değildir. Hedef, "bir yetenek daha artık yeni sistemde, üretim ortamında yaşıyor ve hiçbir şey bozulmadı"dır.
Somut bir sıralama
- Önce ölçümleyin. Cepheyi yerine koyun ve başka hiçbir şeyi değiştirmeden trafiğin %100'ünü onun üzerinden eski sisteme yönlendirin. Tek başına bu bile sonrasında gelecek her şeyin riskini azaltır.
- Gövdeyi değil, bir yaprağı seçin. Az sayıda bağımlılığı olan, sınırları belli bir yetenekle başlayın — bildirimler, PDF oluşturma, bir raporlama uç noktası. Faturalandırma çekirdeğiyle değil.
- İkisini birlikte çalıştırın, çıktıları karşılaştırın. Kritik yollar için bir gölge (shadow) ya da paralel çalıştırma deseni kullanın: isteği hem eskiye hem yeniye gönderin, eski sonucu sunun ve her sapmayı günlüğe kaydedin. Belgesiz vergi uç durumunu, bir müşteriye çarpmadan önce bulursunuz.
- Kademeli olarak geçirin. Bir özellik bayrağıyla (feature flag) trafiğin önce %1'ini, sonra %10'unu, sonra %50'sini kaydırın. Hata oranı oynarsa saniyeler içinde geri alın.
- Eski kodu silin. Bu adım pazarlığa kapalıdır ve ekiplerin her zaman atladığı adımdır. Eski yolu hiçbir zaman emekliye ayırmazsanız, karmaşıklığı azaltmamış, artırmışsınızdır.
İşin ters gittiği yer
Bu desen sihir değildir ve ekiplerin onu bir karmaşaya dönüştürdüğünü gördüm. En yaygın başarısızlık, asla boğmayan boğandır: yeni yetenekler inşa edilir ama eskileri silmek için kimseye bütçe ayrılmaz, böylece iki sistemi süresiz çalıştırır ve iki kat ödersiniz.
İkincisi, paylaşılan veritabanı çekimidir. Yeni servis ve eski monolit aynı tabloları hem okuyup hem yazıyorsa, hiçbir şeyi ayrıştırmamışsınızdır — yalnızca bir ağ sıçraması eklemişsinizdir. Veri sahipliğini çözmek, bu işin zor kısmıdır; koddan da zordur. Bunun için bütçe ayırın. Bazen bir süre çift yazım (dual-write) ve tümüyle atmayı planladığınız bir eşitleme katmanına ihtiyacınız olur.
Üçüncüsü, önce gövdeyi seçmektir. Ekipler heyecanlanır ve yaklaşımı kanıtlamak için en korkutucu, en merkezî modülü hedef alır. Oradan başlarsanız ilk göçünüz aynı zamanda en riskli göçünüz olur. Güveni kenarlarda kazanın.
Pazartesi nereden başlamalı
Başlamak için bir dönüşüm programına ya da yeni bir bütçe kalemine ihtiyacınız yok. Bu hafta üç şey yapın. Monolitinizin gerçek bağımlılık haritasını çizin — wiki'deki mimari diyagramı değil, gerçek olanı. Önüne bir vekil ya da ağ geçidi koyun ve tüm trafiği değiştirmeden onun üzerinden yönlendirin; böylece üzerinde çalışacağınız bir dikiş yeri olur. Sonra, sahip olduğunuz en izole tek yeteneği seçin ve yalnızca onu, yerine geçtiği kodu silmek de dâhil, uçtan uca taşıyın.
Modernizasyon, atlattığınız bir olay değildir. İnşa ettiğiniz bir alışkanlıktır. Kazanan ekipler, eski sistemi her seferinde dürüst bir dilim hâlinde emekliye ayırdıkları bir şey olarak görür — ve incirin büyümesini asla durdurmazlar.
Bugün mimarinize bakın: güvenle boğabileceğiniz ilk en küçük şey nedir?