- Gerçek kullanıcı sayısı az olmasına rağmen gereksiz yere karmaşık bir sistem mimarisi kullanılmasının eleştirisi
- Redis, MongoDB, Kubernetes, mikroservisler gibi çeşitli teknolojilerin gelişigüzel birleştirildiği örnekler sunuluyor
- Tek bir Postgres instance’ı ve basit bir sunucu yapısının yeterli olacağı durumun altı çiziliyor
- Karmaşıklığın bir erdem olmadığı, yalnızca gerekliliği kanıtlandığında ölçeklenmesi gerektiği vurgulanıyor
- Startup’ların ve geliştirme ekiplerinin ölçeğe uygun basit tasarım ilkelerine sadık kalması gerektiğini hatırlatan bir içerik
Gereksiz teknoloji yığınının aşırı kullanımı
- Redis ve MongoDB’nin aynı anda kullanılması gibi rastgele seçilmiş teknoloji kombinasyonları eleştiriliyor
- “Redis neden MongoDB ile konuşuyor?”, “Neden MongoDB kullanılıyor?” soruları yöneltiliyor
- Gerçek kullanıcı sayısı yalnızca 12 kişi olmasına rağmen (bunların 6’sı test hesabı), dağıtık sistem kullanılması eleştiriliyor
- Tek bir Postgres instance’ının yeterli olacağı halde aşırı ölçeklendirmeye gidilmiş bir örnek olarak gösteriliyor
Dağıtım ve altyapı yapısındaki aşırılık
- Mevcut yapı: 15 mikroservis, 8 veritabanı, 3 ortamda Kubernetes cluster’ı, 4 mesaj kuyruğu, service mesh, 2 saat süren bir CI/CD pipeline’ı
- Gerekli yapı olarak ise yalnızca tek sunucu, Postgres, cache için Redis gibi bileşenler öneriliyor
- Gerçek ihtiyaçlara kıyasla altyapı karmaşıklığının aşırı seviyede olduğu açıkça gösteriliyor
Sistem karmaşıklığı ve açıklanabilirlik
- Sistemi junior bir geliştiriciye anlatmak için spagetti gibi dolaşmış diyagramlar gerekiyorsa bunun bir sorun olduğu belirtiliyor
- Ana mesaj, karmaşıklık bir erdem değildir cümlesiyle özetleniyor
- Basit başlanması ve yalnızca ihtiyaç kanıtlandığında karmaşıklık eklenmesi gerektiği vurgulanıyor
Temel dersler
- Teknoloji seçimi ve sistem tasarımı, ölçeğe ve gerçek kullanım miktarına uygun olacak şekilde sadeleştirilmeli
- Kontrolsüz ölçeklendirme ve aşırı teknoloji yığını kullanımı, bakım yapılabilirliği ve verimliliği zedeler
- Startup’ların ve küçük ekiplerin “ölçeğe uygun sadelik” ilkesini koruması önemlidir
1 yorum
Hacker News görüşleri
Bazen bu davranış düpedüz erteleme (procrastination) gibi geliyor
Müşteriler, yatırımcılar, hukuk ekibi gibi insanlarla konuşmak istemediğin için, onun yerine mühendis gözüyle “eğlenceli işleri” yapıyorsun
Dışarıdan üretken görünse de aslında yerinde sayıyor
Her gün bilinçli olarak rahatsız edici işleri yapmazsan giderek köreliyorsun ve sonra aslında kaçınabileceğin büyük sorunlarla karşılaşıyorsun
Bu sadece yazılım için değil, hayatın geneli için de geçerli
Para kazanmak istiyorsan eğlenceli işlerden çok önceliği doğru olan işleri yapman gerektiğini öğrendim
Yoksa gerçeklikten kopuk CTO ya da VPE’lerin ideal mimari takıntısını tatmin etmek için mi yapılıyor diye düşünüyorum
Eskiden sistem tasarımı mülakatlarında monolitik vs mikroservis konusunda ortam yokladığımı hatırlıyorum
Sonuçta yetkili kişilerin istediği yön nettir ve ona karşı çıkmak politik sermaye harcamaktır
“ABC ile XYZ’yi birbirine bağladım” gibi teknoloji yığınıyla övünüp duruyorlar
Özgeçmişi havalı göstermek isteme dürtüsü de var
Aslında projelerin çoğu 1990’lardaki teknolojiyle de gayet yapılabilir, ama işin içine dağıtık sistemler gibi ifadeler girince çok daha ‘cool’ görünüyor
Sektördeki hatalı işe alım kültürü yüzünden, aşçının bıçağı iyi kullanmasından çok ‘belirli bir marka bıçak’ kullanması makbul sayılıyor
Örneğin DuckDuckGo yalnızca algoritmalar ve veri yapıları istiyor, ayrıca sadece “bu arada Perl kullanıyoruz” diyor
Stream, Go bilmeyen adaylara 10 haftalık kurs veriyor; Jane Street de OCaml deneyimi istemiyor
Çalıştığım bevuta IT GmbH de işe girdikten sonra Clojure öğrenmeme imkân tanıdı
Bu yaklaşım, “Ruby on Rails 10 yıl deneyim” gibi eski kafalı ilanlardan tamamen farklı
Çünkü yeni şeyler denemek ve karşılaştırmak istiyordum
Sonuçta yüzlerce kullanıcı için gereksiz karmaşıklık satmak sektörün gerçeği olmuş durumda
“Redis ile cache’leme” sözü çok yaygın ama aslında Postgres de çoğu zaman yeterli
Israrla Redis kullanalım denmesi, yazarın kendisinin de overengineering dürtüsüne yenik düştüğünü düşündürüyor
Ölçek küçükken cache’e ihtiyaç olmaz; geçici veriyi ayrı bir sistemde tutmak daha cazip gelir
Framework’lerin cache soyutlamaları da çoğunlukla Redis düşünülerek tasarlanıyor
Önce in-memory cache ile başlayıp, gerekince Redis eklemek daha iyi
Ama Redis/Valkey fazla kaçıyor. memcached çok daha basit ve pratik
Redis gibi durumu kalıcı tutmadığı için, cache tutarlılığına bağımlı kötü tasarım kalıplarından kaçınmayı sağlıyor
DB cache’i dosya sistemi üzerinden geçmek zorunda olduğu için yavaş
Sorguları verimli yazmak ise bambaşka bir mesele
Postgres’i yeniden hızlandırırsan Redis’i kaldırabilirsin ama genelde olduğu gibi bırakılır
AWS Lambda tabanlı bir web uygulamasında saniyede 1000 isteği işlerken Postgres zorlanıyordu ama Redis rahatça kaldırıyordu
Basitliği sayesinde istisnai olarak kullanmaya değer
Yazarın “basitlik” savunurken sayfayı Tailwind + JS framework + bundler ile yapmış olması komik
İsterse düz HTML ile de yapabilirdi
Bu yüzden kendin yapabileceğin kadar basit bir web framework’ü olan MastroJS’yi tanıtıyorum
Pratikte yalnızca kullanılan utility class’lardan CSS üretiyor
Orijinal tweet, Jeff Atwood’un 2013 tarihli tweet’inden geliyor
Ben de şu an benzer bir karar üzerinde düşünüyorum
Pazar tarafından doğrulanmamış bir ürünse, küçük ve hızlı başlayıp pivot edilebilir bir MVP yapmak doğru
Buna karşılık yatırımcılara ya da büyük şirketlere ölçeklenebilir tasarım yeteneğini göstermen gerekiyorsa, baştan ölçeklenebilir bir yapı seçmelisin
İş modeli ancak tek bir DB’nin kaldıramayacağı kadar büyüdüğünde anlamlı olacaksa, başlangıçtan itibaren ölçeklenebilir mimariyle gitmek uzun vadede daha kârlı olur
Altyapı kâbuslarının içinde çalışan biri için basitlik kulağa boş bir hayal gibi gelebilir
Ama karmaşıklığın büyük kısmı teknik olmaktan çok organizasyonel sorunları çözmek içindir
Dağıtım otomasyonu, arızalara karşı yedeklilik, CI pipeline’ları, secret management, cache’leme gibi şeyler ekibi koruyan güvenlik önlemleridir
Bunları görmezden gelmek ekip ölçeğinde çalışırken risklidir
SQLite da production’da gayet kullanılabilir ama “sadece test için” gibi bir önyargı yayılmış durumda
PaaS varsayılan ayarları da çoğu zaman gereksiz derecede karmaşık oluyor
Önce checklist tabanlı bir build süreciyle başlayıp, bu oturduğunda otomasyona geçmek yeterli
FAANG ölçeğinde olmayan bir hizmette mikroservislerin gerçekten gerekli olduğu örnekleri görmek isterim
Düşünmekten korkulduğu için herkes standart teknoloji yığınını takip ediyor
Kafka, Mongo, Redis gibi şeyleri sorgulamadan kullanmak sorun
Aslında sadece gereken işlevleri kendin uygulamak daha iyi olabilir ve en az bileşeni seçebilme yeteneği mühendisin temel becerisidir
Kafka gibi şeyler çoğu zaman boşuna para harcamaktır
“Karmaşıklığı sadece gerektiğinde ekle” sözü doğru ama bunu sonradan eklemenin zor olduğu durumlar da var
İlk tasarım yanlışsa baştan yazmak gerekebilir
Bu yüzden pratikte basit bir k8s yapısı gibi orta yol çözümler gerekiyor
Yakın zamanda bir mülakatta da benzer bir deneyim yaşadım
10 yıldır ben PMF(Product-Market Fit) bulmaya odaklandım; en baştan ölçeklenebilirliğe takılmadım
Ürün pazara uyarsa, ölçek sorunları parayla çözülebilir
Ama mülakatta “Bir Django servisini günde 10 milyon isteğe nasıl ölçeklersin?” diye sordular
Ben de “sunucu özelliklerini yükseltirim” diye cevap verdim, ama pek tatmin olmamış gibiydiler