Bir Koltuğa 3 Karpuz Sığar mı? DevOps’a Sonsuz Talepler ve Kurtuluş

Yaz aylarını özleten Dall-E çizimi

Karpuzların sayısından, duruşundan ziyade koltuk temelli bir çözüm aramak gerek. Çoğu zaman organizasyonlar tek bir DevOps ekibi

Organizasyondaki tek DevOps ekibindesiniz ve her biri kendi dünyasında yaşayan, birbirinden bağımsız birkaç yazılım ekibine hizmet veriyorsunuz. Her ekip kendi spesifik gereksinimlerini, özel toolchain’lerini, farklı deployment ihtiyaçlarını ve kişisel tercihlerini size iletiyor. Bir ekip Jenkins pipeline’larını istiyor, diğeri CDK kullanmak istiyor, bir başkası ise “Bunlar çok karmaşık, bizim için yönetebilir misiniz?” diye soruyor. Sonuç? DevOps ekibiniz tek bir şey yapıyor: yangın söndürmek.

Her development ekibi için custom çözümler üretmeye çalışırken ortaya çıkan sorunlardan bir kaçı:

1. Sürdürülemez Bir Kaos
   Herkesin özel ihtiyacına göre pipeline’lar, CI/CD akışları, monitoring ve logging çözümleri üretiyorsunuz. Tam bir otomasyon düşmanı. Ancak bunların hepsi farklı ve birbirine entegre edilmemiş. Bir noktadan sonra teknik borç o kadar büyüyor ki, bir değişiklik yapmak her şeye dokunmaya başlıyor. DevOps ekibi daha derin saiklerle inisiyatif almalı, reaktif hale gelmemeli.
2. DevOps Ekibinin Yanlış Konumlandırılması
   DevOps’un temel amacı, development ekiplerini desteklemek, onlara hizmet sunmak değil. Bir developerın bana söylediği cümleyi paylaşmak isterim; “DevOps is here to support us, not the other way around”. Eğer DevOps ekibiniz her gün bir ekip için özel YAML dosyalarında takla atmaya uğraşıyorsa, olayın doğasını kaçırmışsınız demektir.
3. Zaman Kaybı ve Verimsizlik
   Aynı DevOps ekibi, aynı problemleri farklı takımlar için tekrar tekrar farklı yöntemlerle çözüyor. İhtiyaçları örtüşmeyen developerlar kendi çözümlerini üretmek yerine, DevOps’un onları desteklemesini bekliyor. Bu da inovasyonu öldürüyor.
4. Karmaşıklık Arttıkça Hata Olasılığı Artar
   Custom pipeline’lar, farklı konfigürasyon dosyaları, her ekip için özelleştirilmiş cloud altyapıları… Bir süre sonra, DevOps ekibi bile kendi içerisinde senkronizasyonu kaybeder, neyin nerede çalıştığını bilemez hale gelir. Yeni biri ekibe katıldığında onboarding süreci uzun bir kabus olur.

Çözüm Önerisi: Internal Developer Platforms

Bu noktada Internal Developer Platforms (IDP) devreye girebilir. Peki IDP nedir? Her development ekibinin kendi altyapısını yönetebileceği, self-service ve standardize edilmiş bir platform.

IDP ile DevOps ekibi, aynı problemi tekrar tekrar çözmez ve development ekiplerine kendi ihtiyaçlarını karşılayabilecekleri otomasyonlar sunar:

• Self serving CI/CD pipeline’lar: Developerlar kendi pipeline’larını yazabilir ama her şey ortak bir çerçeve içinde olur.
• Önceden tanımlanmış şablonlar ve otomasyon: Basitleştirilmiş Terraform tanımları, kro (Kube Resource Orchestrator) ile güçlendirilmiş Kubernetes manifest dosyaları gibi temel yapılar platform tarafından yönetilir.
• Bağımlılıklardan kurtulma: Development ekipleri, DevOps’a bağımlı olmadan kendi çözümlerini deploy edebilirler.

Böylece, DevOps ekibi olarak sonsuz custom çözümler yazmak yerine, IDP’yi yönetmeye ve geliştirmeye odaklanabilirsiniz.

Sonuç: Karpuzları Dengeli Yerleştirin

Bir koltuğa iki-üç karpuz zor sığar ama belki doğru bir sistem kurup koltuğu da değiştirirseniz belki de dört tanesini bile dengede tutabilirsiniz. DevOps ekibinizi bir “help desk” olmaktan çıkartıp, etkili ve ölçeklenebilir bir altyapı sağlayıcısına dönüştürmek istiyorsanız, custom çözümleri bırakıp IDP’ye yönelmek işinizi görebilir.

Öyleyse kendinize şu soruyu sorun: Gerçekten her gün aynı custom çözümleri üretmeye devam mı edeceğiz, yoksa kendi iş yükümüzü optimize mi edeceğiz?

İlk seçenek kronik bir DevOps baş ağrısı. İkincisi ise sürdürülebilir bir mühendislik kültürü.

Çiviye yandan vurduktan sonra çekice sarılmayla olmuyor.