AWS’ye geri döndüm ve neden ayrıldığımı yeniden hatırladım

 (fourlightyears.blogspot.com)
1 puan yazan GN⁺ 5 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Başlarda AWS’yi destekliyordum, ancak istemci kütüphanelerini topluluğa bırakması, Python 3’e geçişteki gecikme, karmaşık ücretlendirme ve IAM, ayrıca AWS Lambda kilitlenmesi gibi etkenler birikince artık AWS’yi sevmemeye başladım
  • DynamoDB kullandıktan sonra bir gün için 75 dolar fatura geldi; veri çıkış maliyeti GB başına 20 sentten 9 sente düşmüş olsa da, dahili veri aktarımının bile ücretlendirilmesi yapısının hâlâ pahalı ve anlaşılması zor olduğunu düşünüyorum
  • AWS’den ayrıldıktan sonra hesaplarımın çoğunu kapattım, ancak Route53 alan adları, S3 yedeklerinin bir kısmı ve AWS WorkMail kaldı; daha sonra WorkMail’in 12 ay içinde sonlandırılacağına dair bildirim aldım
  • Kısa süre önce Claude/Anthropic’in AWS Bedrock üzerindeki çalışmasını ve 192 çekirdek, 1 TB RAM EC2 Spot testini denemek için tekrar AWS’ye giriş yaptım; Bedrock’ın aynı işi yaptığını ama daha yavaş olduğunu ve Anthropic aboneliğinden çok daha pahalıya geldiğini düşündüm
  • Yaklaşık 3 saatlik EC2 Spot testi sırasında Suspected security breach uyarısından sonra hesabım kısıtlandı; iş için kullandığım WorkMail e-postası ve kaynak oluşturma engellendi, yapılan işlemler ve sohbet desteğine rağmen kısıtlama 4 gün boyunca kalkmadı, bu yüzden AWS WorkMail ve Route53’ü de taşımaya karar verdim

İlk AWS desteğinden kopuşa

  • AWS’nin SQS, S3, EC2 ve SimpleDB merkezli daha küçük bir hizmetler bütünü olduğu dönemden beri güçlü bir destekçisiydim; Melbourne’de ABD’den gelen AWS temsilcisinin AWS’yi tanıttığı ilk etkinliği organize ettim
  • Bulut bilişim, girişimlerin veri merkezine sistem kurup işletmeden birkaç dakika içinde kendi bilgisayar sistemlerini çalıştırabilmesini sağlayan büyük bir değişimdi
  • Yaklaşık 15 yıl boyunca AWS’ye güçlü biçimde inandım, ancak zamanla rahatsız edici unsurlar birikti ve bir noktada artık AWS’yi sevmediğimi fark ettim

