Modüler monolit mi, mik­ro­ser­vis­ler mi?

Yazılım mühendisliğinde pek az karar bu kadar çok bir kimlik meselesi olarak, bu kadar az da bir mühendislik sorusu olarak tartışılır. “Mikroservisler” modern, “monolit” geri kalmış sayılır — ve bir tartıp değerlendirme meselesi böylece bir inanç beyanına dönüşür. Oysa iki kelime de bir kaliteyi değil, bir topolojiyi adlandırır: bir sistemin nasıl teslim edildiğini ve sınırlarının nereden geçtiğini.

Bu metin önceden bir karar vermez. Soruyu olduğu gibi ele alır: bir sistemin kaçınılmaz karmaşıklığını nereye taşıyacağınıza dair bir karar. Koda mı, ağa mı. Derleyiciye mi, işletime mi. İki yolun da bir bedeli vardır ve hiçbiri diğerinden daha ileri değildir. Ustalık doğru stili seçmekte değil, kendi sisteminizin gerçekte maruz kaldığı kuvvetleri tanımaktadır.

Bu tartışma neden var

Tartışma, bir kelime statü sembolüne dönüştüğü için var. Bazı çok büyük şirketler, yüzlerce ekiple birbirinden bağımsız teslimat yapabilmek için sistemlerini servislere böldüğünde, sektör topolojiyi devraldı — ama onu zorunlu kılan kuvvetleri değil. “Mikroservisler” ciddi mühendisliğin işareti, “monolit” ise eski olan her şey için bir hakaret oldu. Yanlış anlamanın özü budur: Organizasyonel bir ölçeklenme sorununa verilmiş bir yanıt, genel bir ilerleme olarak pazarlandı.

Soğukkanlı bakış daha basittir. Önemsiz olmayan her sistem belli miktarda karmaşıklık taşır ve bu miktar yok olmaz — yalnızca yer değiştirebilir. Modüler monolitte karmaşıklık kodda yaşar: Sınırlar modül sınırlarıdır, çağrılar fonksiyon çağrılarıdır, tutarlılık bir transaction'dır. Mikroservislerde aynı karmaşıklık ağda ve işletimde yaşar: Sınırlar süreç sınırlarıdır, çağrılar arıza modlarına sahip ağ çağrılarıdır, tutarlılık dağıtık bir göreve dönüşür. Soru hiçbir zaman “hangi stil daha iyi” değil, “karmaşıklığın hangi dağılımı bu sisteme etki eden kuvvetlere uyuyor” sorusudur.

Kararı asimetrik kılan ve sıkça gözden kaçan bir ayrıntı vardır: İki hatanın bedeli eşit değildir. Kodda yanlış olduğu ortaya çıkan bir sınır kaydırılabilir — tek bir deployable içinde bir refactoring'dir. Ağda yanlış olduğu ortaya çıkan bir sınır ise ancak pahalıya yeniden açılabilen bir kapıdır: Ayrı veritabanları, versiyonlanmış sözleşmeler ve işletim altyapısı geri sökülmek zorundadır. Bu yüzden emin olmayan, geri alınabilir hatayı seçmelidir — sonradan ucuza düzeltilebilecek olanı.

Modüler monolit gerçekte nedir

Modüler monolit çoğu zaman yanlış anlaşılır, çünkü karikatürüyle karıştırılır: her şeyin her şeye eriştiği ve her değişikliğin her yere yayıldığı yapısız monolit, yani “Big Ball of Mud”. Kastedilen bu değildir. Modüler monolit, içeride modüllere net biçimde ayrılmış tek bir deployable'dır — her modül kendi alanına sahiptir, dar bir arayüz sunar ve başka bir modülün iç yapısına ya da tablolarına uzanmaz. Sınırlar gerçektir; yalnızca ağ tarafından değil, disiplin ve araçlar tarafından zorlanırlar.

