Mikroservisler, startup’ların karşılayamayacağı bir vergidir

• Başlangıç aşamasındaki startup’larda kodu aceleyle mikroservislere ayırmak, ekip üretkenliğinde ciddi düşüşe ve artan karmaşıklığa yol açar
• Monolitik (tek parça) mimari, basit dağıtım, yeni özellikleri hızla yayına alma ve verimli iş birliğiyle hayatta kalmayı optimize eder
• Mikroservisler, ancak büyük ölçekli ölçeklenebilirlik, farklı iş yükleri veya ayrı çalışma zamanı gereksinimleri olduğunda ayrıştırmanın faydasını sağlar
• Aşırı servis bölünmesi, depo karmaşası, dengesiz yerel geliştirme ortamları ve teknoloji yığını uyumsuzlukları hız kaybına ve ekip moralinin düşmesine yol açar
• Startup’lar monolitle başlamalı, ancak net darboğazlar ortaya çıktığında ayrıştırmaya gitmelidir; en iyi yaklaşım temkinli ilerlemektir

---

Giriş ve arka plan

• Startup’ların hayatta kalması, hızlı yineleme, yeni özellik sunma ve kullanıcıya değer üretme becerisine bağlıdır
• Projenin temel mimarisi, teknoloji yığını ve programlama dili seçimi ekip hızını etkiler
• Mikroservisleri erken benimsemek kâğıt üzerinde şık görünse de pratikte üretkenlik kaybı, tamamlanmamış servisler ve aşırı karmaşıklık doğurur
• Veri noktaları: servis orkestrasyonu, Docker/script sorunları, tekrarlanan CI/CD, servisler arası bağımlılık, gözlemlenebilirlik maliyeti, dağınık testler gibi çeşitli geliştirme maliyetleri ortaya çıkar
• Gelişigüzel karmaşık mimarilere yönelmek yerine, işe yarayan yalın mimarinin önemi vurgulanır

Monolitin güçlü yönleri

• İster SaaS olsun ister basit bir veritabanı sarmalayıcısı, zamanla uygulamalar karmaşıklaşır; ancak monolit mimariyi basit ve esnek tutmak daha kolaydır
• Dağıtımı kolaydır; popüler framework’ler (Django, ASP.Net, Nest.js vb.) tarafından desteklenir ve açık kaynak topluluğunun avantajlarından yararlanır
• Gerçek örnek: Bir gayrimenkul startup’ı, Laravel monolitiyle çok sayıda üçüncü taraf entegrasyonunu ve özellik genişletmesini rahatça hayata geçirdi
• Karmaşık altyapıya geçmeden ya da mikroservislere bölmeden, iş ihtiyaçlarını ve beklentileri karşılamaya odaklanabildi
• Ders: Mimari sadelik, ekibin dağıtıma odaklanmasına yardımcı olur; iç modülerleşme başarısız olmazsa ölçek de yeterince büyütülebilir

Mikroservisler her zaman en iyi seçenek mi?

• Pek çok mühendis mikroservislerin en doğru cevap olduğunu düşünür; oysa gerçek değeri ancak ölçekleme gibi özel gerekçeler olduğunda ortaya çıkar
• Az kişili, küçük ölçekli ve hızlı değişen aşamalarda ise tekrarlanan altyapı, yavaş yerel geliştirme ve yavaş iterasyon döngüleri nedeniyle ters etki yaratır
• Segment gibi şirketler bile verimsiz yapıların yol açtığı dönüşümleri yaşadı
• Ders: Mikroservisler, darboğaz çözmek için kullanılan bir araçtır; başlangıç şablonu değildir

Mikroservislerin özellikle erken aşamada başarısız olmasının nedenleri

1. Keyfi servis sınırları

• Domain-driven design ve clean architecture teorilerinden yararlanarak iş mantığını servislere bölme girişimleri → gerçek iş mantığı ile servis sınırları çoğu zaman örtüşmez
• Örnek: kullanıcı, kimlik doğrulama ve yetkilendirme ayrımı; dağıtım karmaşıklığını ve API geliştirme zorluğunu artırır
• Gerçek bir darboğaz ortaya çıkmadan yapılan ayrıştırma, sistemi daha dengesiz ve daha yavaş hale getirir
• İç flag’ler veya toggle’larla gelecekteki ayrıştırmayı simüle etmek, acele altyapı işlerine girişmek yerine sınırları organik biçimde keşfetmek açısından daha etkilidir
• Ders: Ayrıştırma kararları teoriden değil, gerçek darboğazlardan hareketle verilmelidir