Zamanla biriken AWS memnuniyetsizlikleri

  • İstemci kütüphaneleri ve Python geçişi

    • AWS, ilk 6 yıl boyunca kendi istemci kütüphanelerini üretmedi; Python gibi diller için kütüphaneleri topluluğun geliştirmesine bıraktı ve bu, ücretsiz zaman harcayan programcıların üzerine yük yıkmak gibi geldi
    • AWS’nin Python 2’den Python 3’e geçmekte aşırı uzun süre alması da büyük bir memnuniyetsizlik olarak kaldı

  • DynamoDB ve maliyet deneyimi

    • DynamoDB kullandıktan sonra gün sonunda 75 dolar fatura çıktı; sadece maliyet değil, sistemin kendisi de hayal edilebilecek en kötü şekilde tasarlanmış gibi geldi

  • Veri aktarım maliyetleri ve karmaşık ücretlendirme

    • AWS’nin veri çıkış maliyeti eskiden GB başına 20 sent idi ve daha sonra GB başına 9 sente düştü, ancak bunun hâlâ çok pahalı olduğunu düşünüyorum
    • AWS içindeki sistemler arasında veri taşımanın bile ücretlendirilmesi ve bazı durumlarda iki ya da üç kez ücret alınıyormuş gibi hissettiren yapı nedeniyle, ayrıntıları çok iyi anlamadan ücret tuzaklarından kaçınmak zor

  • IAM ve genel karmaşıklık

    • IAM, kimlik doğrulama ve erişim kurallarını yöneten bir sistem, ancak aşırı karmaşık bir yapı olarak algılanıyor
    • AWS destekçileri, kendi Linux’unuzu, donanımınızı, ağınızı ve güvenliğinizi işletmenin fazla karmaşık olduğu için AWS kullanılması gerektiğini söyler; ancak AWS’nin kendisinin de neredeyse her alanında devasa bir karmaşıklık var ve sonuçta yine pahalı uzman ekipler gerektiğini düşünüyorum

  • AWS Lambda ve kilitlenme

    • AWS Lambda ölçeklenebilirliği öne çıkarıyor, ancak bunun karşılığında yavaş başlangıç süreleri ve yüksek geliştirme karmaşıklığına katlanmak gerekiyordu
    • Kendi web sunucunuzu işletmeye kıyasla gerçek bir avantajı olmadığını, buna karşılık çok sayıda dezavantajı bulunduğunu düşündüm; AWS’den ayrılırken geri döndürmesi en zor kısım AWS Lambda oldu
    • AWS Lambda kullanımı, tedarikçi kilitlenmesinin gerçekten var olduğuna dair bir deneyim olarak kaldı ve sanki sürekli bunun daha iyi bir seçim olduğuna kendinizi ikna etmeniz gerekiyormuş gibi hissettirdi

  • Açık kaynak projeler ve barındırma geliri

    • AWS’nin, Elasticsearch, Redis ve MongoDB gibi projeler kopyalanıp gelir elde edilmesini istemediklerini belirtmelerine rağmen OpenSearch, Valkey ve DocumentDB’yi ileri götürdüğünü düşünüyorum
    • İlgili topluluklar ve şirketler pazarı oluşturduktan sonra, AWS’nin barındırılan hizmet gelirini aldığını ve bunun sonucunda SSPL, Elastic License, RSAL gibi savunmacı lisansların ve source-available modelinin arttığını düşünüyorum

AWS’den ayrıldıktan sonra bıraktığım bazı hizmetler

  • AWS’ye olan bağlılığım bittikten sonra her şeyi AWS dışına taşıdım ve hesaplarımın neredeyse tamamını kapattım
  • Yine de o dönemde gerçekten doğru çözüm olduğunu düşündüğüm bazı hizmetleri bıraktım
  • Bıraktıklarım Route53’teki alan adları, S3’teki bazı yedekler ve AWS WorkMail idi
  • Daha sonra AWS WorkMail’in 12 ay içinde sonlandırılacağına dair bildirim aldım

AWS’ye kısa süreli dönüş nedenim

  • Kısa süre önce araştırma ve test için tekrar AWS’ye giriş yaptım
  • Claude/Anthropic’in AWS Bedrock üzerinde ne kadar iyi çalıştığını görmek istedim; Claude Code açısından aynı işi yapıyor gibiydi ama daha yavaştı ve Anthropic aboneliğinden çok daha pahalıya geliyordu
  • Sahip olduğum en hızlı ev sistemi 20 çekirdekli CPU ve 32 GB RAM’e sahipti; kodun 192 çekirdek ve 1 TB RAM olan bir sistemde ne kadar hızlı çalıştığını ölçmek istedim
  • Yaklaşık bir ay önce AWS Bedrock testi sorunsuz tamamlandı ve testten sonra her şeyi kapattım
  • AWS Bedrock, gizlilik gerekiyorsa faydalı olabilir, ancak maliyeti yüzünden Claude’u tekrar AWS Bedrock üzerinde kullanmayı düşünmüyorum

EC2 Spot testi sırasında yaşanan hesap kısıtlaması

  • Daha sonra 192 çekirdekli bir EC2 Spot instance başlatıp yaklaşık 3 saat test yaparken AWS’den “Suspected security breach of your account” e-postası aldım
  • Neredeyse hareketsiz durumdaki bir hesabın aniden pahalı bilgi işlem kaynakları kullanmaya başlamasının, AWS iç güvenlik alarmını tetiklemiş olabileceğini düşünüyorum
  • AWS’nin kullanıcıyı koruma amacını ise anlıyor ve olumlu buluyorum
  • Ancak AWS hesabımı askıya aldı veya kısıtladı ve bunun sonucunda AWS WorkMail’de kullandığım ana iş e-posta hesabım çalışmaz hâle geldi
  • Artık kimse bana e-posta gönderemiyordu ve hiçbir AWS kaynağı oluşturamadığım için yapmak istediğim testi de sürdüremedim