Böylece modüler monolit bilinçli olarak iki uç arasında durur. Yapısız monolitte eksik olan net sınırlara sahiptir — ve mikroservislerin gerektirdiği ağ ve işletim maliyetlerinden kaçınır. Dağıtıklığın tam bedelini ödemeden modülerliğin faydasının büyük kısmını elde edersiniz.

Şema: Aynı üç yetenek — bir kez disiplinden oluşan bir sınırın arkasında modüller olarak, bir kez ağdan oluşan bir sınırın arkasında servisler olarak.

Aynı karar birkaç boyut üzerinden incelenebilir. Hiçbir satır, bedeli olmayan bir avantaj değildir — her biri yalnızca karmaşıklığın nereye göç ettiğini tarif eder:

Belirleyici olan, geçiş yolunun ileride üzerine kurulacağı bir özelliktir: Temiz, dar bir arayüze sahip bir modül, ileride bir kuvvet gerektirirse bir servisi ayırabileceğiniz dikiş yeridir. Böylece modüler monolit mikroservislerin alternatifi değil, çoğu zaman onların ön aşamasıdır.

Pek çok ekip neden çok erken bölüyor

En yaygın hata mikroservisleri seçmek değil, onları yanlış zamanda — onları haklı çıkaran kuvvetler ortaya çıkmadan önce — seçmektir. Nedenler insani ve tekrarlayıcıdır. Bu stil olgunluğun işareti sayılır, dolayısıyla ciddiye alınmak için seçilir. Mantıksal sınırlar fiziksel sınırlarla karıştırılır ve bir sınırı ancak bir ağ çağrısının “gerçek” kıldığına inanılır. Dağıtıklığın iyi tasarımı zorlayacağı umulur — oysa kötü çizilmiş bir sınır bir ağ çağrısıyla daha iyi olmaz, yalnızca daha pahalı olur. Ve henüz kimsenin ölçmediği ölçeklenme sorunlarından korkulur.

Bu erken bölmenin bedeli yüksektir ve hemen ödenir: yerel bir transaction yerine dağıtık transaction'lar; fonksiyon çağrıları yerine arıza modlarıyla birlikte ağ çağrıları; daha önce bir transaction'ın yettiği yerde eventual consistency; daha önce gerekmeyen bir işletim altyapısı; süreç sınırlarının ötesine geçen hata ayıklama; kendi inşa ettiğiniz servisler arasında versiyonlanmış sözleşmeler. Dağıtıklığın faydasını tahsil etmeden çok önce faturasının tamamını ödersiniz.

Önerimiz: Modüler bir monolitle başlayın ve ancak somut, şu anda mevcut bir kuvvet gerektirdiğinde bölün. Bedeli, bir servisi en baştan ayrı tutmak yerine sonradan ayırmak zorunda kalmanızdır — ve baskı altında sonradan eklemek, en baştan sahip olmaktan daha pahalıya mal olur. Bu kuvvetlerden biri daha ilk günden kanıtlanabilir ve geri dönülmez biçimde mevcutsa — örneğin yasanın gerektirdiği düzenleyici bir ayrım — farklı karar veririz; o zaman bu tek sınırı hemen, ama hedefli olarak çizersiniz, tüm sisteme yayılan bir ilke olarak değil.

Mikroservisler ne zaman nesnel olarak daha iyi seçimdir

Mikroservislere ayırmanın teknik olarak daha uygun olduğu durumlar vardır. Ortak nokta, belirli bir ihtiyacın bağımsız süreç sınırını ek maliyetine rağmen gerekli kılmasıdır.

