İyi giden bir startup’ın MSA’ya geçip 6 ay içinde neredeyse batma hikayesi

Son dönemde yurt dışındaki teknoloji bloglarında gündem olan "Microservices Killed Our Startup. Monoliths Would’ve Saved Us" başlıklı yazıyı okuyunca, hem çok can yakıcı hem de fazlasıyla tanıdık geldiği için özetini paylaşmak istedim.

En yeni teknolojileri sorgusuz sualsiz benimsemenin ne kadar tehlikeli olabileceğini gösteren iyi bir "yanlışlar defteri" gibi.

---

1. Olayın başlangıcı: "Biz de Netflix gibi yapalım"

• Durum: $2.5M seed yatırım alınmış, aylık gelir %40 büyüyor, 50 bin kullanıcı var. Rails monolitiyle gayet iyi çalışan bir startup.
• Sorunun başlangıcı: Lead architect ortaya çıkıp "ölçeklenebilirlik(Scalability)" diyerek MSA dönüşümünü öneriyor.
• Mantık: "Şu anki yapı fazla sıkı bağlı. Netflix’e, Uber’e bakın. Bizim de onlar gibi olmak istiyorsak mikroservislere geçmemiz lazım."
• Gerçek: 4 geliştirici ve 1 DevOps’tan oluşan bir ekip, Netflix mimarisini benimsemeye karar veriyor.

2. Cehennem gibi geçen 6 ay (MSA geçiş zaman çizelgesi)

[1. ay: Balayı]

• Bildirim servisi başarıyla ayrılıyor. "Bak! Gayet iyi çalışıyor, değil mi?" diye kutlama yapılıyor.
• Ama deploy süresinin uzaması, repository sayısının artması gibi öncü belirtiler başlıyor.

[2~3. ay: Çatlakların başlaması]

• Faturalama(Billing) servisi ayrılıyor. Ama bu servis kullanıcı, envanter ve sipariş servislerinin hepsiyle iç içe geçmiş durumda.
• Sonuç: Ağ gecikmesi nedeniyle yanıt süresi 200ms → 800ms’ye çıkıyor. Bir servis çökünce zincirleme arızayla her şey çöküyor.

[4~5. ay: Dağıtık transaction kâbusu]

• Monolitte tek bir DB transaction ile çözülecek iş için, dağıtık ortam yüzünden Saga pattern bile devreye alınıyor.
• Envanter düşüyor ama ödeme başarısız oluyor, rollback karışıyor... Veri tutarsızlığı yüzünden müşteri desteği talepleri patlıyor.
• Basit bir kolon eklemek için bile 6 servise dokunmak gerekiyor; 2 saatte bitecek iş 3 gün sürüyor.

[6. ay: Ekibin dağılması]

• Geliştiriciler özellik geliştirmek yerine tüm zamanlarını altyapı yönetimine harcıyor.
• Altyapı maliyeti $3,000 → $12,000 (4 kat artış).
• Kilit geliştirici ekipten ayrılıyor ("Ben ürün geliştirmeye geldim, bütün gün Kubernetes kurcalamaya değil")

3. Karar anı: "Biz Netflix değiliz"

Mimar hâlâ "Service Mesh ekleyelim ve monitoring araçlarını artıralım" diye ısrar etse de, yazının yazarı sonunda patlıyor.

> "Biz Netflix değiliz! Netflix’in 500 mühendisi var ama biz 4 kişiyiz!"

Sonunda mimar ayrılıyor ve ekip monolite geri dönme(rollback) kararı alıyor.

4. Monolite dönüş ve yeniden ayağa kalkış

• 8 hafta boyunca kod yeniden birleştirilip monolite taşınıyor.
• Sonuç:
• Özellik çıkarma hızı toparlanıyor (ayda 4 → 20)
• Yanıt süresi 220ms’de dengeleniyor
• Altyapı maliyeti düşüyor
• Hepsinden önemlisi geliştirici mutluluğu artıyor

5. Temel dersler (yazının vardığı sonuç)

1. MSA, 'teknik bir sorunu' değil, 'organizasyonel bir sorunu' çözme aracıdır.

• Geliştirici sayısı 50’yi geçip ekipler birbirinin ayağına basmaya başladığında, deploy döngüleri aşırı farklılaştığında kullanılmalıdır.

