27 puan yazan GN⁺ 2025-04-23 | 19 yorum | WhatsApp'ta paylaş
  • Serverless ilk bakışta pratik görünse de gerçekte karmaşıklık, kısıtlar ve yüksek maliyet üreten bir yapıdır
  • Konteynerler taşınabilirlik, durum koruma ve net kontrol sağlar; çoğu kullanım senaryosu için daha uygundur
  • Serverless modelinde maliyet yapısı opaktır, öngörülemezdir ve bileşenler arasında gereksiz karmaşıklık yaratır
  • Serverless’in ölçeklenebilirlik ve kullanım kolaylığı avantajları yalnızca sınırlı kullanım senaryoları için uygundur
  • Gerçek üretim ortamlarında konteyner tabanlı dağıtım daha basit, ölçeklenebilir ve maliyet açısından verimlidir

Serverless Is a Scam. Just Use a Container.

Serverless nedir?

  • Serverless, kodu tek tek fonksiyonlar halinde dağıtıp çalıştırma ve ölçeklendirmeyi bulut platformuna otomatik olarak bırakan bir yaklaşımdır
  • Ancak pratikte şu sorunlar vardır
    • Çalışma süresi sınırı (ör. AWS Lambda’da 15 dakika sınırı)
    • Durum koruyamama (her çalıştırmada sıfırlanır)
    • Cold start sorunu
    • Debug edilemeyen ortam
    • Platforma özgü ayarlar ve yapılandırmalar
    • Aşırı YAML kullanımı
  • Basit görünse de karmaşık işler için uygun değildir

Konteynerler: basit, güçlü ve iyi anlamda sıkıcı

  • Konteynerlerin şu avantajları vardır
    • Hızlı başlangıç
    • Her ortamda çalışabilme
    • Durum koruyabilme (Docker volume kullanarak)
    • Çalışma süresi sınırı olmaması
    • Debug, yerel geliştirme ve üretim ortamı arasında geçişte özgürlük
  • Örnek kod:
    docker run -v my-data:/data my-app
  • Sonuç olarak durumlu iş yüklerini her yerde tutarlı biçimde çalıştırabilirsiniz
  • Vendor lock-in yoktur, gizli maliyet yoktur, gereksiz mimari değişiklikler gerekmez

Serverless fiyatlandırması: kullanıcıyı kafa karışıklığına sürüklüyor

  • Serverless maliyetleri çok karmaşık biçimde kurgulanır
    • Çağrı başına ücret
    • Bellek kullanımı
    • Çalışma süresi
    • Aktarılan veri miktarı
    • Bölgeye göre farklı fiyatlandırma
    • Gizli anahtar erişim ücreti gibi kalemler
  • Kafa karıştıran terim örnekleri:
    • Provisioned Concurrency Units
    • GB-seconds
    • Requests Tier 1/2/3
  • Öngörülemez ücretlendirme yapısı nedeniyle beklenmedik faturalar gelebilir
  • Karşılaştırma: 5 dolarlık bir VPS ile öngörülebilir sabit ücret karşılığında tüm kaynaklar üzerinde kontrol sahibi olabilirsiniz

“Serverless ölçeklenebilir” iddiasına itiraz

  • Serverless teknik olarak ölçeklenebilir olsa da çoğu uygulamanın buna ihtiyacı yoktur
  • Çoğu uygulamanın gerçekten ihtiyaç duyduğu şeyler şunlardır
    • Öngörülebilirlik
    • İzlenebilirlik
    • Uygun kaynak sınırları
    • Geliştirme ve staging ortamları
  • Konteyner tabanlı yapıda ölçeklemek de basittir
    replicas: 5
  • Ya da bir load balancer ile yatay ölçekleme yapılabilir

Stateless tasarım yapay sorunlar üretir

  • Serverless, zorunlu olarak stateless tasarımı dayatır
    • Cache, session, geçici dosya ve kalıcı bağlantı kullanılamaz
  • Sonuç olarak şunlara ihtiyaç duyulur
    • Harici veritabanı
    • Dağıtık cache
    • Dosya depolama
    • Event bus
    • State machine
  • Sonunda “basit” bir serverless uygulaması 6’dan fazla SaaS bağımlılığına sahip olur
  • Buna karşılık konteynerlerde şunlar mümkündür
    • Bellek içi cache
    • Diske yazma
    • Session koruma
    • Sınırsız çalışma

“Sunucu yönetmek istemiyorum” itirazına yanıt

  • Sunucu yönetmeden konteyner tabanlı platform kullanmanın yolları vardır
    • Sliplane, Railway, Coolify gibi platformları kullanmak
    • Ya da sadece bir VPS üzerinde Docker + systemd ile ilerlemek
  • Git tabanlı dağıtım, rollback, loglama, metrikler gibi operasyonel kolaylıklar sağlanır
  • Tüm sistem üzerinde anlama ve kontrol sahibi olabilirsiniz

