- Erken aşamadaki startup’lar, ilk günden Kubernetes veya otomatik ölçeklendirme kurmak yerine zamanlarını ürünü geliştirmeye ve product-market fit bulmaya ayırsa daha iyi olabilir
- 20–30 Lambda fonksiyonu, SQS ve CloudWatch’a dağılmış loglar; hata ayıklamayı, değişiklik yapmayı ve dağıtımı zorlaştırıyordu. Tek bir NodeJS container’ı veya Redis’li bir Flask/FastAPI uygulamasıyla sadeleştirme alanı vardı
- CRUD ve iş mantığının EKS üzerinde 7 mikroservise bölündüğü bir örnekte, özellik geliştirmekten çok altyapı işletimine zaman harcandı
- Tek bir VM bile EC2, GCP VM, Hetzner, latitude.sh gibi seçenekler ve 40GB RAM·çok çekirdekli sunucularla erken aşama servisler için yeterli işlem gücü sağlayabilir
- Basit bir kurulumda bile pratikte kullanılabilir olması için HTTPS, kısıtlı SSH/SSM, CI/CD, DNS, DB yedekleri, bekleme VM’i, felaket kurtarma, güvenlik kuralları ve yedek saklama politikaları bulunmalıdır
Erken aşama startup’larda gereğinden fazla altyapı nasıl ortaya çıkar?
- Pieter Levels, birden fazla micro-SaaS’i tek bir sunucuda çalıştırarak bulut altyapısı karmaşıklığından kaçınan ve product-market fit’e odaklanan bir örnek olarak gösteriliyor
- Bu yaklaşım her ekip için doğru cevap olmayabilir, ancak dağıtım ve altyapı yönetiminin karmaşıklık uğruna karmaşıklaştığı durumları iyi gösteriyor
- MVP sonrasındaki küçük geliştirme ekipleri dağıtım ve veritabanı yönetiminde zorlanabilir; ancak her proje ilk günden Kubernetes’e, karmaşık dağıtık sistemlere ve otomatik ölçeklendirmeye ihtiyaç duymaz
- Basit altyapı, ekibin iyi bir ürün geliştirmeye ve pazar uyumunu bulmaya daha fazla zaman ayırmasını sağlar
- Kurumsal ölçekli şirketlerin uyumluluk ve büyük iş gücü gibi ayrı sorunları vardır; ancak erken aşamadaki startup’ların bu karmaşıklığı aynen takip etmesi gerekmez
Gerçek örnekler: karmaşıklığın yarattığı operasyon yükü
-
Lambda aşırı yükü
- Farklı servisler için 20–30 Lambda fonksiyonu vardı
- SQS ve çeşitli arka plan işleri de Lambda tabanlı yapılandırılmıştı
- Loglar CloudWatch genelinde dağınık olduğu için kök nedeni izlemek zorlaşıyordu
- Hata ayıklama sancılı, değişiklik yapmak zahmetliydi; monorepo’da bile dağıtım karmaşıklaşıyordu
- Tek bir NodeJS container’ı ya da Python Flask/FastAPI uygulaması ve Redis tabanlı arka plan işleriyle daha basit hale getirilebilirdi
-
Mikroservis fazlalığı
- Kubernetes EKS üzerinde 7 küçük mikroservis çalışıyordu
- CRUD ve iş mantığı ayrı servislere ayrılmıştı
- Kubernetes güçlüdür, ancak bu ekip özellik geliştirmekten çok altyapıya zaman harcıyordu
- O ölçekte bu düzeyde servis ayrımının gerçekten gerekli olup olmadığı soru işareti olarak kalıyor
Tek sunucu yaklaşımı neden gerçekçi?
- Tek sunucu kurulumu, modern VM’lerin performansından aktif biçimde yararlanan bir yaklaşımdır
- Hetzner, latitude.sh üzerinden bütçe dostu güçlü VM’ler bulunabilir
- GCP VMs, EC2 instance’ları da makul fiyat aralığındadır
- 40GB RAM ve birden çok çekirdeğe sahip bir sunucu, birden fazla dağıtık servis, birden fazla Lambda ve birden fazla ECS task’tan daha iyi bir seçenek olabilir
- Her şey tek yerde toplandığı için işletim ve yönetim kolaylaşır
- Milyonlarca QPS’e ölçeklenme konusu gerçekten o noktaya gelindiğinde ele alınabilir; o zaman da büyük olasılıkla bir altyapı ekibi olacaktır
- Kararlı bir tek VM işletimi için temel operasyon düzenekleri gerekir
- EC2, GCP VM, Hetzner gibi sağlam bir makine
- Web için HTTPS; dağıtım için IP kısıtlamalı SSH veya SSM gibi güvenli erişim
- Kesintisiz dağıtım için CI/CD
- DNS ayarları
- Düzenli veritabanı yedekleri
- Yedeklilik için bekleme VM’i
- Sağlam bir felaket kurtarma stratejisi ve test edilmiş ortalama kurtarma süresi gerekir; bu, yedek VM ile sağlanabilir
Docker Compose ve Docker Compose Anywhere
- Docker Compose, yerel geliştirmede birden fazla servisi tek komutla yönetmek için iyidir; ancak prodüksiyonda daha az kullanılıyor
- Docker Swarm’ın deprecated olduğu belirtiliyor
- Docker Compose’ta güncellemeler sırasında kesinti oluşabilir
- Prodüksiyon dağıtım rehberi vardır; basitlik ile prodüksiyona hazır olma arasında denge gerekir
- Docker Compose Anywhere, tek VM kurulumunu daha basit hale getirmeyi amaçlayan bir hafta sonu projesidir
- GitHub Actions ile Linux sunucuyu tek tıkla kurar
- GitHub Container Registry ve Docker Rollout kullanarak kesintisiz sürekli dağıtımı destekler
- Ortam değişkenleri ve secret yönetimi sağlar; güvenlik iyileştirmeleri için age veya sops değerlendiriliyor
- GitHub Actions tabanlı otomatik Postgres yedekleri sağlar
- Tek bir VM üzerinde birden fazla uygulamayı destekler
- Traefik ve Let’s Encrypt ile SSL’i otomatikleştirir
- Next.js, Go, Python, Node.js uygulamaları ve benzerlerini dağıtabilir
Basit olsa da vazgeçilemeyecek güvenlik ve operasyon ilkeleri
- Güvenlik ve veri koruma, basit kurulumlarda bile atlanamaz
- Yalnızca gerekli portları açan sıkı güvenlik duvarı kuralları gerekir
- SSH anahtarları güvenli biçimde yönetilmeli; AWS’de SSM, GCP’de CLI tercih edilmelidir
- Güvenliği artırmak için bastion host kullanılabilir
- Secret’lar korunmalı; WAF veya Cloudflare kullanımı değerlendirilmelidir
- Şifrelenmiş veritabanı yedekleri S3’e veya eşdeğer güvenli bir bulut depolamaya gönderilmelidir
- Ek yedeklilik için düzenli olarak disk snapshot’ları oluşturulmalıdır
- Yedekler ve snapshot’lar için saklama politikası uygulanmalıdır
- Mühendislerin önceliği, kurulumun basitliğini korumak ve ana ürüne odaklanmaktır
- Google mühendisliğini veya büyük şirket yöntemlerini taklit eden karmaşık kurulumlar ve yeni araçlar dikkati kolayca dağıtabilir
- Startup olsun veya olmasın, en önemli iş kullanıcılarla konuşmak ve product-market fit bulmaktır
1 yorum
Hacker News yorumları
Birçok projede moda teknolojiler yüzünden epey ter döktüm
Ekip küçük olmasına rağmen “sonsuz ölçeklenebilirlik” gerektiği gerekçesiyle inanılmaz derecede düşük kaliteli işler çıkarıyorlardı; LTS’nin ne olduğunu bile doğru dürüst anlamayan deneyimsiz bir ekibin Kubernetes’e ihtiyaç olduğuna karar verdiği de oldu
Şimdi herhangi bir sağlayıcıda istediğim boyutta sağlamlaştırılmış bir VM oluşturup üzerinde Docker servisleri veya Python backend’i ya da statik dosya sunumu çalıştırabilen sade Puppet kodum var
Hetzner VM’i 2 çekirdekli de olsa 48 çekirdekli de olsa 5 dakika içinde servisi kuruyor, kaynak kontrolündeki manifest ile yapılandırmayı denetliyor ve özel Naemon eklentileriyle yapılandırma uyumluluğunu izliyorum
Tamamen yeniden üretilebilir bir süreç; buna karşın startup ekipleri bulutta kar tanesi gibi tek seferlik yapılandırmalar oluşturuyor, ayda binlerce euro harcıyor ve yine de 2017’deki DevOps öncülerinin yaptığından daha kötü sonuçlar çıkarıyor
Bu konuda The Emperor's New clouds adlı bir yazı da yazdım: https://logical.li/blog/emperors-new-clouds/
“Docker veya başka teknolojiler olmadan yapılandırmayı nasıl yeniden üretirsiniz” sorusunu hiç anlamadım
Script’ler deterministikti, bağımlılık sürümleri sabitlenmişti, yapılandırma ile giriş argümanları ve çalıştırma sırası da aynıydı; deterministik bir hesaplama aygıtında çalışıyorlardı
Yeniden üretilememesi için bir neden yoktu
Sağlamlaştırılmış bir VM’de Docker olduğunu söylemek yerine kubelet olduğunu söylersiniz; geçici “docker services” yığınları yerine çok düşük maliyetli bir k8s kontrol düzlemiyle tüm bu VM’leri yönetebilirsiniz
Bu yöntemin neden daha iyi olduğunu bilmiyorum; aksine daha kötü görünüyor
Kötü bulut altyapısı, AWS’in sattığı her şeyi kullanmaya çalışıp sonunda tüm altyapının aşırı yüksek bir soyutlama katmanına bağlanarak başka bir platforma taşınamaz hale gelmesidir
k8s bununla hiç aynı şey değil
Bunlardan herhangi birine “kendimiz yaptık” ya da “bir script yeter” diye cevap veriyorsanız, k8s’nin değerli olmasının nedeni tam da budur
Python backend ise VPS üzerinde build script’ini aynen yeniden çalıştırmanız yeter:
pip install requirements.txt>python main.py>nano /etc/systemd/system/myservice.service>systemd start myservice> bittiInstance ölçeklemek için bu komutları
build_my_app.shadlı bir bash script’ine koyarsınız; bu da yeni Dockerfile gibi çalışır ve herhangi bir sunucuya onlarca saniye içinde kurulabilirIaaS olarak kullanıldığında, başka sağlayıcıların VPS’leri dâhil diğer yöntemlere göre çok daha hızlı prototip çıkarabiliyorum
Özellikle Google Cloud’da lock-in etkisi daha az ve en az şaşırtma ilkesine de daha iyi uyuyor
Ancak prototipi yaptıktan sonra daha ucuz bir yerde yeniden kurup kurmayacağınızı sormalısınız
Diski neredeyse sınırsız ölçekleyebilmek ve snapshot alabilmek güzel; bulut, prototipi prodüksiyon yüküne kadar ölçekleyip gerçekten gereken kapasiteyi ölçmenizi sağlayabilir
Ama Cloud Run, Lambda gibi “bulut sihri”ne yaslanınca öğrenme ve debug için harcanan zamanın sonunda eski yöntemle yapmak kadar sürdüğünü gördüm
Küçük bir startup’ta neredeyse tam olarak böyle yapıyoruz
GPU’ların da karıştığı iş kuyruğu otomatik ölçekleme gibi karmaşık kısımlar var, ama çekirdek tek bir VM’deki nginx, web uygulaması, Postgres, Redis
B2B olduğumuz için trafik de neredeyse yok
Geliştiriciler aynı yapılandırmayı Linux dizüstülerinde ya da başka platformlardaki Linux VM’lerinde aynen çalıştırabiliyor; demo veya test için isterlerse herkesin kendi bulut VM’i de olabiliyor
Yeni bir sistemi bootstrap etmek, SSH anahtarını repo’ya ekleyip bir shell script çalıştırmak kadar basit
Debug etmesi kolay, karmaşık ya da pahalı değil; yatay ölçeklemeye ihtiyaç duyulana kadar da epey dikey ölçekleme yapılabiliyor
Herkese uygun değil ama seed öncesi aşama için tamamen makul olduğunu düşünüyorum
Bu, “public key’i repo’ya ekleme” yaklaşımına bir dolaylılık katmanı ekliyor ve kullanıcının Git değişikliği yapmadan kendi anahtarını değiştirebilmesini sağlıyor
Ayrıca asıl anlatılandan epey sapıyor ama SSH anahtarı kiralama, offboarding durumlarını çok daha iyi ele aldığı için gerçekten güzel: https://github.com/hashicorp/vault/blob/v1.12.11/website/con...
Link ararken Vault’un tek kullanımlık parola da sunduğunu iddia eden bir doküman da buldum <https://github.com/hashicorp/vault/blob/v1.12.11/website/con...>
Yine de ben katı bir “PasswordLogin no” taraftarıyım; o tarafı herkes kendi dikkatine göre kullansın
Postgres her şeyi yapabilir
Böyle bir kurulumda VM’in ayarlarını ve güncellemelerini nasıl takip ediyorsunuz?
Cevap “hayır, gerek yok”
Benim SaaS’ım başta tek bir sunucuda çalışıyordu; ürün-pazar uyumunu yakaladıktan sonra birden fazla sunucuya taşıdım
Bunlar Hetzner’ın bare-metal sunucuları; mikroservis yok, Kubernetes ile uğraşmıyorum ama dağıtık veritabanı işletiyorum
Bu bare-metal sunucular, bulut sağlayıcıların sanal makinelerine kıyasla inanılmaz derecede güçlü
Birkaç yıl önce kendim de ölçmüştüm: https://jan.rychter.com/enblog/cloud-server-cpu-performance-...
Genel olarak bu yaklaşım saçma denecek kadar etkili
Kubernetes gibi karmaşıklıklarla uğraşmak zorunda kalmıyor, karmaşık sistemlerde kaçınılmaz olarak ortaya çıkan zincirleme arızalardan kaçınıyor; geliştirme süresinden, bakımdan ve aylık sunucu maliyetinden tasarruf ediyorsunuz
Yaygın itiraz “peki nasıl ölçekleyeceksin?” oluyor; ama henüz ölçeklemeye ihtiyaç olup olmayacağını bilmiyorsunuz ve böylesine güçlü bilgisayarlar ile makul bir tasarımla 3–5 sunucuyla bile çok yol alınabilir
Elbette işi evdeki dolapta çalıştıralım demiyorum
Sunucu yönetimi için otomasyon hâlâ gerekli; ben ansible ve terraform kullanıyorum
Yazılımın çok kısa sürede müthiş başarılı olacağına dair iyimserliği tetikliyor ve insanlar buna inanmak istiyor
Yazıyı mı okudunuz, yoksa sadece başlığa mı baktınız bilmiyorum
Aşağıdaki A few considerations bölümüne kadar inerseniz gülmek zorlaşır
O “birkaç değerlendirme”, özellikle çok hassas bilgiler saklıyor ya da aktarıyorsanız, ciddi bir güvenlik işi yığını demek
Böyle bir durumda HIPAA gibi uyumluluk gereksinimlerini nasıl ele alıyorsunuz?
Programcıların iki türü vardır
Her şeyi gördüğünü sananlar ve neredeyse hiçbir şey görmediğini bilenler
Bu yüzden böyle mutlak kesinlikler yorucu
Kubernetes’in temel %20’si Deployment, Pod, Service, blue-green dağıtımın ele alınış biçimi, bildirimsel tanımlar ve namespace ayrımı gibi kısımlar; bunlar gerçekten iyi.
Bu basit temellere sadık kalıp yönetilen bir bulut Kubernetes servisi kullanır ve durum tutan veritabanlarını kümenin dışında bırakırsanız iyi bir deneyim elde edersiniz.
Sorun, “cloud native” tavşan deliğine çekilip her türlü niş açık kaynak sistemi, operator’ı, ambassador’ı, sidecar pattern’ı vb. kullanmaya başladığınızda çıkıyor.
Bunlar, birbirinden bağımsız ama birbirine bağlanan birden çok teknik ekibin ve çeşitli programlama dillerinin bir arada bulunduğu ortamlar için.
Bu tür tartışmalarda insanların çoğu zaman iki farklı şeyden söz ettiğini hissediyorum.
Benim için Docker Compose’dan daha iyi, tek tip bir dağıtım yönteminden ibaret.
Control plane için çok az maliyet ödüyorsunuz; worker’lar ise üzerinde kubelet olan sıradan VM’ler.
Ama birçok kişi için “Kubernetes” yukarıdaki ikinci paragrafı ifade ediyor gibi.
Kesinlikle böyle kullanmak zorunda değilsiniz.
Bir k3s kümesi kurup yalnızca workload, service, ingress öğrenmeniz de yeterli.
Geçici VM ve Docker yapılandırmalarının yerini almak için gereken şey bu kadar.
%99’unun yalnızca docker-compose++ seviyesinde bir şeye ihtiyacı var ya da istediği bu.
Sıfır kesintili dağıtım varsayılan olarak gelse, replica set’ler veya diğer replikasyon/dağıtım mekanizmaları için basit bir yapılandırma sistemi olsa neredeyse yeter.
Sadece bunu yapan bir şey olsa keşke.
Kubernetes’in yükü fazla; Docker Compose ise önemli production gereksinimleri için biraz fazla temel kalıyor.
Kubernetes’te her kullanım için ayarlanabilecek milyonlarca düğme ve kadran var; ama aynı şekilde bunları görmezden gelip yalnızca çekirdek özellikleri kullanarak basit tutmak da mümkün.
Makul dağıtım, çok kolay log ve metrikler, iyi bir geliştirici deneyimi sunan bir kurulumu kısa sürede oluşturabilirsiniz.
İtibarı çok kötü olduğu ve daha önce hiç kullanmadığım için, dahili araçlar için bir sunucu kurup kuramayacağımı sorduğumda en kötüsüne hazırdım.
Gerçekte ise kurulumu yapan kişi bana 30 dakikalık bir eğitim verdi, tüm kavramları açıkladı ve sunucuyu dağıtmama yetecek bilgiyi sağladı; ben de hiçbir sorun yaşamadan dağıttım.
git pushile otomatik dağıtım olacak şekilde ayarlamak da çok hızlı bitti.Bana fazlasıyla bariz bir tercih gibi göründü.
Hizmetiniz kelimenin tam anlamıyla tek bir şey değilse kullanımı çok daha kolay.
Yine de kurulumu bizzat ben yapmadım; kötü itibar belki de o kısımdan geliyordur.
Özgeçmişinde k8s yoksa kim yeni iş bulacak ki :)
Ciddi konuşursak, birçok kişinin büyük ölçekli altyapıyı öğrenmek için özellikle zor yolu seçtiğini düşünüyorum.
Bir diğer yaygın gerekçe de “müşteri sayısı çok artarsa çok daha kolay olur” ya da “talebe göre dinamik ölçeklenebilir” denmesi.
Bunu yapan kişi için hepsi makul; ama kurucu ya da profesyonel CTO için aynı derecede makul değil.
Bazı insanlar potansiyel müşterilerin ihtiyaçlarını ve takvimini umursamadan, havalı görünen boş şeyler yaparak para yakıyor.
Lastik değiştirmek için servise gidiyorsunuz; tamirci kendi gelişim isteği yüzünden lowrider hidrolikleri ve dönen jant kapakları takmak istediği için işin 3 hafta sürmesine benziyor.
En kötüsü de bunun bir sonraki kişi için özünde belirsiz hale gelmesi.
Orada bir şeyin gerçekten gerektiği için mi, yoksa sadece parlak bir süs olduğu için mi bulunduğunu bilemezsiniz.
İnsanların bunu ilgi duydukları için mi, teknolojiyi sevdikleri için mi, yoksa söylediğiniz gibi özgeçmişlerine k8s eklemek için teknokratik biçimde yetkinliklerini artırmaya çalıştıkları için mi yaptığından emin değilim.
Ben sadece “yönetmesi acı verici görünüyor” diye düşünüyorum.
Bu yüzden k8s altyapısının daha dar bir gerçek uzman kitlesi, en azından mentorluk yapacak deneyimli kişiler tarafından tasarlanıp yürütülmesinin daha iyi olduğunu düşünüyorum.
Gerekli olmadığı durumlarda ise, yani çoğu startup, küçük işletme ve orta ölçekli şirket için, kullanımı daha kolay mevcut paradigmaları sürdürmek yeterli.
Seçimlerinden çok memnunlar ve bloglarında bunu ayrıntılı biçimde yazdılar.
“Müşteri sayısı çok artarsa çok daha kolay olur” ifadesinin gerçekten yerini bulduğu bir örnek.
Eski ve sık sık yorucu hale gelen bir tartışma ama yine de ben de iki kuruşluk fikrimi ekleyeyim.
İlk günden karmaşık bir framework seçmek gerekir mi derseniz, ekipte bu deneyim yeterince yoksa muhtemelen hayır.
Ancak benim karşı çıktığım şey, altyapıyı özel süreçler ve özel araçlarla yönetmenin her zaman kendini kanıtlamış araçlardan daha az bakım çabası gerektireceği fikri.
Kendi yaptığınız süreç hiç de basit olmadığı ve çekirdek üründen epey zaman çaldığı halde “karmaşıklık” korkuluğunu inatla reddetme tutumu.
Herkes bir binary’yi VPS’e kopyalayıp servisi yeniden başlatmanın basitliğini sever.
Ama çok geçmeden yapılandırma ve gizli bilgi yönetimi gerekir; erişilebilirlik ve yedeklilik için sunucu sayısı arttığında kademeli dağıtım, yük dengeleme, rollback vb. gerekir.
Staging ortamı da isteyeceksiniz ve bu iş akışını kolayca kopyalayabilmeniz gerekecek.
Ekip büyüdüğünde, prodüksiyona benzer bir ortamı yerelde çalıştıramadığınız da ortaya çıkar.
Böyle böyle gereksinimler eklenmeye devam eder.
Sonunda her yeni gereksinimi, başkalarının zaten çözmüş olduğu standart çözümlere yaslanmak yerine kendinize özgü özel bir yöntemle çözmeniz gerekir.
Sonrasında bu bir batık maliyet meselesine dönüşür.
Bildiğiniz ve anladığınız özel araçları bırakıp bilmediğiniz “karmaşıklığa” mı geçeceksiniz?
Ne kadar yatırım yaparsanız, sonradan geçmek o kadar zorlaşır.
Benim önerim, daha sonra standart araçlara geçişi kolaylaştıracak pratikleri en baştan benimsemek.
Yani 1. günden itibaren container ile dağıtım yapmak, 12 faktör metodolojisini benimsemek gibi.
Ve ihtiyaç duyulan özellikler yüzünden zorlanmaya başladığınızda, geç kalmaktansa erken davranıp kendini kanıtlamış araçlara geçmek daha iyidir.
Bilinmeyene dair korkunun temelsiz olduğunu görme olasılığınız yüksek; uzun vadede altyapıya harcadığınız zaman da azalacaktır.
Benim düşündüğüm yaklaşım, ilk günden standart araçlarla, yani k8s + gitops ile başlamak ama yine de tek bir VM üzerinde çalıştırmak.
Ne düşünüyorsunuz?
Buna karşılık bu “karmaşık” bulut sistemlerini anlayan ve terraform ile dağıtıp bakımını yapabilen “bulut mühendisleri”ni bolca bulabilirsiniz.
Hemen devreye alınabilecek bir beceri seti.
VM, blok/blob depolama, DNS, IdP, alan adı kayıt şirketi.
Bulutta rahatça kullandığım şeyler aşağı yukarı bunlardan ibaret.
FaaS ve onun benzerlerine girince benim için gerçekten tuhaflaşıyor.
Prodüksiyon ortamının çalıştığı makineye bakamamakla baş etmek zor.
Bulut panosundan debug etme deneyimi berbat.
Microsoft’un yaklaşımını gerçekten “çalışan” şeye en yakın olanı gibi görüyorum ama yine de gerçekten korkunç ve bir daha dokunmak istemem.
10 yıl geçtikten sonra bile ideal mimarim hâlâ tek bir VM üzerinde, yerel SQLite instance’larıyla konuşan monolitik bir codebase.
NVMe depolamanın ortaya çıkışı bu yaklaşıma epey güç verdi.
Yedeklemeleri blok depolama aygıtı snapshot’larıyla, işlem dayanıklılığını ise gerekirse WAL replikasyonuyla hallederim.
Aptalca denecek kadar basit.
İşe ve müşterilere odaklanmanızı sağlar.
Müşterilerin bunların hiçbiri umurunda değil ve bunun için para da ödemezler.
Tüm kod ve altyapı saf birer eksi unsur; bu yüzden mümkün olduğunca azına sahip olmak gerekir.
İnsanların bulutun on-premise’dan pahalı olduğunu söylemesinin nedeni çoğu zaman budur.
VM’i 7/24 çalıştıracaksanız daha iyi seçenekler var.
Mikroservis kitapları bile önce monoliti oluşturun der.
Gerçek kullanıcı tepkisini almadan sistemi nasıl bölmeniz gerektiğini bilemezsiniz; ayrıca servisleri yeniden yapılandırmaktansa monoliti parçalamak daha kolaydır.
Monoliti sonsuza kadar hiç parçalamanız gerekmeyebilir.
Stripe da sonunda Rails monolitinden bazı parçaları ayırdı ama monolit şaşırtıcı derecede uzun yol aldı.
Django/Rails gibi bir monolitten daha kolay debug edilen bir şey yapmak zordur.
Yine de altyapının nereye gideceğini biraz öngörmek faydalı olur.
Şirketimizin ilk sürümü tek bir VM üzerinde Django Docker container’ı olarak yapılmıştı; dağıtım da elle
docker pull; docker stop; docker startidi.Bu kurulum beklediğimizden çok daha uzun süre dayandı.
Docker, bağımlılık paketleme sorunlarından kaçınmak için iyi bir yol.
İlk aşamalarda yeni bir DB driver’ı kurduğunuzda sunucuda gerekli C header dosyaları var mı, Mac ile ayarlar farklı mı gibi sorunlar can sıkıcı olabilir.
Seed uzatma turundan sonra güvenilirlik ve ölçeklenebilirlik gibi iş gereksinimleri nedeniyle k8s’e geçtik; k8s de Series B’ye kadar iyi dayandı.
Her şeyi Docker’laştırmış olmamız geçişi de kolaylaştırdı ama erken aşamada karmaşıklığı agresif biçimde azalttık.
Ayrıca framework’ün sunduğu özelliklerin kötü bir versiyonunu yeniden yapmak yerine framework’ü doğru düzgün kullanmak gerekir.
Bu açıdan tek bir deneyimli kişi, 10 deneyimsiz kişiden daha iyi sonuç verir.
Zaman geçtikçe fark birikir.
İnsanların monolitlerden bıkmasının gerçek nedenlerinin yarısının kötü ve düzgün işletilmeyen monolitler olduğunu düşünüyorum.
Verinin kendi servisinde saklanması gerektiğini söyler; ilişkisel ve tam metin arama gibi çok paradigmalı bir yaklaşım gerekiyorsa bu birden fazla servis anlamına da gelebilir.
Kullanıcı deneyiminin de kendi servisini kullanması gerekir.
En azından arada başka bir servis daha olmalı; genelde Django ve Rails de buraya girer.
İsteğe bağlı olarak kimlik doğrulama, finansal işlemler gibi ek servisler de gerekebilir der.
Bir projeyi yaklaşık 6 yıl boyunca tek bir 10 dolarlık VPS üzerinde çalıştırdım.
lowendtalk’tan aldığım kalıcı indirim sayesinde aslında daha az ödüyordum; sağlayıcı da oyun sunucusu ağırlıklı bir VPS sağlayıcısıydı.
Ben ayarları bozup temiz OS yeniden kurulumu yapmak zorunda kaldığım için tüm gün kapalı kaldığı bir sefer ve sağlayıcının önceden haber verip IP adresini değiştirdiği bir sefer dışında neredeyse 99.999 seviyesinde kararlılık vardı.
VPS teknolojisi gerçekten çok gelişti ve çok kararlı.
Node diskleri RAID 1 olarak yapılandırılmış durumda; node bakımı sırasında VM’in kendisi de kolayca başka bir makineye live migrate edilebiliyor.
Snapshot da alınabiliyor.
Benim için bulut altyapısını seçme nedeni daha yüksek kararlılık değil; IAM, gizli bilgi yönetimi, infrastructure as code gibi iş birliği ve operasyon yönetimi özellikleri ya da HIPAA gibi veri merkezi uyumluluğu gerekçeleri olurdu.
Duruma göre değişir
Kişisel olarak bulut tabanlı çözümleri seviyorum; bana çok zaman kazandırıyorlar
Ancak neyi kullanacağınızı çok seçici belirlemek gerekiyor; fazla karmaşık olup açıkça ters etki yaratan çözümler de var
Küçük, kendi imkânlarıyla ayakta duran bir startup işletiyorum
Kendimize maaş ödeyecek kadar paramız bile yok; geçimimi yan danışmanlık işleriyle sağlıyorum
Bütçe ve zaman bu kadar sınırlı olunca ne kullanacağımız konusunda çok dikkatli olmamız gerekiyor
Bu yüzden Google Cloud gibi şeyleri seviyorum
GCP faturamız oldukça düşük; ayda birkaç yüz avro
Daha ucuz bir sağlayıcıya geçebiliriz, ama bunun gerektireceği zaman yatırımını haklı çıkarmak zor; ayrıca daha önce kullandığım AWS ile karşılaştırınca Google’ın arayüzünü ve araçlarını da beğeniyorum
Kubernetes’e ihtiyacımız yok
Boş bir cluster çalıştırmanın maliyeti bile muhtemelen mevcut aylık GCP faturamızdan daha pahalı olurdu
Mikroservis tuzağına düşmediğimiz için buna ihtiyacımız da yok
Ama Docker’ı seviyorum
Yazılım dağıtımını aptalca kolay hale getiriyor
Web sitemiz, bir yük dengeleyici ve Google CDN üzerinden sunulan bir Google Storage bucket’ı
Aynı yük dengeleyici REST çağrılarını monoliti çalıştıran iki VM’e yönlendiriyor
Bu VM’ler yönetilen DB, yönetilen Elasticsearch ve yönetilen Redis ile konuşuyor
DB ve Elasticsearch pahalı, ama yönetilen olarak kullanmak ciddi ölçüde zaman ve emek tasarrufu sağlıyor
Sahip olduğumuz şeylerin neredeyse tamamı bu; basit ve o kadar da pahalı değil
Her şeyi Hetzner gibi bir yere taşırsak maliyeti yaklaşık %50 azaltabiliriz
Denemeye değer olabilir, ama benim için çok acil bir iş değil
O yönetilen servisleri kaybedersem hayatım daha zorlaşır
Bazı müşterilerin AWS’i tercih ediyor gibi görünmesi nedeniyle bir gün AWS’e geri dönmemiz gerekebilir; işin bir de bu yönü var