Ne zaman bu Serverless?
Serverless ne demek ve ne gibi faydalar sağlar sorularına önceki yazılarımda cevap vermeye çalıştım. En az diğer sorular kadar önemli bir soru da, ne zaman Serverless ortamları kullanmalı, ne zaman kullanmamalı?
Bu kadar çok yazılım dilinin, geliştirme ortamının ve bunları destekleyici aracın bulunduğu ortamda önemli olan, işimizi kolaylaştıracak, hızımızı arttıracak ve bunları sadece kısa vadede değil uzun vadede de yarara dönüştürecek ortamları seçmek.
Serverless ortamlar bazı limitlerden dolayı aşağıda belirteceğim tipteki uygulamaları geliştirmek için uygun değil. Yine ortamın getirdiği bazı avantajlardan dolayı belli tip uygulamalar için ise adeta biçilmiş bir kaftan.
Ne zaman kullanmamalısınız?
İstemciye çok hızlı cevap dönmeniz gerekiyorsa
Serverless ortamlarda container reuse diye bir kavram var. Bu kavram çok kısaca her istekte yeni container yaratmak yerine boşta container varsa onu kullanmak demek. Tabi bunların hiçbirinden haberiniz yok, arka planda halledilen şeyler. Yeni bir event geldiği zaman arka planda yeni bir container oluşturulması ve özellikle JAVA dili kullanıyorsanız class-loading kaynaklı bir gecikme yaşanmakta. Bu gecikme sizin fonksiyonunuzun paket büyüklüğüne ve yaptığınız işlere göre değişiklik gösteriyor. Ancak özellikle hızlı cevap dönmeniz gereken bir durum söz konusu ve cevap dönme süresi için bir SLA (Service Level Agreement — Hizmet Düzeyi Sözleşmesi) sunacaksanız Serverless başınızı ağrıtabilir.
Ek olarak, başlangıçta oluşan gecikme dışında RAM artırdığınızda CPU da arttığı için fonksiyonunuz daha hızlı çalışmasına rağmen, klasik sunuculardan aldığınız performansı bu ortamlardan beklemek çok gerçekçi değil.
Uzun süren işlemler yapıyorsanız
Serverless ortamlar event-driven servisler ve fonksiyonların çalışabilecekleri sürenin bir sınırı var. Örnek olarak AWS Lambda servisinde, sağlayıcı bazlı olarak değişse de, 5 dakika içerisinde işini bitirmek zorunda. Eğer fonksiyon 5 dakika sonra halen çalışmaya devam ediyorsa, AWS tarafından anında durduruluyor.
Klasik anlamda düşünürsek bir web sunucu açıp istekleri dinlemek veya bir queue’yu poll etmek gibi bir durum Serverless için çok anlamlı değil. Kısaca, eğer bir event sonucu çalışan fonksiyonunuz 5 dk gibi bir süreyi geçiyorsa Serverless size uygun değil demektir.
Bulut servis sağlayıcınıza bağlı kalmak istemiyorsanız
Eğer Serverless bir servis kullanacaksanız, servis sağlayıcılardan birini seçmeli ve onunla devam etmelisiniz. “Ben istediğim zaman değiştiririm” diye bir şey çok çok zor. Özellikle bu tarz servisler, bulut hizmet sağlayıcınızın diğer servisleri ile de çok iyi bir şekilde entegre çalıştığı ve onlardan oluşan eventler ile tetiklenebildiği için ister istemez diğer servislere de bulaşmak zorunda kalıyorsunuz.
Kod yazım şekliniz, implement ettiğiniz interfacelerden tutun, kodu deploy etmenize kadar neredeyse her şey sağlayıcıya özel (vendor specific).
Fonksiyonunuzu “idempotent” yapamıyorsanız
Türkçesini bulamadığım için “idempotent” demek zorunda kaldım. Kısaca AWS Lambda, fonksiyonunuzu siz bir kere çağırsanız bile, birden fazla çalıştırmaya çalışabilir. Fonksiyonunuz aynı veri ile birden fazla kere çağrıldığı zaman etkilenmeyecek şekilde yazılmalı. Aksi takdirde neden alıyorum durduk yere bu hataları diye düşünüp durursunuz. İlk elden bu durumu tecrübe etmiş bulunuyoruz ve bu sık sık başınıza gelebilir. Dökümanlarında da en az bir kere çağrılma garantisi verdiklerini belirtiyorlar.
Belli sayıda açık bağlantı tutmanız gereken servisler (ilişkisel veritabanı gibi) kullanıyorsanız
Aslında buna kullanma demek doğru olmaz ancak bağlantı havuzu tutmadığımız, HTTP üzerinden haberleştiğimiz DynamoDB tarzı NoSQL veritabanları kullanmak Serverless ortamlara çok daha uygun. Aksi halde stateful bir bağlantı kuruyoruz, bu bağlantıları kurmak vakit alıyor ve daha da önemlisi çok sayıda bağlantı veritabanı üzerinde yük oluşturuyor. İlla kullanacak isek bu yazının kapsamı dışında olan container reuse denilen kavram ile bu soruna tam olması bile çözüm bulabiliyoruz.
Ne zaman kullanmalısınız?
Operasyonel işlerde tecrübeniz az ve hızlı ürün çıkartmak istiyorsanız
Bu konuya bir başlık ayırdım ancak kesinlikle en önemli başlık bu. Hatta Serverless’ın kullanım durumuna bağlı olarak değişebilen ücretlendirme avantajını saymaksak, tüm olayı bu diyebiliriz :) Söylerken basit gelebilir ancak tüm o ölçekleme, loglama, deploy etme, sunucuyu hazırlama, gerekli ayarlamaları yapma gibi birçok işlem artık bizim işimiz değil ve bu büyük bir artı.
Hiç de kolay olmayan bu işleri yapan insanlar oldukça iyi ücretler kazanıyor doğal olarak. Serverless ortamlarda bu işler çok minimal. Birçok geliştirici uygulamayı hızlı bir şekilde geliştirip deneyebilir. Sonuç olarak şirketler daha hızlı ve daha ucuza yeni şeyler deneyebilir.
Bulut servis sağlayıcınızın diğer servislerinden gelen eventlerle bir işlem yapacaksanız
Serverless ortamların en önemli avantajlarından biri de servis sağlayıcınızın diğer servisleri entegre şekilde çalışabilmesi. Örneğin AWS için konuşursak şuan için 17 civarı trigger bulunuyor ve bunların çoğu S3 gibi çok kullanılan AWS’in diğer servisleri. Serverless denince verilen ilk örneklerden birini düşünürsek; S3'e bir resim yükledik ve bu resmi farklı boyutlarda kaydetmek istiyoruz. Bunu yapmanın en kolay yolu Serverless çünkü S3 trigger’ı ile yeni bir resim geldiğinde bir fonksiyon çalıştırılabiliyor.
Uygulamanız aralıklı-nadiren çalışıyorsa
Diyelim ki uygulamanız sürekli ayakta durmak zorunda ve gün içinde ne zaman çağrılacağı belli değil. Belli aralıkla yüksek sayıda kullanıcı geliyor ve çoğu zaman çok az istek alıyorsunuz. Bu tarz durumlarda otomatik ölçekleme için gerekli ortamı kursanız bile (ki bu ortamı hazırlamak da başlı başına bir iş), bu ücret olarak size pahalıya patlayacaktır. Yeni bir instance ekleyip çıkardığınızda, saatlik ücret ödersiniz ve çoğu zaman sıkıntı yaşamamak için gerektiğinden fazla kaynak ayırırsınız. Serverless ortamlarda böyle bir sorununuz yok çünkü ölçekleme, servis sağlayıcının sorumluluğunda ve siz fonksiyonunuzun çalıştığı her 100 ms. için para ödersiniz.
Micro-Nano servis bazlı uygulamalarınız varsa
Hali hazırda mikro servis bazlı bir mimariniz varsa veya bu tarz bir ortama geçmek istiyorsanız Serverless bunun için oldukça uygun. Herhangi bir “en iyi yol” önerisi olmasa bile fonksiyonlarınızın birbirini çağırması işi oldukça kolay. Bunun için AWS için konuşursak (AWS Lambda kullandığım için genelde bu servisten örnek veriyorum :)), fonksiyonlarınızı AWS Lambda SDK ile veya önlerine API Gateway gibi bir servis koyarak HTTP istekleri ile çağırabilirsiniz. Bunlar birer örnek, bunun için başka yollar da var elbet. Dikkat etmemiz gereken, API Gateway gibi servisler ucuz servisler değil. Eğer çok istek yapıyorsanız, hesabınızı önceden yapmanızda fayda var. Bunlara ek olarak doğası gereği fonksiyonlarınız genelde bir işi yapar ve diğer fonksiyonlar ile konuşur.
Serverless nedir, neden ve ne zaman sorularını elimden geldiğince cevaplamaya çalıştım. Eğer sizin de aklınıza başka kullanım alanları geliyorsa yorumda yazmanız güzel olur :)
Bir sonraki yazımda AWS üzerinde Serverless mimari örnekleri vereceğim. Mimari örneklerin bu üç yazıyı pekiştirici özellikte olacağını düşünüyorum.
Serinin önceki yazıları;
