Mikroservisler: Ne zaman gerekir, ne zaman gerekmez?

Mikroservis terimi artık birçok teknik teklifte yer alıyor ve bazen tek başına modernliğin göstergesiymiş gibi sunuluyor. Oysa bu, belirgin faydaları ve belirgin bir maliyeti olan mimari bir tercihtir. Doğru soru, bunun modern olup olmadığı değil, sizin durumunuzun şu anda buna ihtiyaç duyup duymadığıdır.

Bu karar yalnızca teknik ekibi ilgilendirmez. Sistemi çalıştırmanın her ay ne kadara mal olacağını, takibi için kaç kişiye ihtiyaç duyacağınızı ve herhangi bir değişikliği canlıya almanın ne kadar süreceğini belirler. Bu yüzden konuyu burada mimarların değil, karar vericinin diliyle anlatıyoruz.

Sade bir dille mikroservisler

Siparişleri, stoku ve faturalamayı yöneten bir sistem düşünün. Geleneksel yöntemde bunların hepsi, tek seferde dağıtılan ve tek bir veri tabanı kullanan tek bir uygulamadır. Mikroservis mimarisinde ise sistem küçük ve bağımsız servislere bölünür: Her servis tek bir iş yeteneğini üstlenir, kendi verisine sahiptir ve diğer servislerle tanımlı API’ler üzerinden iletişim kurar.

Temel fark, her servisin ayrı ayrı dağıtılmasıdır: Faturalama servisi, sistemin geri kalanı yeniden dağıtılmadan değiştirilip canlıya alınabilir. Bu, mimarinin hem gücünün hem de maliyetinin kaynağıdır; çünkü tek bir program içindeki bir çağrı, artık ayrı programlar arasında ağ üzerinden yapılan bir iletişime dönüşür.

Bunu, her departmanını ayrı bir binaya taşıyan bir şirkete benzetebiliriz. Her departman kendi işini düzenlemekte daha özgür olur; ancak iki departman arasındaki her koordinasyon artık yazışma ve bekleme gerektirir, yazışmadaki her aksaklık da birinin takip etmesi gereken bir soruna dönüşür.

Burada karşılaştırdığımız alternatif, parçaları düzensizce birbirine dolanmış bir sistem değil; içeriden sınırları net modüllere ayrılmış, Modular Monolith olarak bilinen tek parça bir sistemdir. Bu sistem tek bir uygulama olarak dağıtılır, ancak içindeki her modülün belirli bir sorumluluğu ve sahip olduğu verileri vardır.

İlk teklifte görünmeyen gerçek maliyet

Her ek servis, çalıştırılması, izlenmesi ve güncellenmesi gereken bir şey daha demektir. Bu maliyet beş noktada ortaya çıkar:

• Operasyon: Her servisin kendi dağıtım ortamı, ayarları ve kaynakları vardır; servisler genellikle çalışmalarını düzenleyen ve arızalananları yeniden başlatan bir araca ihtiyaç duyar.
• İzleme: Tek bir istek başarısız olduğunda hata, isteğin geçtiği servislerden herhangi birinde olabilir. Bu yüzden merkezî log kayıtlarına ve isteğin servisler boyunca takibine ihtiyaç duyarsınız; aksi hâlde sorunu teşhis etmek uzun bir aramaya dönüşür.
• Veri tutarlılığı: Veriler birden fazla veri tabanına dağıldığında, tek bir iş artık ya bütünüyle başarılı ya da bütünüyle başarısız olan tek bir işlem olmaktan çıkar. Sipariş bir serviste kaydedilirken stoktan düşme başka bir serviste gecikebilir; tasarımın bu durumu açıkça ele alması gerekir.
• Dağıtım ve sürümler: Bir servise yapılan hiçbir güncelleme, ona bağımlı servisleri bozmamalıdır; bu da API sürümlerinin disiplinli biçimde yönetilmesini gerektirir.
• Ekibin büyüklüğü ve deneyimi: Dağıtık sistemler daha geniş bir operasyon deneyimi ve birden fazla servisten geçen her sorun için ek zaman gerektirir.

Bu maliyet mimarinin kötü olduğu anlamına gelmez; operasyon ve takip için ödediğiniz bedelin karşılığında size gerçekten ihtiyaç duyduğunuz bir şey sunması gerektiği anlamına gelir.

Bu maliyet yalnızca kodda değil, şirketin rakamlarında da görülür: her servis kendi kaynaklarına ihtiyaç duyduğu için daha yüksek bir barındırma faturası, ekibin yeni özellikler geliştirmek yerine operasyona ayırdığı daha uzun süre ve mevcut ekipte bulunmayabilecek becerilere duyulan ihtiyaç.

Mikroservisler maliyetine ne zaman değer?

Mikroservisler, aşağıdaki türden koşullardan yalnızca biri ortaya çıktığında değil, birkaçı bir araya geldiğinde maliyetini haklı çıkarır:

• Sistemin farklı hızlarda ölçeklenmesi gereken bölümleri; örneğin muhasebedeki yük sabit kalırken sezonlarda yükü artan bir e-ticaret sitesi.
• Bağımsız çalışan ve güncellemelerini birbirini beklemeden canlıya alması gereken birden fazla ekip.
• Nitelik olarak birbirinden çok farklı bölümler; örneğin basit veri giriş ekranlarının yanında büyük dosyaları işleyen bir servis ya da geri kalanından farklı bir teknolojiye ihtiyaç duyan bir bölüm.
• Arızalarının izole edilmesi gereken modüller; böylece birinin arızalanması sistemin geri kalanını durdurmaz.
• Bölümler arasında net, istikrarlı ve pek değişmesi beklenmeyen iş sınırları.