Destek süreci ve gecikme

  • AWS destek bildirimine yanıt verip hesabımın hacklenmediğini, ortada bir sorun ya da anormal faturalama olmadığını bildirdim, ancak yanıt gelmedi
  • Premium destek kullanmadığım için AWS’nin belirttiği 24 saatlik yanıt süresini beklemek zorunda kaldım ve 3 gün geçmesine rağmen AWS destekten dönüş olmadı
  • AWS forumunda yardım istedikten sonra, e-postadaki talimatları yerine getirmem ve web yerine sohbeti kullanmam yönünde tavsiye aldım
  • Şifre değiştirme, erişim token’larını silme, fatura kayıtlarını kontrol etme gibi istenen işlemlerin hepsini yaptım; sohbete bağlanmak için yaklaşık 30 dakika bekledikten sonra AWS temsilcisiyle uzun bir görüşme yaptım
  • Temsilci ikna olmuş gibi görünüyordu ve ilgili iç ekibin işlem yapmasını isteyeceğini söyledi, ancak 24 saat geçmesine rağmen kısıtlama kaldırılmadı
  • 8 saat sonra yaptığım takipte ise yalnızca “lütfen bekleyin” yanıtını aldım

Yeniden doğrulanan sonuç

  • Hesabın kısıtlanmasının üzerinden 4 gün geçtiğinde, büyük sistemlerde test etmek istediğim işler hâlâ duruyordu ve bunun için yeniden bir “quota” talebi açmak zorunda kalma ihtimali beni düşündürüyordu
  • İş için kullandığım e-posta sistemi hâlâ çalışmıyordu
  • Bu dönüş deneyimi, AWS’den neden ayrıldığımı bana yeniden hatırlattı; AWS WorkMail’den çıkmaya ve Route53’teki alan adlarını da taşımaya, bir daha geri dönmemek üzere karar verdim
  • Geçmişte AWS’den büyük ölçüde çıkmış olmam büyük bir şanstı, ancak güvenip bıraktığım e-posta sisteminin AWS’ye dönüş sürecinde kesintiye uğramasını bir başarısızlık olarak görüyorum
  • AWS bir gün hesap kısıtlamasını kaldırabilir, ancak bunun ne zaman olacağını bilmiyorum

İlgili okumalar