2. Depo/altyapı fazlalığı

• Kod stili, test, yapılandırma, dokümantasyon, CI/CD gibi tüm unsurlar servis sayısı kadar çoğalır
• Monorepo yapısı kullanılırsa tüm yapılandırmalar tek yerde yönetilebilir, böylece kod tutarlılığı ve iş birliği verimliliği artar
• Node.js tarafında nx veya turborepo gibi araçlar, iç servisler arasındaki bağımlılık ve build yönetimini kolaylaştırır
• Dezavantajları arasında karmaşık bağımlılık ilişkileri, CI performans ayarı ihtiyacı ve daha hızlı build araçlarına ihtiyaç sayılabilir
• Go ekosisteminde de başlangıçta tek bir workspace ile yönetip, ölçek büyüdüğünde modül ayrımı değerlendirilebilir
• Ders: Küçük ekipler, monorepo ve paylaşılan altyapıyla zaman kazanabilir

3. Dengesiz yerel geliştirme ortamı

• Yerelde çalıştırmanın çok zaman alması, karmaşık script’ler ve sistem bazlı bağımlılıklar onboarding’i geciktirir ve üretkenliği düşürür
• Yetersiz dokümantasyon, uyumluluk sorunları ve OS’e özel hack’ler (ör. yalnızca macOS için script’ler) engel oluşturur
• Bir projede Node.js proxy kullanılarak Docker karmaşıklığı azaltıldı ve geliştirici onboarding süresi kısaltıldı
• Ders: Uygulama yalnızca tek bir işletim sisteminde çalışıyorsa, ekip üretkenliği sonunda tek bir laptop’ın güvenilirliğine bağlı kalır

4. Teknoloji yığını uyumsuzluğu

• Node.js ve Python, hızlı yineleme için iyidir; ancak mikroservis ortamında build/çalışma zamanı uyumsuzluğu sorunları sık görülür
• Go, statik binary, hızlı build ve operasyonel sadelik açısından avantajlıdır
• Başta teknoloji yığını seçimi dikkatle yapılmalı; gerekirse gRPC gibi protokollerle birden fazla dil birlikte kullanılabilir
• ML·ETL gibi özel gereksinimler yoksa farklı stack’leri karıştırmak yalnızca karmaşıklığı artırır
• Ders: Hayali tercihlere değil, ekibin gerçekliğine uyan bir stack seçin

5. Gizli karmaşıklık: iletişim ve izleme

• Mikroservislerde servis keşfi, API versiyonlama, dağıtık izleme, merkezi log yönetimi gibi yetenekler zorunludur
• Hata ve kesinti takibi monolitte tek bir stack trace ile yapılabilirken, dağıtık ortamda çok daha karmaşık hale gelir
• Bunu doğru yapmak için OpenTelemetry gibi uzman araçların benimsenmesi ve bir gözlemlenebilirlik stack’inin kurulması gerekir
• Dağıtık sistemlerin, ek mühendislik zorlukları için zorunlu yatırım gerektirdiği kabul edilmelidir

Mikroservislerin geçerli olduğu durumlar

• İş yükü izolasyonu: görsel işleme, OCR gibi belirli asenkron işler ayrıldığında verimli olabilir
• Ölçekleme ihtiyacındaki dengesizlik: web API ile ML iş yüklerinin donanım ve operasyon gereksinimleri farklıysa ayrı ayrı bölünebilir
• Farklı çalışma zamanı gereksinimi: legacy C++ kodu gibi ana uygulamayla çalışma zamanı uyumu olmayan bileşenler ayrı servis olarak tutulabilir
• Uber gibi büyük mühendislik organizasyonlarının örneklerinde görüldüğü üzere, ancak açık örgütsel ihtiyaçlar ve olgun operasyon kabiliyeti varsa uygundur
• Küçük ekiplerde de nadiren, harici analiz servisleri gibi yönetimi basit durumlarda ayrıştırma pratik olabilir
• Ders: Ancak ayrıştırmanın somut faydasının net olduğu iş yüklerinde tercih edilmelidir

Startup’lar için pratik rehber

