“Microservices: Shackles on Your Feet” başlıklı makale, birçok ekibin dağıtım sorunları veya ölçeklendirme ihtiyaçları gibi gerekçelerle mikroservislere yöneldiğini, ancak bu yaklaşımın çoğu zaman gerçek sorunları çözmek yerine yeni zorluklar yarattığını savunuyor. Yazar, ekiplerin genellikle “mikroservislere ihtiyacımız var” demediğini, bunun yerine “dağıtımlar her şeyi bozuyor” veya “ölçekleyemiyoruz” gibi şikayetlerde bulunduğunu belirtiyor. Bu tür sorunların kökeninde genellikle test eksikliği, sıkı bağımlılıklar, net modül sınırlarının olmaması veya veritabanı performans sorunları yattığını vurguluyor. Dağınık bir monolitik yapıyı mikroservislere bölmenin, mevcut karmaşayı temizlemek yerine sadece ağına yaydığını ve gece yarısı operasyonel sorunları artırdığını ifade ediyor.
Makale, mikroservislerin gerçekten anlamlı olduğu durumları da açıklıyor. Bunlar, alanların (domainlerin) veri katmanında birbirine hiç dokunmadığı (örneğin ödeme ve içerik servisleri), ölçeklendirme ihtiyaçlarının tamamen farklı olduğu (örneğin düşük kaynak tüketen bir API ile yoğun CPU gerektiren bir video dönüştürücü) veya mühendis sayısının 150’yi aştığı büyük organizasyonlardır. Bu eşiklerin altında, mikroservislerin getirdiği ek yükün (birden fazla dağıtım hattı, log akışı, hata noktası) faydalarından ağır bastığını belirtiyor.
Sonuç olarak, makale çoğu ekibin mikroservislere değil, daha iyi modül sınırlarına, sağlam testlere ve temiz kod pratiklerine ihtiyacı olduğunu öne sürüyor. Mikroservislere geçiş yapmadan önce, mevcut kod tabanındaki sorunların giderilmesi, monolit içinde gerçek sınırlar çizilmesi ve izleme sistemlerinin kurulması gerektiğini vurguluyor. Ayrıca, geçiş kaçınılmaz olduğunda, “strangler fig” (boğan incir) deseni gibi kademeli yaklaşımların, tam bir yeniden yazmadan çok daha güvenli ve etkili olduğunu belirtiyor.
Mikroservis mimarisinin her zaman bir çözüm olmadığını, çoğu durumda mevcut kod kalitesi ve modül sınırları sorunlarının daha iyi yönetilmesi gerektiğini vurguluyor.