1 yorum

 
GN⁺ 5 시간 전
Hacker News yorumları

  • Birkaç yıl önce bir şirkete katılıp geliştirme ekibinin başına geçtim ve benden 3 ay içinde ürünü yayına almam istendi; AWS'de yeni bir makine eklemeye çalışırken fiyatın arayüzde görünmemesi yapısının kendisi bana düşmanca ve sömürücü bir ilişkinin işareti gibi göründü
    Özellik tablosu ile fiyat listesini ayrı ayrı açıp karşılaştırmak gerekiyordu ve geçmiş deneyimlerime göre böyle işaretleri görüp de ayrılmazsam sonrasının sorumluluğu bana ait olurdu
    Bu yüzden bir DigitalOcean hesabı açtım, her şeyi oraya taşıdım, CI/CD'yi de oraya dağıtacak şekilde ayarladım ve kalan iki ayda ürüne odaklanıp söz verilenden bir ay önce yayına aldım
    Eskiden nehir kıyısına bir çukur kazıp nehirle çukuru bir boruyla bağlayarak balıkların kendi kendine tuzağa girdiği bir video görmüştüm; en az dirençli yolu seçmenin ve hataları geri almamanın insanı o balıklar gibi bir sona götürdüğü izlenimi bende çok güçlü kalmıştı

    • Azure'da hoşuma giden şeylerden biri, tek tek kalemler oluştururken fiyatı aşırı şekilde göze sokmaması ama pahalı olabilecek kalemlerde genel olarak fiyatı gösteren bir denge kurması
      Şimdiye kadar fatura yüzünden şaşırmadım
    • Amazon'un mühendislik kültürü epey mühendis odaklı bir ürün kültürü olduğu için geliştiriciler çoğu zaman UX ve akıştan da sorumlu oluyor olabilir
      Eskiden AWS stajını bitirmiş junior bir geliştiriciyi işe almıştım; yaz boyunca ürün yöneticisi ya da tasarımcı desteği almadan tek başına yaptığı bir dashboard göstermişti ve gerçekten korkunç görünüyordu
      Bazı geliştiricilerin ürün/UX sezgisi iyidir ama çoğunluk UX konusunda ciddi biçimde zayıf, dolayısıyla bu kasıtlı olmaktan çok kötü bir UX kültürü de olabilir
    • Doğru yaklaşım, yayına çıkmanıza yardımcı olan bir altyapı sağlayıcısı seçmektir
      AWS iyi ama herkese uygun değil; Heroku benzeri servislerle bare metal arasında bir yerde durup bakım işini büyük ölçüde soyutlarken ölçeklenen mimari üzerinde size bir miktar kontrol de bırakıyor
      Yani AWS, bulut sağlayıcısı olarak ölçeklenmeye yardımcı olur ama en ucuz ve en basit düzeni kurmak için tasarlanmış bir araç değildir
      VC yatırımı aldıysanız ve büyümeyi öne çıkarıyorsanız AWS güvenli bir tercih olabilir; ayrıca hızlandırıcılar üzerinden gelen 2 yıllık startup kredileri sayesinde ilk 18 ay altyapı bütçesinden çok inşa etmeye odaklanabilirsiniz
      Bootstrapped ya da indie geliştiriciyseniz karşılayabileceğiniz kadar basit bir şey seçin; Hetzner veya DigitalOcean gayet yeterli olur
    • AWS'in oldukça iyi bir fiyat hesaplayıcısı ve işe yarar preset'leri var ama elbette tamamen ayrı bir uygulama
      Amazon fiyat bilgisini kolayca görme sürecinde biraz sürtünme olmasını istiyor olabilir ama asıl neden Conway yasası gibi görünüyor
      AWS hâlâ organizasyon şemasını ürün olarak dışarı veriyor
    • Bir ölçüde katılıyorum ama AWS fiyatlandırması, arayüzde görünen tek bir statik sayıdan ne ödeyeceğinizi çıkarabileceğiniz kadar basit değil
      Maliyet karşılaştırması için iki sekme açmak size zahmet geliyorsa yalnızca AWS'den değil tüm bulut sağlayıcılarından uzak durmanız daha iyi olabilir
      NAT Gateway, CloudFront, S3, auto scaling, load balancer devreye girince maliyet hesabı kesin bir bilimden çok bir sanata yaklaşıyor
      Bunları kullanmıyorsanız AWS kullanmanız için pek sebep yok; ucuz VPS sağlayıcısı çok

  • Sadece OpenSearch ve Valkey'e bakarsak, “AWS fork yaparak lisans değişikliğine yol açtı” açıklaması tamamen tersine çevrilmiş bir anlatı
    AWS ancak upstream proje lisansı değiştirdikten sonra fork yaptı ve özellikle Valkey, eski Redis çekirdek ekibindeki geliştiriciler tarafından oluşturuldu

    • Bu projelerin önemli bir kısmı, çekirdek ürünü açık kaynak olarak yayımlayıp gelişmiş servisler, kurulum, bakım ve managed hizmet sunan bir iş modeliyle çalışıyor
      AWS managed hizmet sunarak onları by-pass ettiği için bu konuda proje üreticilerinin tarafındayım
      Temelde AWS onların ekmek kapısını ellerinden aldı ve lisansı değiştirmek zorunda kaldılar
    • O lisans değişikliği de zaten AWS'nin upstream projenin emeğini sürdürülemez biçimde gelirleştirmesine verilen bir yanıttı
    • Amazon, sattığı açık kaynak yazılımın üretici ve bakımcılarına her faturalama dönemi için kullanım başına 1 cent ödese bunun ne kadar etkisi olurdu diye merak ediyorum
      Böyle bir şey açık kaynak ekipleri için kayda değer bir para olabilir; ayrıca ürünü risk almadan iyileştirmeye katkı vermelerini de teşvik edebilir
    • Redis'e ilk patch'imi gönderdiğimde bir committer mesajıma cevap vermek yerine patch'i kendi adıyla eklemişti; o günden beri birçok açık kaynak projesinin felsefesine duyduğum sempati azaldı
      Valkey başlarına gelmeyi hak etmiş olabilir
      JBoss ve Marc Fleury'yi de hâlâ hatırlıyorum
    • AWS'nin o projenin kodundan para kazanamaması için lisans değiştirildikten sonra fork yapması gayet doğal
      Meselenin özü tam olarak bu

  • Bulut hizmetleriyle self-hosting arasında birkaç kez gidip geldim
    İlk başta Vercel kullandım; proje Next.js olduğu için deneyim iyiydi ama 100 kullanıcıyı bile bulmayan bir proje için aylık 20 dolar, düşük performans gereksinimli bir servis açısından pahalı geldi
    Sonra Hetzner ve Coolify ile kendi sunucumu kurdum; Coolify açık kaynak olduğu için yalnızca VPS ücretini ödüyordum ve aylık 5 dolara bir PostgreSQL instance'ı ile web sunucusu çalıştırabiliyordum
    Ama PostgreSQL ve Redis bakımı yine de çok emek istiyordu; Docker container içinde olsalar bile servisler arasında sistem değişkenleri ve environment variable aktarmak zahmetliydi
    Bu yüzden daha sonra Cloudflare Workers, D1 Database, Cloudflare KV tarafına geçtim; Worker içinden doğrudan çağrılabildiği için environment variable taşımam gerekmiyordu
    Yerel geliştirme deneyimi de iyi, fiyatı da makul olduğu için sonrasında Cloudflare ürün ailesini kullanmaya devam ettim

    • Cloudflare'ın sundukları, benim AWS'de olmasını istediğim şeye daha çok benzemeye başladı
      Temel full-stack uygulama ve dosya dağıtımı çok daha basit ve AWS artık self-hosting'den bile çok daha zor hale geldi
    • Docker'ın PostgreSQL yönetimini gerçekten kolaylaştırıp kolaylaştırmadığını merak ediyorum
      PostgreSQL'de yaşadığım tek sorun, yeni major sürüme geçerken biraz migration işi çıkması oluyor
      Servisler arasında sistem değişkenleri ve environment variable aktarma işi Docker yüzünden daha zorlaşmış da olabilir mi diye düşünüyorum
    • Cloudflare Workers'ı sevmek istiyordum ve teknik olarak sevmek için iyi nedenler de var ama e-posta etkinleştirme gibi işler için Wrangler projesi kullanma zorunluluğu platforma kilitlenmenin bir adım öncesi gibi hissettirdi
      E-postaya izin vermek için gerekli binding'leri kurmanız gerekiyor ama bunlar konsoldan ayarlanamıyor ve Wrangler ayarladıktan sonra da görünmüyor gibiydi

  • Yazarın DynamoDB'den hoşlanmaması şaşırtıcı
    Benim en sevdiğim AWS servislerinden biri; erişilebilirliği iyi, operasyon yükü yok ve kullandığım her seferde maliyeti de oldukça düşük oldu
    Yalnız veri modelini baştan tasarlamak için zaman ayırmanız gerekiyor ve bunun için servis dokümantasyonunu okuyup anlamalısınız

    • DynamoDB, amaçlandığı şekilde kullanılırsa oldukça iyi
      Esasen iyi dayanıklılık sağlayan ve tablo boyutunu neredeyse sınırsız ölçekleyebilen nispeten basit bir key-value store olarak görmek lazım; SQL veritabanı gibi kullanmaya çalışmamak gerekir
      Prototip kodla 75 dolarlık fatura üretmenin en kolay yolu, onu JOIN ve GROUP BY yapan bir SQL veritabanı gibi ele alacak şekilde vibe coding yapmak
      Asıl parladığı yer, küçük kalıcı depolama için 1-2 tabloya ihtiyaç duyduğunuz ama tam bir RDBMS yönetmek istemediğiniz durumlar ya da çok büyük tek bir tabloyu basit sorgularla okuyacağınız ve bunu RDBMS'e uydurmak istemediğiniz senaryolar
    • DynamoDB ve Lambda gibi pek çok servisin çok belirli kullanım senaryoları var
      Neşeli bir key-value store'u veritabanı gibi kullanmamak gerek
    • Birkaç yıl önce uygulama geliştirirken yaklaşık 50 milyon kayıt, ayda yaklaşık 10 bin okuma+yazma ve 1 indeks saklayacak bir veritabanına ihtiyacım vardı
      İlk yükleme maliyeti yaklaşık 50 dolardı; sonrasında bakım maliyeti aylık 10 cent civarıydı

  • Böyle yazılar beni hep güldürüyor
    Hem doğru hem yanlışlar ve sistemler “mümkün olduğunca basit, ama bundan daha basit değil” olacak şekilde kurulmalı
    Ayrıntıları geçiştirebileceğinizi sanırsanız daha sonra daha büyük uğraşlarla karşılaşırsınız
    IAM düpedüz karmaşık
    Kullanıcılar, gruplar, roller, policy'ler, identity provider'lar ve OIDC'yi gerçekten basit uygulayan bir örnek aklıma gelmiyor
    Eskiden Kubernetes'e “fazla karmaşık” diye karşı çıkan birinin sonunda Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash ve biraz tükürükle çimenden oluşan malzemelerle Kubernetes'i kötü ve geçici bir şekilde yeniden icat edip tonla hata yaptığını görmüştüm
    Bazı özelliklere ihtiyacınız olmadığını düşünürsünüz ama sonunda ihtiyaç duyarsınız
    Startup'ta tek altyapı sorumlusu olarak çalışmış biri olarak AWS'nin büyük kısmı çoğu insanın öğrenebileceği sınırlar içinde ve rezil kısımlardan genelde kaçınılabilir
    Lambda'dan hoşlanmıyorsanız kullanmayın; EKS, ECS, EC2 kullanın

    • İçeriden bakınca IAM'de binlerce seçenek var ama özü şu: “Bu rol neye erişebilir ve ne yapabilir (aksiyon + kaynak)” ile “Bu role kim erişebilir?”
      10 bin feet yükseklikten bakınca hepsi bu
      IAM'in iyi yanı, dışarıya ve içeriye aynı şekilde uygulanması
      AWS iç ekipleri diye daha fazla erişim hakları olmuyor; belirli bir servisi sunmak için müşteri hesabında bir şey yapma yetkisi alıyorlarsa bu, müşterinin IAM trust relationship içine service principal ekleyip erişim verdiği anlamına geliyor ve müşteri bunu görüp denetleyebiliyor
      Örneğin Lambda'nın bir Lambda rolü var; çünkü “biz AWS'yiz, otomatik erişiriz” diye Lambda servisinin gidip bir S3 bucket okumasını istemezsiniz
      AWS iç erişimi bile müşteri tarafından açıkça görülebilir ve kontrol edilebilir
    • “X fazla karmaşık” deyip benimsenmesini engelledikten sonra sonunda X'i kötü biçimde yeniden icat etme paterni teknoloji ve yazılım dünyasında şaşırtıcı derecede yaygın
      Bazı şeyler artık açıkça standart olsa da birçok kişi bunları gerçekten öğrenmeye zaman ayırmayı reddediyor
    • AWS self-hosting'den pahalı olabilir ama o tasarruf mühendislik maliyetinin yanında küçük kalır
      İyi bir altyapı mühendisi “para tasarruf edeceğim” diye bir OVH kurulumuna iki ay harcarsa, sadece Fargate veya RDS kullanmayarak biriktireceği paradan daha fazlasını tüketmiş olur

  • Anthropic ve OpenAI gibi yerler için de aynı şeylerin ne zaman söylenmeye başlayacağını merak ediyorum
    Şu anki AI akımı AWS'nin ilk dönemleri gibi kokuyor; herkes atladı ama sonra kolay sökülemeyen büyük bir bağımlılık biriktirdiklerini fark edecekler gibi

  • Lambda gerçekten harika ve baş ağrıtmadan hızlı iterasyon döngüsüyle dağıtım servisi işletmenin en iyi yolu olabilir
    Mutlaka microservice'e gitmeniz ya da kodu milyarlarca küçük repo'ya bölmeniz gerekmiyor
    Sunucu içi durumu istekler arasında paylaşabileceğinizi varsaymıyorsanız standart bir web sunucusunu Lambda üzerine taşıyabilirsiniz

  • O alanda çalışmadığım için AWS'ye bazen sadece kişisel eğlence projeleri için dokunuyorum ve her seferinde kâbus gibi geliyor
    Deneysel bir kart oyunu sunucusu kurmaya çalışıyorum, yeni bir finans kurumu inşa etmiyorum; ama her şey sanki yarın sonsuz ölçeklenecekmiş, bin kişilik bir organizasyon ve VC bütçesi varmış gibi görünüyor
    Neyse ki Netlify gibi servisler üstünü kapatıyor da denizi kaynatmak zorunda kalmıyorsun
    Belki bir gün gerçekten IAM, VPN ve daha adını bile bilmediğim şeyleri öğrenmem gerekecek ama o zamana kadar AWS'ye her dokunduğumda gözlerim fırlayacak gibi oluyor

    • EC2 ya da Lightsail üzerinde ham bir VPS ayağa kaldırıp public IP ekleyin ve bitirin
      Tüm enterprise kalıplarını uygulamak zorunda değilsiniz
    • Heroku'nun neredeyse 20 yıl önce çoğu web uygulamasının ihtiyaç duyduğu şeyi ne kadar isabetli yakaladığını görmek etkileyici
    • Azure ile uğraşmadıysanız AWS size tek başına kâbus gibi gelebilir
    • Cloudflare'a geçtim ve gerçekten nefes aldım
      İhtiyacım olan her şey var ve fiyatı da makul
    • AWS kişisel projeler için değil, enterprise için tasarlanıyor
      Kişisel projelerde eninde sonunda sadece maliyet önemli oluyor, bu yüzden AWS'ye anlamlı bir gelir bırakmıyorlar

  • 2023'ten beri AWS'de teknik kadrolar sistematik biçimde boşaltılıyor
    Bu ya büyük işten çıkarmalarla ya da iki tur performance improvement plan ile oldu; pre-sales ya da support tarafında çok yetenekli olan eski çalışma arkadaşlarımın çoğu artık AWS'de değil
    Buna karşılık iş geçmişi en muğlak görünen insanların kaldığını ve terfi aldığını sık sık gördüm
    AWS'yi herkes kendi riskini alarak kullanmalı; Paul Vixie gelip kurtarmayacak

  • Uzun zamandır ElastiCache özellikle sinirimi bozuyor
    RDS ölçeklenebilirlik, makul ölçüde optimize ayarlar ve uğraşmadan alınan yedekler gibi bir değer kattığı için para vermeye razı olabiliyorum
    Ama ElastiCache neredeyse hiç katma değer sunmuyor ve fiyatı sömürücü hissettiriyor
    Temel Redis kurulumuna göre daha yavaş, daha az optimize, daha az stabil; ayrıca hiç ayar yapılmamış bir Redis birden fazla DB desteklerken ElastiCache yalnızca birini destekliyor
    Ölçeklenebilirlikte bazı kazanımları var ama sıradan Redis benzer instance'larda ElastiCache'i o kadar büyük farkla geçtiği için bu kazanımların gerçekten lazım olduğu durumlar çok nadir

    • ElastiCache kesinlikle self-hosting düşünmeye değer servislerden biri
      AWS'nin API veya genel olgunluk açısından kattığı şey çok fazla değil; buna karşılık Redis/Valkey doğrudan host etmesi en basit servislerden biri