Big bang olmadan legacy moder­ni­zas­yonu

Yeterince uzun süre yazılım işleten neredeyse her şirket aynı noktaya gelir: Bir sistem işi taşır, ama artık kimse onu değiştirmeye gönüllü değildir. Karmaşık hâle gelmiştir, onu inşa eden kişiler gitmiştir ve her uyarlama açık kalp ameliyatı gibi hissettirir. Akla gelen ilk istek, onu bir kez de doğru dürüst yeniden inşa etmektir.

Bu istek, yazılım mühendisliğindeki en pahalı hatadır. Eski bir sistem, temiz biçimde yerine konabilecek bir tasarım değildir — çoğu hiçbir yerde yazılı olmayan, yıllar içinde biriken kararların, özel durumların ve sessiz gereksinimlerin dondurulmuş hâlidir. Bu metin, böyle bir sistemin big bang olmadan nasıl değiştirileceğini anlatır: artımlı olarak, küçük ve geri alınabilir adımlarla, yeni sistem yükü taşıyana kadar eski sistem bir güvenlik ağı olarak.

Büyük yeniden yazım neden başarısız olur

Big bang yeniden yazım (rewrite), her şeyi tek seferde doğru yapmayı vaat eder: yeni sistemi inşa et, her şeyi taşı, belirlenmiş bir günde geçiş yap. Beceriksizlikten değil, üç yapısal nedenden dolayı başarısız olur.

Birincisi: Eski sistem, artık kimsede olmayan bir bilgi içerir. Yıllar içinde biriken binlerce küçük özel durum gereksinimdir — yalnızca görünmezdirler. Sıfırdan bir yeniden inşa bunları yeniden üretmez; onları üretimde, kesinti ardına kesintiyle keşfeder.

İkincisi: Siz yeniden inşa ederken eski sistem durmaz. İşin değişikliklere ihtiyacı sürer. Ya eski sistemdeki geliştirmeyi dondurursunuz — o zaman şirket dönüşüm süresince hareket etme yeteneğini kaybeder — ya da iki sistemin bakımını paralel yürütür ve hareketli bir hedefi yeniden inşa edersiniz.

Üçüncüsü: Geçiş günü tüm riski tek bir anda toplar. Her şeyin aynı anda çalışması gerekir — kod, veri, entegrasyonlar, işletim. Bir şey çökerse kısmi bir geri dönüş yolu yoktur, yalnızca sıfıra dönüş vardır. Bu, bizim inşa etme biçimimizin tam tersidir: küçük, geri alınabilir adımlarla.

Öneri buradan çıkar: Riski tek bir tarihte yoğunlaştırmak yerine, tek tek yönetilebilir küçük parçalara ayırın. Bedeli, değiştirmenin daha uzun sürmesi ve tüm süre boyunca iki sistemin bir arada var olması gerekmesidir — daha fazla işletim yükü, bakımını kendinizin yaptığı geçici bir geçiş katmanı. Yalnızca sistem birkaç haftada tamamen ve gerçek bir test ağıyla yeniden inşa edilebilecek kadar küçükse farklı karar veririz — o zaman temiz bir yeniden inşa, geçiş katmanından daha ucuz olabilir.

“Legacy” gerçekte ne demektir

Legacy “eski” demek değildir. Anlaşılmış, test edilmiş ve bakımı yapılan yirmi yıllık bir sistem bir legacy sorunu değildir — olgun bir teknolojidir. Legacy; işi taşıyan, üretimde çalışan ve kötü anlaşılmış bir sistemdir. Değer “işi taşıyan” kısmındadır; risk ise “kötü anlaşılmış” kısmında.

Bu ayrım tüm stratejiyi belirler. Modernizasyonun amacı eski kodu yeni kodla değiştirmek değildir. Amaç, mevcut olanın içindeki değeri yok etmeden anlayışı ve değiştirilebilirliği geri kazanmaktır. Bunu unutan, yeni teknolojiye göre optimizasyon yapar ve sistemi değerli kılan tek şeyi riske atar: çalışıyor olmasını.

İlke: anlamak, çevrelemek, değiştirmek

Artımlı değiştirme her zaman aynı sırayı izler. Önce bir parçanın ne yaptığını anlamak — tahmin ederek değil, gözlemlenebilir biçimde. Sonra çevrelemek: eski ile yeni arasına, geri kalanına dokunmadan arkasında çalışabileceğiniz bir geçiş katmanı koymak. Sonra parça parça değiştirmek ve değiştirilen her parçayı hemen devreye almak.

