Serverless Mimarinin Gizli Maliyeti: Cold Start Problemi

Serverless mimari, sunucu yönetimini sağlayıcıya bırakarak kodu hızlıca üretime çıkarmamızı sağlar. Ancak “yalnızca kullandığın kadar öde” sloganının gölgesinde kalan bir performans maliyeti vardır: soğuk başlangıç. Uzun süre çağrılmayan bir işlev yeniden çalıştırıldığında ortamın hazırlanması gerekir ve kullanıcı, bazen saniyelere ulaşabilen bu gecikmenin faturasını bekleyerek öder.

serverless-mimarinin-gizli-26

Devamı...

Monorepo vs Polyrepo: Google Neden Tüm Kodlarını Aynı Çatı Altında Tutuyor?

Bir şirketin yüzlerce uygulaması, kütüphanesi ve servisi olduğunu düşünün. Bunları ayrı depolara bölmek düzenli görünür; ancak ortak bir kütüphane değiştiğinde işler hızla “hangi servis hangi sürümü kullanıyor?” bulmacasına dönüşebilir. Monorepo yaklaşımı, bütün kodları tek bir kaynak ağacında toplayarak bu problemi farklı bir yerden çözer. Google’ın yaklaşımı bunun en ünlü örneğidir; fakat küçük bir düzeltme yapalım: Google, dev kod tabanı için Git yerine ağırlıklı olarak kendi geliştirdiği Piper altyapısını kullanır.

Devamı...

Log Yönetiminde Yapılandırılmış Loglama: Metinden JSON'a Geçiş

Bir uygulama küçükken Kullanıcı giriş yaptı gibi bir log satırı yeterli görünebilir. Fakat yüzlerce servisin saniyede binlerce olay ürettiği bir sistemde bu cümle, samanlıktaki iğneye dönüşür. Hangi kullanıcı, hangi servis, ne zaman ve kaç milisaniyede giriş yaptı? Yapılandırılmış loglama, bu bilgileri metnin içine saklamak yerine JSON alanları olarak yazar ve logları makinelerin kolayca sorgulayabileceği verilere dönüştürür.

log-yonetiminde-yapilandirilmis-73

Devamı...

Kubernetes'te CRD ve Operator: Kendi K8s Nesnenizi Yaratın

kuberneteste-crd-ve-33

Kubernetes yalnızca Pod, Service veya Deployment yönetmek zorunda değildir. API sunucusuna yeni bir nesne türü tanıtarak veritabanını, mesaj kuyruğunu hatta şirketinize özgü iş yükünü standart bir Kubernetes kaynağı gibi yönetebilirsiniz. Bunun anahtarı Custom Resource Definition (CRD), otomasyon tarafındaki yardımcısı ise Operator desenidir.

Devamı...

Kubernetes StatefulSets: Durumlu Uygulamaları Konteyner Dünyasına Uydurmak

Konteynerler geçici doğalarıyla ünlüdür: kapanır, yeniden oluşturulur ve hiçbir şey olmamış gibi hayatlarına devam ederler. Ancak PostgreSQL, MongoDB veya Kafka gibi sistemler için “hiçbir şey olmamış gibi” davranmak, verilerin gerçekten kaybolduğu anlamına gelebilir. Kubernetes StatefulSet, bu çelişkiyi kararlı ağ kimlikleri, sıralı yönetim ve kalıcı disklerle çözerek durumlu uygulamaları konteyner dünyasına uydurur.

Devamı...

Kırmadan Değiştirmek: Yazılım Mimarilerinde Geriye Dönük Uyumluluk

Bir sistemi geliştirmek kolaydır; onu yıllardır kullanan istemcileri kızdırmadan geliştirmek ise mühendislik sanatıdır. Mobil uygulamalar güncellenmeyebilir, başka ekipler eski SDK’ları kullanabilir ve kuyrukta dünün formatıyla üretilmiş mesajlar bekleyebilir. Geriye dönük uyumluluk, değişimi durdurmak değil, eski ve yeni dünyaların bir süre güvenle birlikte yaşamasını sağlamaktır.

Devamı...

Immutable Infrastructure: Sunucuyu Yamalamak Yerine Baştan Yaratmak