Bağımsız ölçeklenme en net durumdur. Sistemin bir parçası temelden farklı bir yük ve kaynak profiline sahipse — işlem yoğun karşısında bellek yoğun, nadiren karşısında sürekli talep gören — tüm sistemi en pahalı parçaya göre boyutlandırmak yerine o parçayı ayrı ve daha düşük maliyetle ölçekleyebilirsiniz. Bağımsız teslimat ve ekip özerkliği de aynı ölçüde önemlidir: Ortak bir deployable üzerinde koordinasyon olmadan teslimat yapması gereken yeterli sayıda ekip varsa, süreç sınırı organizasyonel bir zorunluluğa dönüşür. Hata izolasyonu, bir parçanın geri kalanını da beraberinde sürüklemeden bağımsız olarak çökebilmesi gereken yerde gerçek bir kazançtır — bu, ancak süreç sınırının gerçekten sağladığı bir izolasyondur. Bir parça kanıtlanabilir biçimde farklı bir çalışma ortamına ya da dile ihtiyaç duyuyorsa, teknolojik heterojenlik bir kesimi haklı çıkarır. Ve bağımsız yaşam döngüleri — ayrı compliance, veri yerleşimi, farklı kesinti gereksinimleri — ortak deployable içinde temiz biçimde ifade edilemeyecek bir ayrımı zorunlu kılabilir.

Rakamlara ihtiyaç duymayan bir örnek: Bir sistemin, çok sayıda küçük ve hızlı işlemi işleyen transactional bir çekirdeği ve bunun yanında işlem yoğun bir görevi vardır — örneğin kısa süreliğine çok fazla işlemci gücüne ihtiyaç duyan ve en ucuza farklı donanımda çalışan bir analiz. Ortak deployable içinde işlem yoğun görev tüm çekirdeği pahalı makinelere zorlar ve yük altında onu dışarı itebilir. Ayrı bir servis olarak ise ayrı ölçeklenir, kendisine uygun donanımda, çekirdeğe dokunmadan. Burada süreç sınırı somut bir şey satın alır — ayrı ölçeklenme ve hata izolasyonu —; monolitin sunamayacağı bir şey. İşte kuvvet tam olarak budur.

Ortak payda önemlidir: Kesimi haklı çıkaran büyüklük değil, kuvvetlerdir. Ve bir kesim nadiren ya hep ya hiçtir. Tam olarak bir kuvvetin etki ettiği tek parçayı ayırabilir ve geri kalanını monolitte bırakabilirsiniz. Üstün mimari çoğu zaman “mikroservisler” değil, “önemli olduğu yerlerde birkaç servisi ayrılmış modüler bir monolit”tir.

Önerimiz: Adı konmuş, şu anda mevcut bir kuvvet gerektirdiğinde bir servisi ayırın — ve yalnızca o servisi. Bedeli, ayrılan parça için var olduğu ilk günden itibaren ödenen tam işletim ve tutarlılık yüküdür. Aynı kuvvet monolit içinde de yönetilebiliyorsa — örneğin bir cache'in ya da asenkron bir kuyruğun karşılayabileceği bir yük zirvesi — farklı karar veririz; o zaman kesim, daha ucuz çözümün de sunmayacağı hiçbir şey satın almaz.

Kuvvetlere genel bakış

Kuvvet yoksa, kesimden geriye yalnızca bedel kalır.

Organizasyonel ön koşullar

Mikroservisler önce organizasyonel, ancak sonra teknik bir karardır. Süreç sınırları ekip sınırlarını izler: Bir servisin ona sahip olan — onu tasarlayan, teslim eden ve işleten — bir ekibe ihtiyacı vardır. Bu eşleşme olmadan en kötü sonuç ortaya çıkar: herkese ve hiç kimseye ait olan, her değişikliğin birden fazla ekibe dokunduğu ve kimsenin sorumluluk taşımadığı dağıtık bir sistem.

Ön koşullar somuttur. Servislere anlamlı biçimde sahip olabilecek kadar ekip; bir ekibin kendi servisini işlettiği bir sahiplik kültürü; nöbet ve incident yönetimi için olgunluk; ve ortak iç yapılar üzerinden anlaşmak yerine ekipler arası sözleşmeleri sürdürme disiplini gerekir. Bunlar eksikse, dağıtıklığın faydası olmadan maliyetlerini alırsınız.