2. Netflix/Google sizin rol modeliniz değil.

• Onlar da başlangıçta monolitti. Ölçek büyüdüğü için değiştirdiler; en baştan böyle kurulmadılar.

3. Karmaşıklık bir vergidir.

• Servis sayısı arttıkça yönetim maliyeti bileşik şekilde büyür.

4. Ağ çağrıları bedava değildir.

• Bellek içi fonksiyon çağrısı (nanosaniye) ile ağ çağrısı (milisaniye) aynı ligde değildir.

---

Tek cümlelik özet:
"Monolit düşman değil. Kötü mimari düşmandır. 4 kişilik ekipler, lütfen gidip monolit kullanın."

[ahwjdekf]

Tamam. Şimdi de MSA fanatikleri üşüşür.

[aer0700]

"Ağ çağrıları bedava değildir" sözü gerçekten doğru galiba. Fonksiyon çağrısıyla API çağrısı kesinlikle aynı şey değil.

[bungker]

Ben ürün geliştirmeye geldim, bütün gün Kubernetes kurcalamaya değil —> Duyduğum en aptalca laflardan biri bu

[hohemian]

Neden? Amaç k8s olduğu için k8s yapılan bir durumda, bence söylenen doğru gibi duruyor?

[roxie]

bungker adlı kullanıcının yorumlarını beğendiğim için tek tek tıklayıp okuyorum ama sadece bu yorumunuza pek katılamadım, hmm biraz daha açıklayabilir misiniz

[passerby]

İçi boş bir yapay zeka yazısı olmuş; bu yüzden son zamanlarda Medium'a neredeyse hiç bakmıyorum

[mhj5730]

Hizmeti 4 kişi yaptıysa, MSA ile bölmek için bir neden yok gibi görünüyor.

[moderato]

MSA yapmak istiyorsanız organizasyonun da MSA'ya uygun olması gerekir...

[ifmkl]

Sanırım aşağıdaki özette 4. maddenin anlatmak istediği asıl nokta bu. Ayrıca genel olarak içeriğin kendisine de katılıyorum.

[bsh998]

Hmm... Bir şeyler garip görünüyor.
Bu yazı sanki yapay zekayla yazılmış gibi.

[baeba]

Ben de bunu bu aralar çok hissediyorum..
Birçok blog yazısının, yazarın kendi deneyimi + yapay zekanın yardımıyla
yazıldığını tahmin ediyorum.
Yazılar fazla mantıklı ve düzenli, ayrıca okunması çok kolay yazılmış gibi geliyor bana.

[bsh998]

Benim söylemek istediğim şey, bunun fazlasıyla yapay zeka işi gibi durduğu ve herhangi bir referans da içermediği için böyle bir yazının paylaşılmamasının daha iyi olacağı yönündeki görüştür.

[baeba]

Bu, Hacker News'te paylaşılan bir yazı. Benim paylaştığım yazıların çoğu Hacker News'te yer alan içeriklerdir.

https://news.ycombinator.com/item?id=46469845

Dediğiniz gibi... sanırım Hacker News referansını eklemem gerekecek.

[baeba]

1) Yazının güvenilirliğine dair şüphe: pazarlama/AI üretimi kokuyor

Özet

• “Bu fazla ibretlik hikâye gibi kusursuz kurgulanmış” → HN’in seveceği türden bir ‘ahlak oyunu’na optimize edilmiş cümleler olduğu şüphesi doğuyor
• Metinde ücretli kaynak bağlantıları fazlasıyla serpiştirilmiş olduğu için “sonuçta bu bir satış yazısı değil mi?” görüşü güçlü
• Liste bombardımanı ve emoji benzeri üslubun “AI slop (özensizce üretilmiş AI içeriği)” sinyali olduğu da söyleniyor

Sert alıntı (çeviri)

“Bence bütün yazı sadece bağlantısı verilen ücretli kaynakları satmak için var. Ve onca liste yüzünden AI slop gibi hissettiriyor.”
(Orijinal: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

Tek cümlelik yorum

• “İçeriğin doğru ya da yanlış olmasından önce, satış kokusu + AI kokusu fazla baskın” ilk tepki buydu.

---

2) Liderlik/mimar eleştirisi: sorun teknoloji değil, ‘karar alma yapısı’ydı

