Bir proje başladığında ilk mimari toplantısında Kubernetes'in masaya gelmesi artık şaşırtıcı değil. Ama bu durumun kendisi şaşırtıcı olmalı. Kubernetes aşırı kullanımı, teknoloji dünyasının belki de en az sorgulanmış varsayımlarından birini temsil ediyor: araç ne kadar güçlüyse, o kadar çok yerde kullanılmalıdır. Kubernetes, yüzlerce servisin onlarca node üzerinde çalıştığı ortamlarda gerçek değer üretir. Otomatik ölçekleme, self-healing, trafik yönlendirme ve sıfır kesinti dağıtım gibi özellikler, bu ölçekte harcanan çabayı karşılar. Ama aynı araç, iki servisin bir VPS üzerinde çalıştığı bir uygulama için devreye alındığında, çözmeye çalıştığı problemden daha büyük bir yük yaratır. Kubernetes'in operasyonel yükünü küçümsememek gerekir. Cluster kurulumu, node yönetimi, network politikaları, secret yönetimi, ingress controller konfigürasyonu ve izleme altyapısı, bunların her biri öğrenilmesi ve bakımı gereken karmaşık katmanlardır. Bu katmanlar üzerindeki her arıza, uygulamanın kendisiyle değil altyapıyla mücadele anlamına gelir. Kubernetes aşırı kullanımı tartışmalarında göz ardı edilen bir nokta, basit alternatiflerin olgunluğudur. Tek bir sunucuda iyi yapılandırılmış bir dağıtım süreci, küçük bir uygulama için yıllarca güvenilir biçimde çalışabilir. Container orkestrasyonu gerektiren ölçeğe ulaşmadan bu düzenin sürdürülmesi, pek çok durumda daha rasyonel bir tercihtir. Bu konuda sıklıkla duyulan savunma, kariyer geliştirme boyutunda ortaya çıkar: Kubernetes öğrenmek faydalıdır, üretim ortamında çalışmak öğrenmenin en etkili yoludur. Bu savunma bireysel kariyer açısından anlaşılırdır, ama proje kararlarını kariyer eğitim zeminine çevirmek ayrı bir tartışmayı hak eder. Doğru soru şudur: mevcut ve yakın vadeli ölçeğimiz, Kubernetes'in getirdiği operasyonel yükü haklı kılıyor mu? Bu soruya dürüst bir yanıt vermeden alınan mimari karar, ilerleyen dönemde takımı sürükleyeceği borçla birlikte değerlendirilmelidir.