Özü geri alınabilirliktir. Her adım, tek başına teslim edilebilecek ve tek başına geri alınabilecek şekilde kesilir. Tüm sistemi asla tek bir değişikliğe bağlamazsınız; ince bir dilimi taşır, dayanıp dayanmadığını kontrol eder ve bir sonrakine geçersiniz. Bir dilim ters giderse, zarar geçiş gününe değil, o dilime sınırlı kalır.

Strangler Fig yaklaşımı

Taşıyıcı kalıbın adı Strangler Fig'dir; bir ağacın çevresini sararak büyüyen ve ağaç tüm bu süre boyunca ayakta dururken sonunda onun yerini alan boğucu incirden gelir. Eski sistemin önüne bir cephe (facade) konur — tüm isteklerin ulaştığı nokta. Başlangıçta cephe her şeyi değiştirmeden eski sisteme iletir. Sonra iş alanına ait dilimleri birer birer yeni sisteme taşır ve cephenin tam olarak bu dilimleri yönlendirmesini sağlarsınız. Eski küçülür, yeni büyür ve sistem hiçbir anda durmaz.

Şema: Cephe tek sabit noktadır; sistem onun arkasında yer değiştirir.

Önerimiz: Önce cepheyi devreye alın ve herhangi bir şeyi değiştirmeden önce onu doğrudan iletim modunda yayına alın. Böylece geçiş katmanının riskini taşıma riskinden ayırırsınız. Bedeli, her isteğin içinden geçtiği ek bir katmandır — biraz gecikme, işletilmesi ve güvence altına alınması gereken bir altyapı parçası ve hiçbir yeni işlevin eski sistemi atlayarak doğrudan bağlanmaması disiplini. Sistemin bir cephe konabilecek net bir giriş noktası yoksa farklı karar veririz — örneğin servis sınırı olmayan hantal bir masaüstü uygulaması; orada değiştirme başlamadan önce geçiş katmanının bir arayüzle oluşturulması gerekir.

Dikiş yeri: cephe ve Anti-Corruption Layer

Dikiş yerinin iki görevi vardır. Cephe olarak, hangi isteğin eskiye, hangisinin yeniye gideceğine karar verir. Anti-Corruption Layer olarak ise eski ve yeni dünya arasında çeviri yapar; böylece eski sistemin kavramları ve hataları yeni alana sızmaz. Bu çeviri olmadan yeni sistem eskisinin model hatalarını miras alır — ve aynı sorunları yeniden paketlemek için çok emek harcamış olursunuz.

Önerimiz: Yeni alanı eski modelden bağımsız tutun; eski sistemden gelen her şey geçiş katmanında yeni alanın diline çevrilir. Bedeli, tekrar gibi görünen ve iki dünya bir arada var olduğu sürece bakımı yapılması gereken çeviri kodudur. Eski modelin kanıtlanabilir biçimde temiz olduğu ve yaşamaya devam etmesi gerektiği durumda farklı karar veririz — o zaman çeviri gereksiz bir sürtünmedir ve modeli kapsüllemek yerine bilinçli olarak devralırsınız.

Asıl sorun veridir

Kod dilim dilim taşınabilir. Veri o kadar kolay taşınmaz: Ortaktır, büyüktür ve veritabanı üzerindeki her uygulama katmanından uzun yaşar. Her modernizasyonun en zor kısmı neredeyse hiçbir zaman kod değildir — veriyi kaybetmeden ve sistemi durdurmadan taşımaktır.

Bunun aracı adım adım, geri alınabilir şema değişikliğidir — Expand, Migrate, Contract. Önce genişletmek: Hiçbir şeyi kaldırmadan yeni şemayı eklemeli olarak eskisinin yanına koymak. Sonra geçmek: Bir süre yeni ve eskiye paralel yazmak (dual write), mevcut veriyi arka planda doldurmak, okumayı yavaş yavaş yeniye geçirmek. Ancak artık hiçbir şey eskiyi okumadığında daraltmak: eski alanı kaldırmak. Her tekil değişiklik kendi içinde geriye dönük uyumludur ve dolayısıyla geri alınabilir.

Şema: Hiçbir alan değiştirilmez; eklenir, doldurulur, sonra eskisi kaldırılır.