“Serverless daha ucuzdur” iddiasına itiraz

  • Son derece düşük çağrı sıklığında daha ucuz olabilir
  • Ancak şu durumlarda maliyet hızla artar
    • Trafik belli bir seviyeyi geçtiğinde
    • Daha fazla belleğe ihtiyaç olduğunda
    • Gerçek işlem yükü yüksek olduğunda
    • Veri aktarımı fazla olduğunda
  • Serverless’ta platform her şeyi gizlediği için optimizasyon zordur
  • Buna karşılık konteynerler
    • Ucuz donanımda bile sürekli çalışabilir
    • Cache ve depolamayla birleştirilebilir
    • Benchmark ve tuning yapmak kolaydır
    • Milisaniye bazlı ücretlendirme yoktur

Serverless’ın gerçekten uygun olduğu durumlar

  • Şu tür aralıklı ve durumsuz işler için uygundur
    • Event tabanlı fonksiyonlar (ör. görsel yeniden boyutlandırma)
    • Nadiren çalışan işler veya webhook’lar
    • İç araçlar
    • POC
    • Hızlı scale up/down gereken durumlar
  • Ancak gerçek uygulamalarda sınırlara çabuk ulaşılır ve
    • zaman, maliyet ve karmaşıklık açısından büyük bedeller ödenir

Neden daha iyi seçenek konteynerlerdir

  • Konteynerler şunları sunar
    • Taşınabilirlik
    • Kontrol
    • Basitlik
    • Şeffaflık
    • Esneklik
  • Tekli veya çoklu konteyner dağıtımı, ölçekleme, durum koruma, arka plan işleri ve veritabanı entegrasyonunun tamamı mümkündür
  • Kodu yeniden yazmadan platform değiştirmek de mümkündür

Özet (TL;DR)

  • Serverless teoride havalı görünür
  • Gerçekte ise:
    • Opaktır
    • Pahalıdır
    • Aşırı karmaşıktır
    • Abartılmıştır
      > Başlamadan önce kendinize şunu sorun:
      > “Bunu sadece bir konteyner olarak kuramaz mıyım?”
  • Cevap ‘evet’ ise, konteynerle başlamak daha iyi bir seçimdir

Sonraki adım önerisi

  • Serverless yüzünden yaşanan beklenmedik maliyetler ve verimsiz iş akışları örneklerinin paylaşılması önerilir
  • Basit bir problemi gereğinden fazla karmaşık hale getirmeyin

19 yorum

 
nullvana 2025-04-27

xfaas var... cf workers da var. Biraz taraflı bir yazı gibi görünüyor.

 
softer 2025-04-26

GPU kiralarken serverless function ile kısa süreli çalıştırmayı düşünüyordum.
Bu, container’da da mümkün mü?

 
nemorize 2025-04-25

Geçmişteki PHP web hosting hizmetlerinde PHP’yi çıkarıp yerine bolca vendor lock-in içeren JS koyunca....
önde gelen serverless FaaS platformlarından ayırt etmenin zor olacağı hissinden kurtulamıyorum.

Elbette ben, ağırlıklı olarak PHP ve JS/TS kullanan bir bok1melier olarak, bunu memnuniyetle kullanıyorum,
ama buna rağmen neden bu kadar çok insanın bunu lezzetli bulduğunu değerlendirdiğini pek anlayamıyorum.

 
elbanic 2025-04-24

Bana göre vendor’un serverless hizmetlerini kullanmak riskli, ancak container’ları kullanarak şirketin kendi içinde serverless ortamı sunması iyi bir fikir gibi görünüyor. Serverless’ı bir hizmetten ziyade bir kavram olarak kullanmak iyi olabilir.

 
pedogunu 2025-04-23

Bir süre önce vercel'in Edge rendering'den vazgeçtiğini anlatan tweet ve video[1] ile serverless server (haha)[2] hakkındaki yazı epey gündem olmuştu. O zaman çıkan yazılarla benzer bir görüşe sahip olduğumu düşünüyorum.

Kişisel görüşüm ama frontend geliştiricisi açısından bakınca, kullanıcı isteklerine serverless function bağlamak hâlâ erken gibi geliyor (tabii yapmaya çalıştığınız uygulama bir MVP değilse).

[1] https://youtu.be/lAGE-k1Zfrg
[2] https://vercel.com/blog/…
[2-1] https://bobaekang.com/blog/…

 
pedogunu 2025-04-23

