CNCF Ambassador ve Platform Engineering TCG organizatörü olarak Atulpriya Sharma’ya göre platform mühendisliğinde en önemli soru, kurumun bir platform kurup kurmadığı değil, geliştiricilerin platformun yetenekleriyle gerçekte nasıl etkileşime girdiğidir. Henüz resmî bir platforma sahip olmayan kurumlar genellikle dağınık betiklere ve bireysel bilgiye dayanırken, diğer bazı kurumların geliştirici portalı, CLI arayüzü ve hazır iş akışları bulunabilir; ancak bu kurumlar talepleri hâlâ manuel olarak ele alır. Her iki durumda da sorun, ekiplerin platform yeteneklerini tükettiği arayüzün olgunluğunda yatar.
Makale, CNCF Platform Mühendisliği Olgunluk Modeli temelinde hazırlanmıştır. Bu model beş boyutu bağımsız olarak ölçer: yatırım, benimseme, arayüzler, operasyonlar ve ölçüm. Her boyut için dört seviye vardır: geçici, operasyonel, ölçeklenebilir ve optimize edilmiş. Modele göre kurum tek bir birim olarak ilerlemez; bir boyutta ilerlerken başka bir boyutta geride kalabilir. Analiz, geliştiricilerin kullandığı şablonlar, CLI arayüzleri, portallar ve API’ler anlamındaki arayüzler boyutuna odaklanır.
Platform arayüzünün dört aşaması
İlk seviyede kurum, özel prosedürlere dayanır: manuel talepler, ekipler arasında farklılık gösteren süreçler ve kişiden kişiye aktarılan bilgiler. Platform için resmî bir adın bulunmaması, platformun gerçekte var olmadığı anlamına gelmez; belirli bir mühendise veritabanı kurması için tekrar tekrar gönderilen mesajlar, yönetilmese de platformun mevcut arayüzünü temsil eder.
İkinci seviye standart araçlar olarak adlandırılır. Bu aşamada yetenekleri sağlamak ve izlemek için altın yollar veya döşeli yollar, belgeler, şablonlar ve tutarlı arayüzler ortaya çıkar. Sonuçlar genellikle olumludur: daha yüksek benimseme, yeni çalışanların daha hızlı işe alıştırılması ve göstergelerde iyileşme. Ancak beklenen yolun dışında kalan talepler hâlâ platform ekibinin müdahalesini gerektirir. Bu nedenle arayüz standartlaştırılmış olsa da kendi kendine yeterli değildir.
Üçüncü seviyede self servis çözümleri ortaya çıkar; geliştirici, rutin taleplerin çoğunu platform ekibinden geçmeden gerçekleştirebilir. Bu seviye yalnızca göstergelere dayanmak yerine ekiplerin davranışını ölçer: rutin tedarik talepleri azalır, yeni mühendisler platformu doğrudan kullanmaya başlar ve platform ekibinin çalışması bireysel talepleri yerine getirmekten, bu talepleri yöneten çerçeveyi iyileştirmeye dönüşür. Yazarın aktardığı örneklere göre bazı kurumlar, self servis yapılandırma seçenekleri eklendikten sonra istisna taleplerinde %40 ile %60 arasında azalma bildirmiştir.
Dördüncü seviye olan entegre hizmetler, platform yeteneklerini günlük çalışma araçlarının şeffaf bir parçası hâline getirir. Yeni bir hizmet oluşturulduğunda izleme, günlük kaydı ve güvenlik otomatik olarak entegre edilebilir; güvenlik politikaları da geliştiriciden bunları manuel olarak müzakere etmesini istemek yerine kurallarını platform üzerinden uygular. Platform neredeyse görünmez hâle gelir ve başarısı, geliştiricilerin altyapı hakkında düşünmek zorunda kalma sıklığının ne kadar az olduğuyla ölçülür.
Kurumlar neden ikinci seviyede kalır?
Analiz, tekrarlanan dört sorunu belirler. İlki kuyruk sorunudur: altın yollar yaygın durumları kapsar, ancak istisnai durumlar büyük kurumlarda işin %30’unu oluşturabilir. Yazar, bir perakende kuruluşunun Helm chart’ları ve ArgoCD üzerinden Kubernetes dağıtmak için altın bir yol kullandığı bir örnek verir. Benimseme altı ay içinde %85’e ulaşmış, ancak 40 istisna durumu birikmiş ve ekip zamanının %60’ını yol dışı yapılandırmalara harcamaya başlamıştır.
İkincisi uzmanlık açığıdır; platform ekipleri, uzman ekiplerin ihtiyaçlarına tam olarak uymayan genel yetenekler oluşturabilir ve bu durum söz konusu ekipleri kendi alternatiflerini geliştirmeye yöneltebilir. Üçüncüsü bakım tuzağıdır: her yeni yetenek, bir güvenlik açığı ortaya çıktığında veya Kubernetes yükseltildiğinde güncelleme, test ve düzeltme için ek bir yüzey anlamına gelir. Yazar, eski Helm chart arayüzlerinin, bir bulut sağlayıcısına özgü bağımlılıkların ve ağ varsayımlarının birikerek güncellenmelerini riskli hâle getirdiği bir durumdan söz eder.
Dördüncü sorun ise katılıktır. Altın yol tasarlandığında doğru olan varsayımları yansıtır; ancak teknolojiler, süreçler ve ekiplerin ihtiyaçları değiştikçe bu varsayımlar kısıtlamalara dönüşebilir. Bunun sonucunda istisnalar ve gölge altyapı çoğalır, platform ekibi temel arayüzü iyileştirmek yerine bireysel çözümler üreten bir fabrikaya dönüşür.
Pratikte ne değişir?
Yazar, birinci seviyeden ikinci seviyeye geçmek için yeni bir portal oluşturmadan önce mevcut olanı adlandırmayı önerir: en sık tekrarlanan, en çok zaman alan ve standartlaştırılmaya en uygun talepleri tespit etmek; ardından kataloğu genişletmeden önce tek bir altın yol seçip onu gerçekten iyileştirmek.
İkinci seviyeden üçüncü seviyeye geçmek için platform ekibinin zorunlu bir insan halkası olmaktan çıkması gerekir. Bunun için altın yolların yapılandırılabilir hâle getirilmesi, sabit değerler yerine doğrulanmış seçenekler ve politikalarla uygulanan kısıtlamalar sunulması, ayrıca meşru durumlar için çıkış yolları sağlanması gerekir. Analiz ayrıca talepler otomatikleştirilmeden önce ölçülmesini önerir. Medya sektöründen bir örnekte, taleplerin üç ay boyunca kaydedilmesi, talep türlerinin %20’sinin hacmin %80’ini oluşturduğunu ortaya çıkarmış; önce bu örüntüler için self servis oluşturulmuş ve birikmiş işler altı ay içinde %60 azalmıştır.
Ayrıca arayüz bir ürün olarak ele alınmalıdır; yalnızca arka uç yetenekleri ele alınmamalıdır. Keşfedilebilirlik, doğrulama kuralları, sözleşmeler ve beklenmedik taleplerin ele alınma biçimi ürünün birer parçasıdır. Dördüncü seviyeye yaklaşırken otomasyon, geliştiricinin seçtiği bir çalıştırma biçiminden; Git, geliştirme ortamı ve CI/CD sistemleri içinde politikalar tarafından uygulanan akıllı varsayımlara dönüşür. Güvenlik, veritabanı ve izleme ekipleri arasındaki yetenek sahipliği de açık sözleşmeler çerçevesinde dağıtılır.
certi.news’un değerlendirmesi
Makalenin dikkat çektiği asıl değişim, geliştirici platformunun başarı ölçütünün başlatılan araç ve iş akışlarının sayısından, kullanıcıların elde ettiği bağımsızlık düzeyine ve ardından bu yeteneklerin iş akışına ne ölçüde entegre olduğuna kaymasıdır. Bu durum platform ekipleri için önemlidir; çünkü görünürde benimsemeyi artırırken uygulama yükünü istisna ve bakım kuyruğuna aktarabilirler.
Ancak burada yer alan örnekler ve rakamlar, yazar tarafından kurumlarla yapılan etkileşimlerden edinilmiş gözlemler olarak sunulmaktadır; aynı oranların her kurum için geçerli olduğunu kanıtlayan bağımsız bir nicel çalışma değildir. Ayrıca dördüncü seviyeye ulaşmak, yalnızca bir portal satın alınması veya yapay zekâ ajanı eklenmesiyle sağlanamayacak sözleşme, politika ve sahiplik dağılımı olgunluğunu varsayar. Sonuç bölümü önemli bir açık soru ortaya koyar: Geliştiriciler için tasarlanmış self servis arayüz, yapay zekâ ajanları tarafından tüketilebilecek bir arayüz olmak zorunda değildir; bu ajanlar API’lerle insan iş akışlarına benzemeyen sıklık ve örüntülerle etkileşir. Bu nedenle makine tarafından tüketilebilen arayüzlerin olgunluğu, platform ekiplerinin ölçmesi gereken bir sonraki aşama olabilir.