Çünkü “geleceği” mimariler tehlikelidir
“Bu yazılım mimarisi gelecek için mi?” Aslında genel olarak “hayır” ile yanıt verebilirsiniz. Yine de daha kötüsü: Soruyu sormak zaten yanlış bir mimarlık anlayışını gösterebilir.
Bir BT sisteminin yazılımının mimarisi iki alan içerir: sistemin tek tek modüllerde uygulanması ve yapılandırılması için teknolojiler. Gelecekteki mimarinin güvenliği söz konusu olduğunda, her iki bölgeye de bakmanız gerekir.
yapı
İnsanların sistemi anlayabilmeleri ve değiştirebilmesi için bir sistemin kaba granüler bir yapısı gereklidir. Yazılım sistemleri ekipte geliştirilmiştir. Bu bir soruna yol açar: Kimse ekibin tüm insanların çalışmalarını ayrıntılı olarak anlayamaz. Modüllerde yapılandıran bir sistem, soyut bir anlayışa izin verir: modül seviyesi, tek tek kod satırlarının seviyesinde değil.
Mimari yapı, özelliklerin değiştirilmesi ve anlaşılması kolay olacak şekilde sistem modüllerini sipariş etmelidir. Dolayısıyla yapı işlevselliğe ve dolayısıyla gereksinimlere bağlıdır. Yazılımın geliştirilmesiyle ilgili temel sorun, gereksinimlerin sadece yeni gereksinimler yaptığı için değil, aynı zamanda sistemi düşündüğünüzde veya kullandığınızda, yeni olasılıkları ortaya çıkardığınızda veya tutarsızlıkları ortaya çıkarması ve ortadan kaldırması gerektiğinde de daha net hale gelmesidir. Ekip, müşteriler sürekli sistem ve geliştirilecek işlevler hakkında daha fazla bilgi edinir. Bu yeni bilgiyi görmezden gelmek saçma olurdu. Bu nedenle, kaçınılmaz olarak değişiklikler vardır.
Gereksinimlerde bazı değişiklikler o kadar önemlidir ki sistem yapısı ve bu nedenle mimari düzenlenmelidir. Prensip olarak, sistem geleceğin kanıtı ise, bilgimizin ötesindedir, çünkü geleceği ve yeni gereksinimleri tahmin edemeyiz. Belki de mimari yeni gereksinimlere iyi uyum sağlar, ancak belki de daha büyük değişiklikler gereklidir.
Yalnızca öngörülebilir değişiklikler ekleyin
Ancak tüm yeni gereksinimler tamamen şaşırtıcı değil. Tabii ki, mimarlık tasarımına öngörülebilir değişiklikler dahil etmek mantıklıdır. Değişiklikler gerçekleşmezse, mimari bazı yerlerde gereksiz yere esnektir ve bu nedenle muhtemelen bazı yerlerde çok karmaşıktır. Ancak bu mimaride başka bir uzlaşma. Sistem öngörülebilir değişiklikler için hazırlanmalı mı? Bu soruları düşünmek ve bunlara bireysel olarak karar vermek, “İhtiyacınız Olmayacak” ile körü körüne cevap verdiğinizden kesinlikle daha iyidir (Yagni, buna ihtiyacınız olmayacak). Bu slogan, binyılın başlangıcının aşırı programlama ortamından geliyor. Aşırı jenerik çözümlerden memnun kaldı. Bir sistem, akla gelebilecek tüm değişiklikler için hazırlanacak şekilde gelişirse, aşırı karmaşık hale gelir. Bu nedenle, mimari öngörülebilir değişiklikleri göz önünde bulundurmalı ve bunları yalnızca avantajlar avantajları aşarsa mimariye dahil etmelidir.
Futibility = Anlaması kolay
Ancak, yapılandırmada sistemin gelecekteki belirli bir fizibilitesini elde edebilirsiniz. Yapılandırma, anlayış veya modülleri daha kolay hale getirmezse veya serbestçe birleştirilmezse ve değişiklikler sistemin giderek daha büyük bölümlerini etkilerse, sistemin beklemesi kolay değildir. Bu gelecekte gelişmeyecek.
Uzman alanının merkezi kavramları sistemde gösterilmezse veya teknik kavramlar genellikle sistemde zayıf bir şekilde temsil edilirse, profesyonelliğin sistem üzerindeki eşlenmesini anlamak zordur. Ancak, anlayış her değişiklik için ön koşuldur.
Böylece sistem yapısını olabildiğince yakından hizalayabilir ve gelecekteki hale getirebilirsiniz. Teknik kavram açıkça ve anlaşılır bir şekilde uygulanırsa, gelecekteki gereksinimlere de değiştirilebilir ve uyarlanabilir. Teknik kavramlara ek olarak, yapılı esneklik yardımcı olduğundan daha zararlıdır: genellikle yanlış noktalardadır ve bu nedenle anlaşılabilirlik kötüleşir. Gelecekteki değişiklikleri tahmin edemez ve uygulamayı kolaylaştıramazsınız.
teknoloji
Yapıya ek olarak, teknoloji seçimi de mimarinin önemli bir parçasıdır. Yazılımın geliştirilmesi sürekli teknolojik değişime tabidir. Yine de az çok modern olduğunu onaylayabilirsiniz. Bu ifade zaten gelecekteki güvenlik eksikliğini gösteriyor: Modern bugün yarın eski. “Modern” başlangıçta nispeten boş bir terimdir: Bir teknoloji sadece birkaç yaşında ise ne kullanılır?
Teknolojilerin modernliği kendi içinde bir son olmamalıdır: Sonuçta, yazılım mimarisi şirket sorunlarını çözmeli ve en modern teknolojik yığın kesinlikle gerekli değildir. Teknolojilerin modernizasyonu ve yeni yaklaşımlar öğrenmede akan çabanın, faaliyete akması ve kurumsal değeri üretmek için belki de daha iyi olması gerekir. Ancak bir noktada teknolojiler o kadar yaşlı ki, artık sürdürülmeyecekler. Güvenlik güncellemeleri güncelleyemediğinde veya değiştiremediğinde en geç saatlerde. Aksi takdirde, bir güvenlik sorunu artık kullanılamayan veya hatta önemli hasara neden olan sisteme yol açabilir. Her iki durumda da, sistem artık ticari bir değer üretmez, ancak aşırı durumlarda bir faaliyet kaybı. Bir noktada teknolojiler o kadar yaşlı ise, artık kimse onunla yüzleşmek istemiyorsa, göç baskısı artmaya devam ediyor.
Tabii ki, görünüşe göre geleceğin dayanıklı teknolojileri olabilir. Örneğin Java programlama dili 25 yılı aşkın bir süredir var olmuştur. Ancak aşağıdakiler de: Eski Java sürümleri artık güvenlik güncellemeleri almıyor. Ve geçen yüzyılın Java kodu, dilin yeni işlevselliği nedeniyle mevcut koddan farklı görünüyor. Sonuçta, çerçevenin tamamen farklı çerçevesi veya en az yeni sürümleri vardır. Uzun süre var olan bir teknoloji bile değişikliklere tabidir ve sürekli olarak güncellenmelidir.
Başka bir deyişle, yeni teknolojiler kullanmaktan kaçınamazsınız. 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 büyük ölçüde diğer kaplar tarafından izole edilir. Yazılım bakış açısından, neredeyse her bir kapsayıcının kendi dosya sistemine, ayrı bir ağ arayüzüne vb. Sahip ayrı bir bilgisayar olduğu görülmektedir. Bu nedenle, programlama diliniz ve çerçeveniz her kapta kullanılabilir. Örneğin, sistemin parçaları mikro hizmetlere sahip birden çok kaplara dağıtılırsa, yeni bir teknolojiye güncelleme önce bir kapta ve dolayısıyla yavaş yavaş diğer kaplarda uygulanabilir. Bu daha az risklidir ve mimariyi geleceğin daha fazla kanıtı haline getirir, çünkü yeni teknolojilerin tanıtımı kolaylaşır.
Konteyner teknolojileri de bir noktada icat edildi: Kubernetes, 2014'ten beri Docker 2013'ten beri dolaşımda. Teknolojilerin ana akıma gelmesi birkaç yıl sürdü. Bunları kullanmak için eski projeleri değiştirmek zorundasınız. Bu yenilikler tahmin edilemez. 2012 yılında, hiçbir mimarlık revizyonu, bir projenin konteyner kullanmadığı için geleceğin bir kanıtı olmadığını öngörmüş olamaz.
Ve kaplarda da bir şey kesin: Birisi hala kaplar kullandığında burun iç içe geçtiği bir zaman olacak çünkü çok daha iyi yeni bir teknoloji olacak.
Buna ek olarak, farklı JavaScript çerçevesinin kullanımı birlikte gerçek bir meydan okuma olmaya devam ediyor, ancak yeni JavaScript çerçevesinin ortaya çıkma hızı hala etkileyici. Bu nedenle, bu sorunların çözülmesi zordur, yeni teknolojilerin hala çok daha fazla hızda göründüğü.
Bu nedenle, şu anda bir noktada teknolojik olarak eski çözümler üzerinde çalıştığınız düşüncesine alışmalısınız. Ve sadece sorunu azaltabilirsiniz, ancak çözmeyin.
Bu yüzden gelecekteki güvenlikten kaçının!
Gelecekteki güvenlik sorunu da bir sorunun göstergesi olabilir: eğer bir mimari gelecek olsaydı: düzeltmemelisiniz. Ama bu arzu edilir. Düzeltmeler bunun yerine bir mimarinin zayıflığı olarak yorumlanırsa ve bu nedenle mümkün olduğunca hedef haline gelirse, bu bir sorun olabilir. Bu nedenle, mimariye düzeltmeler yapmamak için gerçekten gerekli değişikliklerin göstergeleri göz ardı edilebilir. Kim mimarinin gelecek, dirençli olmadığını itiraf etmek ister? Değişiklikleri destekleyen mimarlık “geleceğin testi için” gibi görünüyor, ancak gerçekte mimari sisteme gittikçe daha kötü. Mimarilerin zaman içinde değişikliklere uyarlanmaması, muhtemelen orijinal taslakla ilgili sorunlardan daha geniş bir kötü mimari kaynağıdır. Gelecekteki geçirmez bir mimariye yönelik arzu, en fakir bir mimariye yol açar.
Ancak bu paradoks mimaride değişikliklerin olmamasının tek nedeni olmamalıdır. Bir mimari değişiklikler yorucudur: Sonuçta, taslak çok çaba sarf etti ve belki de prototiplerde temel kavramları da denedi. Tüm bu çabalara veda etmek zordur, ancak bazen gereklidir. Ve suçlu bir bilinciniz bile olmamalısınız, çünkü mimari artık kullanılmıyor. Yazılımın geliştirilmesi yalnızca yinelemelerde uygulanabilir. Bir mimarlık yinelemesi zaten bir sonrakini giyiyor. Ancak, mimarlık tasarımında çaba sarf etmelisiniz. Sadece optimizasyon potansiyel şovunu mimarlık tasarlamaya çalıştığınızda.
Mimariyi değiştirmek gerekiyorsa, mimarinin oluşturulması, sonunda tamamlanan bir projenin aşaması olamaz. Sonuçta, mimarlık sürekli değişen dünyaya uyarlanmalıdır. Bunun için bir süreç olmalı. Mimaride değişiklik süreci yoksa, muhtemelen ayarlanmayacaktır. Böylece özellikler giderek daha fazla uygulanmaktadır.
Çözüm
Bu nedenle mimari değişim süreci sorunu, gelecekteki mimarinin güvenliği sorunundan daha önemlidir. Ve bu soruya cevabı olmayan projeler, gelecekte mimarlıkta zorluk yaşama riskini ortaya koyuyor.
TL; Dr.
Teknolojik yenilikler ve yeni gereksinimler mimaride değişiklikler yapar – geleceğin bir kanıtı olamaz. Çözüm: Bu gerçekliğe gözlere bakın ve gerekirse mimarileri uyarlayın.
Makalenin önceki bir versiyonu hakkındaki yorumlar için Gerrit Legs, Martin Eigenbrodt, Joachim Praetorius ve Gernot Strong'a çok teşekkürler.
()