Bir çoğumuz yukarıda geçen layer ların ne anlama geldiğini biliyoruz.
Zamanla bu katmanların maintenance şekli değişebiliyor.
Ve her bir farklılaşma kendine has başka kavramları ortaya çıkarıyor.
IaaS
PaaS
SaaS
gibi
developerlar veya şirketler proje ihtiyaçları doğrultusunda bu modellerden birini veya birkaçını seçerek implementasyon yapıyor
Uygun model ile sadece üretmek istedikleri işin detaylarına odaklanmış oluyorlar.
Bazı katmanların yönetimini başka vendorlara,şirketlere,platformlara ya da yazılımlara bırakarak
ve zamansal kısıtları lehine çevirecek şekilde üretim yaparak yazılım geliştirme process lerini daha verimli hale getirebiliyorlar.
Nedir bu kavramlar ve bu kavramlar arasında serverless nereye oturmaktadır.
Şekilde de gördüğünüz üzere serverless kavramı PaaS ile SaaS arasında bir yere oturmaktadır.
Geliştirilen ürünün frontend client managementı size kalmakta ancak backend management ı paylaşılmış durumda.
Bu ne demek?
IaaS de ya da PaaS de olduğu gibi bazı katmanların yönetimini vendorlara bırakarak çalıştığımız durumlarda yazılım geliştirme süreci nasıl olmaktadır? Düşünelim????
İlgili network tasarımını yapıp üzerine makineleri provize ediyoruz. Sonrasında ürettiğiniz yazılımın ihtiyacı olan konfigürasyonları tamamlayıp yardımcı yazılımları kuruyoruz.
Yazılımın kullanacağı datanın giriş yöntemini belirliyoruz datayı biryerlerde saklıyoruz ve ordan alıp bu datayı kullanan başka bir yazılıma,platform a ya da data source a işlenmiş şekilde aktarıyoruz.
NOT: Backend yazılımlarından hahsediyoruz şimdilik.
Her ne kadar bu anlattığımız olayların bir çoğunu sanallaştırılmış da olsak, cloud nimetlerinden faydalanıyor da olsak
kurduğumuz makinelerin yönetim sorumluluğunun bir kısmı halen daha bizim elimizde.
Build ve Deployment süreçlerinin bir çok kısmı da bizim yönetimimize bırakılmış durumda.
Ancak Serverless concept inde build ve deployment süreçlerinin daha da hafifletildiğini söylememiz gerekiyor.
Sadece gerekli kodu yazmak ve belli başlı temel configurasyonları tamamlamak yeterli oluyor.
İlgili Cloud çözümü sizin yerinize bu süreçlerin ve kavramların birçoğuna müdahale ediyor ve yönetiyor.
Böylece siz sadece kodunuzu yazıyor ve kendi iş değerinize daha fazla katkı sağlayacak vakti bulabilir hale geliyorsunuz.
Yukarıdaki şemada bu kavramları ve onların karşılığındaki implementasyonları görüyorsunuz
Serverless framework ü bir node projesi.
Temel hedefi bir çok cloud çözümüne ve onların serverless concepti için oluşturdukları altyapıya rahat bir geçiş yapabilmek adına
bütün konfigürasyonları implementasyondan biraz olsun soyutlamak ve kolaylaştırmaktır.
Cloud çözümlerinin yayınladıkları API ler aracılığıyla da bu konsept e geçiş yapılabilir ancak daha da uğraştırıcı bir hal alacaktır bu durum.
Bütün kullanacağınız servislerin API lerini iyi bilip onlara uygun temel kodları yazmak gerekecektir.
API lerin kullandığı iletişim yöntemini ve structure ını iyi bilmek gerekecek ki bu herbir cloud çözümünde çok farklılaşabilmektedir.
Ancak serverless framework ü bu kodları yazmaktan sizi kurtarıyor ve concept e hızlı adapte olmanıza yardımcı oluyor.
Aynı zamanda Cloud çözümleri arasındaki geçişi de kolaylaştırabilir bu proje( ama belirli noktalarda tabiki.)
Nasıl bir yapısı var peki bu framework ün.
Sağ tarafta gördüğünüz serverless.yml dosyasında aslında bazı tanımları yapıp bütün deployment ı framework e bırakıyoruz. ( bu örnekte ne var anlat , dealer locator kodlarını aç)
AWS için konuşursam eğer ki özellikle ondan bahsedeceğim,
kullanmak istediğiniz dili de farklılaştırabilirsiniz. En çok kullanılan dil Javascript ve python ama java c# da destekliyor.. Deployable bir folder oluşturmak gerekiyor. Standalone bir project gibi düşünelim bu folder ı.
Framework deployment komutları ile serverless.yml file ı kullanarak proje dosyasını zipleyip yüklüyor ve ihtiyac duyulan servisleri kaldırıyor.
Bunun için uygun AWS profilini de tanımlamak gerekli
Serverless user ı açmak gerekiyor IAM üzerinden .Belli haklara sahip olan bir user kullanarak bu işi yapıyor framework.
Oluşturduğumuz functiondan ve onun haklarından bağımsız düşünmek gerek. Birisi deployment hakları diğeri ise genelde okuma yazma üzerine haklar.
Bazı detaylara demo da gireceğim için çok üzerinde durmayacağım.
Şimdi en basit hali ile lambda function ların kullanımında yukarıdaki eşitliği aklımızda canlandırabiliriz.
Frontend den bir api gateway call yapılarak arkadaki lambda function ları çağırılabilir ve backend application ları implemente edebiliriz.
Sol taraftaki frontend applicationlarının maintenance ı bize ait ancak backend de AWS bize yardımcı olacak. İlk slaytlardaki layerları hatırlayalım.
Ürününü, web sayfasını vs. tamamen bu sistem üzerine kuran şirketler var. Örnek ?
Ancak Lambda functionların triggerlarını elbette sadece API gateway olarak düşünmemek lazım.
Burada lambda functionları tetikleyebilecek servislerin listesi var. Buradaki servisler den sadece 1 tanesi API Gateway.
Daha farklı servisler de var.
Örneğin s3 ye yüklenen bir image olduğunda function tetiklenip image ı resize edip farklı bir yere taşıyabilir ve bunu asenkron ve yüksek bir concurrency başarısı ile yapıyor.
EC2 ile bu işlemleri yapıyor olsak bu concurrency I biz yönetmek zorunda kalıyoruz. Load yönetimini biz yapmak zorunda kalıyoruz ve bu maliyetleri yükseltiyor.
Pricing karşılaştırmalarını yapan bir çok blog var ama genel olarak lambda daha ucuz. Tabiki function ın execution süresine göre bu ücretler değişiyor.
SQS desteklenmiyor henüz. Orada queue lar arasındaki concurrent execution problemleri olduğu için henüz destek veremediklerini biliyorum.
Ama cloud watch üzerinde alarmlar kurarak custom şekilde sqs kullanmaya çalışan 1-2 plugin var ama tam olarak SQS altyapısına destek vermiyor.
SQS yerine biraz daha gelişmiş bir alt yapı kinesis var.
SQS de hatalı mesajları farklı bir queue ya aktarabilmek gibi otomatik feature lar var iken kinesis de hatalı mesaj saklanıyor. Aynı stream içinde index I kaydırarak hatalı mesajları bulup yeniden execution yapılabiliyor.
Kinesis oldukça fazla miktarda event i üzerinde tutabiliyor 24 saat gibi bir süre. O yüzden SQS yerine kinesis tercihi yapmak gerekebiliyor.
Aslında yapmaya çalıştığınız servisin ya da application ın ihtiyacına göre lambda function bir tercih sebebi olabiliyor ama bazen de tam olarak istediğiniz şeyleri lambda ile yapamıyorsunuz
Maksimum execution time sınırlaması birazcık elinizi kolunuzu bağlayabiliyor. 5 dk içerisinde sonuçlanmayan bir lambda function execution ı var ise bu noktada yapılacak iş kesintiye uğruyor.
Çözüm olarak yapılacak işi küçük parçalara bölerek maksimum concurrent limitleri içerisinde o işleri parça parça hızlandırarak yapmak.
Burada da az önce konuştuğumuz SNS,SQS veya kinesis gibi servisler devreye giriyor.
Deployable tek bir folder oluşturmak bazen problem olabiliyor.Node ve python da bu oldukça kolay ancak diğer dillerde biraz daha zor.
Ayrıca Folder ın size ı noktasında da limitlisiniz. Source code size ınız belli bir limit içerisinde büyütülebiliyor.
Bu limitationların tüm detaylarını kendi dökümantasyonunda bulunmaktadır.
