Awesome Cloud Emulators, AWS, Azure, GCP ve dahası için yerel test araçlarını derliyor

Paylaşılan cloud hesaplarına karşı özenli bir yanıt

Awesome Cloud Emulators adlı yeni bir açık kaynak proje, cloud servisleri için yerel emülatörleri ve destekleyici araçları topluyor; böylece geliştiriciler cloud'a bağımlı kodlarını paylaşılan bir cloud hesabı üzerinden değil, kendi makinelerinde çalıştırabiliyor. Liste 2 Ekim 2026'da dev.to'da yayımlanan bir yazıyla tanıtıldı; yazarı, listeyi nelerin mevcut olduğunu keşfetmenin, her aracın gerçekte neyi kapsadığını görmenin ve eldeki işe uygun aracı seçmenin bir yolu olarak sunuyor.

Hedeflediği sürtünme

Tanıtım yazısı birçok ekibin tanıdığı bir senaryoyla açılıyor: bir mühendis bir değişikliği doğrulamak için cloud hesabına ihtiyaç duyarken meslektaşı zaten hesabı kullanıyor; biri paylaşılan bir kaynağı düzenliyor, bir test bozuluyor ve öğleden sonranın tamamı hatanın koddan mı yoksa ortamdan mı kaynaklandığını anlamaya harcanıyor. Çalıştırmalar arasında sağlanmiş durumda bırakılan kaynaklar da faturayı sürekli büyütüyor.

Yazıya göre emülatörler bunu, seçili cloud servis API'lerini yerel olarak yeniden üreterek hafifletiyor. Araca bağlı olarak biri container olarak, bağımsız bir server olarak ya da testlerin içinde in-process bir bağımlılık olarak çalışıyor; böylece her geliştiriciye veya CI işine kendi durumuna sahip izole bir ortam sağlıyor. Bir maliyet tarafı da var — daha az tekrarlanan provisioning, daha az boşta bekleyen kaynak, daha az faturalandırılan servis çağrısı — ancak yazar, tasarrufun iş yüküne bağlı olduğunu, çünkü yerel işlem gücünün, bakımın ve yazılım lisanslarının bedava olmadığını hatırlatıyor.

Liste neler içeriyor

Kapsam AWS, Microsoft Azure, Google Cloud ve Firebase, Oracle Cloud, Cloudflare, Snowflake, çoklu sağlayıcı araçları ve Avrupa cloud sağlayıcılarını kapsıyor; daha gençek paketler tek servis emülatörlerinden ayrı tutuluyor. Temsili girdiler şunlar:

• AWS API mocking için Moto, SQS uyumlu mesajlaşma için ElasticMQ ve S3 işlemlerinin bir alt kümesi için S3Mock
• Yerel Azure storage için Azurite, ayrıca istemci testi için bir Azure Key Vault emülatörü
• Google Cloud ve Firebase için Firebase Local Emulator Suite, Fake GCS Server ve Spanner Emulator
• Cloudflare Workers'ı ve desteklediği storage binding'lerini simüle eden Miniflare
• Scaleway, Outscale ve Exoscale gibi Avrupa sağlayıcılarının API'lerini emüle eden Feint

Her girdi upstream dokümantasyona bağlanıyor; depoya ayrıca yaygın senaryolara göre kısa listeler içeren bir seçim rehberi, girdiler arası bir karşılaştırma ve bir değerlendirme kontrol listesi eklenmiş.

Destekleyici araçlar

Tek başına bir emülatör bir workflow oluşturmuyor — yine de başlatılması, uygulamaya bağlanması, veriyle doldurulması ve kapatılması gerekiyor. Depo ayrıca yardımcı araçları da katalogluyor: emülatör container'larını testlerden yönetmek için Testcontainers entegrasyonları; fonksiyonları yerel olarak çalıştırmak için AWS SAM CLI, Azure Functions Core Tools ve Serverless Devs; uygulama ile emülatör arasına gecikme ve bağlantı kopması eklemek için Toxiproxy; istekleri kaydederek test tabanını yeniden oluştururken tekrar oynatılabilmesini sağlayan Moto Recorder; ve anlık görüntü-geri yükleme deneyleri için CRIU, DMTCP ve container checkpoint araçları.

Yazı bu rollerin farklı olduğunu vurguluyor: yerel bir fonksiyon çalıştırıcısı, bir fonksiyonun çağırdığı servisleri emüle etmez ve kaydedilmiş istekleri tekrar oynatmak, bir sürecin belleğini geri yüklemekle aynı şey değildir.

Nasıl seçilir ve emülasyon nerede biter

Önerilen ilk adım, doğrulanması gereken workflow'u yazıya dökmek — örneğin bir uygulama bir nesne yazıyor, bir mesaj yayınlıyor ve bir worker onu tüketiyor — sonra bir emülatörün şu noktaları karşılayıp karşılamadığına bakmak: bu API işlemlerinin tamamını desteklemek, kullanılan SDK veya IaC sağlayıcı sürümüyle çalışmak, test başına izole durum sağlamak, kurulum, sıfırlama ve teardown desteklemek ve hata yollarını da çalıştırabilmek.

İki uyarı öne çıkıyor. Infrastructure-as-code tarafında, bir kaynak tanımını kabul etmek, ortaya çıkan iş yükünü çalıştırmakla aynı şey değil; bir simülasyon bir oluşturma isteğini onaylayabilir ama kullanılabilir bir VM, veritabanı veya ağ ayağa kaldırmayabilir. Ve yerelde geçmek ne tam servis eşliğinin ne de üretim davranışının kanıtıdır: kimlik ve izinler, ağ yapısı, kotalar, tutarlılık ve yönetilen servis davranışı farklılık gösterebilir. Yazarın konumu şu: yerel test daha hızlı bir geri bildirim döngüsü sağlar; uygulamanın bağlı olduğu garantiler ise hâlâ kontrollü bir cloud ortamında hedefli testler gerektirir.

Lisanslama ve katkılar

Her bölümde açık kaynak araçlar önce listeleniyor; diğer dağıtımlar ve ticari ürünlerden önce. Ticari girdiler karşılaştırma amaçlı bulunuyor, destek anlamına gelmiyor. Liste ücretli ticari koşulları sağlayıcıya özgü şartlardan ayırıyor; yazar yine de upstream lisansların kontrol edilmesini öneriyor. Katkılar issue ve pull request yoluyla davet ediliyor; rehber katkı sağlayanlardan upstream kanıt göstermesini, sınırlamaları belirtmesini ve bağlantılarını açıklamasını istiyor.

Neden önemli

Tek tek servisler için emülatörler yıllardır mevcut ama keşif parçalıydı — çoğu ekip bir ya da iki tanesini, çoğunlukla bir storage emülatörünü biliyor ve orada duruyordu. Awesome Cloud Emulators, büyük ve bölgesel sağlayıcılar arasındaki seçenekleri birleştirerek, her aracın neyi uygulayıp neyi uygulamadığını açıkça belirterek ve bunları yaşam döngüsü ve hata enjeksiyonu araçlarıyla eşleştirerek, geliştirme ve CI döngüsünün bir kısmını paylaşılan hesaplardan ve ölçümlü kaynaklardan uzaklaştırmayı pratik hale getiriyor. En az bunun kadar değerli olanı sınırlara dair dürüstlük: yerel emülasyonu gerçek cloud doğrulamasının yerine değil, onun yanında bir hızlandırıcı olarak görmek, yaklaşımın bir ekibe yardım mı edeceğini yoksa yanlış mı yönlendireceğini belirliyor.