Mimari toplantılarının en pahalı cümlesi genellikle en masum görünenidir: "Netflix de böyle yapıyor." Mikroservis tartışması çoğu şirkette teknik bir analizle değil, bir özentiyle başlar — ve faturası aylar sonra, dağıtık sistemin operasyon yükü ekibin sırtına binince gelir. Bu yazı o tartışmayı özentiden çıkarıp karara bağlamak için var.
Pratik kural şu: mikroservis bir ölçek çözümüdür, kalite çözümü değil. Kod kalitesi düşük bir monoliti servislere bölmek, dağınık bir odayı on küçük dağınık odaya bölmek gibidir — dağınıklık kalır, üstüne bir de koridor bakımı eklenir. Doğru soru "mikroservise geçmeli miyiz" değil, "hangi problemi çözmeye çalışıyoruz" sorusudur.
Mikroservis neyi çözer, neyi çözmez?
Çözdüğü problemler gerçek ve nettir: farklı parçaların bağımsız ölçeklenmesi, ekiplerin birbirini beklemeden yayın yapabilmesi, bir parçadaki hatanın bütünü indirmemesi ve parça başına farklı teknoloji seçebilme özgürlüğü. Çözmediği problemler de bir o kadar net: karmaşık iş kuralları, düşük test kapsamı, belirsiz alan sınırları ve ekip içi iletişim sorunları. İkinci listedeki dertler, bölünmeyle çözülmek şöyle dursun, ağ üzerinden konuşan parçalara dağılınca daha zor ayıklanır hâle gelir.
Bu ayrımı erken yapmak, yazılım danışmanlığı çalışmalarımda mimari değerlendirmenin ilk adımıdır: önce problemin sınıfı konur, mimari ona göre konuşulur. Tersi sıra — önce mimari hevesi, sonra ona problem aramak — projelerin en pahalı başlangıcıdır.
Monolit ne zaman doğru cevaptır?
Şaşırtıcı sıklıkla. Tek ekip, tek ürün ve öngörülebilir yük varsa; iyi modüllenmiş bir monolit, aynı işlevi dağıtık kurulumdan daha az operasyon maliyetiyle, daha kolay hata ayıklamayla ve daha hızlı geliştirme döngüsüyle taşır. Veritabanı işlemleri tek sınırda kalır, dağıtım tek pakettir, log tek yerdedir. Bunlar "eski usul" değil, mühendislik avantajıdır.
Bölünme vaktinin üç gerçek işareti
Birincisi, ekip çakışması: birden fazla ekip aynı kod tabanında birbirinin yayınını bekliyor, merge kuyrukları büyüyor ve "kim ne zaman çıkacak" toplantıları çoğalıyorsa sınır ihtiyacı doğmuştur. İkincisi, asimetrik yük: sistemin bir parçası (ör. rapor üretimi, arama) diğerlerinden bariz farklı ölçek istiyorsa onu ayırmak somut para tasarrufudur. Üçüncüsü, farklı değişim hızı: haftada üç kez değişen parçayla yılda üç kez değişen parçanın aynı dağıtım paketinde yaşaması, hızlı olanı yavaşın riskine bağlar.
Dikkat: üç işaretin üçü de organizasyon ve yük gerçekleridir, teknoloji modası değil. Ekip yapınız mimarinizi belirler — bunun tersini zorlamak (mimariyle organizasyonu düzeltmeye çalışmak) Conway yasasına kafa tutmaktır ve genellikle kaybedilir.
Telekomda, abone sayısının milyonlarla ölçüldüğü sistemlerde şunu gördüm: bölünme teknik bir zafer olarak değil, ekip sınırlarıyla hizalandığı gün işe yarayan bir karar olarak yaşıyordu. Aynı servisi iki ekibin sahiplendiği her yerde sınır kâğıt üstünde kalıyordu — Conway yasasını kitaptan değil, nöbet listesinden öğrendim.
Atlanan orta yol: modüler monolit
İkili seçim yanılgısına düşmeyin; arada güçlü bir durak var. Modüler monolit, tek dağıtım birimi içinde sınırları sert çizilmiş modüller demektir: her modülün kendi iç yapısı, kendi veri erişimi ve diğerleriyle yalnızca tanımlı arayüzlerden konuşması. Bu disiplin kurulduğunda iki kazanç birden gelir — bugün monolitin operasyon kolaylığı, yarın gerekirse en olgun modülü servise çıkarma opsiyonu. Sınır çizmeyi öğrenmeden servise bölünen ekip, sınırsızlığı ağ üzerinden yaşar; bu da en pahalı öğrenme biçimidir. Sınır çizme pratiğinin — alan ayrıştırma, bağımlılık yönetimi, arayüz disiplini — nasıl çalıştığını yazılım mimarisi sayfasında anlattım.
Geçiş: büyük patlama değil, boğucu sarmaşık
Mevcut bir monoliti bölecekseniz, "hepsini yeniden yazalım" cümlesi neredeyse her zaman tuzaktır. İşleyen desen kademelidir: yeni yetenekler ayrı servis olarak açılır, mevcut sistemden bir sınır bağlamı (örneğin bildirimler, raporlama) seçilip dışarı alınır, trafik kademeli yönlendirilir ve eski kod ancak yenisi kanıtlandığında kapatılır. Her adımda geri dönüş yolu açık tutulur. Bu yaklaşımın adı strangler fig — sarmaşığın ağacı yavaşça sarması gibi, yeni sistem eskisini çalışır hâlde tutarak devralır.
Kimsenin baştan söylemediği fatura: operasyon
Mikroservisin gerçek maliyeti geliştirme değil, işletmedir. Dağıtık izleme (hangi istek hangi beş servisten geçti?), servisler arası kimlik doğrulama, ağ hatalarına dayanıklılık, veri tutarlılığı (dağıtık işlem yönetimi) ve her servis için ayrı dağıtım hattı — bunların hepsi, monolitte bedava gelen şeylerin dağıtık dünyada elle kurulan karşılıklarıdır. Ekipte bu altyapıyı kuracak ve yaşatacak kas yoksa, mimari kararından önce o kası edinme kararı gelir.
Devraldığım bir sistemde ilk haftalarda gördüğüm tablo ders gibiydi: birbirine ağ üzerinden bağlı, ama fiilen tek ekipçe yönetilen ve hep birlikte dağıtılan bir düzine servis. Kâğıt üstünde mikroservisti; pratikte, ağ gecikmesi eklenmiş bir monolit. İlk işimiz bölmek değil, birleştirmek oldu — ve sistem hızlandı.
Karar çerçevesi: dört soru
Toplantıda tartışmayı kısaltan dört soru şudur. Bir: bu bölünme hangi ölçülebilir problemi çözüyor — ekip çakışması mı, yük asimetrisi mi, değişim hızı mı? İki: alan sınırlarını bugün monolitin içinde çizebilir miyiz; çizemiyorsak ağ üzerinden nasıl çizeceğiz? Üç: dağıtık izleme, dayanıklılık ve dağıtım altyapısını kim kuracak, kim yaşatacak? Dört: geri dönüş planı ne — ilk servis beklediğimiz faydayı vermezse ne yapacağız? Dördüne de yazılı cevap yoksa karar olgunlaşmamıştır; iki cevap "bilmiyoruz" ise cevap büyük olasılıkla modüler monolittir.
Sık sorulan sorular
Monolitten mikroservise ne zaman geçmeliyiz?
Üç işaretten en az biri ölçülebilir biçimde varsa: ekipler aynı kod tabanında birbirini blokluyorsa, sistemin bir parçası bariz farklı ölçek istiyorsa ya da parçaların değişim hızı ciddi ayrışıyorsa. Sadece "modern olmak" gerekçesi, operasyon faturasını karşılamaz.
Kaç kişilik ekip mikroservisi taşıyabilir?
Kesin bir sayı yerine oran verilir: her servis, onu sahiplenen bir ekibe (ya da net bir sahibe) ihtiyaç duyar. Beş kişilik tek ekibin on beş servisi sahiplenmesi kâğıtta mümkün, pratikte nöbet listesi kâbusudur. Ekip sayınız birse, cevabınız büyük olasılıkla modüler monolittir.
Modüler monolit ile mikroservis arasında performans farkı var mı?
Aynı süreç içindeki modül çağrısı, ağ üzerinden servis çağrısından her zaman hızlı ve güvenilirdir. Mikroservisin performans avantajı bütünde değil, seçici ölçeklemededir: yalnızca yük altındaki parçayı büyütebilirsiniz. Genel gecikme çoğu sistemde bölünmeyle artar, azalmaz.
Her servisin kendi veritabanı mı olmalı?
İlkesel hedef evet — ortak veritabanı, servis sınırlarını arka kapıdan deler. Ama geçiş döneminde pragmatizm meşrudur: önce şema içinde sahiplik ayrılır, sonra fiziksel ayrım yapılır. Kalıcı ortak veritabanıyla "mikroservis" işletmek, dağıtık monolit denen en zahmetli ara türü üretir.
Yeniden yazmak mı, kademeli geçiş mi?
Neredeyse her zaman kademeli geçiş. Büyük yeniden yazımlar, iş kurallarının yıllar içinde koda gömülmüş inceliklerini kaybeder ve bitiş tarihi kayan projeler üretir. Strangler yaklaşımı — sınır bağlamlarını tek tek dışarı alıp trafiği kademeli çevirmek — riski dilimlere böler ve her dilimde geri dönüş yolu bırakır.
Bu karar için dışarıdan göz ne zaman mantıklı?
Karar organizasyonu, bütçeyi ve birkaç yıllık teknoloji yönünü bağlıyorsa. İç ekip günlük teslimatın içinden sınırları tarafsız çizmekte zorlanabilir; dışarıdan bakış, mimariyi hevesten değil ölçülebilir problemden başlatır. Bu tam olarak fractional teknoloji liderliğinin çalıştığı alandır.
Sonuç: mimari bir moda değil, bilanço kararıdır
Mikroservis ne kahraman ne kötü karakter; belirli problemlerin belirli maliyetle çözümüdür. Kazanan ekipler mimariyi süreçten seçenler değil, problemi ölçüp mimariyi ona uyduranlar oluyor. Elinizdeki monolit sınırları belirsizce büyüyorsa ilk adım bölünmek değil, sınır çizmektir — bölünme o sınırların ödülü olarak gelir.
Bu kararı şirketinizin gerçek yük, ekip ve bütçe tablosuyla birlikte değerlendirmek isterseniz CTO danışmanlığı tam bu masada oturur; yapay zekâ çağında geliştirici rollerinin bu mimari kararlardan nasıl etkilendiğini ise yazılımcı kariyeri yazısında tartıştım.
Bu yazıyı, telekomünikasyon ve havacılıkta hem monolit hem dağıtık sistemler kurup işletirken ve devralınan mimarileri değerlendirirken edindiğim deneyimle yazdım. Hakkımda daha fazlası: Ufuk Aytaş kimdir.