Monolit mi mikroservis mi sorusu, çoğu zaman teknoloji sorusu sanılır; oysa cevabı belirleyen değişken çoğunlukla kod değil insan sayısıdır. Conway yasası boş değil: çıkan sistem, konuşan ekibin haberleşme çizgilerini takip eder. Bu yüzden aynı soruya verilecek doğru cevap, ekibin büyüklüğüyle değişir.

Soruyu bu çerçevede sormak, tartışmayı da değiştirir: "hangi mimari daha iyi" yerine "bizim ekibimiz bugün hangi mimariyi işletebilir" sorusuna geçilir. İkincisinin cevabı, ilkine göre çok daha az duygusal ve çok daha pratiktir.

Küçük Ekip: Monolit Kazanır

İki ilâ altı kişilik bir ekip için monolit neredeyse her zaman doğru cevaptır. Tek kod tabanı, tek dağıtım hattı, tek veritabanı: sürüm çıkarmak bir komuttur, hata ayıklamak tek bir yerdedir. Aynı ekibe hem sipariş hem ödeme hem bildirim servislerini canlıda tutmak düşünüldüğünde, dağıtık sistemlerin operasyon maliyeti ekibin tamamını yer.

# 6 kişilik ekip için dağıtım: tek birim, tek adım
deploy:
  birim: web-app
  adimlar:
    - test
    - derle
    - yayinla

Bu tabloda mikroservisin getirisi — bağımsız ölçekleme, ekip başına özerklik — henüz bir yük değildir; ama gideri, yani ağ gecikmesi, sürüm uyumsuzlukları ve altyapı işletme derdini, bugünden ödersiniz.

Büyüyen Ekip: Sınır Çiz, Bölünmeye Başla

Ekip on beş, yirmi kişiye ulaştığında tablo değişir. Tek kod tabanına on farklı ekipin aynı dalda çalışması, inceleme kuyruklarından ve "ben değiştirdim, senin testin bozuldu" konuşmalarından ibaret bir hayat üretir. Bu noktada her şeyi bir anda dağıtmak yerine, en kalabalık ve en ayrışan alanı ayırmak doğru adımdır: ödemeler, bildirimler veya arama gibi net bir iş sınırı seçin. Kararın gerekçesi kod değil, sahiplik olmalıdır: bu alanı ileride hangi takım tek başına taşıyacaksa, sınır oraya çizilir. Sahipsiz ayrılan servis, kısa sürede kimsenin bakmadığı bir küçük monolite dönüşür.

deploy:
  birimler:
    - web-app        # ana uygulama: hâlâ monolit
    - odeme-servisi  # kendi veritabanı, kendi takvimi

Modüler monolit burada da bir seçenektir: tek dağıtım, ama iç sınırlar net. Servise ayırmak yalnızca, o parça için bağımsız ölçekleme veya bağımsız sürüm takvimi gerçekten gerektiğinde yapılmalıdır.

Bu geçiş döneminde dikkat edilecek en kritik nokta, veri sahipliğidir. Ayrılan servisin kendi veritabanı olmalıdır; aksi hâlde iki servis aynı tabloları paylaşır ve sınır yalnızca kodda değil, veride de kurulmuş olmaz. Paylaşılan tablo, ileride yapılacak her ayrışmayı iki kat pahalı hâle getirir. Ayrıca ilk ayrışmayı mümkün olduğunca küçük tutun: ekip, dağıtık sistemin işletme alışkanlıklarını tek bir serviste edinip doğrulamadan ikinci taşı kaldırmamalıdır.

Büyük Organizasyon: Mikroservisin Vakti

Yüz kişilik bir mühendislik organizasyonunda, takımlar arası koordinasyon maliyeti servislere bölünme maliyetini geçmiştir. Her ekip kendi servisine, kendi veritabanına ve kendi yayın takvimine sahip olduğunda, dağıtık sistem bu sefer bir zorunluluk değil, serbesti aracıdır. Ama bu noktaya gelmek için önce monoliti yönetmeyi öğrenmiş olmak gerekir.

Cevap, ekip büyüklüğüyle birlikte değişen bir tayfır: küçük ekipte monolit, büyüyen ekipte modüler sınır ve gerekirse bir-iki servis, büyük organizasyonda ise dağıtık mimari. Tersini savunan, teknolojiyi ekibinden büyük hayal etmektedir.

Bir de unutulmaması gereken vardır: geri dönüş yolu. Servise ayırdığınız bir parçayı, gerekçesi ortadan kalktığında yeniden birleştirmek de mimari bir karardır ve ayırmak kadar meşrudur. Mimari bir kader değil, bugünün koşullarına verilen bir cevaptır; koşullar değişince cevabı güncellemek zorunluluktur.