Yazılım dünyasının moda akımlarına kapılma hızı, Paris Moda Haftası'nı bile kıskandıracak seviyededir. Bir zamanlar herkes NoSQL kullanmak zorundaydı, sonra "Serverless" kelimesini cümle içinde kullanmayanları sektörden aforoz ettiler. Şimdi ise sahnenin mutlak yıldızı: Mikroservisler.
Sorunları böl, parçala ve yönet... Kulağa muazzam bir mühendislik zaferi gibi geliyor değil mi? Ancak gerçekte olan şey, sorunları bölmemiz ve onları yönetecek 15 farklı DevOps aracına, 3 farklı bulut sağlayıcısına ve kimsenin tam olarak nasıl çalıştığını anlamadığı bir service mesh ağına muhtaç kalmamız oldu.
Babil Kulesi'nin Dijital İnşası
Eski Ahit'te Babil Kulesi efsanesi, insanoğlunun kibri yüzünden cezalandırılmasını anlatır. Tanrı, gökyüzüne ulaşmaya çalışan bu kuleyi inşa edenlerin dillerini karıştırır. İnsanlar birbirlerini anlayamadıkları için kule hiçbir zaman tamamlanamaz ve yıkılır.
Bugün modern yazılım mimarilerinde kendi Babil Kulemizi inşa ediyoruz. Sistemimizi 40 farklı küçük servise böldüğümüzde, hepsi kendi veritabanına sahip olduğunda ve hepsi farklı dillerde (biri Go, diğeri Rust, bir diğeri Node.js) yazıldığında tam olarak efsanedeki o laneti yaşıyoruz. Servisler birbirleriyle HTTP üzerinden konuşmaya çalışıyor, ancak araya giren ağ (network) gecikmeleri, zaman aşımı (timeout) sorunları ve çöken RabbitMQ kuyrukları yüzünden iletişim sürekli kopuyor.
İki fonksiyonun bir monolitik yapıda (monolith) birbiriyle hafıza (RAM) üzerinden 0.001 milisaniyede konuşabildiği bir problemi, mikroservisler dünyasında çözmek için Kafka, Redis, gRPC ve bolca umut kullanmak zorunda kalıyoruz.
Özgürlüğün Bedeli: Karmaşıklık
Mikroservis mimarisinin bize vaat ettiği en büyük yalan "bağımsızlıktır". Ekipler birbirinden bağımsız kod dağıtımı (deploy) yapabilecektir. Fakat bu bağımsızlığın bedeli öylesine ağırdır ki, kimse bu bedeli ödemeye hazır değildir.
Eskiden uygulamanızda bir hata (bug) olduğunda tek bir log dosyasına bakardınız. Şimdi? Kullanıcının bir butona tıklaması arka planda 8 farklı servisi tetikliyor. Hatanın nerede olduğunu bulmak için, Dağıtık İzleme (Distributed Tracing) araçlarının içinde dedektifçilik oynamanız gerekiyor.
Daha da kötüsü, veritabanlarını ayırdığımız için eskiden tek bir SQL satırıyla (JOIN) hallettiğimiz raporlama işlemleri, artık devasa bir Veri Ambarı (Data Warehouse) mühendisliği problemine dönüşmüş durumda.
Ne Zaman Kullanmalı?
Mikroservisler kötüdür demiyorum. Netflix, Uber veya Amazon ölçeğindeyseniz, binlerce mühendisiniz ve saniyede milyonlarca isteğiniz varsa bu kaçınılmaz bir zorunluluktur.
Ancak sorun şu ki, günlük 5.000 ziyaretçisi olan ve ekibinde sadece 4 geliştiricisi bulunan bir e-ticaret girişiminin Netflix mimarisini kopyalamaya çalışması bir mühendislik harikası değil, bir kibrin (hubris) tezahürüdür.
"Eğer sistemimiz büyürse hazır oluruz" bahanesiyle, hiç gelmeyecek olan o efsanevi trafik için sistemi ölümcül bir karmaşıklığa sürüklüyoruz. Oysa büyüme (scale) problemi yaşamak bir ayrıcalıktır. Çoğu şirket büyüme problemi yaşayacak kadar hayatta kalamaz; tam da bu aşırı mühendislik (over-engineering) yüzünden iflas ederler.
Bir dahaki sefere yeni bir projeye başlarken o modüler, sıkıcı ve yaşlı monolitik yapıyı tekrar düşünün. Belki de ihtiyacınız olan şey yeni bir servis eklemek değil, sisteminizin tek ve bütün bir dil konuşmasına izin vermektir. Babil kulesini yıkmanın zamanı geldi.