Önerimiz: Bir sistemi ancak organizasyonunuzun servislere gerçekten sahip olabileceği ölçüde bölün. Bedeli, mimarinin organizasyona bağlı kalmasıdır — şirket büyürse kesimi yeniden ayarlamanız gerekir; küçülürse çok az ekip için çok fazla servis taşırsınız. Tamamen teknik bir kuvvet, küçük bir ekibin de işletebileceği tek bir servisi zorunlu kılıyorsa farklı karar veririz — o zaman organizasyon geniş bir dağıtıklığa göre yapılandırılmamış olsa da kesim haklıdır.

Teknik ön koşullar

Anlamadığınız şeyi temiz biçimde kesemezsiniz. İlk teknik ön koşul, net alan sınırlarıdır — modüler monolitte zaten modül sınırları olarak var olan bounded context'ler. Sınırlar anlaşılmadan servis ayıran, yanlış bir kesimi düzeltilmesinin en pahalı olduğu yere, ağa ve işletime betonlar.

Diğer ön koşullar bunun üzerine kurulur: Bir servisin diğerlerini bozmadan değişebilmesi için servisler arasında istikrarlı, versiyonlanmış sözleşmeler; sıkı bağlılığın tehdit ettiği yerlerde, çift teslimatın zarar vermemesi için idempotent alıcılarla asenkron iletişim; her servis için kendi veri saklaması, çünkü paylaşılan bir veritabanı az önce çizdiğiniz sınırı yeniden ortadan kaldırır; ve bir işlemin sistem boyunca görünür kalması için servis sınırları boyunca kesintisiz izlenebilirlik.

Önerimiz: Bir servisi ancak sınırı monolit içinde sınanmışsa ve sözleşme, veri saklama ve izlenebilirlik hazırsa ayırın. Bedeli, daha ilk servis ortaya çıkmadan görünür bir ilerleme getirmeyen hazırlık çalışmasıdır. Sınırı zaten net olan, sistemin belirgin dış kenarındaki bir serviste — örneğin üçüncü taraf bir servise bağlantı — farklı karar veririz; orada kesim daha erken yapılabilir, çünkü yanlış sınır riski düşüktür.

İşletimsel ön koşullar

İşletim yükü, hesabın en çok hafife alınan kısmıdır. Büyük ölçüde sabittir: Dağıttığınız anda, üç servis mi yoksa otuz servis mi işlettiğinizden neredeyse bağımsız olarak ödersiniz. Tek bir deployable bir pipeline'a, bir log hedefine, bir deploy'a ihtiyaç duyar. Dağıtık servisler daha fazlasına ihtiyaç duyar, hem de her servis için.

Somut olarak dağıtık işletim şunları gerektirir: servis başına otomatik teslimat ve geri alma (rollback); container'laştırma ve çok sayıda servisi yöneten bir orkestrasyon; merkezi loglar, metrikler ve dağıtık trace'ler, çünkü kesintisiz gözlemlenebilirlik olmadan dağıtık bir sistem bir kara kutudur; servis keşfi ve yapılandırma; servis sınırları boyunca secret yönetimi; ve servis sayısıyla birlikte büyüyen bir nöbet ve incident süreci. Gözlemlenebilirlik ilk incident'a değil, ilk güne aittir.

Önerimiz: İşletim altyapısı — pipeline'lar, orkestrasyon, kesintisiz gözlemlenebilirlik, geri alma — kanıtlanabilir biçimde hazır olduğunda dağıtın. Bedeli, ancak belli sayıda servis ve ekipten sonra kendini amorti eden kayda değer bir başlangıç yatırımıdır. Tek bir kuvvet tam olarak bir servisi zorunlu kılıyorsa ve bu tek servis için ek işletim yükü yönetilebilir kalıyorsa farklı karar veririz — o zaman tüm sistemi dağıtmak yerine bu küçük sabit maliyet kalemini bilinçli olarak üstlenirsiniz.

Geçiş yolu

Mikroservislere giden yanlış yol, legacy sistemden uzaklaşmanın yanlış yoluyla aynıdır: büyük yeniden yazım. Bir sistemi sıfırdan servislere bölmek, henüz anlamadığınız sınırları ağda sabitlemek — ve tüm riski tek bir son tarihte toplamak demektir. Doğru yol, her modernizasyonda olduğu gibi, adım adım, geri alınabilir ayırmadır.