• Başlangıçta monolitle başlayın ve kanıtlanmış framework’lerle işe odaklanın
• Tek repo, operasyon ve yönetim verimliliği ile güvenlik açısından erken aşama ekipler için daha faydalıdır
• Yerel geliştirme ortamını sadeleştirmek önemlidir; zorsa ayrıntılı kılavuzlar ve videolar sağlanmalıdır
• CI/CD’ye erken yatırım yapın; tekrar eden işleri otomatikleştirip ekibin zihinsel yükünü azaltın
• Yalnızca net darboğazlar ortaya çıktığında seçici biçimde ayrıştırın; aksi halde monolit içinde modülerleşme ve testleri güçlendirmeye odaklanın
• En yüksek öncelik geliştirme hızını korumaktır
• Ders: Sadelikle başlayın, ayrıştırma ihtiyacı doğdukça ölçeklendirin

Mikroservisleri mutlaka kullanmanız gerekiyorsa

• Teknoloji yığını değerlendirmesi ve geliştirici deneyimi araçlarına yatırım: servis bazlı otomasyon, net script’ler ve birleşik dağıtım yönetimi araçları gerekir
• Güvenilir servis iletişim protokolleri ve standardizasyon: mesaj şeması tutarlılığı, dokümantasyon ve hata işleme gibi ek gereksinimler önceden anlaşılmalıdır
• Test altyapısını sağlamlaştırın: birim, entegrasyon ve E2E testleri servis ayrımına uygun şekilde ölçeklenebilmelidir
• Ortak kütüphaneleri dikkatle ele alın: gözlemlenebilirlik ve iletişim için ortak kod minimum kapsamda tutulmalı, tüm servislerin sürekli yeniden build edilmesi önlenmelidir
• Gözlemlenebilirliği erken kurun: yapısal JSON log’lar, correlation ID gibi temel loglama araçları baştan hazırlanmalıdır
• Sonuç olarak, karmaşıklığı kabul ediyorsanız onu yönetilebilir kılacak sistemi ciddi biçimde tasarlamanız gerekir

Sonuç

• Mikroservisleri aceleyle benimsemek sadece yük getirir; bu yüzden öncelik sadelik olmalıdır
• Belirgin bir acı noktası olmadan ayrıştırmaya gitmeyin; hayatta kalmak ve büyümek için gereken asgari karmaşıklığı ekleme bakış açısı önemlidir
• Önce hayatta kalmak, sonra ölçeklenmek gerekir

[kuil09]

Genel olarak özgün metindeki anlatıya katılıyorum.
Bunun örgütün deneyim meselesi olduğunu düşünüyorum.
Yemek kamyonunda yemek satarken bir restorana dönüşmeyi hayal etmek iyi olabilir.
En baştan iş bölümü ve uzmanlaşmayı hesaba katmak için paydaşların deneyimi mutlak olarak yetersizdir.

[dhlee0305]

Bence startup’lar, hayatta kalma sürelerini uzatmak için maliyeti düşük yöntemleri seçmeli. Mikroservisler kesinlikle ucuz değil. Sahada gerçekten uygulandığında ciddi maliyet yaratıyor. Mümkünse kendi hizmetinize uygun bir mimari tasarlamanın, daha düşük maliyetle benzer etki elde etmenin yolu olduğunu düşünüyorum.
Mikroservislerin kötü olduğunu söylemiyorum. Çok fazla maliyet gerektiren bir model.

[mhj5730]

Yalnızca senkron için bir monolit ve yalnızca asenkron için bir monolit olmak üzere sadece iki tane olsa bile yeterli olduğunu düşünüyorum... Bence mikroservis benimsenmesi nihayetinde veritabanında yönetilmesi gereken tabloların ölçeğine bağlı. Tablolar akıl almaz derecede fazla ve karmaşıksa MSA düşünmek gerekir; basitse monolit en uygun seçenektir.

[roxie]

Tüm bu dalgalar geçip gittiğinde, gelecek nesiller bu kuşağı nasıl hatırlayacak?

[n1ghtc4t]

O zaman da yine o zamanın dalgası vardı...

[bungker]

Bence startup’larda mikroservislerin de birçok avantajı var. Öncelikle monorepo kullanmanın avantajını gerçekten tavsiye ederim.

