Bin Mikroservisle Gelen Ölüm
(renegadeotter.com)- Mikroservisleri varsayılan gibi benimseyen kültürün, gerçek ölçek sorunlarını değil var olmayan sorunları çözmek için maliyeti ve karmaşıklığı artırdığına yönelik bir eleştiri
- JavaScript/Node.js ekosisteminin kapalılığı, FAANG tarzı uygulamalar ve bol girişim sermayesi birleşince startup’ların da web-scale mimariyi taklit ettiği bir ortam oluştu
- Docker ve Kubernetes olsa bile geliştirme, hata ayıklama, dağıtım, test ve dayanıklılık sağlama gibi dağıtık sistemlerin zorlukları ortadan kalkmaz
- Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow, WhatsApp gibi şirketler monolitik kod tabanıyla başladı ya da bugün hâlâ çekirdeğinde monolit bulunduruyor
- Çoğu şirket gerçek bir dağıtık sisteme ihtiyaç duyacak ölçeğe ulaşmadığından, yalnızca açıkça ayrılması ve ölçeklenmesi gereken yükler olduğunda bunları servis olarak ayırmak daha gerçekçidir
Karmaşıklığa tapan kültür
- Bir kullanıcının doğum gününü almak için karmaşık bir mikroservis labirentini anlatmaya çalışıp başarısız olan hiciv, günümüz teknoloji kültüründeki aşırı mühendisliği hedef alır
- Sorun, eldeki işi çözmek yerine var olmayan sorunları çözmek için para yakmaya doğru hedefin değişmiş olmasıdır
- JavaScript ve Node.js eleştirisi yalnızca belirli bir teknolojiyle ilgili değildir; daha önce öğrenilmiş dersleri yeniden öğrenmeye zorlayan kapalı yazılım ekosistemi riskleriyle bağlantılıdır
- Sektör geçmişte CORBA ve SOAP gibi karmaşıklık duvarlarına çarpıp yönünü geri çevirdiği deneyimler de yaşadı
Mikroservis modasını yaratan koşullar
- Tarayıcı için JavaScript yazan geliştiriciler “full-stack” olduklarını söyleyerek sunucu geliştirmeye ve asenkron koda girdiler; erken dönem Node kişisel öğrenme projelerine daha yakındı ve erken dönem JavaScript sunucu geliştirme için çok sorunlu bir tercihti
- Node dışındaki dünya fiilen yokmuş gibi kabul edilince, yalnızca Node yaklaşımının doğru olduğu dogmatik bir düşünce oluştu
- Daha sonra FAANG kökenli çalışanlar startup’lara girip “Google’da yapılan yöntemleri” bağlam ve ölçek fark etmeksizin doğru cevap gibi yaydı
- Ayrı bir
User Preferences Serviceyoksa ölçeklenemezsiniz türü baskı bunun tipik bir örneğidir
- Ayrı bir
- Girişim sermayesinin bol olduğu dönemde, gelirden çok yatırımcılara patlayıcı büyüme göstermek önemli hâle geldi ve şirketler pahalı yazılım mühendislerini hızla işe alıp “bir şeyler” yaptırdı
Dağıtık sistemler hâlâ zor
- Mikroservisler “ölçeklenebilir yazılım yazmanın yeni yolu” gibi paketlendi, ancak özünde uzun zamandır var olan dağıtık sistemler sorunuyla bağlantılıdır
- Geçmişte dağıtık sistemler zor ve riskli araçlar olarak görülürdü; özellikle çetrefilli sorunlar için neredeyse son çare sayılırdı
- Dağıtık sistemlerde aşağıdaki işlerin hepsi daha zor ve daha uzun sürer
- Geliştirme
- Hata ayıklama
- Dağıtım
- Test
- Dayanıklılık sağlama
- Mikroservis tabanlı geliştirme için standart araçlar ya da ortak framework’ler yoktur; 2020’lerde bile dağıtık sistemlerle çalışmak yalnızca biraz kolaylaşmıştır
- Docker ve Kubernetes, dağıtık kurulumların özsel karmaşıklığını sihirli biçimde ortadan kaldıramaz
Basitliğin daha iyi sonuç verdiği örnekler
- 5 yıllık startup kod denetimlerinden çıkarılan derslerin özeti, başarılı startup’ların neredeyse arsız denecek kadar Keep It Simple yaklaşımını benimsediğini söylüyor
- Erken mikroservise geçiş, dağıtık bilişime dayanan mimariler ve mesajlaşma merkezli tasarımlar birçok şirketi zor durumda bırakan başlıca tuzaklardı
- Birçok startup basit ve performanslı sistemler kurarken bile “ilk günden mikroservis yapmıyor olmak” konusunda sahte bir aşağılık duygusu hisseder
- “Birkaç mühendisin sürdürdüğü bir Django monoliti ve MySQL instance’ından ibaret; bunda ne yanlış var?” sorusunun cevabı neredeyse her zaman “yanlış bir şey yok”tur
- Deneyimli mühendisler bile bugünün teknoloji kültüründe kendini yetersiz hissedebilir; oysa asıl sorun haksız özgüven, israf ve Dunning-Kruger etkisinin karıştığı bir ortam olabilir
Monolitle de büyüyen şirketler
- Monolit olmadan büyüyemezsiniz düşüncesi neredeyse bir efsanedir
- Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow gibi şirketler monolitik kod tabanıyla başladı; bazıları bugün hâlâ çekirdeğinde monoliti koruyor
- StackOverflow, büyük bir siteyi az donanımla çalıştırmasını performans sayfasında övünç kaynağı yapar
- Shopify hâlâ Rails monoliti kullanıyor ve doğrulanmış Resque ile milyarlarca işi işliyor
- WhatsApp, Erlang monoliti ve yaklaşık 50 mühendisle büyük ölçekte büyüdü
- Mühendislik organizasyonunu yaklaşık 50 kişiyle küçük tuttu
- Bireysel ekipler 1–3 kişilikti ve yüksek özerkliğe sahipti
- Az sayıda sunucuyu tercih etti ve her sunucuyu mümkün olduğunca dikey ölçekledi
- Instagram, 12 kişilik ekiple milyarlarca dolara satın alındı; Threads de Instagram modelini izliyor
Var olmayan sorunları çözmemek gerekir
- Temel soru “hangi sorunu çözüyoruz?”dur
- Sorun ölçekse, neyin neden ayrı bir servise bölünmesi gerektiğini gösteren veri gerekir
- Dağıtık sistemler ölçek ve dayanıklılık için yapılır, ancak bir servis yavaşladığında ya da öldüğünde trafiğin diğer servislere yığılması gibi durumlar da hesaba katılmalıdır
- Gerekli değerlendirme unsurları sistemin kullanım desenlerine ve yük özelliklerine göre değişir
- Backpressure
- Circuit breaker
- Kuyruklar
- Jitter
- Tüm endpoint’ler için makul timeout’lar
- Küçük bir değişikliğin tüm sistemi çökertmemesini sağlayan koruma mekanizmaları
- Çoğu şirket gerçek bir dağıtık sistem gerektiren devasa ölçeğe ulaşmaz
- Amazon ve Google’ın ölçeğine, uzmanlığına ve kaynaklarına sahip olmadan onların yöntemlerini taklit etmek zaman ve para israfına kolayca yol açar
- Kötü bir dağıtık sistemin, dağıtık sistemin kendisinden bile daha zor olduğuna dair uyarı geçerliliğini korur
Ekip başına servis ve API ideali ile gerçeklik
- Şirket yapısını dağıtık topolojiye uydurma çabası, sorunları küçük parçalara bölerseniz kolaylaşacağı fikrinden doğar
- İdeal mikroservis, özel bir ekip tarafından sıkı biçimde sürdürülen, güzel ve geriye dönük uyumlu sürümlenmiş API’lerin arkasına saklanan ve diğer ekiplerle neredeyse hiç iletişim gerektirmeyen bir yapıdır
- Gerçekte ise Slack kanalları release’ler, bug’lar, ayar değişiklikleri, kırıcı değişiklikler ve duyurularla dolar taşar
- Herkesin her zaman tüm durumlardan haberdar olması gerekir; zaten yoğun olan ekiplerin birden fazla mikroservisi yarım yamalak üstlenmesi yaygındır
- İnsan hareketliliğiyle birlikte servis sahipliği de değişir; tek bir iyi yarış arabası yerine birden çok kötü golf arabası üretilen bir duruma dönüşür
Mikroservislerin kaybettirdikleri
-
DRY’nin zayıflaması
- Mikroservisler temelde DRY değildir ve her serviste yinelenen boilerplate bulunur
- Küçük mikroservislerde tesisat kodunun payı büyür; ortalama bir servis instance’ı ürün kodundan çok “servis” koduna benzeyebilir
- Ortak kodu dışarı çıkarmaya çalışsanız da seçeneklerin hepsi acı verir
- Ortak kütüphane oluşturursanız sürüm ve güncelleme stratejisini belirlemeniz gerekir
- Tüm depolara düzenli olarak pull request açıp zorunlu güncelleme yaptırabilirsiniz
- Monorepo altında toplarsanız bunun kendi sorunları ortaya çıkar
- Bir miktar kod tekrarına izin verirsiniz ya da her ekibin her seferinde tekerleği yeniden icat etmesine neden olursunuz
-
Geliştirici deneyiminin kötüleşmesi
- Geliştirici deneyimi, yeni özellik geliştirmek veya bug düzeltmek için gereken sürtünme ve çabanın büyüklüğüdür
- Mikroservis ortamında belirli bir iş için hangi servislerin ayağa kaldırılması gerektiğini, hangi ekibe ve kime ne sorulacağını bilmek için tüm sistemin zihinsel haritasına ihtiyaç vardır
- Spotify, çok sayıda sistemi ve servisi kataloglamak için Backstage’i geliştirdi; bu da bu oyunun maliyetinin yüksek olduğuna dair bir ipucudur
- Spotify olmayan şirketler kendi çözümlerini geçici yamalarla üretir; sağlamlık ve taşınabilirlik beklemek zordur
- Yeni bir servisi başlatmak için otomatikleştirilmesi gereken çok şey vardır
- GitHub/GitLab geliştirici yetkileri
- Varsayılan ortam değişkenleri ve ayarlar
- CI/CD
- Kod kalitesi kontrolleri
- Kod inceleme ayarları
- Branch kuralları ve korumaları
- İzleme ve observability
- Test harness’i
- Infrastructure as code
- Birden fazla programlama dili kullanırsanız bu liste dil sayısı kadar büyür
- Bu otomasyonu olgunlaştırmak aylar sürebilir; ürün mü yapacaksınız, araç mı yapacaksınız seçmeniz gereken bir durum oluşur
-
Entegrasyon testinin zorluğu
- Tekil servis testleri ve birim testleri geçse bile her commit’ten sonra kritik yolların hâlâ korunduğu ayrı bir meseledir
- Dağıtık kurulumlarda entegrasyon testi neredeyse imkânsız bir sorun olarak ele alınır; bunun yerini observabilitynin aldığı düşünülür
- Observability yeni bir sektör alanı hâline geldi ve yalnızca maliyet değil geliştirici zamanı da gerektirir
- Observability bir eklenti gibi hemen çalışmaz; canary release’leri ve feature flag’leri anlamak ve uygulamak gerekir
- Sorunu parçalara bölmek çözümü kolaylaştırmaz; bunun yerine daha zor bir sorunlar demeti elde edersiniz
Monolit otomatik olarak iyi kod demek değildir
- Monoliti savunmak “monolit iyi koddur, mikroservis kötü koddur” anlamına gelmez
- Gerçekte aceleci ekiplerin ya da ortalama ekiplerin yaptığı çok sayıda ortalama monolit vardır
- Ancak dağıtık sistemler üstünkörü geçilen noktalara, kötü kararlara ve kaçırılan hata modlarına çok daha acımasızdır
- Dağıtık sistemlerde her zaman yüksek seviyede işletmezseniz bedel ödersiniz
Mikro olmak zorunda değil; sadece servis yeterli olabilir
- Bir servisin mutlaka “micro” olması gerekmez; sadece servis yeterli olabilir
- Bazı startup’lar her fonksiyon için servis oluşturma seviyesine kadar gitti; bu da doğrulanmamış cargo cult’un ne kadar ileri gidebileceğini gösterir
- Monolitle başlamak net bir seçenektir
- “trunk & branches” deseni de birçok durumda uygun olabilir
- Çekirdek işlevleri “et ve patates” gibi ana monolit üstlenir
- Açıkça tanımlanabilen ve ayrı ölçeklenmesi gereken yükleri branch servisleri üstlenir
- CPU’yu yoğun kullanan
Image-Resizing Service,User Registration Servicee göre ayrı servis olarak daha mantıklıdır - Saniye başına kayıt sayısının bağımsız yatay ölçekleme gerektirecek kadar yüksek olup olmadığı sorusu, servis ayırma kararının ölçütü olur
Modanın geri çekilmesi ve gerçekçi tercih
- Mikroservis aşırılığının soğuduğu görülüyor; girişim sermayesi akışı sıkılaştıkça piyasa şirketleri daha sağduyulu kararlar almaya zorluyor
- Web-scale sorununuz yokken web-scale mimariye para harcama biçimi sürdürülebilir değildir
- New York’tan Philadelphia’ya gitmeniz gerekiyorsa karmaşık bir uzay gemisi yapmak yerine 90 dakikalık bir Amtrak tren bileti almak, soruna daha uygun çözümdür
1 yorum
Hacker News yorumları
Ben mikroservisleri güçlü biçimde savunan kişilerden biriydim; Netflix platformunun kurulmasına yardım ettim ve dünyayı dolaşıp avantajlarını anlattım. Ama startup’lara tavsiye verirken neredeyse her zaman monolit ile başlamalarını söylerim.
Kod tabanını ve veritabanını tek tutmak çok daha kolaydır ve oldukça uzun süre ölçeklenebilir. DynamoDB gibi bir anahtar/değer deposu kullanırsanız ilişkisel özelliklerin bir kısmını kaybedersiniz ama daha uzun süre dayanabilirsiniz.
Monoliti de Lambda’ya dağıtabilirsiniz; servisleri bölmeden de Lambda’nın avantajlarından yararlanabilirsiniz.
Büyüdükten sonra, bağımsız ölçeklenmesi gereken ya da ayrı dağıtım gerektiren parçaları, kendi veri deposuna sahip mikroservisler olarak ayırmanız yeterlidir.
Mikroservisler yalnızca platformu ayakta tutmak için mühendislik zamanının en az %25’ini yer; bu verimliliği geri kazanamıyorsanız değmez.
Büyüme aşamasındayken, hatta çoğu durumda, mikroservis yapmamak daha iyidir.
Ve lütfen veriyi bölmeyin. Veriyi yönetmek koddan çok daha karmaşıktır.
Sistemi sonradan daha karmaşık hale getirmek her zaman mümkündür. Monolitten bazı kısımları ayırıp servis yapabilirsiniz; elbette zordur ama sisteme zaten girmiş karmaşıklığı söküp çıkarmakla kıyaslanamaz.
Birden çok mikroservisi tekrar monolite döndürmüş olanlar bilir; genelde en baştan yeniden yapmakla benzer miktarda iş çıkar.
Bu tür ürünlerde isterseniz üretim ortamını gerçekten bir dizüstü bilgisayarda bile çalıştırabilirsiniz.
Önceki iş yerimde 300 müşteri için mikroservis şöleni yapılmıştı. Binlerce müşteriye ulaşmanın başarı, on binlerce müşterinin ise büyük başarı sayılacağı bir iş olmasına rağmen böyleydi.
Genellikle platformu ayakta tutmaya mühendislik zamanının %25’i harcanmadığı için, yerelde çalıştırmak bile mümkün olmaz ve üretim ortamı ancak koli bandıyla tutturulmuş halde durur.
Yakın zamanda bir mülakatta “500 milyon eşzamanlı kullanıcı” sistemini tasarlamam istendi; o şirket genel olarak müşteri sayısı az, müşteri başına geliri yüksek türdendi.
500 milyonun dünyadaki internete bağlı nüfusun yaklaşık %10’u olduğu için saçma bir sayı olduğunu fark edip etmeyeceğimi ölçen bir test miydi, yoksa startup’ın gerçekten böyle olabileceğine mi inanıyorlardı, hâlâ bilmiyorum.
Ben en basit şeye, yani bir monolit yapmaya ve bunun insanların istediği özelliklere ve ürüne sahip olup olmadığını doğrulamaya odaklanacağımı söyledim; işe alınmadım.
Yaklaşık 800 katkıcısı olan devasa bir monolit üzerinde çalışıyorum; kullanıcı doğum günü gibi basit bir alan eklemek bile aynı derecede karmaşık. Ancak karmaşıklığın tamamı teknik değil; herkesin koduna dokunduğu için “organizasyonel hizalanma” gerekiyor.
Tasarım ve review sonsuza dek tekrar ediyor, en az 2 mimarın onayı gerekiyor ve birden çok planlama döngüsüne ekleniyor. Asıl kod yarım günden az sürüyor.
Code review’da %90 test coverage’ı tutturmak gerekiyor, ama testler o kadar çok ki tek bir PR için fazla büyük oluyor; birden çok PR’a bölünüp birkaç haftalık release’e yayılıyor.
Bu yüzden özellik bayrağının arkasına saklanıyor; şu anda 13.000 özellik bayrağı var.
Üretime girip dashboard ve monitoring eklendikten sonra açıp kapatıp duruyoruz. Doğum günü özelliğinin faturalandırma servisini neden bozduğundan emin değiliz ama sebep o gibi göründüğü için haftalarca analiz etmek gerekiyor.
Sonunda, bir yıl sonra bu işi üstlenen mühendis iyi değerlendirme alıp terfi adayı bile olabilir. Ardından hemen, geliştirmede üçüncü yılına giren başka bir bozuk projeye, kullanıcıların saat dilimi ayarlayabilmesini sağlama işine atanır.
Mikroservis de monolit de her derde deva çekiç ya da gümüş kurşun değildir; tersine kötülüğün ta kendisi de değildir. İkisi de trade-off’ları olan araçlardır ve her organizasyonda farklı bağlamlardaki trade-off’larla birleşir.
Sorun, mühendislerin karmaşıklığa kapılması ve “basitliği” “geçici çözüm” ile karıştırması; organizasyonların da araçları ve mimari desenleri körü körüne taklit etmesidir.
Bir mimari ya da tasarım desenini yalnızca kullanmakla fayda elde edileceğine inanıp safça uygularsanız bu gerçekleşmez.
Yazılım mühendisliğinin karmaşıklıkla bitmeyen bir mücadele olduğunu aklımda tutmaya çalıştım; başarılı olduğum da oldu, başarısız olduğum da.
Bu mücadele her zaman verilmelidir ve en öncelikli değer olmalıdır. Aksi halde böyle şeyler olur.
Bu savaşı bitirecek bir mimari ya da ideoloji yok; bu sadece mesleğin doğası.
Üretim ortamında bu release bayraklarının açılmasını engelledik ve geliştiricilerin son test ile release öncesinde bayrak kodunu kaldırması gerekiyordu.
Bayrak gerektiren her özellik için biraz ek iş çıkıyor, ama birkaç ay sonra bile kod tabanındaki karmaşıklığın azalması büyük fayda olarak geri dönüyor.
Mikroservisler, teknik bir sorunun değil, toplumsal bir sorunun çözümüdür
N mühendisten oluşan bir ekip N² düzeyinde koordinasyon gerektirir. Büyük ekipler bitmek bilmeyen toplantılara, e-postalara ve tasarım incelemelerine saplanır; küçük ekipler daha etkilidir ama büyük sistemleri sürdürmekte zorlanır
Sistemi alt sistemlere bölerseniz her ekip kendi bulmaca parçasına odaklanırken insanlar arasındaki koordinasyonu azaltabilir
Mikroservislerin karmaşıklık ve ek yük getirdiği doğru, ama bu yaklaşım büyük organizasyonların büyük sistemleri hızlıca inşa edip yinelemeli olarak iyileştirmesini sağlar
Artık doğrudan bağlantı kurmak yerine ekipler arası “çapraz fonksiyonel” toplantılara ve karmaşık bir iletişim katmanına ihtiyaç duyarsınız
Alt sistemler arasında neredeyse hiç bağlantı gerektirmeyen bir ayrıştırma bulduysanız, o bağlantılar zaten özgün sistemde de yoktur ve N² sorunu da olmazdı
Tekrar tekrar gördüğüm şey, “herkesin tüm mikroservislerden sorumlu olduğu” devasa tek bir ekip; sonunda da kimse hiçbir şeyden sorumlu olmuyor
“İnsan sorununu” çözeceğiz derken önemsiz bir teknik sorunu karmaşık bir dağıtık sistem sorununa dönüştürüyorlar
Şimdi gerçek bir sorun var
İki tür veritabanını destekliyordu ve yatay ölçeklenebilir bir iş yürütücüsü de vardı
Bir ara 35 kişiydik, ama işten çıkarmalarla 7 kişiye kadar düştük ve o dönemde aslında çok daha fazla iş çıkarmaya başladık. Çünkü herkesi aynı hizaya getirmek için harcanan zaman ciddi biçimde azalmıştı
Toplantılar, onaylar, incelemeler, planlamalar, retrospektifler ve yönetim toplantıları çok daha azaldı; geliştiricilerin takdir alanı büyüdü ve işi öylece bitirdiler
Özellikleri rahatlıkla yarı sürede tamamlıyor, kalan %50'yi teknik borcu kapatmaya ayırıyorduk. Karmaşıklığı acımasızca azalttığımız için yeni özellik ekleme hızı da arttı
Bazı projeler daha fazla insana ihtiyaç duyabilir, ama belirli bir sürede bir sisteme eklenebilecek karmaşıklığın bir üst sınırı olduğunu düşünüyorum
Eşiği aşıp geliştirici sayısını artırdığınızda haftalık özellik sayısı aynı kalır; herkes biraz daha az çalışır ve iletişime daha fazla zaman harcar
Bu süreci binlerce kişiye kadar tekrarlarsanız tek bir alan eklemek aylar sürer
Farklı klasörlere taşıma yöntemini düşünüp düşünmediklerini merak ediyorum
Yeni depo, yeni Docker ayarlarıyla modülerleştirmeye gerek yok. Sadece klasör kullanın
Sık gördüğüm kalıp şu: Mevcut CTO'lar veya VP'ler ilk monoliti ya kendileri yaptı ya da yapılmasına katıldı
Kimse CTO'ya o kodun berbat olduğunu söylemek istemez. Ya da sadece dönem değişmiştir ve baştan elden geçirilmesi gereken bir koddur; bunun monolit olmasıyla ilgisi yoktur
CTO pazarlama ya da yatırım toplamakla meşguldür, mikroservis mi monolit mi kararını veremez; kararı yeni işe alınan mimar verir
Herkes mikroservisleri alkışlar. Çünkü hızla büyüyen ciddi bir teknoloji şirketi anlatısına iyi uyar ve kimse tek başına karşı çıkmak ya da CTO'yu eleştirmek istemez
Mikroservislerin gerçekten en iyi ödünleşim olduğu için önerildiği durumlar çok nadirdir. İnsanlar kendi işlerini sever, daha fazla insan işe almayı sever ve bu şirketin anlatısına iyi uyar
Büyük çaplı yenileme sırasında birçok kodu yeniden yazıp iyileştirebilirsiniz; buna da sadece mikroservislere geçiş dersiniz
Sonuçta CTO'nun duygularını incitmeden, kalabalığı takip ederek ve neredeyse herkesin desteklediği bir gerekçeyle eski kötü kodun büyük bölümünü yeniden yazmanın yolu olur
İster bireysel lead mühendis, ister CTO/kurucu olsun, sonunda geriye dönüp bakınca daha iyisini yapabilirdim sonucuna varır; ekibin özenle izlediği kalıp ve süreçlerin faydalarını ve dezavantajlarını hem sevinç hem de dehşet içinde görür
Önyargılarımı doğrulayan bir yazı olduğu için daha da hoşuma gitti
Yıllardır söylüyorum ama mikroservis çılgınlığının, vasat mühendislerin talebi canlı tutmak için kullandığı bir bahaneye daha yakın olduğunu düşünüyorum. Vasatlık bunu körüklüyor ve aynı zamanda birçok teknoloji şirketinin çarklarını döndürmeye devam etmesini sağlıyor
UNIX’i gerçekten iyi kullanabilen ve StackOverflow gibi güzel, minimalist sistemler kurabilen yetkin mühendis sayısı yeterli değil
Bu yüzden vasatlığı örten bir sis perdesi olarak mikroservisler varlığını sürdürecek. AWS gibi bulut sağlayıcıları kendilerini mümkün olan her kanaldan pazarlayıp karar vericilerin o yolu seçmesini sağladığı için bu daha da böyle
Bulut, mikroservisler ve doğrulanmamış en yeni framework’lerden bahsetmezsen çağın gerisinde kalmış yaşlı biri muamelesi görüyorsun
Oysa böyle sistemlerin en verimli, güçlü ya da güvenli seçenek olduğu durumlar nadirdir
Şu anki şirketim başka şirketlerin içinde kullanılan yazılımlar geliştiriyor; eşzamanlı kullanıcı sayısı en fazla 200 ve kullanımda ani sıçramalar da yok
Sıradan bir web sunucusu için mükemmel bir ortam olurdu ve beklenmedik ölçekleme sorunları da yaşanmazdı, ama herkes buluta geçmek istiyor
Bence nedeni, yöneticilerin, programcıların, hatta müşterilerin bile bulut pazarlamasına ikna olup bulutun havalı olduğuna inanması
Şirketler yalnızca organizasyon şemasını dışa vurmaz; tüm işlev bozukluklarını ve tarihsel yüklerini de ürüne taşır
Beş yıl önce verimli ve iyi tasarlanmış bir veri modeli ile API’ye, iyi yazılmış ve test edilmiş koda sahip güzel bir platform olsa bile; CEO’nun bitmeyen yön değişiklikleri, satış ekibinin bastırdığı son dakika müşteri talepleri, ihtiyaç duyulmayan ve istenmeyen özellikler ekleyen ürün yöneticileri, yetersiz personel ve zaman yüzünden beş yıl sonra tamamen karmakarışık hale gelebilir
Bir gün kendinizi devasa bir teknik borç yığınının karşısında, hata düzeltmenin ve özellik eklemenin gerekenden çok daha uzun sürdüğü bir durumda bulursunuz; mikroservisler de her şeyi yakıp baştan başlamak zorunda olmadığınızı fısıldayan bir siren şarkısı gibi gelir
Bu laf kalabalığı gibi görünebilir ama daha büyük bir nokta var: teknik seçimler nadiren darboğazdır
Buna karşılık mikroservisler çok daha fazla hareketli parçaya ve hata moduna sahip olduğu için çok daha karmaşıktır; bu yüzden vasat mühendislerin, hatta vasat olmayan pek çok mühendisin bile sorun yaratma olasılığı çok daha yüksektir
Bu işi yaparken neyin önemli olduğunu mevcut nesle doğru düzgün öğretmekte başarısız olmuş gibiyiz
Küçük bir ekipte mikroservislere geçiş yaptığımız için katılıyorum. En büyük sorun gözlemlenebilirlik
Operasyonda bir sorun çıktığında tam olarak neyin yanlış gittiğini bulmak devasa bir angaryaya dönüşüyor
Tek bir dağıtık uygulamanın loglarını takip etmek yetmiyor; mesajları birbirine karışmış birden fazla dağıtık uygulamanın loglarına aynı anda bakmak gerekiyor
İzleri görselleştiren araçlar gelirse iyi olur, ama küçük bir ekip olduğumuz için insan kapasitesi sınırlı ve henüz böyle araçlarımız yok
Buna karşılık monolite yıllar önce NewRelic entegre edilmişti. Performans sorunları vardı ama çoğu indekslerle ve birkaç materialized view ile çözüldü
Neyin yanlış gittiğini anlamak kolay; kod eski ve yarış koşullarıyla dolu olsa bile sorunun kendisini çözmek zor değil
Her mikroservis için ayrı bir veritabanı instance’ı olması ve ileride bunları yükseltmek zorunda kalacağımız zaman beni korkutuyor. Tek bir veritabanı instance’ı içinde birden çok veritabanı olmasını isterdim ama o mimari seçenekler arasında yok
Merkezi loglama ve servis çağrısı/kod yürütme izleme yeni şeyler değil. Ancak çoğu zaman sonraya ertelenip böyle tatsız durumlara düşülüyor
Doğru araçlar en baştan eklenmediği için ekip daha küçük ve daha kısıtlı hale geliyor; çünkü servislerin ne yaptığına dair çok az şey biliyor ya da hiçbir şey bilmiyor
Veritabanı instance’larını tek tek yükseltirsiniz. Güvenlik gibi ciddi bir hata yoksa, sırf yükseltme mümkün diye acele etmeye gerek yok
Böyle yazıları okuyunca tuhaf biçimde terapi görmüş gibi hissediyorum. Çünkü 10 yıl önce de aynı şeyleri yüksek sesle söylemiştim ama inançsız muamelesi görüp susmam söylenmişti
“Mikroservis” paradigmasının ağzımda acı bir tat bırakmasını mazur görün. En yeni moda teknolojilerin trade-off’larını tam anlamadan bütünüyle benimsediğinizde neler olacağını bizzat yaşadım
Yıllar önce StumbleUpon’a alındığımda, önde gelen bir bilgisayar bilimi doktorası sahibi, iyi çalışan ve kâr da getiren PHP monolitini Scala/Java mikroservis mimarisine dönüştürmeye çalışıyordu
Yeni işe giriş sürecinde o çılgın bilgisayar bilimciyle tuhaf bir bire bir görüşme de vardı; mikroservislerin avantajlarını hararetle anlatıyor ve “Sadece sayı listelerini toplamak için neden dağıtık bir servis yapalım?” gibi soruları “neden çok daha iyi olduğunu sen anlayamazsın” tarzı el hareketleriyle ustaca geçiştiriyordu
30’dan fazla yeni işe alım ve 4 yılı aşan yoğun geliştirmeden sonra, artık kâr etmeyen şirketin elinde daha yavaş, daha hatalı ve debug edilemez bir dağıtık cehennem tablosundan başka bir şey kalmamıştı
Tüm tasarımın sahibi ve mimarı, o anın “sabbatik izne” çıkmak için iyi bir zaman olduğuna karar verdi; kısa süre sonra da kaçıncı olduğu belli olmayan yatırım parası tükendi ve herkes iş aramaya başladı
Amtrak benzetmesini kullanırsak, bu yazı tamamen raydan çıkmış.
Yazar, berbat mikroservisler yaptıysanız sadece monolit yapsaydınız bunun sihirli biçimde iyi olacağını varsayıyor.
Aynı düzeyde tasarım ve mühendislikle çöp gibi mikroservisler yapılmış olsa bile, hedef monolit olsaydı altın gibi bir sonuç çıkardı der gibi.
Yazının yer yer kendinden memnun bir tonu da var; full-stack JS geliştiricileriyle ilgili yorum buna bir örnek.
Ama gerçek mühendislik açısından içerik neredeyse yok. Ölçüm ya da veri bekleseniz de karşınıza sadece uzun nutuklar çıkıyor.
Sistem değişikliklerinin maliyetini düşük tutmak için karmaşıklığı yönetmek iyi bir hedef, fakat bu yazının önerdiği şey bu değil.
Yazar bunu kabul etseydi ya da veri, en azından tek bir anekdot sunsaydı yazı daha iyi olurdu.
Bizim ekipte olsam, zaten her şeyi bildiğine inanıp artık gelişecek bir şeyi kalmamış biri yerine, bakış açısını genişletip full-stack geliştirici olarak büyümek isteyen parlak ve hevesli bir front-end geliştiriciyi seçerdim.
Mevcut iş yerimde bu akımla mücadele ediyorum; bazı ekiplerde bir ölçüde başarılı olduk, bazılarında ise çok daha az. O ekipler şimdi kendi yarattıkları dağıtık monolit ile boğuşuyor.
İronik biçimde, eski FAANMG çalışanlarının hepsi monolit yanlısı.
Birçok kişi mikroservislerin yinelemeli bir sürecin sonucu olduğunu kaçırıyor gibi. Sonuçta ölçeklenmesi gereken parçaları monolitten ayırıyorsunuz.
Mikroservisler, ihtiyaç olmadıkça bakımını yapmak istemeyeceğiniz çok fazla temel altyapı gerektirir.
Çoğu şirketin de bu modeli destekleyecek uygun bir platformu yok.
Katılıyorum. Bizim şirkette araçlar düzgün çalışmadığı için debugging yapmayı fiilen bırakmış durumdayız.
Yerel makinede tek bir servisi çalıştırmak için diğer 9 servisi bununla konuşacak şekilde ayarlamak gerekiyor.
Müşteri için bir “özellik” geliştirmeye kalksanız bile doğal olarak en az 2 servise aynı anda dokunup daha fazla veri taşımanız gerekiyor.
Bir tarafa breakpoint koyunca diğer taraf timeout oluyor.
Bu yüzden tüm geliştiriciler release build’leri yerel VM’e deploy ediyor; hot reload olmadan console.log, System.PrintLines(), _logger serpiştirip dağınık log dosyalarını okuyor.
Elbette ben bu gemiden atlamayı planlıyorum.
Tamamını distributed tracing’e taşımak daha iyi olur, ancak istekleri doğru izleyebilmek için izleme metadatasını genelinde standartlaştırmak gerekir; bu da daha büyük bir yatırım.
Geliştirmeden çok operasyona faydası olabilir ama yine de yardımcı olur. Düzgün span bilgisi bile bu karmaşayı anlamak için epey içgörü sağlar.
Bir taraftaki breakpoint diğer tarafta timeout’a yol açıyorsa, geliştirme modunda timeout’ları artırmanın ya da kapatmanın bir yolu yok mu merak ediyorum.