Önerimiz: Veriyi geçiş gününden önceki son adım olarak değil, erken ve paralel olarak taşıyın. Bedeli, iki kaynağın tutarlı tutulması gereken bir çift yazma evresi ile mevcut veriyi doldurma ve iki tarafın eşitliğini doğrulama emeğidir. Kabul edilebilir bir bakım penceresi olan küçük, kritik olmayan veri miktarlarında farklı karar veririz — orada pencere içinde tek seferlik bir taşıma, kalıcı çift yazma düzeneğinden daha basittir.

Branch by Abstraction ve paralel işletim

Her parça cephenin arkasına rahatça oturmaz. Sistemin derinliklerine bağlanmış bir yapı taşı — bir hesaplama, harici bir servise erişim — Branch by Abstraction ile değiştirilebilir: Eski uygulamanın üzerine bir soyutlama koyarsınız, aynı soyutlamanın arkasına yenisini yazarsınız, bir anahtarla geçiş yaparsınız ve sonunda eskisini kaldırırsınız. Dönüşüm, uzun ömürlü bir yan dal olmadan, çalışan kodun içinde gerçekleşir.

Geçişten önce paralel işletim gelir: Yeni ve eski uygulamayı bir süre birlikte çalıştırmak, iki sonucu karşılaştırmak, ama bağlayıcı olarak yalnızca eskisini kabul etmeye devam etmek. Ancak yeni olan gerçek trafik boyunca aynı sonucu verdiğinde geçiş yapılır. Böylece doğruluk, sorumluluk üstlenmeden önce — sonra değil — üretimde kanıtlanır.

Önerimiz: Yeni uygulamayı, bağlayıcı hâle gelmeden önce paralel işletimde gerçek trafiğe karşı kanıtlayın. Bedeli, karşılaştırma süresince çift çalıştırmadır — daha fazla yük, daha fazla enstrümantasyon ve çoğu zaman unutulmuş özel durumları ortaya çıkaran sapmalarla uğraşmak. Çift çalıştırmanın güvenle iki kez yapılamayacak yan etkileri olacağı yerde — örneğin ödemeler ya da gönderim — farklı karar veririz; orada canlı yerine bir gölge ortamda kaydedilmiş trafiğe karşı doğrulama yapılır.

Sıralama: en riskli olan önce, ince dilimlerle

Nereden başlamalı? Hızla bir şey gösterebilmek için en basitinden değil, bir an önce bitirmek için en büyüğünden de değil. Önce en riskli, en az anlaşılmış yol gelir — ama geçiş katmanından uçtan uca geçen mümkün olan en ince dilim olarak. Böylece en büyük bilinmezi, değiştirmenin hâlâ ucuz olduğu başlangıçta ortadan kaldırırsınız; onu sonda keşfetmek yerine.

İyi bir ilk dilim iş açısından kendi içinde tamamlanmış, küçük ve gerçekten devrededir. Tüm zinciri — cephe, yeni alan, veri, işletim — gerçek ama sınırlı bir durum üzerinde kanıtlar. Dikiş yeri ve veri yolları hakkında öğrettikleri, sonraki her dilimi taşır.

Önerimiz: İşi teknik katmanlara göre değil, iş yeteneklerine göre kesin ve en riskli ince dilimle başlayın. Bedeli, ilk dilimin orantısız derecede pahalı görünmesidir, çünkü görünür ilerleme ortaya çıkmadan önce tüm geçiş katmanını birlikte inşa eder. Bir parça akut baskı altındaysa farklı karar veririz — bir güvenlik riski, bir veri koruma sorunu, sürekli çöken bir yapı taşı; o zaman bu parça risk profilinden bağımsız olarak öne alınır.

Karakterizasyon testleri: dönüşümden önceki güvenlik ağı

Gözlemleyemediğiniz şeyi güvenle değiştiremezsiniz. Bir dilim taşınmadan önce eski sistemin mevcut davranışı karakterizasyon testleriyle kayda geçirilir — sistemin ne yapması gerektiğini değil, ne yaptığını, tuhaflıklarıyla birlikte tarif eden testler. Bunlar güvenlik ağıdır: Yeni davranış saparsa, üretim fark etmeden önce alarm verirler.

Belirleyici nokta sıralama ve ayrımdır. Önce davranış ağın altına alınır, sonra taşınır ve taşıma sırasında davranış aynı anda iyileştirilmez. Aynı anda yeni işlevler ekleyen bir modernizasyon sapmaları artık yorumlayamaz — her fark kasıt da olabilir, hata da.