• Ürünün yönü değiştiğinde, mikroservislerde değiştirilmesi gereken kısımlar monolitik yapıya göre daha nettir ve daha azdır. Bence bu gerçekten çok büyük bir avantaj.
• Yapay zeka destekli geliştirme çağında, mikroservislerin küçük birimleri yapay zeka aracılığıyla geliştirmeyi kolaylaştırır. (Bu, monolitik yapıda yapılamaz demek değildir.)
• CI/CD yükünü kabul ediyorum, ancak yön belirleme aşamasında tasfiye edilen servisler de oluyor. Son yön belirlendikten sonra kurulum yapılsa bile neredeyse kopyala-yapıştır seviyesinde olduğu için bir hafta içinde kurulabilir.
• Dillere göre güçlü olduğu açık kaynaklar belirgin. Security ve business logic Java ile, yapay zeka ise Python ile yapılacak şekilde, mikroservis mimarisinde mümkün olduğunca çok açık kaynak kullanılabilir.

[andone]

Büyük yapay zeka geliştirme çağına uygun olarak, küçük birimler halinde ve tek sorumluluk ilkesine göre uygulamanın hayati olduğuna katılıyorum.

[bus710]

Yorumlarda da kısaca geçmişti ama beam/otp ekosistemi bu açıdan epey esnek ve iyi görünüyor. Gleam örneğinde ise Go ve Rust’ın her iki taraftaki iyi sözdizimi özelliklerine beam kararlılığı da eklenince oldukça etkileyici bir dil ortaya çıkmış. Küçük ölçekli projelerde yavaş yavaş denemek istiyorum.

[ndrgrd]

Ekipleri gelişigüzel bölerseniz, bir araya gelip fikir alışverişi yapmak bile başlı başına devasa bir işe dönüşür.

[GN⁺]

Hacker News görüşleri

• Gerçekten ölçeklenme sorununuz, büyük ekipleriniz ya da bağımsız olarak evrilmesi gereken alanlarınız yoksa mikroservisler sadece maliyet getiriyor, fayda sağlamıyor; Segment de bu yüzden mikroservis ayrımını geri almıştı. Bunun bir teknoloji değil, bir organizasyon kalıbı olduğu vurgulanıyor. Genelde tek bir monolit işletilir, sonra sadece frontend, backend ve uzun süren işler (ör. PDF üretimi) ayrı servislere çıkarılır. Servis sayısı arttıktan sonra standardizasyon ve mimari üzerine düşünülmeye başlanır. 200'den az mühendisin olduğu yapılarda ise çoğu zaman verim kaybı daha büyüktür. Şirketler mikroservisler sayesinde hayatta kalmıyor; onlara rağmen hayatta kalıyor deniyor
  • Bazı geliştiriciler gelecekte büyük şirketlere geçerken CV'lerine iyi görünsün diye mikroservisleri benimsemeye çalışıyor, ama bunun gerçek startup'a pek faydası olmuyor. Bunu engellemek için gerçekten akıllı teknik liderlik gerekiyor
  • 50 mühendisten oluşan bir startup'ta onlarca servise bölünmüş bir yapı görülmüş; yeni katılan birinin sistemi anlaması en az 6 ay sürüyor, kullanıcı sayısı yalnızca birkaç yüz olmasına rağmen inanılmaz bir karmaşıklık oluşmuş. $50 milyon VC parası yakılmış ve şirket sonunda batmış. Ürün yenilikçiydi ve iyi tasarlanmıştı ama bunun bir anlamı olmamış
  • Servisleri ayırırken kodu bölmeden, normal bir monoliti yalnızca rol bayraklarıyla farklı dağıtımlar hâlinde çalıştırmak da mümkün. Arka plan worker'ları da web sunucusuyla birlikte çalıştırılıp health check ve metrikler kullanılabiliyor; load balancer da role göre trafiği dağıtıyor
  • Khan Academy'nin yaşadığı örnekte olduğu gibi, bir monoliti yeterince ölçekledikten sonra edinilen deneyim sayesinde servis sınırlarını belirlemek mümkün oluyor; işte o noktada mikroservislere geçmek uygun hâle geliyor
  • Teknik olarak ayırmak için gerekçeler var ama servis işletmek zaten doğası gereği zor bir iş. Yine de gerçekten gerekiyorsa bu konuda ustalaşma yaklaşımı önemli; sırf moda diye körü körüne reddetmek yerine trade-off'lara bakmak gerekiyor
  • Sırf "birden fazla ekip" var diye organizasyonu bölmek gerekmiyor; gerçekte iki küçük squad oluşur oluşmaz monoliti parçalamaya çalışan direktörler var. Ekipler sık sık yeniden düzenleniyorsa (9 ayda bir gibi), mimari sınırları erken çizmek felaket olabilir. Bir alanın en az 18 ay kadar istikrarlı biçimde tek ekip tarafından yürütülüp yürütülmediğine bakmadan bunu mimari sınır saymamak gerektiği söyleniyor
  • Mikroservis tanımının özü zaten "bağımsız biçimde evrilebilen alanlar" olduğu için bunda yeni bir şey olmadığı düşünülüyor
  • Çok özel bir URL'nin trafik/bellek ihtiyacı diğerlerinden farklı olduğu için, PHP sunucusunun uygun olmadığı yerde başka bir dilde tek bir ek sunucu konmuş ve 1000 kat performans/maliyet iyileşmesi görülmüş. Java/Spring/Guava tarzında servis kavramını "process dışında" ya da "içinde" kurma şeklinde düşünmek gerektiği de belirtiliyor. Teknoloji yığını/sürüm ve serialization iyi standardize edilirse verim artabilir; ama standardizasyon olmazsa iletişim hataları ve uyumluluk sorunları gibi karmaşalar çıkıyor
  • Conway's law'un (kod yapısı organizasyon yapısını yansıtır) pratikte gerçekten doğru olduğu söyleniyor
  • Servisin aslında insanların sunduğu bir şey olduğu, mikroservislerin de şirket içi ekonomideki hizmetler olduğu vurgulanıyor
  • 15 yıl önce yaşanan bir deneyimde, küçük ekibin tek çözümü kolayca işlettiği ama mikroservislere geçince her servisi ayağa kaldırıp koordine etmek zorunda kaldığı anlatılıyor; bunun da YAGNI'yi (gerekmeyene kadar yapma) gerçekten öğrettiği söyleniyor
  • Yüksek trafikli ya da kritik yolları ayırmak gibi teknik gerekçeler çok olabilir; küçük organizasyonlarda genelde arzu edilen yaklaşım olmasa da, sadece yüksek yük getiren yolları kesip ayırmak startup'larda büyük fayda sağlayabilir
  • Gerçekten de mikroservislerin ana faydası, küçük grupların birbirine karışmadan bağımsız çalışabilmesi. Ancak farklı ekipler farklı mikroservislerin sahibi olunca standardizasyon toplantıları sonsuza kadar sürüyor ve başka servislerle iş birliği yapmaktan çok "başkasının işine karışma" diplomasisi daha önemli hâle geliyor
