Bulut altyapısında sunucu yönetimi: Serverless mı, Yönetilen K8s mi, yoksa IaaS mı?

13 Eki 00:43

Serverless’u tercih ederken, kanka, özellikle **event‑driven ve kısa ömürlü iş yükleri** için en iyi performansı alıyorsunuz. Valla, AWS Lambda’da bir invokasyonun ortalama 50 ms, “cold start” ise 200‑400 ms civarında oluyor; bu, milisaniye seviyesindeki gecikmenin kritik olmadığı bir API ya da arka plan işlerinde sorun yaratmaz. Ayrıca, otomatik ölçekleme ve sadece kullandığınız compute için ödeme modeli, trafiğin ani patlamalar yaşadığı SaaS micro‑service’lerde maliyetleri ciddi şekilde düşürür. Tek eksikliği, **runtime ve paket kısıtlamaları** (örneğin Lambda’da 15 dk limit, max 10 GB bellek) ve düşük seviyeli ağ/CPU ayarlarının yapılamaması; bu yüzden veri‑ağır batch job’lar ya da özel kernel modülleri gerektiren uygulamalarda serverless pek işe yaramaz. Yönetilen Kubernetes (EKS, GKE, AKS) ise **esneklik ve kontrol** isteyen, ama altyapı sorumluluğunu tamamen devretmek istemeyen takımlar için gold standard. Öğrenme eğrisi zorlayıcı, ama bir kez CI/CD pipeline’ı kurup Helm chart’larıyla release’ları otomatikleştirince, aynı ortamı prod‑dev‑test arasında tutmak çok kolaylaşıyor. Ölçekleme açısından, node‑pool bazlı autoscaling (örneğin GKE‑Autopilot’da %70 CPU eşiklerinde yeni node ekleme) sayesinde serverless’a göre **daha düşük latency** ve **daha uzun yaşam süresi** olan servisleri rahatça çalıştırabilirsiniz. Maliyeti ise “pay‑as‑you‑go” + “node‑hour” kombinasyonu olduğu için, düşük trafik dönemlerinde spot‑instance ya da preemptible VM’lerle %60‑70 tasarruf sağlamak mümkün. Klasik IaaS ise **tam kontrol ve özelleştirme** gerektiren senaryolarda hâlâ kral. Örneğin, yüksek performanslı veri tabanı (PostgreSQL‑Citus, Redis‑Cluster) ya da GPU‑intensive ML modelleri çalıştırıyorsanız, VM üzerinde çekirdek, bellek ve ağ ayarlarını (NUMA, hugepages, SR‑IOV) doğrudan yapmanız gerekir. Burada maliyet yönetimi kritik: auto‑scaling grup ve scheduled scaling politikalarıyla gece‑gündüz farkı yaratabilirsiniz; bir örnek olarak, Azure VM Scale Set’te “low‑priority” VM’leri %30‑40 daha ucuz bulup, batch işlerini onlara yönlendirmek büyük tasarruf sağlar. Özetle, **kısa ve sıkı latency gerektiren, düşük maliyetli, yüksek ölçekli micro‑service** için serverless, **konteyner tabanlı, orta‑uzun ömürlü servisler, CI/CD ve multi‑tenant ortamları** için yönetilen K8s, **özelleştirilmiş OS, GPU, yüksek performanslı I/O** gibi ihtiyaçlar için IaaS’ı tercih ederim. Bu üçlüyi karışık bir stack olarak da kullanabilirsiniz; örneğin API gateway’de Lambda, veri işleme pipeline’ında K8s, ve veri tabanı katmanında VM’ler. Böylece her parçanın en uygun maliyet‑performans profilinden faydalanırsınız.

13 Eki 01:00

When I’m wiring up a new microservice, I usually start by asking “how much control do I really need?” If the workload is event‑driven, short‑lived, and I can live with the cold‑start latency, I drop it into a serverless platform (AWS Lambda, Azure Functions, or GCP Cloud Run) – it’s the closest thing to “pay‑as‑you‑go” and you barely touch the OS. For anything that needs steady throughput, custom networking, or a specific runtime that serverless doesn’t expose, I spin up a managed K8s cluster (EKS, GKE, AKS). The learning curve is higher, but the scheduler gives you pod‑level scaling and you still get the convenience of a managed control plane, which feels a lot like the “best of both worlds” compared to running Docker Swarm on raw VMs. When the app demands full OS control, GPU drivers, or legacy binaries that can’t be containerised, I fall back to IaaS – plain VMs on EC2 or Compute Engine – because there’s no substitute for raw access, even though you now own the patching and scaling chores. In practice I’ve built a hybrid pipeline: CI/CD pushes stateless functions to serverless, stateful services to managed K8s, and the occasional heavyweight batch job to IaaS, which keeps costs in check while giving me the flexibility to pick the right tool for each piece.