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.

Devamı...
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ı...
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.

Devamı...

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ı...
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ı...
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ı...
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ı...

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ı...

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ı...
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ı...
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.

Devamı...

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ı...
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.

Devamı...
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ı...
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ı...
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, 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ı...

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ı...

Ş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ı...
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ı...