01Sorun ve çözüm
Serverless mimari bu tür işleri olaylara bağlı küçük fonksiyonlara ayırır. Bir dosya yüklendiğinde, kuyruğa mesaj düştüğünde ya da bir API çağrıldığında ilgili fonksiyon çalışır, iş bitince kaynak bırakılır. Ölçekleme, işletim sistemi yaması ve sunucu bakımı bulut sağlayıcısına geçer. Bizim işimiz hangi parçanın bu modele uyduğunu ayırmak, olay akışını tasarlamak ve sistemi izlenebilir, test edilebilir biçimde kurmaktır.
Devamını okuDaha az göster
Her iş yükü serverless'a uygun değildir. Sürekli ve dengeli yük taşıyan ya da uzun süren hesaplamalar için konteyner veya sanal sunucu daha mantıklı olabilir; bu ayrımı tasarımın başında açıkça yaparız.
02Kimler için
Serverless mimari hangi işler için uygun
Aşağıdaki durumlardan biri sizi tarif ediyorsa serverless mimari değerlendirmeye değer.
- Trafiği gün ve saate göre çok dalgalanan API ve web uygulamaları
- Yüklenen görselleri, PDF'leri ya da Excel dosyalarını işleyip başka bir sisteme aktaran iş akışları
- Sunucuda cron ile çalışan ve o sunucu kapanınca unutulan zamanlanmış görevleri olan şirketler
- Pazaryeri, ödeme ya da kargo sağlayıcılarından gelen webhook çağrılarını karşılaması gereken e-ticaret altyapıları
- Sunucu yönetecek ekibi olmayan, ürüne odaklanmak isteyen girişimler
- Monolit uygulamasından belirli işlevleri adım adım ayırmak isteyen yazılım ekipleri
03İhtiyaçlar
Serverless'a geçerken dikkat edilmesi gerekenler
Sunucuyu yönetmemek, mimariyi düşünmemek anlamına gelmez; sorunların yeri değişir.
- 01
Soğuk başlangıç gecikmesi
Bir süre çağrılmayan fonksiyonun ilk isteği daha geç yanıtlanır. Kullanıcıya dönük uç noktalarda paket boyutunu küçültmek, çalışma zamanını doğru seçmek ve gerekirse hazır bekleyen kapasite ayırmak bu gecikmeyi azaltır.
- 02
Veritabanı bağlantı patlaması
Yük arttığında yüzlerce fonksiyon kopyası aynı anda veritabanına bağlanmaya çalışır. RDS Proxy gibi bir bağlantı havuzu ya da HTTP tabanlı veri erişimi kullanılmazsa ilişkisel veritabanı ilk yoğunlukta tıkanır.
- 03
Tekrar çalışan olaylar
Kuyruk ve olay servisleri bir mesajı en az bir kez teslim eder; aynı sipariş iki kez işlenebilir. Fonksiyonların aynı girdiyle ikinci kez çalıştığında sonucu değiştirmeyecek biçimde yazılması gerekir.
- 04
Zaman ve boyut sınırları
Fonksiyonların en uzun çalışma süresi, bellek ve istek boyutu sınırları vardır. Uzun işler adımlara bölünüp Step Functions ya da Durable Functions gibi iş akışı servisleriyle yönetilir.
- 05
Dağınık hata ayıklama
Tek bir kullanıcı isteği birkaç fonksiyon, kuyruk ve servisten geçer. Ortak bir istek kimliği ve dağıtık izleme olmadan bir hatanın hangi adımda oluştuğunu bulmak saatler alır.
04Özellikler
Serverless mimari hizmetinin kapsamı
Sıfırdan bir ürün için ya da mevcut bir uygulamanın parçası için çalışabiliriz.
- 01
İş yükü ayrıştırması
Mevcut uygulamanın hangi işlevlerinin olaylara bağlanabileceği, hangilerinin sunucuda ya da konteynerde kalması gerektiği gerekçesiyle belirlenir.
- 02
Olay akışı tasarımı
Kuyruklar, olay yolları, yeniden deneme kuralları ve işlenemeyen mesajların düştüğü ölü mektup kuyrukları şema olarak çıkarılır.
- 03
Altyapının kodla tanımlanması
Fonksiyonlar, izinler ve tetikleyiciler AWS SAM, Serverless Framework, AWS CDK ya da Terraform ile tanımlanır; ortamlar aynı koddan üretilir.
- 04
Test ve dağıtım hattı
Birim testleri, yerel emülatör ve her ortam için ayrı dağıtım adımları kurulur; yeni sürüm trafiğin küçük bir kısmıyla denenip sonra yaygınlaştırılabilir.
- 05
Maliyet ve kullanım görünürlüğü
Çağrı sayısı, çalışma süresi ve bellek kullanımı fonksiyon bazında izlenir; beklenmedik artışlar için bütçe uyarıları tanımlanır.
05Entegrasyonlar
Serverless mimaride kullanılan servisler
Sağlayıcı seçimi mevcut altyapınıza, ekibinizin deneyimine ve bölge gereksinimlerine göre yapılır.
- 01
Fonksiyon platformları
AWS Lambda, Azure Functions, Google Cloud Run functions ya da konteyner tabanlı Cloud Run; çalışma zamanı olarak Node.js, Python, Go, Java veya .NET seçilebilir.
- 02
API katmanı
Amazon API Gateway, Azure API Management veya bir CDN'in uç fonksiyonları kimlik doğrulama, istek sınırlama ve sürümleme için kullanılır.
- 03
Kuyruk ve olay servisleri
Amazon SQS, SNS ve EventBridge; Azure Service Bus ve Event Grid; Google Pub/Sub gibi servisler fonksiyonları birbirinden bağımsız hâle getirir.
- 04
Veri depolama
DynamoDB, Cosmos DB, Firestore gibi sunucusuz veritabanları ya da bağlantı havuzuyla erişilen ilişkisel veritabanları, nesne depolama ile birlikte kullanılır.
- 05
Dış servisler
Ödeme altyapısı, kargo firması, ön muhasebe programı ya da SMS sağlayıcınızdan gelen webhook'lar doğrudan bir fonksiyona bağlanır; gelen istek doğrulanıp kuyruğa alınır.
06Süreç
Serverless mimari hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Sağlayıcı bağımlılığı, güvenlik ve izlenebilirlik
Serverless mimari, bulut sağlayıcısının servislerine daha sıkı bağlanmak demektir. Bu bağımlılığı tamamen ortadan kaldırmak yerine yönetilebilir tutmayı öneririz: iş mantığını sağlayıcıdan bağımsız modüllerde yazar, tetikleyici ve servis çağrılarını ince bir katmanda toplarız. Gerektiğinde bir fonksiyonu konteynere taşımak bu yapıda daha az iş çıkarır.
Devamını okuDaha az göster
Her fonksiyon yalnızca ihtiyaç duyduğu kaynağa erişebilen ayrı bir rolle çalışır. Gizli anahtarlar kodda ya da ortam değişkeninde düz metin olarak değil, Secrets Manager veya Key Vault gibi bir kasada tutulur. Kişisel veri işleyen akışlarda verinin hangi bölgede saklandığı ve işlendiği KVKK açısından baştan belirlenir.
İzlenebilirlik için yapılandırılmış loglar, istek kimliği taşıyan dağıtık izleme ve hata oranı, süre ve kısıtlanma için alarmlar kurulumun parçasıdır. Sunucu olmadığında sorun aranacak tek yer bu kayıtlardır.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Bakım ve destek
Aylık sözleşmeli, SLA'lı bakım, destek ve geliştirme saati
Yayındaki bir sistemin sürekliliği için.
- Aylık sözleşme ve SLA
- İzleme, güncelleme ve hata düzeltme
- Aylık geliştirme saati
- 03
Danışmanlık
Saatlik veya günlük teknik danışmanlık
Karar, denetim veya yön belirleme gereken durumlar için.
- Saatlik veya günlük çalışma
- Yazılı rapor ve öneriler
- Ekibinizle birlikte çalışma
09Sık sorulan sorular
Serverless mimari hakkında sık sorulan sorular
Serverless mimari fiyatları nasıl oluşur?
Proje bedelini fonksiyon ve entegrasyon sayısı, mevcut bir uygulamadan ayrıştırma yapılıp yapılmayacağı, test ve dağıtım hattı ihtiyacı ve kurulum sonrası destek belirler. Bulut faturası ise ayrıdır ve çağrı sayısı, çalışma süresi ve bellek kullanımına göre değişir; tasarım aşamasında beklenen kullanımla bir tahmin çıkarırız.
Serverless her zaman daha mı ucuzdur?
Hayır. Düşük ya da dalgalı yükte genellikle avantajlıdır; gün boyu yüksek ve sabit yük altında aynı işi bir konteyner ya da sanal sunucu daha düşük maliyetle yapabilir. Kararı beklenen kullanım üzerinden hesaplayarak veririz.
Mevcut uygulamamızı tamamen serverless'a taşımamız gerekir mi?
Gerekmez. Çoğu durumda dosya işleme, bildirim gönderme ya da zamanlanmış raporlar gibi ayrık işlevleri ayırmakla başlamak daha güvenlidir. Ana uygulama yerinde kalır, yeni parçalar ona olaylarla bağlanır.
Lambda veya Azure Functions arasında nasıl seçim yapılır?
Kullandığınız bulut sağlayıcı, kimlik altyapınız ve ekibinizin bildiği diller belirleyicidir. Microsoft ekosisteminde çalışan bir kurum için Azure Functions, AWS üzerinde altyapısı olan bir ekip için Lambda genellikle daha az entegrasyon işi çıkarır.
Fonksiyonları yerelde test edebilir miyiz?
Evet. AWS SAM, Azure Functions Core Tools veya Google'ın fonksiyon çerçevesi ile yerelde çalıştırma mümkündür. Bulut servislerine bağımlı akışlar için ayrıca kısa ömürlü test ortamları kurarız.
Bir serverless mimari firmasıyla çalışırken kodun sahibi kim olur?
Kod, altyapı tanımları ve dağıtım hattı sizin hesabınızda ve sizin depo erişiminizde tutulur. Proje sonunda mimari şeması ve işletim belgesiyle birlikte teslim edilir; bakımı ekibiniz ya da destek anlaşmasıyla biz sürdürebiliriz.
10İlgili hizmetler