• 2-3 geliştiricilik bir ekipte sırf havalı göründüğü için mikroservis benimsenmiş; buna karşı uyarı yapılmasına rağmen uygulanmış. 2 yıl sonra ancak mevcut kodu yeniden inşa etmeye başlamışlar ve 3 yıl geçmesine rağmen deployment ve diğer sorunları hâlâ çözememişler. Başta tavsiyeyi dinleyip modüler monolit seçselerdi bunların hiçbiri yaşanmayacaktı; bu görüşe katılınıyor
  • Gösterişli teknoloji/proje geçmişini bırakıp kısa süre sonra iş değiştirince, sonradan gelen yük başkalarına kalıyor
  • Mikroservisler ancak her servisten bir ekibin sorumlu olduğu durumda gerçekten işe yarıyor; tek bir ekibin birçok servise bakmasının iyi sonuç verdiği pek görülmemiş
  • Sorunların büyük kısmı, ekip üyelerinin mikroservisleri hâlâ tek bir sistemmiş (monolitmiş) gibi düşünmesinden kaynaklanıyor. Tasarımdan deployment'a kadar her adımda sürtünme çıkıyor; bunun başarılı olması için tüm organizasyonun bu yaklaşımı gerçekten içselleştirmesi gerekiyor. Var olan sistemi mikroservislere dönüştürmek ise içeride ciddi direnç yaratıyor
  • Sonuçta startup'larda herkesin benzer bir çileden geçtiği hissi oluşuyor
  • 8-12 mikroservisten oluşan bir iç UI projesinde bile gerçek kullanıcı sayısı 5-10 kişiyken gereksiz karmaşıklığın büyüdüğü, nedeninin anlaşılmadığı söyleniyor
  • Thoughtworks danışmanlığıyla mikroservis + Java benimsenmiş; danışmanlık şirketi parasını kazanıp gitmiş ama organizasyon aslında çok özellikli bir monoliti dağıtık mikroservisler olarak yeniden yazmaya çalışırken kaybolmuş. Proje sonunda başarısız olmuş, şirket de kapanmış; o günden sonra büyük danışmanlık şirketlerine güven azalmış