Bu yol, temiz sınırlara sahip modüler monolitle başlar. Somut bir kuvvet ortaya çıktığında — bir parçanın ayrı ölçeklenmesi, bir ekibin bağımsız teslimat yapması gerektiğinde — tam olarak o tek modülü mevcut arayüzü boyunca ayırırsınız. Modülün zaten dar bir arayüzü olduğundan, ayırma büyük ölçüde mekaniktir: Ona kendi verisini verirsiniz, önceki fonksiyon çağrısını arıza modlarıyla birlikte bir ağ çağrısıyla değiştirirsiniz ve tam da bu servis için gerekli işletim altyapısını sağlarsınız. Servisleri birer birer ayırır, her birini işletimde kanıtlar ve geri kalanını monolitte bırakırsınız. Böylece dağıtıklık kuvvetleri önceden varsaymak yerine onlarla birlikte büyür.

Şema: Modüler monolit, kademeli ayrıştırmanın temelidir. Sistemi tamamen değiştirmek yerine gerekli modüller bağımsız servislere dönüştürülür.

Önerimiz: Servislere big bang bir dönüşümle değil, tek tek modüllerin adım adım ayrılmasıyla geçin. Bedeli, monolitin ve tek tek servislerin bir arada var olduğu ve birlikte işletilmesi gereken bir geçiş dönemidir. Mevcut sistemde ayırmaya elverişli sağlam sınırlar yoksa farklı karar veririz — o zaman yanlış bir kesim boyunca dağıtmak yerine, daha tek bir servis ortaya çıkmadan önce sınırları monolit içinde çizersiniz.

Sık yapılan hatalar

Dağıtıklığı pahalı ya da tehlikeli kılan, hep aynı kalıplardır:

• Dağıtık monolit: Birbirine senkron olarak bağımlı olan ve bir veritabanını paylaşan servisler — dağıtıklığın maliyetleri var, faydalarının hiçbiri yok.
• Alan sınırları yerine teknik katmanlar boyunca kesim; böylece her iş değişikliği birden fazla servise dokunur.
• Kesimin çizmesi gereken sınırı tam da yeniden ortadan kaldıran paylaşılan veritabanı.
• Nanoservisler: o kadar ince bölünmüş ki servisler arasında, servislerin içinde olduğundan daha fazla çağrı gerçekleşir.
• Gözlemlenebilirlik olmadan dağıtıklık — işlemleri artık servis sınırları boyunca izleyemediğiniz bir sistem.
• Yanlış sınırları ağda sabitleyen, mikroservislere big bang dönüşüm.
• Artık faydasından çok işletim yöneten tek bir ekip için mikroservisler.
• Bir fonksiyon çağrısının yeteceği yerde ağ çağrısı — kendi başına amaç olarak dağıtıklık.

Karar kontrol listesi

Bir ekibin kesimden önce sorabileceği sorular. Bunlar hüküm değil, teşhis sorularıdır.

• Sınırları önce monolit içinde bulduk ve sınadık mı? Temiz biçimde ayıramadığınız şeyi dağıtmamalısınız.
• Somut bir ihtiyaç var mı? Bağımsız ölçeklenme, hata izolasyonu, ekip özerkliği, farklı teknoloji veya uyumluluk gereksinimi bugün mevcut mu?
• Aynı ihtiyaç monolit içinde karşılanabilir mi? Önbellek, kuyruk veya ayrı bir modül yeterliyse bağımsız servis ek fayda sağlamayabilir.
• Organizasyonumuz servislere gerçekten sahip olabilir ve onları işletebilir mi? Sahibi olmadan, sorumluluğu olmayan dağıtık bir sistem ortaya çıkar.
• İşletim altyapısı — pipeline'lar, orkestrasyon, kesintisiz gözlemlenebilirlik, geri alma — hazır mı? Sabit işletim bedeli hemen ödenir.
• Bu, gerçek bir sınır boyunca hedefli olarak ayrılmış bir servis mi — yoksa tüm sistemin bölünmesi mi? Kesim nadiren ya hep ya hiçtir.
• Beklenen faydayı ve ek maliyeti tek cümleyle açıklayabiliyor muyuz? Açıklayamıyorsak karar için yeterli netlik yoktur.
• Emin değilsek: Geri alınabilir varsayılanı — modüler monoliti — seçtik mi? Koddaki bir sınırı geri almak, ağdaki bir sınırı geri almaktan daha ucuzdur.

