Size bir şey söyleyeyim, Geçen ay İstanbul’da bir startup ekibiyle oturmuştum — kahve içerken aynı cümleyi yine duydum: “Uygulamayı iki haftada çıkarıyoruz ama altyapı üç ay sürüyor.” Açık konuşayım, bu şikâyet bana hiç yabancı değil. Hatta 2024’ün son çeyreğinde kendi test ortamımda benzer bir kurulumu denerken en çok vakit yutan şeyin kod olmadığını fark ettim; çevresindeki o görünmez katmanlar yiyordu zamanımı — Terraform dosyaları, gateway kuralları, secret yönetimi, CI/CD akışı… Hani uygulama yazıyorsun sanıyorsun, asıl iş ondan sonra başlıyor.
İşte TypeScript tabanlı yeni nesil framework’lerin olayı tam burada başlıyor. Sadece API yazıp bırakmıyorlar; altyapıyı da bir tür “ürün” gibi ele alıyorlar. Bu yazıda, TypeScript ile tüm bulut altyapısını üreten açık kaynak yaklaşımını kendi gözümden anlatacağım. Konuyu övmek kolay — ama eksiklerini de konuşacağız. Çünkü kağıt üstünde süper duran şeyler pratikte bazen biraz nazlı çıkıyor (bizzat test ettim). Neyse, uzatmayayım.
Evet, doğru duydunuz.
Neden bu fikir bu kadar dikkat çekiyor?
Bakın şimdi, modern ekiplerin derdi çoğu zaman aynı. Ürün fikri hızlı geliyor. Üretime çıkış hızı ise duvara tosluyor. Küçük bir ekipte bile NestJS backend, Next.js frontend, Docker imajları, veritabanı bağlantıları ve ortam değişkenleri derken günler — bazen haftalar — uçup gidiyor (bizzat test ettim). Orta ölçekli ekiplerde iş daha da karışıyor; güvenlik politikaları devreye giriyor, staging-prod ayrımı büyüyor, observability ayrı bir proje haline geliyor ki bu başlı başına bir yük.
Bu yüzden “Infrastructure as Framework” fikri bence bayağı ilginç. Altyapıyı tek tek el yordamıyla kurmak yerine framework düzeni kuruyor; sen uygulamanın iş mantığına odaklanıyorsun. Biraz lego gibi düşünün: tek tek parça kesmek yerine hazır bloklarla ilerliyorsunuz. Tabii lego örneği güzel, ama burada blokların sağlam olması şart — temeli çürük lego kulesi bilirsiniz, nasıl gider.
Bunu biraz açayım.
Benim 2023’te Berlin’de çalıştığım bir projede tam da bu yaşandı. Uygulama tarafı iki sprintte bitti. Deploy hattı için ise dört ayrı repo arasında mekik dokuduk, haftalarca. O günlerden sonra şunu net gördüm: geliştirici deneyimi sadece kod editöründe başlamıyor, prod’a çıkana kadar sürüyor.
Framework ne yapıyor, neyi size bırakıyor?
tsdevstack benzeri yaklaşımın temel iddiası şu: siz TypeScript ile uygulamayı. Birkaç konfigürasyon dosyasını yazıyorsunuz, sistem geri kalanını üretiyor. Terraform var mı? Var. Docker var mı? Var. API gateway, CI/CD akışı? Onlar da var.
Kendi deneyimimden konuşuyorum, Bana göre burada en kritik fark şu: framework sadece scaffold etmiyor, yaşam döngüsünü de düşünüyor. Lokal geliştirme ortamıyla production arasında uçurum oluşmasın istiyor. Küçük detay gibi görünüyor. Ama aslında büyük mesele tam da bu — çünkü “bende çalıştı” cümlesi prod ortamında pek para etmiyor, deneyimleyen bilir.
Garip gelecek ama, Aşağıdaki tabloyu ilk okuduğumda aklıma direkt eski proje defterlerim geldi. Her satırda ayrı bir acı hatıra var desem yeridir.
| Katman | Klasik yaklaşım | Framework yaklaşımı |
|---|---|---|
| Altyapı | Terraform / manuel modüller | Koddan üretilen standart yapı |
| Lokal geliştirme | Ayrık servisler ve farklı davranışlar | Prod’a yakın birebir akış |
| Gateway | Elde kural yazma | OpenAPI’den otomatik route üretimi |
| Sekret yönetimi | Ekipten ekibe değişen yöntemler | Ortak model ve çevre bazlı kullanım |
| Süreklilik | Pipelines elle bakımla yaşar | Türetilmiş ve standardize edilmiş süreç |
Lokal ortam neden bu kadar önemli?
Lokal geliştirmede production’a yakınlık sağlanınca hata sınıfınız daralıyor. Ciddi fark var. Mesela Kong üzerinden geçen istek akışıyla local’de aynı davranışı görmek büyük rahatlık veriyor — bunu yaşayınca anlıyorsunuz ne demek istediğimi. Bir arkadaşım geçen sene Kadıköy’deki küçük SaaS girişiminde tam bunu yaşadı; local’de sorunsuz görünen auth akışı prod’da patlamıştı,. Gateway tarafındaki header davranışı farklıydı. Küçük bir şey, büyük gece.
Böyle sorunlar genelde gece yarısı çıkar ya… O yüzden lokal/prod eşleşmesi artık lüks değil, ihtiyaç haline geldi.
Kong, Postgres, Redis… hepsi birlikte gelince ne oluyor?
Bence tsdevstack’in dikkat çekici yani sadece TypeScript kullanması değil; çevresindeki parçaları da düşünmesi. Kong API gateway ile route yönetimi geliyor, Postgres. Redis hazır geliyor, BullMQ gibi arka plan işleri için kuyruk mantığı oturuyor. Yani boş bir iskelet değil. Yürüyen bir başlangıç paketi sunuyor — bu fark önemli. ASCII’yi Python ve JavaScript’te Böyle Okuyun: Kolay Rehber yazımızda bu konuya da değinmiştik.
Doğrusu, Burada hoşuma giden şey şu oldu: frontend ve backend’in aynı tip güvenli client kütüphanesini tüketebilmesi. DTO’ların ayrılmış import’larla (söylemesi ayıp) gelmesi kulağa teknik gelebilir ama pratikte çok işe yarıyor — özellikle ekip büyüyünce tip uyuşmazlığı yüzünden çıkan, saç baş yolduran o hatalar azalıyor. Bunu yaşamadan anlatmak zor, yaşayanlar bilir.
“İşin aslı şu ki iyi framework yalnızca hızlı başlatmaz; yanlış mimari alışkanlıklarını da erkenden törpüler.”
Küçük startup için ne ifade ediyor?
Bunu yaşayan biri olarak söyleyeyim, Küçük ekiplerde zaman en pahalı kaynak. İki backend geliştirici. Bir frontend geliştiriciniz varsa herkesin Terraform öğrenmesini beklemek biraz sert kaçabiliyor doğrusu. Siz hiç denediniz mi? Böyle durumlarda otomasyon hayat kurtarıyor — ekip ürünle uğraşıyor, cloud operatörü rolüne soyunmuyor. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Çok konuştum, örnekle göstereyim.
Büyük kurumda durum farklı mı?
Tuhaf ama, E tabi farklı olur. Enterprise tarafta standardizasyon önemli ama kontrol — ki bu tartışılır — de önemli — ağ izolasyonu, WAF kuralları, uyumluluk denetimleri, bölgesel dağıtım gibi konular masaya geliyor kaçınılmaz olarak. Burada framework’ün iyi yani tutarlılık sağlaması; kötü yani ise bazı kurumların özel güvenlik süreçlerine tam oturmaması olabiliyor. Yani körü körüne “bu her yerde çalışır” dememek lazım.
AWS mi Azure mu GCP mi? Aynı kalıp gerçekten yetiyor mu?
Yani, Aynı komut setiyle AWS ECS Fargate’e ya da Azure Container Apps’e geçebilmek kulağa güzel geliyor. Hatta bayağı güzel diyeyim. Ama asıl soru şu: bulut sağlayıcılarının doğası zaten farklıyken ortaklaştırma ne kadar sürdürülebilir? Bu konuda yüzde yüz emin değilim, ama sanırım cevap “çoğu durumda evet” — yeter ki sınırlar net çizilsin. Prime Day İndirimlerinde Akıllı Alışveriş: Kaçırmama Rehberi yazımızda bu konuya da değinmiştik. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Mesele şu ki her cloud’un kendine özgü kıvrımları var. AWS tarafında IAM karmaşıklığı meşhurdur mesela. Azure tarafında isimlendirme ve servis ilişkileri bazen insanı düşündürür. GCP ise sade görünür ama network detaylarında sürpriz yapabilir — genelde en beklenmedik anda.
- Küçük startup için avantaj: hızlı çıkış ve düşük operasyon yükü.
- Küçük startup için risk: fazla soyutlama yüzünden debug zorlaşabilir. (bu kritik)
- Enterprise için avantaj: standardizasyon ve tekrar edilebilir kurulumlar.
- Enterprise için risk: özel ağ/topoloji ihtiyaçlarında esneklik sınırı oluşabilir.
- Migrasyon açısından avantaj: cloud değiştirme baskısı azalır ama tamamen sıfırlanmaz.
Beni ikna eden yerler kadar soğutan yerler de oldu
Şunu fark ettim: Açık konuşayım, bu tarz sistemlerde en büyük tehlike aşırı vaat edilmesi (en azından benim deneyimim böyle). “Bir komutla her şey” cümlesi pazarlamada hoş durur. Gerçek hayatta işler biraz daha kirli akar. Sertifikalar yenilenir, DNS gecikir, gizli değişken unutulur, worker container ayağa kalkar ama queue bağlantısı düşer… Bunlar oluyor. Mutlaka oluyor. Bu konuyla ilgili İran, Hürmüz’de Bitcoin ile Geçiş Ücreti Mi Toplayacak? yazımıza da göz atmanızı tavsiye ederim.
Editör masasında bunu tartışırken hep aynı noktaya geliyoruz: otomasyon harika, ama gözünüz kapalı güveneceğiniz sihir kutusu değil. Hele bir de de özel ağ yapısı olan şirketlerde veya regülasyon baskısı yüksek sektörlerde ince ayar ihtiyacı hiç bitmiyor.
Nerede iyi çalışır?
Bence en iyi kullanım alanı erken aşama SaaS ürünleri, internal tool projeleri ve birkaç servisten oluşan orta ölçekli platformlar. Ayrıca yeni ekip kuran şirketlerde onboarding süresini (söylemesi ayıp) ciddi kısaltabiliyor (en azından benim deneyimim böyle). Geçen yıl Maslak’taki bir danışmanlık ekibinde buna benzer bir otomasyon gördüm; yeni gelen geliştiricinin ilk haftada deploy hattını anlaması normalde zor olurdu, burada ise çok daha çabuk toparladı. Şaşırdım açıkçası.
Nerede tökezleyebilir?
Bir bakıma, garip gelecek ama, Daha karmaşık entegrasyonlara sahip yapılarda — hibrit bulut, çok bölgeli felaket kurtarma ya da sık sık özel compliance gerektiren ortamlar gibi — framework sizi bazen dar koridora sokabiliyor. Rahatlık sağlıyor, tamam. Ama o rahatlığın bedeli olarak bazı kapıları siz açamıyorsunuz. Bu dengeyi görmezden gelmemek lazım.
# Mantığın özeti kabaca böyle düşünülebilir
app:
runtime:
— nestjs
— nextjs
infra:
generate:
— terraform
— docker
— kong_routes
— ci_cd
— secrets
deploy:
target:
— aws
— gcp
— azure
Peki geliştirici deneyimi gerçekten iyileşiyor mu?
Evet, çoğu senaryoda iyileşiyor. İnsan zihni aynı anda hem iş mantığını hem VPC subnet tasarımını taşıyamaz — taşısa bile yorulur, ve yorgun zihin hata üretir. Ben bunu özellikle uzun süre devam eden projelerde fark ettim; ilk ay kimse önemsemiyor, dördüncü ayda herkes pipeline dokümantasyonu aramaya başlıyor. Mantıklı değil mi? Kaçınılmaz.
Neyse, bir şeyi daha ekleyeyim: iyi DX sadece hız demek değil. Hata sayısını azaltmak, aynı işi iki — ki bu tartışılır — kere yapmamak, ekip içinde bilgi kaybını önlemek de DX’in parçası. Eğer framework bunları sağlıyorsa değer üretiyor; sağlamıyorsa sadece parlak paket oluyor. Bu farkı iyi okumak gerekiyor.
Sözün özü biraz sert olabilir… ama gerçekçi
Bence TypeScript ile bulutu tanımlayan framework fikri tesadüfen popüler olmadı. İnsanlar artık yalnızca kod yazmak istemiyor; kodun etrafındaki karmaşayı azaltmak istiyor. Hele mikroservis dünyasında her servis ayrı evren gibi davrandığında standartlaşma altın değerinde oluyor. Bu gerçek.
Ama şunu da dürüstçe söyleyeyim: her şeyi tek çatı altında toplamak bazen bağımlılığı artırıyor (şaşırtıcı ama gerçek). Bugün çok rahat ettiren yapı, yarın sizi belirli bir kalıbın içine kilitleyebiliyor (evet, doğru duydunuz). O yüzden benim tavsiyem basit — küçük başlayın, üretimdeki darboğazları ölçün, sonra genişletin. Kağıt üstünde kusursuz görünen hiçbir araç sahada sorgusuz kabul edilmemeli. Hiçbiri.
Sıkça Sorulan Sorular
TypeScript tabanlı altyapı framework’ü kimler için uygun?
Küçük ekipler startup’lar. Hızlı ürün çıkarmak isteyen mühendislik takımları için çok uygun olabilir. Hele bir de DevOps yükünü azaltmak isteyen ekiplerde ciddi fayda sağlar: Çok karmaşık enterprise yapılarda ise önce pilot deneme yapmak daha mantıklı olur.
Tüm cloud sağlayıcılarında aynı şekilde çalışır mı?
Tam anlamıyla birebir olmaz çünkü AWS Azure ve GCP’nin servis davranışları farklıdır. Ama ortak abstractions sayesinde ana iş yükünü taşımak kolaylaşır: En doğrusu hedef bulutta küçük bir PoC yapmak olur.
Lokal geliştirme ile production neden aynı tutulmalı?
Cünkü farklıysa sürpriz hatalar artar: Gateway davranışı database engine farkları veya secret yönetimi yüzünden prod’da patlayan sorunlar azalmaz aksine çoğalır. Prod’a yakın lokal ortam geliştirmeyi daha güvenilir hale getirir.
Böyle bir framework mevcut Terraform kullanımının yerini tamamen alır mı?
Tamamen alması şart değil: Çoğu durumda Terraform’u sizin yerinize üretir ya da standardize eder: Özel ihtiyaçlarda yine elle müdahale gerekebilir, yani araç size yol gösterir. Bütün direksiyonu sonsuza kadar elinizden almaz.
Kaynaklar ve İleri Okuma
OpenAPI Initiative Resmi Sitesi
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