Önerimiz: Karakterizasyon testlerini dönüşümden önce yazın ve taşıma ile işlev değişikliğini kesinlikle ayrı tutun. Bedeli, zaten değiştirmek istediğiniz davranış için test yazmanız ve istenen iyileştirmelerin taşıma tamamlanana kadar beklemesidir. Eski davranışın kanıtlanabilir biçimde yanlış olduğu ve kimsenin ona dayanmadığı yerde farklı karar veririz — o zaman hatayı testte dondurmazsınız, onu bilinçli olarak düzeltir ve sapmayı belgelersiniz.

Gözlemlenebilirlik ve dönüş bileti

Artımlı değiştirme, işletimde iki şeye dayanır: Ne olduğunu görebilmeniz ve geri dönebilmeniz gerekir. Her dilim bir anahtarın arkasında, ilk dakikadan itibaren gözlemlenebilirlikle canlıya çıkar — eski ve yeni yollar karşılaştırılabilir sinyaller üretir; böylece bir sapma hemen görünür olur. Eski yol, yeni dilim yeterince gerçek trafik boyunca güven kazanana kadar çalışmaya hazır kalır.

Önerimiz: Her dilimi saniyeler içinde eski yola geri dönülebilen bir anahtarın arkasına koyun ve güven oluşana kadar eski yolu yerinde bırakın. Bedeli, iki yolun bir süre çalışır durumda kalması gerekmesidir — çift kod, çift işletim ve sonunda eski yolu, sinsice kalıcı duruma dönüşmesine izin vermek yerine gerçekten kaldırma yükümlülüğü. Kayda değer bir riski olmayan ve geri dönüş yolu olası zararından daha pahalı olan bir dilimde farklı karar veririz — orada doğrudan geçiş yapılır ve çift yoldan tasarruf edilir.

Yeniden yazım ne zaman yine de doğrudur

Dürüst yanıt, kendi yöntemimize aykırı düşse bile danışmanlığın bir parçasıdır. Artımlı yolun yanlış olduğu durumlar vardır. Platformun kendisi ölmüşse — artık güvenlik güncellemesi almayan, ne insanı ne de geleceği olan bir çalışma ortamı — mevcut yapı içinde hiçbir dönüşüm işe yaramaz. İş görevi, eski model artık doğru soruyu yanıtlamayacak kadar temelden değişmişse, yanlış bir modeli taşımazsınız, doğrusunu inşa edersiniz. Ve sistem, gerçek bir test ağıyla kısa sürede tamamen yeniden inşa edilebilecek kadar küçükse, yeniden inşa, değiştirmenin gerektirdiği geçiş katmanından daha ucuz olabilir.

Ortak payda: Yeniden yazım, eski sisteme duyulan hayal kırıklığı büyük olduğunda değil, risk küçük ve yönetilebilir olduğunda doğrudur. Soru hiçbir zaman “Yenisini mi istiyoruz?” değil, “Yeniden inşa için de mevcut sistem için üstlendiğimiz sorumluluğun aynısını üstlenebilir miyiz?” sorusudur. Yanıt hayırsa, artımlı yol geçerlidir.

Sık yapılan hatalar

Modernizasyonları pahalı ya da tehlikeli kılan, hep aynı kalıplardır:

• Tüm riski, kısmi geri dönüş yolu olmayan tek bir anda toplayan big bang geçiş günü.
• Eski sistemin görünmez gereksinimlerini üretimde yeniden keşfeden sıfırdan yeniden yazım.
• Tüm dönüşüm süresi boyunca, işin çevikliğini elinden alan ve özeni yiyip bitiren bir baskı yaratan özellik dondurma (feature freeze).
• Taşıma ve yeni işlevlerin aynı anda yapılması; böylece sapmalar artık yorumlanamaz.
• Veriyi erken ve paralel değil, en sona bırakmak — devrilme olasılığı en yüksek olan kısım.
• Dikiş yeri olmaması: Yeni işlevler doğrudan eski sisteme bağlanır ve değiştirilmek istenen şeyin ömrünü tam olarak uzatır.
• Geçişten sonra “geçici olarak” kalan ve kalıcı ikinci bir sisteme dönüşen eski yol.

Kontrol listesi

Bir CTO'nun bir modernizasyon projesine sorabileceği sorular. Bunlar hüküm değil, teşhis sorularıdır.