Bir sunucu yıllarca çalıştıkça üzerine yamalar, geçici ayarlar ve “şimdilik böyle kalsın” çözümleri birikir. Sonunda kimsenin dokunmaya cesaret edemediği dijital bir antikaya dönüşür. Immutable Infrastructure, yani değişmez altyapı yaklaşımı, bu sorunu radikal bir kuralla çözer: Çalışan sunucuyu güncelleme; yeni sürümü içeren temiz bir imaj üret, yeni sunucuları başlat ve eskilerini çöpe at.

Devamı...

GitOps Felsefesi: Argo CD ile Altyapıyı Git Deposundan Yönetmek

gitops-felsefesi-argo-89

Bir Kubernetes kümesinde çalışan uygulamayı güncellemek için gece yarısı sunucuya bağlanıp gizemli komutlar çalıştırdığınızı düşünün. Sabah olduğunda kimse neyin, neden değiştiğini bilmiyor! GitOps bu maceraya son verir: Sistemin istenen durumu Git deposunda tanımlanır, Argo CD ise kümeyi sürekli izleyerek gerçek durumu bu tanıma yaklaştırır. Böylece Git yalnızca kaynak kodun değil, altyapının da güvenilir kayıt defteri olur.

Devamı...

Feature Toggles ile Mavi/Yeşil Dağıtımdan Kontrollü Özellik Açılımına

feature-toggles-ile-21

Mavi/yeşil dağıtım, iki ayrı üretim ortamı arasında trafik değiştirerek sürüm riskini azaltır. Ancak yalnızca bir özelliği açmak için bütün trafiği yeni ortama taşımak bazen balyozla ceviz kırmaya benzer. Feature toggle yaklaşımında yeni kod önceden canlıya çıkar; davranış ise dağıtım yapmadan, bir yönetim paneli veya yapılandırma servisi üzerinden etkinleştirilir.

Devamı...

Dekorator ve Proxy: Aynı Arayüzün Ardındaki İki Farklı Niyet

Decorator ve Proxy kalıpları ilk bakışta birbirinin ikizi gibidir: İkisi de başka bir nesneyi içinde tutar, onunla aynı arayüzü uygular ve çağrıları sarılmış nesneye iletir. Ancak tasarım kalıplarında yalnızca sınıf diyagramına bakmak yanıltıcı olabilir. İnce çizgiyi belirleyen şey yapı değil, niyettir: Decorator davranışı zenginleştirirken Proxy erişimi yönetir.

Devamı...

Dağıtık İzleme ile Darboğaz Avı: Jaeger ve OpenTelemetry

Bir kullanıcı “Satın Al” düğmesine tıkladığında perde arkasında API Gateway, kimlik doğrulama, sepet, stok, ödeme ve bildirim gibi birçok servis harekete geçebilir. Ekranın dönüp durduğu üç saniye boyunca hangi servisin zaman kaybettirdiğini yalnızca loglara bakarak bulmak, samanlıkta iğne aramaya benzer. Dağıtık izleme ise bu yolculuğu tek bir harita üzerinde göstererek performans dedektifliğini oldukça keyifli hâle getirir.

dagitik-izleme-ile-26

Devamı...

Chaos Engineering: Üretimde Kontrollü Kaosla Dayanıklılığı Ölçmek

chaos-engineering-uretimde-89

Bir sunucuyu üretim ortamında bilerek kapatmak ilk bakışta fişi çekilmiş bir kariyer planı gibi görünebilir. Oysa Chaos Engineering, sistemleri rastgele bozmak değil; beklenmeyen arızalar müşterileri bulmadan önce sistemin davranışını kontrollü deneylerle gözlemlemektir. Netflix’in geliştirdiği Chaos Monkey bu yaklaşımın en ünlü örneğidir: Çalışan sunucuları devre dışı bırakarak mimarinin gerçekten dayanıklı olup olmadığını sınar.

Devamı...

Bounded Context Sınırlarını Çizmek: Mikroservisler Nereden Bölünmeli?

Mikroservis mimarisine geçerken ilk refleks çoğu zaman şudur: Kullanıcı tablosu için bir servis, sipariş tablosu için bir servis, ürün tablosu için de başka bir servis… Tebrikler, artık basit bir veritabanına ağ gecikmesi, dağıtık transaction ve hata ayıklama zorluğu eklediniz! Sağlıklı servis sınırları teknik yapılara göre değil, domain içindeki iş yetenekleri ve anlamsal bütünlük dikkate alınarak çizilmelidir.

bounded-context-sinirlarini-85

Devamı...

API Tasarımında HATEOAS: İstemciye Yol Gösteren Öz-Keşifli REST API’ler