Sıkça Sorulan Sorular

Monolit artık basitçe modası geçmiş bir şey değil mi? Hayır. “Monolit” bir kaliteyi ya da yaşı değil, bir teslimat topolojisini tarif eder. Modüler bir monolit, kötü kesilmiş bir servis ağından daha temiz yapılandırılmış olabilir. Modern olan, dağıtan değil, karmaşıklığı en az maliyetli olduğu yere koyandır.

Mikroservisler daha iyi tasarımı zorunlu kılmaz mı? Hayır. Kötü çizilmiş bir sınır bir ağ çağrısıyla daha iyi olmaz, daha pahalı ve düzeltilmesi daha zor olur. İyi tasarım, anlaşılmış sınırlardan doğar — ve bu sınırları monolit içinde de aynı şekilde çizebilirsiniz, orada sadece yeniden kaydırmak daha ucuzdur.

İleride geçiş yapmak zorunda kalmamak için mikroservislerle mi başlamalıyız? Bu, maliyetleri tersine çevirir. Tam işletim ve tutarlılık bedelini hemen ödersiniz ve başlangıçta en az anladığınız sınırları sabitlersiniz. Modüler monolit, tam da sonradan ondan ayırma yapılabildiği için daha ucuz bir başlangıç düzenidir.

Modüler monolit, ekstra adımları olan bir monolit değil mi? “Ekstra adımlar” sınırlardır — ve bütün mesele de onlardır. Fayda sağladığınız ve dağıtıklığın ağ ve işletim maliyetlerini önceden üstlenmeden sonradan kesebileceğiniz modülerliği onlar verir.

Kaç servis doğrudur? Kuvvetlerin gerektirdiği kadar az. Doğru sayı bir idealden değil, gerçek bir kuvvetin süreç sınırını bedelinden daha değerli kıldığı noktaların sayısından çıkar. Sonuç çoğu zaman pek çok servisten oluşan bir alan değil, birkaç servisi ayrılmış bir monolittir.

Peki serverless fonksiyonlar? Aynı eksen üzerinde bir basamak daha ileridirler: daha da ince dağıtıklık, kod yerine ağda daha da fazla işletim. Aynı soru geçerlidir — sınırı hangi kuvvet haklı çıkarıyor? Kuvvet yoksa burada da geriye yalnızca bedel kalır.

İleri okuma

• On yıl sonra hâlâ çalışan yazılım — geri alınabilirlik ve sınırlar neden ömür boyunca belirleyicidir.
• Big bang olmadan legacy modernizasyonu — bütün sistemlere uygulanan adım adım ayırma.
• İstemci sistemlerini bozmadan API sürümleme — dağıtık servislerin onlarsız ayakta duramayacağı sözleşmeler.
• Modüler monolit ve Modüler monolit mi, mikroservisler mi? — bu konudaki bakış açımız ve belgelenmiş kararımız.

Temel, Batunet Engineering Method'tur: erken karmaşıklık yok, tahmin yerine geri alınabilirlik, sınırlar bilinçli ve küçük adımlarla.

Bu soruda kazanan yoktur — yalnızca kendisine etki eden kuvvetlere maruz kalan bir sistem ve bu kuvvetleri tanıyan bir mimari vardır. Bedeli ve kuvveti tek bir cümleyle adlandırabilen, yanıt ne olursa olsun doğru karar vermiştir.