Mikro hizmetlerde bir sistem basit ve küçük modüller tarafından oluşturulur, ancak karmaşıklık bir yerde kalmalıdır. Dolayısıyla entegrasyon ve ilişkiler seviyesi daha karmaşık olmalı ve – sıklıkla olduğu gibi – hiçbir şey kazanmadınız. Ancak mikro hizmetler aslında karmaşıklığı ortadan kaldırır.
Mimariler büyük ve eksiksiz yazılım sistemleridir. Açıkçası her sisteme genel bir bakışınız olmalı. Neden başka hangi şekilde değişiklik yapabilirsiniz veya değişikliklerin sonuçlarını tahmin edebiliyorsunuz?
Bir mikro hizmet projesinde şaşkınlığım için tam bir genel bakış vardı. Bu yüzden hangi mikro hizmetlerin hangi mikro hizmetlerle iletişim kurduğunu gösteren bir tane oluşturdum. Diyagram da estetik açıdan cazipti, bazı meslektaşları da böyle bir genel bakışa sahip olmak istedi. Ama sonunda işle ilgisizdi. Çünkü açıkçası projenin sadece genel bir resmi yoktu; Dahası, bir tane olsa bile yazılım geliştirmesine gerek yoktu.
Bir noktada hala projeye genel bir bakışa ihtiyacımız vardı. Çünkü yeni bir teknisyen toplanmalıdır. Genellikle ona bu projede bulunmayan mimariye genel bir bakış verirdi. Bunun yerine, bazı uzmanlar alanlarından çeşitli kullanım vakaları sundu ve kullanım durumunda gerekli mikro hizmetlerin etkileşimini gösterdi. Bireysel parçaların bilgisi ve kullanım vakaları mevcuttu, ancak birkaç çalışanın zihninde. Kimse tüm sistemi anlamadı.
Bu gerçekten korkutucu: artık kimse sistemi anlamıyor. Nasıl geliştirebilirsiniz? Ancak, örneğin Netflix'ten mikro hizmet sistemlerinin diyagramlarına bakarsanız, herkes şu soruyu sorar: Herkes hala anlıyor mu? Bu sistemin inşasına karışan birine sorma fırsatım oldu ve ifadesi şuydu: Hayır, kimse bunu mevcut Netflix ekibinde anlamıyor. Yukarıda belirtilen proje yalnız değil – Netflix de tamamen kimseyi içermiyor.
Tüm sistem anlaşılmalı mı?
Soru şimdi: Kimse tüm sistemi anlamıyorsa sorun mu? Sonuçta, kuruluşlar başarılı bir şekilde yazılım geliştirebilir. Görünüşe göre hayır. Sadece kapsüllerin mantıklı bir devamı, modülerleşme ve bilgi gizleme yeri veya yazılım mühendisliğinin temel kavramlarıdır. Düşük bir sistem hakkında gerekli bilgiyi mümkün olduğunca sürdürmeyi amaçlamaktadırlar. Herkes sistemin yalnızca kullanım durumlarıyla ilgili olan kısmını anlaması gerekiyorsa, bu bu kavramların açıkça başarılı bir şekilde uygulanmasıdır.
Ancak kavramlar bu kadar eskiyse, mikro hizmetler gibi modern yaklaşımlarla ne ilgisi var? İkincisi, modüllerin birbirine karşı daha iyi bir yalıtımına izin verir. Bireysel olarak kullanılabilirler, farklı platformlar ve programlama dilleri kullanabilirler. Bir mikro hizmetteki bellek kaybı sadece bu mikro hizmetlerin arızasına yol açar, ancak diğer mikro hizmetlerin arızalanmasına yol açmaz. Bir diğerinin etkileşime girmediği bir mikro hizmet ilgilenmemelidir. Modüller bir dağıtım monolitinde çok iyi izole edilmez.
Bu nedenle mikro hizmetlere bölünme, mikro hizmetler arasındaki entegrasyondaki karmaşıklığı hareket ettirmez: ayırma çok tutarlı olduğundan, herkes sistemin sadece küçük bir bölümünü anlamalıdır. Ve böylece, tabiri caizse, bir karmaşıklık parçası kaybolur ve yine de karmaşık sistemler geliştirebiliriz.
()
Mimariler büyük ve eksiksiz yazılım sistemleridir. Açıkçası her sisteme genel bir bakışınız olmalı. Neden başka hangi şekilde değişiklik yapabilirsiniz veya değişikliklerin sonuçlarını tahmin edebiliyorsunuz?
Bir mikro hizmet projesinde şaşkınlığım için tam bir genel bakış vardı. Bu yüzden hangi mikro hizmetlerin hangi mikro hizmetlerle iletişim kurduğunu gösteren bir tane oluşturdum. Diyagram da estetik açıdan cazipti, bazı meslektaşları da böyle bir genel bakışa sahip olmak istedi. Ama sonunda işle ilgisizdi. Çünkü açıkçası projenin sadece genel bir resmi yoktu; Dahası, bir tane olsa bile yazılım geliştirmesine gerek yoktu.
Bir noktada hala projeye genel bir bakışa ihtiyacımız vardı. Çünkü yeni bir teknisyen toplanmalıdır. Genellikle ona bu projede bulunmayan mimariye genel bir bakış verirdi. Bunun yerine, bazı uzmanlar alanlarından çeşitli kullanım vakaları sundu ve kullanım durumunda gerekli mikro hizmetlerin etkileşimini gösterdi. Bireysel parçaların bilgisi ve kullanım vakaları mevcuttu, ancak birkaç çalışanın zihninde. Kimse tüm sistemi anlamadı.
Bu gerçekten korkutucu: artık kimse sistemi anlamıyor. Nasıl geliştirebilirsiniz? Ancak, örneğin Netflix'ten mikro hizmet sistemlerinin diyagramlarına bakarsanız, herkes şu soruyu sorar: Herkes hala anlıyor mu? Bu sistemin inşasına karışan birine sorma fırsatım oldu ve ifadesi şuydu: Hayır, kimse bunu mevcut Netflix ekibinde anlamıyor. Yukarıda belirtilen proje yalnız değil – Netflix de tamamen kimseyi içermiyor.
Tüm sistem anlaşılmalı mı?
Soru şimdi: Kimse tüm sistemi anlamıyorsa sorun mu? Sonuçta, kuruluşlar başarılı bir şekilde yazılım geliştirebilir. Görünüşe göre hayır. Sadece kapsüllerin mantıklı bir devamı, modülerleşme ve bilgi gizleme yeri veya yazılım mühendisliğinin temel kavramlarıdır. Düşük bir sistem hakkında gerekli bilgiyi mümkün olduğunca sürdürmeyi amaçlamaktadırlar. Herkes sistemin yalnızca kullanım durumlarıyla ilgili olan kısmını anlaması gerekiyorsa, bu bu kavramların açıkça başarılı bir şekilde uygulanmasıdır.
Ancak kavramlar bu kadar eskiyse, mikro hizmetler gibi modern yaklaşımlarla ne ilgisi var? İkincisi, modüllerin birbirine karşı daha iyi bir yalıtımına izin verir. Bireysel olarak kullanılabilirler, farklı platformlar ve programlama dilleri kullanabilirler. Bir mikro hizmetteki bellek kaybı sadece bu mikro hizmetlerin arızasına yol açar, ancak diğer mikro hizmetlerin arızalanmasına yol açmaz. Bir diğerinin etkileşime girmediği bir mikro hizmet ilgilenmemelidir. Modüller bir dağıtım monolitinde çok iyi izole edilmez.
Bu nedenle mikro hizmetlere bölünme, mikro hizmetler arasındaki entegrasyondaki karmaşıklığı hareket ettirmez: ayırma çok tutarlı olduğundan, herkes sistemin sadece küçük bir bölümünü anlamalıdır. Ve böylece, tabiri caizse, bir karmaşıklık parçası kaybolur ve yine de karmaşık sistemler geliştirebiliriz.
()