Özet

• “4 kişilik ekipte mimar mı olur?” diyen çok kişi var; daha baştan işlerin ters gittiği düşünülüyor
• Özellikle kod yazmayan mimar / ayrı DevOps rolü yaklaşımı “darboğaz + CV optimizasyonu” olarak görülüyor
• Ton genel olarak, şirketi batıranın mikroservis değil “kimsenin dağıtımdan/operasyondan/kriz toplamadan sorumluluk almadığı yapı” olduğu yönünde

Can yakan alıntı (çeviri)

“Gerçekte hiçbir şey implement etmeden ‘kurallar’ ve ‘pattern’lar tanımlayan mimarlar neredeyse her zaman kötü fikirdir. Sadece ürünü çıkarın... 10 satır kod bile yazmayacak birinin kararları tekeline alması felaket getirir.”
(Orijinal: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

Tek cümlelik yorum

• Birçok kişiye göre sorun MSA değil, “yetkisi var ama sorumluluğu yok” rol tasarımıydı.

---

3) İş perspektifi: startup’ın başarısızlık nedeni gerçekten MSA mıydı?

Özet

• “Mimari yüzünden battı” çerçevesine inanmayan yorumlar da var
• Temel argüman şu: PMF/talep/müşteri kilidi zayıfsa hangi stack’i kullanırsanız kullanın batabilirsiniz
• Özellikle “müşteri iki gün yavaşladı diye hemen gider mi?” gibi ayrıntılar üzerinden, aslında ürün değer önerisinin zayıf olup olmadığı sorgulanıyor
• Yazının kendi içindeki çelişki de işaret ediliyor: “MSA startup’ı öldürdü” deniyor ama sonuçta “kurtuldu mu?” → anlatının abartılmış olabileceği şüphesi

Sert alıntı (çeviri)

“Startup’ı öldüren şey insanların istemediği bir ürün yapmanızdı. Bu, Python yerine Go kullanmanın startup’ı öldürdüğünü söylemek kadar anlamsız.”
(Orijinal: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

Tek cümlelik yorum

• “Mimari bahane olabilir; asıl neden pazar/ürün/nakit akışı olabilir” görüşü net biçimde mevcut.

---

4) Teknik içgörü: monolith vs MSA konusunda deneyime dayalı tavsiyeler (gerçekten faydalı kısım)

Özet

• “MSA’nın sabit bir genel gider vergisi (operasyonel karmaşıklık) vardır” → küçük ekipler için ölümcül olabilir diyen çok kişi var
• Anahtar kavramlar: Premature distribution (fazla erken dağıtım), modüler monolith/modulith, “sınırları (boundary) hak ederek kazan”
• MSA’nın gerçekten gerektiği koşullar da daha gerçekçi biçimde anlatılıyor: ekip büyüyüp çakışma/dağıtım/organizasyon sorunları fiilen ortaya çıktığında
• Buna karşılık performans/ölçeklenme sorunlarında çözümün çoğu zaman “MSA’ya geçmek” değil; önce algoritma/darboğaz/sharding/partitioning tarafına bakmak gerektiği de söyleniyor

Can yakan alıntı (çeviri)

“Startup’ı öldüren şey mikroservisler değil, ‘fazla erken dağıtım’dı. Gerçek sınırlar oluşmadan sistemi böldünüz; karşılığında sadece latency ve koordinasyon maliyeti ödediniz. Modüler bir monolith ile başlayın, sınırlarınızı hak ederek kazanın, sonra ayırın.”
(Orijinal: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

Tek cümlelik yorum

• Topluluğun gerçekten benimsediği ders şuydu:
  “Monolith ile başlayın, ancak sınırlar ‘doğal olarak’ oluştuğunda servisleri ayırın.”

---

Topluluk genel değerlendirmesi, tek cümleyle

Çoğu kişi “Biz Netflix değiliz” fikrine katıldı; ama aynı anda “bu yazının kendisi de Netflix hastalığını pazarlayan bir anlatı (= pazarlama/AI) olabilir” şüphesi de oldukça güçlüydü.