“Geleceğe hazır” mimariler neden tehlikelidir?
“Bu yazılım mimarisi geleceğe hazır mı?” aslında genellikle “hayır” ile cevaplanabilir. Daha da kötüsü, soruyu sormak mimarinin yanlış anlaşıldığını gösterebilir.
Bir bilgisayar sisteminin yazılım mimarisi iki alan içerir: sistemi tek tek modüller halinde uygulamaya ve yapılandırmaya yönelik teknolojiler. Mimarilerin gelecekteki güvenliği söz konusu olduğunda, her iki alanın da dikkate alınması gerekir.
çerçeve
İnsanların sistemi anlaması ve değiştirebilmesi için kaba taneli bir sistem yapısına ihtiyaç vardır. Yazılım sistemleri ekipler halinde geliştirilir. Bu bir soruna yol açar: hiç kimse tüm ekip üyelerinin çalışmalarını ayrıntılı olarak anlayamaz. Sistemin modüller halinde yapılandırılması, tek satır kod düzeyinde değil, soyut düzeyde, modüller düzeyinde anlamaya olanak tanır.
Mimari yapı, sistemin modüllerini, işlevlerin değiştirilmesi ve anlaşılması kolay olacak şekilde düzenlemelidir. Dolayısıyla yapı, işlevselliklere ve dolayısıyla gereksinimlere bağlıdır. Yazılım geliştirmedeki temel sorun, gereksinimlerin yalnızca müşterilerin yeni gereksinimleri olduğu için değil, aynı zamanda sistem düşünüldükçe veya uygulandıkça gereksinimlerin daha net hale gelmesi, yeni olasılıkların ortaya çıkması veya ortadan kaldırılması gereken tutarsızlıkların ortaya çıkması nedeniyle değişmesidir. Ekipler, müşteriler ve kullanıcılar sistem ve geliştirilecek özellikler hakkında sürekli olarak daha fazla şey öğreniyor. Bu yeni bilgiyi görmezden gelmek saçma olurdu. Bu nedenle değişimler kaçınılmazdır.
Gereksinimlerdeki bazı değişiklikler o kadar önemlidir ki, sistem tasarımı ve dolayısıyla mimari de uyarlanmalıdır. Prensip olarak sistemin geleceğe hazır olup olmadığını bilmiyoruz çünkü geleceği ve yeni ihtiyaçları öngöremiyoruz. Belki mimari yeni gereksinimlere iyi uyum sağlar, ancak belki de büyük değişikliklere ihtiyaç vardır.
Yalnızca öngörülebilir değişiklikleri dahil edin
Ancak yeni gereksinimlerin tümü tamamen şaşırtıcı değil. Elbette, mimari tasarıma öngörülebilir değişiklikleri dahil etmek mantıklıdır. Tüm bunlara rağmen değişiklikler yapılmazsa, mimari yer yer gereksiz yere esnek ve bu nedenle belki de yer yer çok karmaşıktır. Ancak bu, mimaride başka bir uzlaşmadır. Sistem öngörülebilir değişikliklere hazırlıklı olmalı mı, olmamalı mı? Bu tür sorular üzerinde düşünmek ve bireysel olarak karar vermek, körü körüne “Buna ihtiyacınız olmayacak” (YAGNI, buna ihtiyacınız olmayacak) şeklinde yanıt vermekten kesinlikle daha iyidir. Bu slogan, milenyumun başındaki aşırı programlama ortamından geliyor. Kendisini çok genel çözümlerden ayırmaya hizmet etti. Çünkü bir sistemi akla gelebilecek tüm değişikliklere hazır olacak şekilde geliştirirseniz, aşırı derecede karmaşık hale gelir. Bu nedenle, mimari yalnızca öngörülebilir değişiklikleri dikkate almalı ve bunları yalnızca avantajlar dezavantajlardan açıkça daha ağır basarsa mimariye dahil etmelidir.
Sürdürülebilirlik = anlaşılması kolay
Ancak yapılanmada sistemin belirli bir sürekliliğini sağlamak mümkündür. Yapı, anlaşılmasını kolaylaştırmıyorsa veya modüller gevşek bir şekilde bağlı değilse ve bu nedenle değişiklikler sistemin daha büyük ve daha büyük parçalarını etkiliyorsa, o zaman sistemin bakımı zaten kolay değildir. Bu gelecekte daha iyi olmayacak.
Teknik alanın temel kavramları sisteme hiç eşlenmemişse veya teknik kavramlar sistemde genellikle zayıf bir şekilde temsil ediliyorsa, teknik ayrıntıların sisteme nasıl eşlendiğini anlamak zordur. Ancak anlayış, herhangi bir değişikliğin ön koşuludur.
Bu şekilde, sistemin yapısını işlevselliğe mümkün olduğu kadar yakın hale getirmek ve böylece geleceğe hazır hale getirmek mümkündür. Teknik konsept açık ve anlaşılır bir şekilde uygulanmışsa, kolayca değiştirilebilir ve gelecekteki ihtiyaçlara uyarlanabilir. Teknik kavramların ötesine geçen esneklik yarardan çok zarar verir: genellikle yanlış yerlerdedir ve bu nedenle anlaşılmasını zorlaştırır. Gelecekteki değişiklikleri önceden tahmin edemez ve bunların uygulanmasını kolaylaştıramazsınız.
teknoloji
Yapının yanı sıra teknoloji seçimi de mimarinin önemli bir parçasıdır. Yazılım geliştirme, sürekli teknolojik değişikliklere tabidir. Bir teknoloji yığınının az ya da çok modern olduğu hala kanıtlanabilir. Bu ifade şimdiden gelecekteki güvenlik eksikliğini gösteriyor: bugün modern olan yarın demode olacak. İlk olarak, “modern” nispeten anlamsız bir terimdir: Bir teknoloji sadece birkaç yaşındaysa ne anlamı var?
Teknolojilerin modernliği kendi başına bir amaç olmamalı: Sonuçta, yazılım mimarilerinin iş sorunlarını çözmesi gerekiyor ve bunun için mümkün olduğunca modern bir teknoloji yığınına kesinlikle gerek yok. Teknolojileri modernleştirme ve yeni yaklaşımlar öğrenme çabaları, iş için değer yaratan faaliyetlere daha iyi yönlendirilebilir. Ancak bir noktada teknolojiler o kadar eski ki artık bakımları yapılmıyor. En geç güvenlik güncellemesi olmadığında güncelleme veya değişiklik yapmanız gerekir. Aksi takdirde bir güvenlik sorunu, sistemin artık kullanılamayacağı ve hatta ciddi hasarlara yol açabileceği anlamına gelebilir. Her iki durumda da sistem artık iş değeri üretmez, ancak aşırı durumlarda bir iş kaybı oluşturur. Bir noktada teknolojiler artık kimsenin onlarla uğraşmak istemeyeceği kadar eskiyse, geçiş baskısı artacaktır.
Elbette geleceğe hazır gibi görünen teknolojiler olabilir. Örneğin, Java programlama dili 25 yılı aşkın bir süredir kullanılmaktadır. Ancak aynı şey burada da geçerli: Eski Java sürümleri artık güvenlik güncellemelerini almıyor. Ve geçen yüzyılın Java kodu, dilin yeni özelliklerinden dolayı mevcut koddan farklı görünüyor. Sonuçta, tamamen farklı çerçeveler veya çerçevelerin en azından yeni sürümleri var. Uzun süredir var olan bir teknoloji bile bu nedenle değişime tabidir ve sürekli güncellenmesi gerekir.
Başka bir deyişle, yeni teknolojileri kullanmanın bir yolu yoktur. Gelecekteki güvenlik arzusu mümkün değildir.
Konteyner
Konteynerler gelecekteki güvenliği artırabilir: her konteyner kendi dosya sistemini içerir ve diğer konteynerlerden büyük ölçüde yalıtılmıştır. Yazılım açısından, neredeyse her konteyner kendi dosya sistemi, ağ arayüzü vb. ile ayrı bir bilgisayar gibidir. Bu nedenle, her kapsayıcı kendi programlama diline ve çerçevesine sahip olabilir. Örneğin, sistemin parçaları mikro hizmetlerle birden çok kapsayıcıya dağıtılırsa, yeni bir teknolojiye yükseltme önce bir kapsayıcıya ve ardından kademeli olarak diğer kapsayıcılara yayılabilir. Bu daha az risklidir ve yeni teknolojilerin tanıtılması daha kolay hale geldiği için mimariyi geleceğe daha uygun hale getirir.
Ancak bir noktada konteyner teknolojileri de icat edildi: Kubernetes 2014’ten beri, Docker 2013’ten beri ortalıkta. O zaman teknolojilerin ana akıma ulaşması birkaç yıl daha aldı. Bunları kullanmak için önceki projeleri düzenlemeniz gerekir. Bu yenilikler tahmin edilemez. 2012’de hiçbir mimari inceleme, kapsayıcı kullanmadığı için bir tasarımın geleceğe dönük olmayacağını tahmin edemezdi.
Ve konteynerler hakkında da kesin olan bir şey var: İnsanların hala konteyner kullananlara burun kıvıracağı bir zaman gelecek, çünkü o zaman çok daha iyi, yeni teknoloji olacak.
Ayrıca, birden çok JavaScript çerçevesini bir ön uçta birlikte kullanmak oldukça zor olmaya devam ediyor, ancak yeni JavaScript çerçevelerinin ortaya çıkma hızı hala etkileyici. Dolayısıyla, yeni teknolojilerin çok daha hızlı ortaya çıktığı yerlerde bu sorunları tam olarak çözmek zordur.
Bu nedenle, şu anda sonunda teknolojik olarak demode olacak çözümler üzerinde çalıştığınız fikrine alışmalısınız. Ve en fazla sorunu hafifletebilirsin ama düzeltemezsin.
Bu yüzden gelecekteki güvenlikten kaçının!
Geleceğe uyum sorunu aynı zamanda bir sorunun göstergesi olabilir: eğer bir mimari geleceğe hazır olsaydı, düzeltilmesi gerekmezdi. Ama arzu edilir. Bununla birlikte, düzeltmeler bir mimaride bir zayıflık olarak yorumlanırsa ve bu nedenle mümkün olduğunca azını hedeflerse, bu bir sorun olabilir. Bu nedenle, mimaride düzeltmeler yapmaktan kaçınmak için gerçekten ihtiyaç duyulan değişikliklere yapılan atıflar göz ardı edilebilir. Mimarinin geleceğin kanıtı olmadığını kim kabul etmek ister? Değişiklikleri bastırarak, mimari “geleceğe dayanıklı” görünür, ancak gerçekte mimari, sistem için giderek daha uygunsuz hale gelir. Değişikliklere zamanında uyum sağlamayan mimariler, orijinal tasarımdaki sorunlardan daha büyük bir kötü mimari kaynağı olabilir. Dolayısıyla, geleceğe dayanıklı mimari arzusu, daha düşük mimariye yol açar.
Ancak bu paradoks, mimari değişikliklerin olmamasının tek nedeni olmak zorunda değildir. Bir mimariyi değiştirmek yorucudur: Ne de olsa tasarım için çok fazla çaba harcanmıştır ve hatta bazı temel kavramlar prototiplerde denenmiştir. Tüm bu sorunlara elveda demek zor olabilir ama bazen gereklidir. Ve vicdan azabı çekmemelisiniz çünkü mimari artık demode oldu. Yazılım geliştirme yalnızca yinelemelerde uygulanabilir. Mimarinin bir yinelemesi, bir sonrakini de beraberinde getirir. Ancak mimariyi tasarlarken çaba sarf etmeniz gerekiyor. Yalnızca mimariyi gerçekten tasarlamaya çalıştığınızda optimizasyon potansiyeli ortaya çıkacaktır.
Mimarileri değiştirebilmek gerektiğinde, mimarinin inşası bir projenin sonunda biten bir aşaması olamaz. Ne de olsa mimarlık sürekli olarak değişen dünyaya adapte edilmelidir. Bunun için bir süreç olmalı. Çünkü mimari değişiklikler yapmak için bir süreç yoksa, muhtemelen ölçeklenmeyecektir. Böylece özelliklerin uygulanması giderek daha zor hale geliyor.
Çözüm
Bu nedenle, bir mimari değişim süreci sorunu, mimarinin gelecekteki güvenliği sorunundan daha önemlidir. Ve bu sorunun cevabı olmayan projeler, gelecekte mimaride zorluk yaşama riskini taşır.
tl; doktor
Teknolojik yenilikler ve yeni ihtiyaçlar, mimaride geleceğe dönük olamayacak değişiklikleri zorunlu hale getiriyor. Çözüm: Bu gerçeği ele alın ve gerekirse mimarileri ayarlayın.
Makalenin önceki bir versiyonuna yaptıkları yorumlar için Gerrit Beine, Martin Eigenbrodt, Joachim Praetorius ve Gernot Starke’ye çok teşekkürler.
()
ana sayfaya