• grug beyni tarzı düşününce, niye insan sistemi bilerek parçalayıp üstüne bir de network call ekleyen daha zor yolu seçsin ki diye soruluyor
  • Bu, sanki Python'daki gibi bir dil özelliği olan "monkey patch"i böyle bir özellik olmayan yere sonradan eklemeye benziyor gibi hissettiriyor
  • Bir görüşe göre network call, bir kuralı (rule) yasaya (law) dönüştürüyor
  • grug mizahıyla, çok fazla grug beyinli grug olunca bir üst grubun 9 grug ile 1 ayda bebek grug yapabileceği gibi bir yanılgıya düştüğü söyleniyor
• Mikroservisler büyük organizasyonlarda insan kaynaklı sorunları çözmek, bürokratik engelleri azaltmak ve geliştiricilere özerklik vermek için etkili olabilir; küçük startup'larda ise gerçek fayda çoğu zaman sınırlıdır. Yine de belirli alanlarda teknoloji yığını karışıyorsa (ör. Elixir ile Python/Go birlikte kullanılıyorsa) böyle bir ayrım gerekebilir
  • Uygulamanın farklı kısımlarının yük veya kaynak gereksinimi farklıysa, küçük startup'larda bile ayrı servisler kurmanın avantajı olabilir. Çoğu iş mantığını monolitte tutup yalnızca GPU gibi özel işleri ayırmak mantıklı görülebilir. Ama bu yaklaşımın 100 servislik bir yapıya dönüşmesi istenmez; temel tercih monolit olup, ayrım yalnızca gerektiğinde yapılmalıdır
  • Mikroservisler aslında yeni organizasyonel bağımlılıklar ve koordinasyon ihtiyacı da yaratıyor. Örneğin "herhangi bir servisi al kullan" politikası bakım yükünü ciddi biçimde artırıyor ve sistemin işlemesi için herkesin her şeyi öğrenmesini gerektiriyor. Sonunda da insanlar geliştirici aramaya daha çok zaman harcıyor
  • Birbiriyle çatışan ya da örtüşen ekipler varsa verimsizlik büyüyor
• Mikroservisler yazılım mimarisinde Conway's Law'a (organizasyon yapısının kod yapısını etkilemesi) benziyor; her ekip sınırında aşılması gereken yeni bir sınır oluşuyor ve içeride büyük mimari sınırlar yapay biçimde yaratmak çoğu durumda verimsiz oluyor. Bunun yerine dependency injection, modül sınırı tasarımı ve actor model gibi yaklaşımlarla modüler monolit kurmak, sonra gerçekten ihtiyaç doğarsa servislere bölmek daha kolay oluyor; maliyet/fayda açısından bunun daha iyi sonuç verdiği söyleniyor. Monolitin 3-4 kez başarıyla parçalandığı doğrudan deneyimlenmiş
  • Conway's Law aslında iletişim, yani communication sınırlarıyla ilgili bir yasa; her ekip sınırına mutlaka dokunmak gerekmiyor. Hatta çoğu zaman organizasyonu yazılıma göre yeniden düzenlemek gerekiyor; yani mimari her değiştiğinde şirketin de reorganizasyon yaşaması gerekebilir. Bunun da ekipler ile iş hedefleri arasındaki kopuşu derinleştirdiği, Amazon tarzı yaklaşımı körü körüne benimsememek gerektiği savunuluyor
• Teknik açıdan startup'ta mikroservislerin uygun olabileceği durumlar şunlar: (1) çekirdek uygulamadan farklı bir dil zorunluysa (ör. Rails + R), (2) bazı servislerin ölçek ihtiyacı diğerlerinden aşırı farklıysa, (3) belirli verilerin güvenlik/yaşam döngüsü gereksinimleri farklıysa (ör. sağlık verisi). Bunun dışında daha ince bölmeye çoğu zaman gerek yok; küçük organizasyonlar için zararı daha fazla olabiliyor
  • Yeni birkaç servise bölmek, gerçek mikroservis olmakla aynı şey değil; gerçek mikroservis yaklaşımında normalde uygulama içinde modül olarak kalabilecek parçalar bile servis hâline getiriliyor
  • Sadece ölçek değil, güvenilirlik ve erişilebilirlik gereksinimleri de çok farklıysa ayrı servis mantıklı olabilir. SLA'yı korumak için ilgi alanlarını ayırarak riski azaltmak ve deployment hızını artırmak mümkün görülebilir
  • Ama bunun bile çoğu zaman yalnızca DB sunucusunu ayrı çalıştırmaktan çok farklı olmadığı da söyleniyor
