Bir bulut inşa ediyorum
(crawshaw.io)- Mevcut bulut soyutlamaları, CPU·bellek·disk kaynaklarını istenen şekilde birleştirip kullanmayı zorlaştırıyor; hem VM hem de PaaS, sıradan bir bilgisayardan daha fazla kısıt yaratıyor
- Uzak blok depolama ve yüksek egress maliyetleri, HDD döneminin varsayımlarına bağlı bir yapıyı sürdürürken SSD ve modern ağ ortamlarında performans ve maliyet sorunlarını daha da büyütüyor
- Kubernetes, kullanımı zor bulut API’lerinin üstünü örtüyor ama hatalı temel soyutlamayı değiştiremediği için VM·disk·ağ sınırlamalarını aynen taşımaya devam ediyor
- Agent'lar ile yazılım ve çalıştırma talebi arttıkça, özel yürütme alanı, kolay paylaşım ve düşük operasyonel ek yük daha önemli hale geliyor; mevcut bulutun yapısal darboğazları da aynı ölçüde büyüyor
- exe.dev, önce CPU ve belleği ayırıp ardından bunun üzerinde VM’leri doğrudan çalıştırmayı; TLS proxy·kimlik doğrulama proxy’si·yerel NVMe·asenkron replikasyon·anycast tabanlı yerleştirmeyi birleştirerek gerçekten kullanmak istenen bir buluta yaklaşmayı hedefliyor
Neden yeniden yeni bir bulut inşa ediliyor?
- Mevcut bulut soyutlamalarının bilgisayarları istenen şekilde kullanmayı zorlaştırması, yeni bir şirket kurmanın doğrudan nedeni olmuş
- Bilgisayarların kendisi iyi olsa da bugünün bulutlarında neredeyse her üründe aynı kısıtlar tekrar ediyor; sorunun özü de basit bir UX ya da API tasarım hatasından çok temel yapı taşlarının biçimiyle ilgili görünüyor
- VM’ler CPU ve belleğe bağlı ayrı örnekler olarak sunuluyor; oysa istenen yapı, önce CPU·bellek·disk kaynaklarını ayırıp ardından bunun üstüne ihtiyaç kadar VM çıkarmaya daha yakın
- Linux VM’leri, başka bir Linux’un cgroup’u içinde çalışan süreçler olsa da mevcut bulutlarda bunu kolayca ele almak zor
- Bunu aşmak için gVisor ya da iç içe sanallaştırmayı tek bir bulut VM’i üzerinde çalıştırmak gerekiyor; bu da performans kaybı yaratırken en azından reverse proxy işletme yükünü de kullanıcıya bırakıyor
- PaaS da bu sorunu çözmüyor; hatta sıradan bir bilgisayardan daha az güçlü sağlayıcıya bağımlı soyutlamaları dayatıyor
- Her bilgi işlem sağlayıcısı için yeni bir geliştirme biçimi öğrenmek gerekiyor
- Proje belli bir noktaya geldikten sonra, normal bir bilgisayarda kolay olan işlerin platformun derin kısıtları yüzünden neredeyse imkânsız olduğu ortaya çıkabiliyor
- Defalarca “bu kez olacak” denmesine rağmen yarım kalmış soyutlamalara takılmak tekrar ediyor
Disk ve ağda ortaya çıkan yapısal sınırlar
- Disk tarafında bulut sağlayıcıları uzak blok depolamayı ya da ondan da daha kısıtlı ve yavaş S3 benzeri yöntemleri tercih ediyor; bu HDD döneminde bir ölçüde mantıklıydı
- Uzak depolama, sıralı okuma ve yazmada büyük kayıp yaratmıyordu; HDD’lerde rastgele seek yaklaşık 10ms düzeyindeydi, bu yüzden Ethernet bağlantısının 1ms RTT’si katlanılabilir bir maliyetti
- Sağlayıcı açısından standart örnek türlerinden bir ekseni çıkarmak operasyonu kolaylaştırıyordu
- Ancak SSD’ye geçişle bu varsayım bozuldu
- Seek süresi 10ms’den 20 mikrosaniyeye indi
- Uzak blok sistemlerinin ağ RTT’si iyileşse de IOPS ek yükü HDD dönemindeki %10 seviyesinden SSD çağında 10 katın üzerine çıktı
- EC2’de 200k IOPS’lik bir yapı kurmak için kurulum da karmaşık ve aylık 10 bin dolar gerekiyor; buna karşılık bir MacBook 500k IOPS sunuyor
- Ağ teknolojisinin kendisi yeterince iyi ama egress maliyetleri ve iş modeli kullanılabilirliği engelleyecek yönde çalışıyor
- Hyperscaler ağları çok güçlü ama çok pahalı ve diğer sağlayıcılarla birlikte çalışmayı da zorlaştırıyor
- Bulut sağlayıcılarının egress birim fiyatı, sıradan bir veri merkezine sunucu yerleştirmeye kıyasla GB başına 10 kat düzeyinde veriliyor
- Kullanım biraz arttığında bu çarpan daha da kötüleşiyor
- Aylık on milyonlarca dolar harcayan müşteriler daha iyi fiyat alabiliyor ama aylık onlarca ya da yüzlerce dolarlık projelere bu model uymuyor
- Bu aralıkta ne yapılırsa yapılsın ucuza işletmek zorlaştırılıyor
Kubernetes ve API’ler sorunu örtüyor ama çözmüyor
- Bulut API’leriyle çalışmak acı verici; Kubernetes de bunun üstünü örterek mühendislerin yaşadığı sıkıntıyı azaltma amacıyla ortaya çıktı
- Ancak VM’ler, bulutun iç içe sanallaştırmayı doğrudan kullanıcıya yıktığı bir yapı olduğu için Kubernetes üzerinde de hâlâ zor yönetiliyor
- Disk tarafında da Kubernetes tasarlanırken Google tarafında işe yarar bir uzak blok aygıtı fiilen yoktu; bugün ortak desenler yakalansa bile sonuçta yine yavaş depolamaya bağımlı kalmak kolay
- Ağ tarafında da bunu kolay açmak, yakındaki açık veri merkezlerindeki bazı sistemleri private link ile bağlayıp bulut maliyetindeki bir sıfırı silebilmeyi mümkün kılacağı için bunu kolaylaştırmak yönünde teşvik az
- Kubernetes’i sahte bir meşguliyet olarak görmektense, taşınabilir ve kullanılabilir bir bulut yaratmaya çalışan imkânsız bir soruna verilmiş bir yanıt olarak değerlendirmek gerekiyor
- Temelden yanlış bulut soyutlamalarının üstüne yeni soyutlamalar koyarak bu sorun çözülemiyor; Kubernetes’i daha iyi hale getirme çabalarının da sonunda belirgin sınırları var
- Bu rahatsız edici bulutlarla geçen süre 15 yıla ulaşmış; bu sürede, tatsız bir yazılım yığınının diğer parçalarında olduğu gibi buna katlanıp mümkün olduğunca az temas ederek idare edilmiş
Şimdi neden düzeltme zamanı?
- Şimdi dönüm noktası olmasının nedeni agent'ların ortaya çıkması
- Jevons paradox örneğinde olduğu gibi, kod yazmak kolaylaştıkça toplam yazılım miktarı da artıyor; hem işte hem hobilerde herkes daha fazla program kullanıyor
- Bu şekilde artan programları çalıştırmak için özel yürütme alanı, kolay paylaşım ve düşük operasyonel ek yük gerekiyor
- Toplam yazılım miktarı arttıkça, geçmişte sadece can sıkıcı görünen bulut sorunları çok daha büyük darboğazlara dönüşüyor
- Daha fazla bilgi işlem gücü gerekiyor ve yönetimin de daha kolay olması lazım
- Agent'lar AWS API’lerini insanların yerine kullanmakta yardımcı olabilir ama bunun için kimlik bilgilerini vermek gerekir ve bazen üretim veritabanını silebilirler
- Daha da önemlisi, agent'lar da mevcut bulut soyutlamalarının temel sınırlarında insanlarla aynı duvara çarpıyor
- Gereğinden fazla token harcanıyor ve sonuçlar da beklenenden kötü oluyor
- Agent'ın context window’u klasik buluta zorla uyum sağlamak için ne kadar çok kullanılırsa, gerçek problemi çözmeye o kadar az alan kalıyor
exe.dev’in önce düzeltmeye başladığı yerler
- exe.dev’in önce çıkardığı şey, VM kaynak yalıtımı sorunu için bir çözüm olmuş
- Tek tek VM sağlamak yerine önce CPU ve belleği verip, bunun üzerinde istenen VM’leri doğrudan çalıştıran bir yapı sunuluyor
- Yeni VM’leri doğrudan internete açmak istenmediği varsayımıyla, TLS proxy ve kimlik doğrulama proxy’si birlikte ele alınıyor
- Disk tarafında yerel NVMe kullanılıyor ve bloklar makine dışına asenkron olarak çoğaltılıyor
- Dünyanın farklı bölgelerine makine koyulabilmesi sağlanarak iş yüklerinin yakın konumlarda çalışması hedefleniyor
- Makineler anycast ağının arkasına yerleştiriliyor; böylece dünya çapındaki kullanıcılara düşük gecikmeli giriş noktaları sunuluyor
- Bu temel üzerinde yakında yeni özellikler de inşa edilebilecek şekilde tasarlanmış
- Hâlâ yapılacak çok şey var
- Statik IP gibi nispeten açık başlıklar hâlâ duruyor
- Otomatik oluşturulan geçmiş disk snapshot’larına erişimin UX’i gibi konular da çözülmeyi bekliyor
- Aynı zamanda yeniden veri merkezlerine doğrudan bilgisayar raflama aşamasına dönülerek, ağ bağlantı biçimi de dâhil olmak üzere yazılım yığınının tüm katmanları tekrar gözden geçiriliyor
- Nihai hedef, gerçekten kullanmak istenecek bir bulut yapmak
6 yorum
Şimdi dönüp bakınca "neden şimdi?" diye düşündüm ama...
Yazarın Tailscale'in ortak kurucusu olduğunu görünce nedense desteklemek istedim.
Lütfen güzel yapın!
Fiyat tablosu çok kafa karıştırıcı; 2 çekirdek 8 GB, 50 VM gibi yazıyor. Bunu, tek bir VM verip üzerinde 50 container çalıştırılabilir şeklinde anlamak gerekiyor gibi görünüyor.
Bulutun karmaşık olmasının bir nedeni var.
Hesap silme özelliği görünmüyor, bulan var mı?
Sadece sürükle ve bırak ile servisleri birbirine bağlayabilmek güzel olurdu
Hacker News yorumları
Kubernetes ilk başta birkaç web uygulaması container’ı çalıştırmak için uygun gibi görünse de, kısa süre içinde üzerine SDN eklenip her tür servis bağlandıkça kontrolden çıkacak kadar şişme eğiliminde oluyor
Cluster’ı ne kadar "optimize" edip "harden" etmeye çalıştıysak, cloud maliyeti, arızalar, downtime ve debugging emeği de o kadar 2-3 kat arttı
Sonunda bu DevOps ataleti bırakıp cluster’ı tamamen kaldırdık; tek bir Debian VM üzerinde firewall’u açıp Kamal ile Docker deploy edince altyapı istikrarı ve güvenilirliği en iyi seviyeye geldi, maliyet de ciddi biçimde düştü
Çoğu iş uygulaması yüzlerce ila binlerce kullanıcı ölçeğinde olduğundan tek bir büyük VM çoğu zaman yeterli oluyor; Google gibi cloud sağlayıcılar da donanım arızalarını zaten ele aldığı için, gerçekten gerektiğinde sadece ikinci bir VM açıp Cloudflare’de IP’yi değiştirmek yetiyor
Çok küçük ölçeklerde bile k8s dayatıldığını sık görüyorum; o durumda da zaten en başta k8s gerektirecek bir ölçekte değilsinizdir
Bu yüzden yaygın deployment kalıplarını basitleştiren daha üst bir katmana ihtiyaç var; Knative buna iyi bir örnek
Alttaki primitive’lerin hepsini açığa çıkarmaya çalışan her çözüm eninde sonunda Kubernetes kadar karmaşık hale geliyor
Benim yaptığım https://github.com/openrundev/openrun, ekipler için iç web uygulaması deployment’ını deklaratif şekilde ele alıyor; ayrıca SAML/OAuth ve RBAC ekliyor, hem tek makinelik Docker’ı hem de Kubernetes’i destekliyor
Aşırı karmaşık, debug etmesi zor ve pahalı düşünme biçimi VM üzerinde de aynen yeniden üretilebilir
Şu anda tek Debian VM’in onların politika radarının dışında kaldığı için özgür olması da mümkün
Biri işe karışmaya başladığında HA, rollout/rollback, 3-5 VM, sanal ağ politikaları, 4 güvenlik tarayıcısı, 2 log processor, watchdog, ağ monitörü, mTLS ve trafik görünürlüğü ekipmanı gibi şeyleri peş peşe eklemeye kalkmaları çok olası
Bir makine daha olunca upgrade ya da değişiklik sırasında sorun çıkarsa daha az stres oluyor
Üzerinde çalıştığım https://github.com/psviderski/uncloud, Kamal’dan ilham alarak çok makineli yapıyı tek VM kadar basit hale getirmeyi amaçlıyor; zero-config WireGuard overlay ve standart Docker Compose ile birden çok VM’e deployment yapıyor
Orchestrator ya da control plane karmaşıklığı olmadan 1 makineyle başlayıp, ihtiyaç olunca cloud VM’lerle on-prem’i karıştırarak ölçeklenebiliyor
Production’da kullandığımda her anı güzeldi; adeta hesaplamanın kendisini yeniden tanımlamış gibi geldi
O yüzden bu kadar nefret eden tarafın bakış açısından neyi kaçırdığımı merak ediyorum
OP, Tailscale kurucu ortaklarından biri olduğu için bağlam daha da ilginç
Geleneksel Cloud 1.0 şirketlerinin VM varsayılanlarında yaklaşık 3000 IOPS verirken dizüstü bilgisayarların 500 bin IOPS görebildiğini söylemesi oldukça yerinde
Vizyon gerçekten çok iyi ve ben de tam hedef müşteri gibi hissediyorum; ama başarı büyüdükçe ideallerin yerini kârlılık baskısının alacağı o tanıdık yola girer mi diye endişeleniyorum
Cloud fiyatlandırması çoğu zaman maliyet temelli değil; özellikle müşteriler iyice bağımlı hale geldikten sonra patlayan bandwidth ya da NAT gateway gibi kalemlerde güçlü kâr bırakacak şekilde tasarlanıyor
OP’nin de bu yapıyı bilmiyor olması mümkün değil diye düşünüyorum
Ama bu storage doğası gereği ephemeral ve yeterli yedekliliğe sahip değil
RAID1 ile donanım arızası riski azaltılabiliyor ama bu kez takılabilecek NVMe sayısı azalıyor; ayrıca host’un RAM/CPU gibi başka sorunları yüzünden VM’i taşımak gerektiğinde de temiz bir çözüm yok
Sonuçta böyle VM’lere neredeyse bare metal gibi davranmak gerekiyor ve uygulama katmanında yedeklilik, örneğin veritabanı replikasyonu, şart hale geliyor
Azure tarafında, istedikleri anda VM’i taşıyıp ephemeral veriyi silebileceklerini varsaymanız gerekir; ama OpenStack’te gerekirse VM kapatılıp yerel block-level migration ile NVMe verisi de başka host’a kopyalanabiliyordu
Yine de host crash ederse o VM, host geri gelene kadar kapalı kalıyordu; yani uygulama seviyesinde yedeklilik baştan varsayılmış olmalıydı
Ama 99.9 persentil gecikme Hetzner’de yaklaşık 5ms, DO’da ise yaklaşık 18ms’di; maksimum gecikme de Hetzner’de 7ms, DO’da 85ms civarındaydı, yani fark belirgin
Sıralı dd testinde Hetzner 1.9GB/s, DO ise 850MB/s verdi
Fiyat farkı da büyük: Hetzner 4 euroyken DO instance’ı 18 dolar
Yazının tamamını okumadan önce bunu yazmıştım; meğer OP de tam olarak bu ikisini işaret ediyormuş
Yani basit bir sunucuda bile makine içi DB kullanmayı zorlaştırıp lock-in yaratıyor olabilirler
Bir şeyi üretmenin maliyeti X diye fiyatı 1.y*X şeklinde belirlemek, gerçek piyasa fiyatlamasından oldukça uzak
Bottom-up yerine top-down yaklaşım daha gerçekçi
AI etrafındaki tartışmalar nasıl uçlara savruluyorsa, Kubernetes konusunda da aynı kutuplaşma var gibi görünüyor
Yıllar boyunca farklı büyüklüklerde cluster’lar yönettim ama kesintinin sebebi doğrudan k8s oldu diyebileceğim tek bir olay yaşamadım
Bir keresinde bir saat süren, tam elektrik kesintisi ölçeğinde bir outage olmuştu; k8s’ten hoşlanmayan taraf hemen her şeyi o "lanet k8s sistemi"ne yıkmaya çalıştı
Oysa asıl sebep, belirli bir durumda servislerin bir anda on binlerce port açıp kendi kendine DOS üretmesiydi
K8s’in geleceğin tamamı olduğunu da düşünmüyorum, çöp olduğunu da; gerçekten ihtiyaç olduğunda iyi bir sistem olduğunu düşünüyorum
İlki, öğrenmesi gereksiz yere karmaşık ama benim problemim için gerekli değil, mevcut deployment yöntemim zaten yeterli diyenler; ikincisi ise bare metal’e göre maliyet/enerji verimliliğinin daha düşük olması
Çoğu zaman ikisi bir arada geliyor
Ölçülü şekilde nötr ya da ilgisiz kalmak artık daha nadir görünüyor; insanın aklına hemen ABD siyaseti geliyor
Ben de k8s’i çok iyi bilmiyorum; bir staff engineer pod ve cluster diye anlatmaya başlayınca gözlerim boş bakıyor ama ekibimize uyuyor ve gerçekten çalışıyor
Elinde yalnızca çekiç olan herkese her şey çivi gibi görünür; baltası olan biri ise insanların neden odunu çekiçle parçalamaya çalıştığına şaşırır
Hatta iş aslında balta işi olduğu halde, çekiçli biri yüzünden işini kaybediyorsan çekice nefret duyman da kolaylaşır
K8s tarafında birçok kullanım senaryosu için best practice’ler az çok oturmuş durumda; ama LLM tarafında neyin best practice olduğu bile henüz çok net değil
VM’lerin CPU/bellek paketlerine bağlı olması nedeniyle işe değil zamana para ödediğimiz tespiti bana da çok doğru geliyor
Bu yüzden ucuz bir Hetzner auction server alıp, kendi yaptığım self-hostable Firecracker orchestrator üzerinde kullanıyorum
https://github.com/sahil-shubham/bhatti, https://bhatti.sh
İstediğim şey, donanımı satın alıp VM’leri istediğim gibi bölmek ve provisioning ya da lifecycle ile uğraşmamaktı
Boştaki VM’ler bellek durumunu diske snapshot alıp tüm RAM’i geri verdiği için, donanım bana ait, VM’ler disposable ve boşta kaldıklarında neredeyse hiçbir maliyet oluşturmuyorlar
Özellikle memory-state snapshot geldikten sonra her şeyin devam ettirilebilir hale gelmesi beklediğimden çok daha güçlü çıktı
Oturum açılmış bir Chromium durumunu snapshot’layıp gerektiğinde anında kopya oturumlar başlatabiliyorum; agent’lar sandbox içinde çalışıyor ve preview ortamları için docker compose da orada çalışıyor
Hiçbir şey çalışmıyorken sunucu fiilen idle durumda ve aylık 100 dolarlık tek bir kutu bütün bunu hallediyor
Ayrıntılar https://shellbox.dev/blog/race-to-the-bottom.html içinde var
Dokümantasyon kapsamlı ve faydalı, ama bazı bölümlerinde belirgin bir AI tarafından yazılmış hissi var; biraz daha kısa tutulsa daha iyi olabilir
Yine de "design decisions" bölümü özellikle güzeldi ve oradan yeni şeyler öğrendim
Henüz yapmadıysan Show HN’de paylaşmaya değer
Zaten kullanılmayan yazılım fazlasıyla varken, neden hâlâ daha fazla kod üretmeye bu kadar takıntılı olduğumuzu pek anlamıyorum
Sadece app store’lara bakmak bile kimsenin kullanmadığı yazılımlarla dolu olduğunu gösteriyor
Bence LLM’lerin daha bariz kullanım alanı daha fazla yazılım üretmek değil, daha iyi yazılım üretmek olmalı
Odağın sadece kod üretiminden çıkıp başka yönlere kaymasını isterim; LLM’lerin daha iyi kod yazmaya yardımcı olmasının pek çok yolu var
İnce işlenmiş, bakımı yapılan, güncellenen deterministik sistemler fikri elbette varlığını sürdürecek; ama AI şimdiden kullanıcıların bilgisayarla etkileşim biçimini değiştiriyor
Bunun sonucu olarak çok daha tek kullanımlık yazılımlar ortaya çıkacak gibi duruyor
Şu anda hâlâ "AI, mühendislerin yazılım yazmasına nasıl yardımcı olur" aşamasındayız; ama giderek "mühendisler, AI’ın daha iyi yazılım yazabilmesi için ne yapar" aşamasına geçiyoruz
Bu da yazılımın ne olduğu ve bilgisayar etkileşiminin nasıl tasarlanması gerektiği konusunda tamamen farklı düşünen yeni bir mühendis kitlesi doğuracak
App store’a hiç çıkmayacak türden özel yazılımların sayısı muhtemelen çok artacak
Yazılım üretim birim maliyeti düşmesine rağmen talep artışı tasarrufu aşıp toplam harcamayı yükseltiyorsa ancak o zaman Jevons paradox denebilir
Bu kavram, fiyat değişimine talebin güçlü tepki verdiği yani talep esnekliğinin yüksek olduğu piyasalarda geçerlidir
Oyunlar hariç, yüz milyonlarca hatta milyarlarca kişinin kullandığı tek bir yazılım yapma fikrinin ne kadar garip bir dönem olduğunu ileride fark edeceğiz gibi geliyor
İnsanlar artık çelişen önceliklere ya da çarpık gelir modellerine daha az mahkûm olacak, gerçekten istedikleri işi tam olarak yapan yazılımlar üretebilecek
Tanım gereği bunun daha yüksek kaliteli yazılım anlamına geldiği de söylenebilir
Böylece her iki taraf için de maliyet ve gelir tahmini kolaylaştı; ama temel fikir mümkün olduğunca genel amaçlı yazılım üretmekti
Sonuç olarak yalnızca bazı kullanıcılara önemli gelen UX ve özellikler sürekli budandı
Vibe coding ve LLM hızlandırmalı geliştirme bunu tersine çevirebilir
Artık herkes kendi ihtiyaç ve tercihlerine göre özelleştirilmiş yazılımı karşılayabilir; Salesforce’un 150 bin müşterisinin aynı CRM’i kullanması yerine 150 bin farklı özelleştirilmiş CRM kullanacağı bir dünya hayal edilebilir
Yazılımın ölçekleneceği alan şu anda inanılmaz büyük
Yazılımın şişme döngüsünü anlamazsanız aynı hataları tekrar tekrar yaparsınız
Süreç hep şu: lean software ile başlanır, kullanıcıdan gelen özellik talepleri birikir, sistem giderek bloated bir karmaşaya dönüşür, sonra yeniden daha küçük bir rewrite gerekir ve tekrar lean software’e dönülür
Reboot girişimleri genellikle ya başarısız olur ya da gerçekten önemli bir şeyi doğru yapıp mevcut devleri tehdit edecek kadar ileri gider
DevOps’u CV doldurma aracı ya da aşırı karmaşıklığın kaynağı gibi küçümseyen bakış bana daha çok startup zihniyetini çağrıştırıyor
Küçük şirketlerde gerçekten tek bir DevOps kişisi tüm altyapıdan sorumlu olabilir; ama özellikle finans tarafında yönü belirleyenler çoğu zaman platform engineering MD’leri oluyor
Bunlar yazılım mühendislerini çok sayıda küçük gruba bölüyor, her takımın kendi repo’sunu, kendi deployment’ını, kendi her şeyini kontrol etmesini istiyor ve microservices’in onlara bu gücü verdiğine inanıyor
Emin olun DevOps tarafı karmaşıklıktan nefret eder
Gece ve hafta sonu çağrılan taraf onlardır ve her şey daima "altyapı problemi" varsayımıyla başlar
Deployment log’ları log aggregation sistemine eksiksiz gidiyor olsa bile, geliştiricilerin kendi deployment sorunlarını doğrudan log’a bakıp çözmesi nadir; olay çok hızlı biçimde Incident’a dönüşüyor
Belki de artık mikroservisleri geçmiş bir moda olarak görmenin zamanı gelmiştir
exe.dev’e olumlu baktım; LLM geliştirme akışını akıcı hale getirirken root yetkili Linux makine esnekliği sunan tarafta kesinlikle fırsat var
Ama "yarım uygulanmış, yarım düşünülmüş soyutlamalar tarafından sürekli hayal kırıklığına uğradım" cümlesini okuyunca ironik şekilde benim Tailscale deneyimim aklıma geldi
Ağ kurmayı kolaylaştıracağını söylüyor ama pil neden bu kadar hızlı tükeniyor, firewall kuralları neden diğer araçlarla çakışacak şekilde değişiyor, bug tracker neden sessiz; sonuçta yine iç işleyişi benim anlamam gerekiyor
Bu da insana "No thank you" dedirtiyor
Hizmetin kendisi gerçekten çok etkileyici görünüyor
Ben router ACL’i yazmıyorum; peer-to-peer ağ katmanı kurgulamaya çalışıyorum ve eksik hissettiren nokta tam orası
Ben sadece Hetzner kullanıyorum
Cloud şirketlerinin sunduğu her şey aşırı pahalı geliyor; kendi işlettiğim Postgres HA ve backup sistemi 10 yıldır kesintisiz çalışıyor ve buna rağmen RDS ya da CloudSQL production maliyetinin yaklaşık onda birine mal oldu
Grafana’da toplanan metriklerle instance’ları kendim autoscale ediyorum; webhook tabanlı autoscaler da son derece basit ve bugüne kadar hiç sorun çıkarmadı
Bu yüzden artık neden GCP ya da AWS kullanmam gerektiğini pek anlamıyorum
Tüm servisler HA, backup’lar da her gün sorunsuz alınıyor
O zaman amaç, mümkün olan en esnek dedicated server deneyimini ucuza yeniden üretmekti ve UML bunu mümkün kılıyordu
Ama 2010’lar boyunca geliştiricilerin çoğunun, biraz rahatlık uğruna stack’teki her parçanın metrik bazlı faturalandırılmasını kabul etmeyeceğini sanarak tamamen yanılmışım
Bugün 20’li yaşlardaki yazılım mühendisleri, eBay’den alınmış sunucu ve router’larla yüksek trafikli web uygulaması platformu kurmayı hâlâ biliyor mu gerçekten merak ediyorum
Ben geçen yıl bunu yaparak 50PiB+ bir datastore kurdum ve bu yöntemin orta-büyük projelerde ne kadar kullanıldığını samimiyetle merak ediyorum
Hetzner fiziksel uğraşın önemli kısmını ortadan kaldırırken ekonomik avantajın neredeyse tamamını koruyor; buna rağmen neden hosting dünyasının kralı değil de 2021 itibarıyla 367 milyon euro ciro seviyesinde kalıyor, şaşırtıcı
Dedicated server filosu yönetme bilgisi gerçekten bu kadar uzmanlaşmış olabilir mi ki insanlar bu kadar büyük tasarrufu görmezden gelsin, emin değilim
Ama doğru insanları bulabiliyorsanız, işleri kendiniz yürütmek gerçekten çok daha ucuza gelebilir
Her dakika çalışan cron,
docker pullile güncel image’ı çekiyor; sadece yeni sürüm varsadocker up -dile değiştiriyorÖn tarafta HTTPS için caddy var ve bu kurulum yıllardır çok ucuz ve çok stabil şekilde çalışıyor
Benzer felsefeye sahip, Birleşik Krallık merkezli bir sağlayıcı gibi göründü; henüz denemedim ama bir sonraki VPS adayım olarak hesap açtım
Başlangıçta 5 kat hızlı bir sunucuyu karşılayabildiğiniz için autoscaling’e çoğu durumda zaten ihtiyaç kalmıyor
Zaten birçok alternatif var; ben de https://shellbox.dev yapıyorum
exe’den farklı olarak kullandığın kadar öde modeli var, scale-to-zero yapabiliyor ve SSH ile anında VM başlatabiliyorsun
Normal Linux olduğu için VSCode ve Zed remote da destekleniyor, nested virtualization da mümkün
Yatırım yapmak isterseniz 5 milyon dolar da işimi görür
Dışarıya açık port yok ve tüm web frontend’ler parola korumalı
Bunu yayımlamayı düşünmüyorum; TV’nin arkasındaki kişisel Raspberry Pi’da çalışan benim izole geliştirme ortamım
Maliyeti de fiilen sıfır
Umarım servisiniz de başarılı olur
Gerçek altyapının nerede olduğu, hangi güvenlik garantilerinin verildiği gibi şeyler net olmadığı için üzerine workload emanet etmek kolay değil