Bir API istemcisinin bütün URL’leri önceden ezberlemesi gerekmeseydi nasıl olurdu? Kullanıcı bir siparişi görüntülediğinde API yalnızca sipariş verisini değil, o anda yapılabilecek “iptal et”, “öde” veya “kargoyu takip et” gibi eylemlerin bağlantılarını da döndürebilir. İşte HATEOAS, biraz ürkütücü açılımının arkasında tam olarak bu yönlendirici fikri taşır.

Devamı...

API Gateway ile Merkezi Kimlik Doğrulama ve Rate Limiting Mimarisi

Onlarca mikroservisin bulunduğu bir sistemde her servise ayrı ayrı kimlik doğrulama, yetkilendirme ve trafik sınırlama kodu eklemek kısa sürede bakım kâbusuna dönüşebilir. API Gateway, dış dünyadan gelen istekleri tek noktada karşılayarak bu ortak sorumlulukları merkezileştirir. Ancak kapıya güçlü bir kilit takarken herkesin aynı kapıda kuyruk oluşturabileceğini de unutmamak gerekir.

Devamı...

Yazılımın Karanlık Alışkanlıkları: God Object ve Spagetti Kodun Psikolojisi

Bir sınıfın kullanıcı doğrulamasından e-posta göndermeye, fatura hesaplamaktan veritabanı temizlemeye kadar her işi üstlendiğini düşünün. İlk bakışta bu sınıf oldukça “yetenekli” görünebilir. Gerçekte ise ekipteki herkesin çekindiği, en ufak değişiklikte üç farklı modülü bozan bir God Object doğmuştur. Kontrol akışı takip edilemeyen koşullar, iç içe döngüler ve rastgele bağımlılıklar da tabloya eklenince menüde spagetti kod vardır.

Devamı...

Tersine Proxy Sızıntıları: Nginx Yanlış Yapılandırmalarının Bedeli

Tersine proxy, internetten gelen isteklerle uygulama sunucuları arasında duran güvenlik görevlisine benzer. Ancak bu görevliye yanlış talimat verirseniz yalnızca ziyaretçileri yönlendirmekle kalmaz; kaynak kodu, yedek dosyalarını veya yapılandırma sırlarını da servis edebilir. Nginx yapılandırmalarındaki tek bir regex karakteri ya da hatalı alias kullanımı, görünmez olması gereken dosyaları halka açık hâle getirebilir.

Devamı...

Şifre Kırma Arenasında GPU Gücü ve Hashcat Optimizasyonları

sifre-kirma-arenasinda-73

Modern ekran kartları yalnızca oyunlardaki ejderhaları gerçekçi göstermek için çalışmıyor; binlerce paralel çekirdeği sayesinde parola denetimlerinde de ciddi hesaplama gücü sunuyor. Hashcat, bu gücü kullanarak hash karşılaştırmalarını büyük ölçekte gerçekleştiriyor. Bu yazıdaki örnekler yalnızca size ait sistemlerde veya açıkça izin verilmiş güvenlik testlerinde kullanılmalıdır.

Devamı...

Sıfır Güven Mimarisi: Ağdaki Herkese Yabancı Muamelesi Yapmak

sifir-guven-mimarisi-77

Şirket ağının içindeyseniz güvenilir, dışındaysanız şüphelisiniz… Geleneksel güvenlik yaklaşımı uzun süre bu kadar basit çalıştı. Ancak bulut servisleri, uzaktan çalışma, mobil cihazlar ve ele geçirilmiş kullanıcı hesapları kale duvarlarını anlamsızlaştırdı. Sıfır Güven, herkesi kötü ilan etmek yerine hiçbir isteğe konumundan dolayı ayrıcalık tanımayan modern bir güvenlik felsefesidir.

Devamı...

Multi-Tenant Mimarilerde Veritabanı İzolasyonu: Komşunun Verisi Komşuda Kalsın

Bir SaaS uygulamasında yüzlerce müşteri aynı altyapıyı paylaşabilir; fakat hiçbir müşteri bu paylaşımı verilerinde hissetmemelidir. Multi-tenant mimarinin temel sözü şudur: “Aynı apartmanda yaşayabiliriz, ama anahtarlarımız farklıdır.” Bu sözü tutmanın yolu, doğru veritabanı izolasyon stratejisini seçmek ve izolasyonu yalnızca uygulama koduna bırakmamaktır.

Devamı...