• Mikroservislerin asıl başarısı organizasyon tarafında: sorunu parçalara ayırıp her ekibin kendi parçasına tam sahip olması, uçtan uca teslimattan sorumlu olması sayesinde uzmanlaşma mümkün oluyor; değişim de doğal olarak kademeli ilerliyor. API tek etkileşim yolu oluyor; ortak DB, dosya sistemi ya da API paylaşılmıyor. Bunun karşılığında standardizasyon ve yönetim araçları (monitoring, testing, CI/CD dâhil) kritik hâle geliyor; gerçi bunlar monolitte de belli ölçüde gerekiyor
  • Altyapı, logging, authentication gibi konular paketleniyor ya da gRPC ve message queue gibi araçlarla yönetiliyor; yeni servis oluşturmak hızlanıyor, ekip içindeki merge request'ler küçülüyor, çatışmalar azalıyor ve verim artıyor. 5-10 kişilik ölçekte monolit kullanılırken çatışma, deployment ve release sorunları sık yaşanırken, mikroservislere geçince üretkenlik, iş birliği ve README'ler iyileşmiş. Ama test, dokümantasyon ve endpoint kurallarının sıkı olması gerektiği de vurgulanıyor
  • DB ayrımı gibi performans kaynaklı teknik nedenlerle servisleri ayırmak gerekebilir ama sıradan startup'larda bu daha nadir olabilir
• BEAM/OTP (Erlang, Elixir) ekosisteminin gücü, monoliti korurken "mikroservis benzeri" tasarımı uygulamaya izin vermesi ve gerçek ayrım gerektiğinde bunu kolaylaştırması olarak anlatılıyor. Küçük ölçekte monolitin avantajları korunuyor, büyüdükçe aynı anda ölçeklenme ve bağımsızlık kazanılabiliyor. Ama immutable object'ler, concurrency communication ve hata yönetimi gibi konuların öğrenilmesi gerekiyor; ayrıca uygun çalışan bulmak da zor olabilir
• Çoğu kişi buna katılıyor; startup ortamında servis sınırlarını doğru belirlemek neredeyse imkânsız. Yine de küçük ekiplerde dış API'ler ya da karmaşık bağımlılıklar yüzünden mikroservisleşmenin faydalı olduğu durumlar olabiliyor. Bu gibi durumlarda network sınırı zaten kaçınılmaz olduğu için bunu ayrı servis yapmak ek karmaşıklığı çok büyütmüyor. Ya da build/deployment karmaşıklığı varsa ayırmak monoliti sadeleştirebiliyor
• Mikroservisler ancak çok büyük ölçek ya da ekip mikro yönetimi ihtiyacı olduğunda uygun görülüyor; yine de net modül sınırlarından vazgeçmemek gerekiyor. Mesajlaşma tarzı nesne yönelimiyle, monolit içinde de mikroservislerin bazı avantajları elde edilebilir. DB'ye doğrudan dokunmama disiplini önemli; Java gibi dillerde modülerlik, DB schema namespace'leri ve yalnızca minimum arayüzleri açma yaklaşımıyla bağımsız test ve monitoring mümkün olabiliyor, birden fazla servisi aynı anda deployment etmek de kolaylaşıyor
  • Mantıksal sınırlar yeterince iyi anlaşılırsa bunu ArchUnit gibi araçlarla zorunlu kılmak da mümkün deniyor
• 2-3 geliştiriciden oluşan bir ekipte, havalı göründüğü için mikroservis benimsenmesi tavsiye edilmiş ve buna rağmen uygulanmış; 2 yıl sonra ancak mevcut kodu yeniden kurmaya başlamışlar, 3 yıl geçmesine rağmen deployment ve diğer sorunlar hâlâ çözülmemiş. Başta modüler monolit seçilseydi bunların yaşanmayacağı söyleniyor; bu görüşe güçlü bir katılım var