Mikroservis mi Monolit mi? Küçük Ekipler İçin Gerçekçi Cevap

Mikroservis hangi sorunu çözer?

Asıl çözdüğü sorun teknik değil örgütseldir: çok sayıda ekibin birbirini beklemeden yayın yapabilmesi.

Elli geliştiricili bir organizasyonda tek kod tabanı darboğaz olur. Beş geliştiricili bir ekipte olmaz.

Küçük ekipte maliyeti

Her servis kendi dağıtımını, izlemesini, günlüğünü ve veritabanını gerektirir. Operasyonel yük servis sayısıyla çarpılır.

Servisler arası çağrılar ağ üzerinden gider; hata senaryoları çoğalır. Tek süreçte basit olan bir işlem, dağıtık sistemde tutarlılık problemine dönüşür.

Hata ayıklama zorlaşır. Bir isteğin beş servis arasında nasıl dolaştığını izlemek için ek altyapı gerekir.

İyi kurulmuş monolit

Tek uygulama olmak, düzensiz olmak demek değildir. İyi bir monolit, içinde net sınırlarla ayrılmış modüllerden oluşur.

Modüller arası iletişim tanımlı arayüzler üzerinden yapılırsa, ileride bir modülü ayrı servise çıkarmak kolaydır.

Kendi ürün ailemizde tek uygulama ve net katman ayrımı yaklaşımını tercih ediyoruz; aynı yapı birden fazla projede tekrarlanabiliyor ve ekip her projede aynı haritayı kullanıyor.

Ne zaman ayırmalı?

Bir bileşen diğerlerinden bağımsız ve çok daha yoğun ölçeklenmesi gerekiyorsa.

Bir bileşen farklı bir teknoloji gerektiriyorsa.

Farklı ekipler farklı hızlarda yayın yapmak zorundaysa.

Bu üç durumdan biri yoksa, ayırmanın getirisi maliyetini karşılamaz.

Ara yol: modüler tek uygulama

Kodu modüllere ayırın, her modülün kendi sınırları olsun, ortak veritabanını modül bazlı şemalarla bölün.

Tek dağıtım biriminin basitliğini korurken, ileride ayrılabilir bir yapı elde edersiniz.

Bu yaklaşım, çoğu orta ölçekli kurumsal proje için en dengeli seçenektir.

Arka plan işleri ayrı düşünülmeli

Uzun süren işler, rapor üretimi ve toplu gönderimler ana uygulamadan ayrılmalıdır.

Bu ayrım mikroservis mimarisi gerektirmez; kuyruk tabanlı arka plan işçileri yeterlidir.

Karar kuralı

Ekibiniz on kişiden azsa ve farklı ölçeklenme ihtiyacı yoksa, iyi yapılandırılmış tek uygulama ile başlayın.

Gerçek bir sınır ortaya çıktığında o parçayı ayırın. Baştan ayırmak, olmayan bir soruna maliyet ödemektir.

Modül sınırlarını korumak

Tek uygulamada modüller arası sınırlar zamanla aşınır. Bir modül diğerinin veritabanı tablosuna doğrudan erişmeye başlar.

Bu aşınmayı önlemek için modüller arası erişimi tanımlı arayüzlerle sınırlayın ve doğrudan tablo erişimini engelleyin.

Kod incelemelerinde bu kurala uyulup uyulmadığını kontrol edin; otomatik denetim araçları da yardımcı olabilir.

Sınırları korunan bir tek uygulama, gerektiğinde parçalara ayrılabilir. Sınırları aşınmış olan ayrılamaz.

Ekip büyüdüğünde

Ekip on kişiyi geçtiğinde aynı kod tabanında çalışmak sürtünme yaratmaya başlar.

İlk çözüm ayırma değil, sahiplik tanımlamaktır: hangi ekip hangi modülden sorumlu?

Bu tanım, çoğu koordinasyon sorununu mimari değişiklik yapmadan çözer.

Ayırma kararı, sahiplik tanımı da yetmediğinde ve farklı yayın hızları gerçekten gerektiğinde alınmalıdır.