Soyutlamanın Bedeli: Altyapıyı Gerçekten Anlamak

Bir oyun oynayalım. Şimdi bazı terimler söyleyeceğim, sen de kendine dürüstçe bak bakalım: Kubernetes, DNS propagasyonu, reverse proxy, TLS termination, load balancing.

Çoğu geliştirici gibi sen de büyük ihtimalle bunları production ortamında kullanıyorsun. Belki Stack Overflow'dan bir Kubernetes manifest dosyası kopyaladın, kubectl apply yazdın ve "haydi hayırlısı" dedin. Ve şimdiye kadar işe yarıyordu. Ta ki yaramazlığa başlayana kadar.

Soyutlama Vergisi

Bulut platformları bize o kadar çok işi hallettiki, birçok geliştirici arka planda neler döndüğünü tamamen unutmuş durumda. Bunu anlıyorum—neli bilmeye gerek var ki? Zaten bulut sağlayıcısı hallediyor. Konteynırlarının yanmasını engellemek için bütün bir ekip kurmuşlar.

Ama şu gerçekle yüzleşelim: soyutlamanın bir bedeli var. Gece saat ikide bir şeyler kırıldığında ve yönetilen Kubernetes cluster'ın garip garip hatalar verdiğinde, çaresizsin. Maliyetleri optimize etmen gerektiğinde platform fiyatını ikiye katladığında, alternatiflerin yok. O yan projeni kendi sahip olduğun donanımda çalıştırmak istediğinde—$50/ay gibi bir ücret ödemek yerine—seçeneklerin kısıtlı.

Mesele bulut platformlarını tamamen terk etmek değil. Altında ne olduğunu bilmek. Seçim hakkına sahip olmak.

Kendi Altyapını Kurarken Öğrendiklerin

Geçen sene, ıvır zıvır laptoplarımla küçük bir Kubernetes cluster kurmaya bir hafta sonumu ayırdım. Production için değil, sadece öğrenme amaçlı bir hobi projesi. O hafta sonu, iki yıllık managed servis kullanımından çok daha fazla şey öğrendim.

Servislerin birbirini bulabilmesi için DNS yapılandırmasının neden önemli olduğunu öğrendim. SSL sertifikalarının gerçekte nasıl çalıştığını öğrendim—sadece "şu HTTPS işini ekleyeyim" değil, handshake'in tamamı, sertifika zinciri, süreleri dolduğunda neler olduğu. Load balancer'ların sihirli olmadığını, sadece tanımladığınız kurallara göre yönlendirme yapan yazılımlar olduğunu öğrendim.

Daha da önemlisi, hata ayıklama becerisi kazandım. Managed bir ortamda sorun çıktığında bir ticket açarsın. Kendi altyapında sorun çıktığında çözümü bulman gerekir. Ve bu problem çözme yeteneği birikir. Bir dahaki sefere bir şey kırıldığında, üzerinde çalışabileceğin zihinsel modellerin olur.

Kimsenin Konuşmadığı Pratik Avantajlar

Dürüst olalım—"DevOps becerileri" hakkındaki çoğu makale kariyer ilerlemeye ya da 10x mühendis olmaya odaklanıyor. Bu güzel bir hedef, ama daha acil bir şey var: para.

Kendi altyapını çalıştırmak bedava değil, ama doğru kullanım senaryolarında managed servislerden dramatik şekilde ucuz olabilir. $200/ay'lık bir managed Kubernetes cluster, bazen zaten sahip olduğun donanımla veya $40-80/ay'a mal olan dedicated sunucularla değiştirilebilir. Runway tüketen startup'lar için bu önemsiz bir fark değil.

Bir de kontrol meselesi var. Müşterinin migrate etmeyi reddettiği o eski PHP uygulamasını çalıştırmak ister misin? Sıradışı ağ yapılandırmalarıyla denemeler yapmak ister misin? Uyumluluk nedeniyle verilerin belirli bir bölgede kalması gerekiyor mu? Managed platformlarda sunulanlarla sınırlısın. Kendi altyapın varsa, karar senin.

Boğulmadan Başlamak

Ne düşündüğünü biliyorum: "Güzel duyuyor ama sysadmin olacak zamanım yok." Haklısın. Olmasına da gerek yok.

Küçük başla. Gerçekten küçük. Kubernetes'e dokunmadan önce şunları anladığından emin ol:

• Domain adlarının nasıl çözümlendiği (ipuucu: DNS sunucuları ve TTL'lerinvolur, ve evet, domain registrar'ın sandığından çok daha önemli olduğunu)
• Bir konteyner çalıştırdığında ne olur
• Reverse proxy'nin ne işe yaradığı ve neden isteyebileceğin
• TLS sertifikalarının nasıl alındığı ve yenilendiği

Bunlar gösterişli beceriler değil, ama temel taşlar. Parçaları anlayınca, birleştirmek çok daha az korkutucu hale geliyor.

Senin Altyapın, Senin Kuralların

Şu var ki, kendi deployment'ını öğrenmek modern araçları reddetmek değil. Kubernetes gerçekten güçlü. Bulut platformları inanılmaz kolaylık sunuyor. Mesele, kullandığın şeyi anlamak—onu sihirli bir kutu gibi görmemek.

Startup'ın tüm altyapısını ev yapımı Kubernetes üzerinde çalıştırsan da, sadece CI/CD pipeline'ının "deploy ettiğinde" gerçekte ne yaptığını anlamak istesen de, bu bilgi seni daha iyi bir geliştirici yapar. Kodunun bağlamını bileceğin için daha iyi kod yazarsın. Dengeleri bileceğin için daha iyi mimari kararlar alırsın. Ve işler bozulduğunda—ki her zaman bozulur—onarabilirsin.

Tam stack'i anlayan geliştiriciler yok olmuyor. Aksine, sektör soyutlamanın sadece belirli bir noktaya kadar götürdüğünü kavradıkça, değerleri artıyor.