Tabii, bu yazıda da belirtildiği gibi biraz fazla dikkat çekmek için yazılmış bir metin gibi görünüyor :(

 
unknowncyder 2025-04-23

Hem konteyner tabanlı ortamlarda (ECS Fargate ağırlıklı, Kubernetes cluster'ları) hem de serverless ortamlarda (AWS) deneyim sahibi biri olarak bana çok da isabetli gelmiyor.

Konteyner tabanlı ortamların avantajı olarak sıralanan maddeler, aynı zamanda dezavantaj da olabilecek noktalar.

Doğrudan kontrol edilebilir ve state tutabilir diye bahsedilen kısımların tamamı birer yönetim noktası hâline geliyor ve operasyon zorluğunu artırıyor denebilir.

Bence küçük ölçekli organizasyonlarda, özellikle de profesyonel bir sunucu yönetim ekibi olmayan yapılarda serverless'ı güçlü biçimde tavsiye ederim.

Ha, maliyet hesaplamasının karmaşık ya da öngörmesinin zor olması ve vendor lock-in sorunu konularına ise katılıyorum.

 
unknowncyder 2025-04-23

Geliştirici deneyimi ve gözlemlenebilirlikten bahsedenler olduğu için eklemek gerekirse,

Başlangıç entegrasyon ortamı iyi kurgulanırsa, konteyner tabanlı yaklaşımdan geri kalmayan, hatta belki konteyner tabanlı yaklaşımdan daha native’e yakın bir geliştirici deneyimi de elde edilebilir. (Bunun için çeşitli araçlar da var.)

Gözlemlenebilirlik ise, işi derinlemesine yapmak isterseniz, serverless olsun konteyner tabanlı olsun aynı şekilde kolay bir mesele değildir. Logların merkezileştirilmesi, çeşitli metriklerin görselleştirilmesi, APM, CPU/bellek kullanım oranlarının görselleştirilmesi ve buna göre ölçekleme stratejisi oluşturulması gibi şeyler...

O kadar ileri bir aşama değilse, bulut sağlayıcısının varsayılan olarak sunduğu metrik/log entegrasyonu güçlü olduğu için çok da fark etmiyor.

Biraz agresif ifade edecek olursam, “Serverless’ı ne kadar ciddi şekilde gerçekten denediniz?” diye sormak isterim...😅

 
aer0700 2025-04-23

Yalnızca gerekli bazı endpoint’leri Lambda’da çalıştırmak daha iyi olmaz mı diye de düşünüyorum. Zaten benim en başta serverless geliştirme deneyimim yok, o yüzden net bir şey söyleyemem ama bazı özel durumlarda iyi olabilirmiş gibi görünüyor.

 
skageektp 2025-04-23

Bu yazıyı yazan şirket bir konteyner barındırma platformu şirketi olduğu için, makaleyi önyargılı bir bakış açısından yazmış olamaz mı? haha

 
preserde 2025-04-23

Daha önce de frontend tarafında nextjs (vercel) hakkında endişelerini dile getiren netlify (rakip şirket) geliştiricisinin yazısından şüphelenenler olmuştu. Yorumlara bakınca taraflı görünmüyor gibi.
Ben frontend tarafındayım... bu alana çok yakın değilim ama "serverless (server var)" memini sık sık gördüğümü söyleyebilirim haha

 
asheswook 2025-04-23

Native'e kıyasla geliştirme deneyiminin belirgin biçimde daha kötü olması çok büyük bir pain point ve yazılımın kendisi de altyapı sağlayıcısına bağımlı hale geldiği için, bir kez yerleşince ondan çıkmak zorlaşıyor. Referansların bariz şekilde daha az olması bir yana, gözlemlenebilirlik de çok düşük.

Cloudflare, en azından diğer şirketlere kıyasla serverless'i daha iyi yapmaya çalışanlardan biri gibi görünüyor. Veritabanı da serverless, key-value storage da serverless, hatta message queue bile serverless var... (Bu arada, işler böyle olunca platforma tamamen bağımlı ve onunla kısıtlanmış hale geliyormuşsunuz gibi hissettirdiği için bir direnç de oluşabiliyor.)

Buna rağmen debugging, gözlemlenebilirlik ve geliştirme deneyimi iyileşmezse, yine de yerinde sayıyor olacaktır.

 
hilft 2025-04-23

cloud run gitsin

 
bbulbum 2025-04-23

Sunucusuz mimariyle hizmet işletmek, yanlış aracı seçmek demektir.
Sunucusuz mimarinin gerekli olduğu belirli problemler vardır. Aralıklı kullanılan işler için uygundur.

 
tolluset 2025-04-23

Serverless container hizmetleri için de aynı fikir geçerli mi acaba?

Mevcut serverless hizmetlerin (lambda gibi) sorunları yüzünden AWS fargate'i yaptı, sonra da daha da basitleştirmek için app runner'ı çıkardı 🤔

Hatta Google Cloud'da, scale to zero yapan müthiş bir serverless container hizmeti olan cloud run da var

Bunların arasında kişisel olarak en iyi geliştirme deneyimini cloud run ile yaşadım

 
ndrgrd 2025-04-23

Serverless (sunucu var)

 
GN⁺ 2025-04-23
Hacker News görüşleri
  • Serverless, başlangıçta küçük projeler için iyiydi, ancak AWS Lambda büyük uygulamalarda tam bir bakım cehennemi (build, bağımlılıklar, debug, yavaş deploy vb.)
    • Buna rağmen, 2019'da deploy edilen Lambda tabanlı bir React web uygulamasının hâlâ hiçbir değişiklik olmadan çalışıyor olması etkileyici
    • Buna karşı çıkanlar da var; bakım sorunlarının sebebi framework olabilir ve modüler tasarım ile yerel geliştirme birlikte kullanılırsa çoğu sorun çözülebilir
    • Lambda, çoğu zaman runtime güncellemeleri gerektirir ve bu da uzun süre sorun çıkarmayıp bir anda kesinti olarak ortaya çıkabilir
    • Bağımlılık azsa güncelleme kolaydır, ancak eski runtime'lara bağımlıysanız önceden hazırlık yapmak önemlidir
  • Serverless, aralıklı ve stateless workload'lar için uygundur ve iç/dış JSON API'lerle iyi uyum sağlar
    • Ancak aşırı duygusal anlatım yerine, serverless'in her derde deva olmadığı daha net anlatılsaydı daha iyi olurdu diyenler de var
    • Serverless'in kendi kendini toparlama kabiliyeti iyidir ve container gibi stateful sistemlere kıyasla operasyon yükü daha düşüktür
    • Buna rağmen, container'ların geliştirme modelinin daha iyi olduğunu savunanlar da var — her yerde çalışabilirler ama durum yönetimi ve ölçeklenebilirlikte sınırlamalar bulunur
  • Container'lar özünde durumsuzdur; sadece üzerlerine durum eklenebilir
    • Büyük organizasyonlarda sonuçta Kubernetes (K8s) standart hâline gelir ve bu da container'ların sadeliğinden uzaktır
    • K8s de bir platform ekibi varsa basit işletilebilir, ancak böyle bir ortamın nadir olduğu belirtiliyor
  • GCP Cloud Run, yeterince takdir edilmeyen bir serverless platformu; yalnızca kullanım anına göre ücretlendirme yaptığı için ekonomik
  • AWS Lambda'da Postgres bağlantısı ya da bcrypt kullanmak mümkün, ancak kurulum ve çalıştırma süreci çok zahmetli olmuş
    • Sürücüleri elle build etmek gerekiyor ve libc sürüm farklarından kaynaklanan sorunlar çıkıyor
    • Yerel test ortamı da net olmadığı için çok fazla deneme-yanılma yaşanıyor
  • Yazının adeta Sliplane reklamı gibi göründüğünü söyleyenler var
    • "İş mantığını Lambda'ya koymak yerine, onu cloud ortamını programlamak için kullanmak gerekir" diyenler de mevcut
    • Serverless sayesinde küçük ekipler büyük ölçekli servisler işletebilir, ancak karmaşıklık sorunu hâlâ sürüyor
    • Container teknolojisini öğrenen birinin kendi değerini artırmak için herkese container kullanmayı dayatıyor gibi göründüğü yönünde eleştiriler de var
    1. nesil serverless platformlarda (AWS Lambda vb.) ölçeklenebilirlik ve durum yönetimi zorlukları bulunuyor
      1. nesil platformlar container tabanlı serverless yöne evriliyor, ancak container'lara durum eklemek ölçekleme sırasında ciddi sorunlar yaratabilir
    • Örneğin, "Docker volume ekleyerek durumu korumak", ölçeklenebilirlik düşünülmeden verilmiş tehlikeli bir tavsiye olarak görülüyor
    • Yazıda geçen “10 container'a ölçekleme + kendi DB'ni işletme” gibi ifadeler, gerçekçi olmayan veya verimsiz iddialar olarak değerlendiriliyor
  • Bazıları bu yazıyı "adil bir değerlendirme" olarak görse de, başkaları fazla duygusal ya da ticari niyeti ağır basan bir metin olduğunu düşünüyor
 
iolothebard 2025-04-23

Zaten en başından beri Serverless değil, Serverlease idi.

 
kaydash 2025-04-24

lololol