• Bir geçiş katmanı var mı? Eski ve yeni sistem arasında işlevleri adım adım ayırabileceğimiz bir nokta bulunuyor mu?
• Mevcut davranış, ona dokunmadan önce bir test ağının altında mı? Gözlemleyemediğiniz şeyi güvenle değiştiremezsiniz.
• Her dilim tek başına teslim edilebilir ve tek başına geri alınabilir mi? Aksi hâlde taksitli bir big bang'dir.
• Veriyi erken ve geriye dönük uyumlu olarak mı taşıyoruz, yoksa sona mı saklıyoruz? Veri en son ve en pahalı biçimde devrilir.
• Taşıma ile işlev değişikliğini temiz biçimde ayırıyor muyuz? İkisi aynı anda sapmaları okunamaz kılar.
• Eski yol, güven oluşana kadar çalışmaya hazır kalıyor mu — ve sonrasında onu kaldırmak için bir plan var mı? Hiç kapatılmayan bir dönüş yolu ikinci sisteme dönüşür.
• En görünür olanla değil, ince bir dilim hâlinde en riskli olanla mı başlıyoruz? Risk başa aittir.
• Bir yeniden inşa için de mevcut sistem için üstlendiğimiz sorumluluğun aynısını üstlenebilir miyiz? Hayırsa, artımlı yol doğrudur.

Sıkça Sorulan Sorular

Kademeli modernizasyon, yeniden yazımdan daha uzun sürmez mi? İlk işlevin devreye alınması daha uzun sürebilir; çünkü önce geçiş katmanı kurulmalıdır. Ancak mevcut sistem bu sırada çalışmaya devam eder. Toplam süre ve risk, yalnızca kodlama hızına değil, veri geçişine ve canlıya alma sürecine de bağlıdır.

Ek bir cephe, başlı başına yeni bir karmaşıklık değil mi? Evet, ve geçicidir. Cephe, geri alınabilirliğin bedelidir: Geri kalanına dokunmadan dilim dilim taşımaya olanak tanır. Eski sistem devreden çıkarıldığında kaldırılır. Amaçsız biçimde kalıcı olarak kalıyorsa, yanlış yerdeydi.

Ya eski sistemin aslında ne yaptığını artık kimse bilmiyorsa? O zaman ilk adım inşa etmek değil, anlamaktır. Karakterizasyon testleri ve gözlemlenebilirlik, gerçek davranışı taşınmadan önce görünür kılar. Bilgiyi tahmin etmek yerine ortaya çıkarırsınız — big bang yeniden yazımın atladığı adım tam olarak budur.

Modernizasyon sırasında yeni işlevler teslim edebilir miyiz? Evet — bu, artımlı yolun başlıca nedenlerinden biridir. Ama bir taşımayla aynı dilimde değil. Yeni işlevler geçiş katmanının arkasındaki yeni sistemde ortaya çıkar; sapmaların yorumlanabilir kalması için taşıma ve işlev değişikliği ayrı tutulur.

İşin bittiğini nereden anlarız? Artık hiçbir şey cephe üzerinden eski sisteme gitmediğinde, hiçbir kaynak eski veri şemasını okumadığında ve eski yol kaldırıldığında. Bitiş, son yeni kod değil, eski sistemin kimse fark etmeden kapatılabildiği andır.

Nereden başlanır — önce hangi dilim? Mümkün olduğunca ince bir biçimde en riskli olanla. Riskli olanı önce taşımak, zor sorunları proje henüz gençken ve geri dönülebilirken ortaya çıkarır — her şeyin ona bağlı olduğu sonda değil. Dilim, bir başarısızlık ucuz olsun diye ince tutulur. Riskli olanı geç ve kalın bir dilim hâlinde taşımak, artımlı avantajı heba etmenin en yaygın yoludur.

İleri okuma

• On yıl sonra hâlâ çalışan yazılım — temel: sistemleri uzun ömürlü ve değiştirilebilir tutan nedir.
• Legacy monoliti modernize etmek — somut yöntem için uygulama kılavuzu.
• Modüler monolit ve Modüler monolit mi, mikroservisler mi? — neye doğru değiştirilir ve neden çoğu zaman dağıtık servislere doğru değil.
• Laravel mi, Symfony mi? — dilimlerin yeniden inşasında uzun vadeli bir teknoloji seçimi örneği olarak.

Temel, Batunet Engineering Method'tur: anlamak, karar vermek, kanıtlamak, inşa etmek, sağlamlaştırmak, işletmek — küçük, geri alınabilir adımlarla.

Başarılı bir modernizasyon görülmez. Geçiş günü yoktur, endişe yoktur, her şeyin tehlikede olduğu bir gece yoktur. Bir noktada yeni sistem çalışır, eskisi kapanmıştır ve kimse bunun gerçekleştiği anı söyleyemez.