Bir şirketin e-ticaret sitesi, depo sistemi ve muhasebe sistemi olduğunu, her biri üzerinde ayrı bir ekibin çalıştığını ve siteye olan talebin belirli sezonlarda arttığını varsayalım. Bu durumda e-ticaret sitesini tek başına ölçeklenen bağımsız bir servise ayırmak, pratik gerekçesi açık bir karar olur; çünkü her ekip değişikliklerini kendi zamanında canlıya alır ve sitedeki yük muhasebeyi etkilemez.

Net modüllere ayrılmış tek parça sistem ne zaman daha uygun bir başlangıçtır?

Ekip küçükse, sistem daha yolun başında olup iş kuralları hâlâ değişiyorsa ya da bölümleri arasındaki sınırlar henüz netleşmemişse, erken bölmek yanlış olabilecek sınırları kalıcı hâle getirir. Bu sınırları sonradan ayrı servisler arasında değiştirmek, tek bir sistem içinde değiştirmekten çok daha zordur.

Modüllere ayrılmış tek parça bir sistem, dağıtık bir mimariyi işletmenin maliyeti olmadan, düzenli bir yapının birçok faydasını sunar: tek bir dağıtım, tek bir veri tabanı, ya bütünüyle başarılı ya da bütünüyle başarısız olan işlemler ve hataların daha kolay teşhisi. Disiplinle geliştirildiği sürece bu model, şubeleriyle birlikte tek bir şirkete hizmet veren birçok yönetim sisteminin ihtiyaçlarını karşılar.

Küçük bir yazılım ekibi olan bir ticaret şirketinin satış, stok ve satın alma için bir sistem istediğini varsayalım. Bu sistemi baştan servislere bölmek, izlenmesi ve çalıştırılması gereken şeyleri katlar, ama şirketin gerçekten yaşadığı bir sorunu çözmez. Sistemi net modüllere ayrılmış tek parça bir yapı olarak geliştirmek ise onu daha düşük bir operasyon maliyetiyle modül modül canlıya almayı mümkün kılar.

Kapıyı açık tutmanın yolu

Tek parça bir sistemle başlamak, ileride mikroservislere giden yolu kapatmak anlamına gelmez; yeter ki sistem, gerçek bir neden ortaya çıktığında ayırmaya izin verecek şekilde geliştirilsin:

• Her modülün net sınırları: Siparişler, stok ve faturalama kodda ayrı modüllerdir ve her birinin yazılı bir sorumluluğu vardır.
• Her modülün kendi verisi: Hiçbir modül başka bir modülün tablolarına doğrudan yazmaz, onun iç ayrıntılarını da okumaz.
• Modüller arasında tanımlı arayüzler: Modüller, API’ye benzeyen ve açıkça tanımlanmış arayüzler üzerinden iletişim kurar; böylece herhangi birini ağ üzerinden çalışan gerçek bir API’ye dönüştürmek kolaylaşır.
• Uygun olduğu yerlerde birbirine dolanmış çağrılar yerine olaylar: Bir sipariş onaylandığında sipariş modülü bunu duyurur, ilgili modüller de buna göre hareket eder.
• Baştan itibaren düzenli izleme ve log kayıtları; böylece ayırma zamanı geldiğinde sıfırdan başlamak gerekmez.

Böylece ayrılmaya aday modül neredeyse hazır olur: Sınırları bilinir, verileri ayrıdır ve onunla nasıl iletişim kurulacağı tanımlıdır. Ayırma da bugünden bedelini ödediğiniz bir bahis değil, ihtiyaç ortaya çıktığında vereceğiniz bir karar olarak kalır.

Sistemin içinde net sınırlarla başlayın; bir servisi, onu ayırmak için pratik bir neden bulduğunuzda ayırın, daha önce değil.

Hızlı karar rehberi

1. Değişikliklerini diğerlerinden bağımsız olarak canlıya alması gereken birden fazla ekibiniz var mı? Yanıtınız hayırsa, tek parça sistem çoğu zaman daha uygundur.
2. Belirli bir bölümün geri kalanından bağımsız olarak ölçeklenmesi gerekiyor mu ve bu ihtiyaç bir varsayım olarak değil, gerçekten ortaya çıktı mı?
3. Bölümler arasındaki iş sınırları istikrarlı ve anlaşılır mı, yoksa her aşamada hâlâ değişiyor mu?
4. Ekibinizin dağıtık sistemleri çalıştırma, izleme ve arızalarını teşhis etme deneyimi var mı?
5. Bölümlerin bağımsızlığı karşılığında daha yüksek bir operasyon ve izleme maliyetini kabul ediyor musunuz?

Yanıtların çoğu hayırsa, net modüllere ayrılmış tek parça bir sistemle başlayın ve koşullar değiştiğinde soruyu yeniden sorun. Çoğu evetse, tüm sistemi tek seferde değil, önce ayrılmak için en çok gerekçesi olan bölümü ayırın.

Ayırma zamanı geldiğinde de bu iş tek seferde yapılmaz. Bir modül bağımsız bir servise ayrılır, canlı ortamdaki davranışı izlenir, ardından başka modüllerin de ayrılmasına ya da o noktada durulmasına karar verilir. Geri kalanını bölmeye gerek kalmadan, tek parça sistem ve yanında bir ya da iki bağımsız servis, sizin durumunuz için uygun yapı olabilir.

Sağlıklı bir mimari karar, terimlerden değil, işin niteliğinden, ekibin büyüklüğünden ve büyüme planından yola çıkar. Yeni bir sistemin mimarisini değerlendiriyor ya da mevcut bir sistemi bölmeyi düşünüyorsanız, iki seçenekten birine bağlanmadan önce durumunuzu ITS ekibiyle görüşebilirsiniz.