Londra’daki son Kubecon + Cloud Native Computing Foundation (CNCF) Europe 2025 etkinliğinde yapılan bir tartışma sırasında, panel üyeleri modern yazılım geliştirmenin büyük eleştirilerinden birini tartıştılar: Kod dağıtım neden hala sorunlarla dolu?
Geliştiricilerin kodlarını üretime koymak için daha fazla sorumluluk üstlendiği sola kaymak, bazı kuruluşlarda durmuş gibi görünüyor.
Diagrid teknoloji ürünü lideri Kendall Roden, büyük zorluklar arasında dağıtılmış sistemlerin yükselişi olduğunu söyledi. Roden’e göre, bu geliştiricilerin artık “ek bilişsel yük” dediği şeylerin çoğuna sahip oldukları anlamına geliyor. “Ne zaman esneklik nasıl yapılacağı gibi birçok yeni sorumluluk var. [the code] Artık tek bir süreç olarak çalışmıyor ”dedi.
Roden’in deneyiminde, birçok kuruluşun bu sorumlulukları üstlenmeye yardımcı olacak platform ekibi yoktur. “Geliştiriciler daha az üretkendir; DevOps deneyimi biraz şişirilmiş hale geldi ve sorumluluğun açık bir şekilde tanımlanmıyor” diye uyardı.
Bazı kuruluşlar geliştiricileri desteklemek için platform mühendisliği benimseyebilirken, geliştiricilerin kodu üretime koymaları hala zor. Mirantis’te açık kaynak stratejisi ve teknoloji başkan yardımcısı Randy Bias, DevOps’un ve platform mühendisliği gibi uygulamaların amacının geliştiriciler ve operatörler arasındaki duvarları yıkmak olduğunu söyledi, böylece herkes Google gibi çalışabilir ”.
Platform mühendisliğinin rolü, bir ekibin genellikle Kubernetes’in üzerine inşa edilen bir platform sağladığı BT operasyon personeli ve yazılım geliştiricileri arasında oturmaktır. Bu, bir soyutlama tabakası eklediğini ve geliştiricilere üretime giden yol sağladığını söyledi.
Bununla birlikte, önyargı ekledi: “Ortalama bir işletmeye bakarsanız, Google gibi faaliyet gösterme şansları yok. Silolar her zamanki gibi sessiz ve geliştiriciler ve operasyonlar arasında büyük engeller var.” Geliştiricilerin bu altyapı hakkında bilgi sahibi olmak istemediklerine dikkat çekti. “Bunu umursamıyorlar,” dedi Bias. “Uygulamalarını geliştirmek ve sihirli bir şekilde konuşlandırmalarını istiyorlar.”
Kubernetes’in yapay zeka ile ilişkisi
Google Cloud mühendislik direktörü Jago MacLeod’a göre, yapay zeka (AI) ve makine öğrenimi (ML) iş yükleri Kubernetes Komitesi için tamamen yeni bir şeyi temsil ediyor. “Bu yeni AI ve ML iş yükleri turu, CNCF ve Kubecon topluluklarının şimdiye kadar inşa ettiklerinden gerçekten farklı” dedi.
AI ve ML büyük eğitim iş yükleridir. Kubernetes dünyasında, iş yükleri baklalar halinde dağıtılır, ancak AI ve ML iş yüklerinin boyutu göz önüne alındığında. MacLeod, bunun düğüm başına bir bölme kullanmak anlamına geldiğini söyledi. “Düğümlerden herhangi biri durursa, başka bir tane yerine getirmeniz ve ardından yeniden başlatmanız gerekir. [the workload] Bir kontrol noktasından, ”dedi.
MacLeod’a göre, bir başka zorluk da AI Foundation modelleriyle çalışan AI araştırmacılarının Python’u kullanarak programlama eğiliminde olmalarıdır.
“Birçoğu akademiden geliyor ve Python kodu yazıyorlar, bu da yazılım mühendisliğinde zarif kod dediğimiz şey değil ve kaynak yok [code] Kontrol, ”dedi ve AI araştırmacılarının bu Python iş yüklerini on binlerce düğüme dağıtmaya çalıştıklarını da sözlerine ekledi.
MacLeod, “Bu, BT operasyonlarıyla tercih ettiğimiz yolla karşılaştırıldığında tamamen farklı bir zihinsel model ve onu kaynağa kontrol ediyorsunuz ve daha sonra kontrollü bir şekilde patlıyor; bu çok farklı bir dünya” dedi.
AI ve ML, diğer Kubernetes iş yüklerinde çok farklı sorunlar sunmaktadır. Roden, AI alanında, geliştiriciler arasında AI ile nasıl çalışabilecekleri konusunda anlayışlarını geliştirmek için zihniyette bir değişim olması gerektiğini söyledi. “Ortalama bir işletme geliştiricisinin kullanım ölçeğinin aslında orada olup olmadığını bilmiyorum, çünkü oldukça karmaşık ve farklı bir beceri seti, farklı bir yaklaşım ve farklı bir altyapı kümesi gerektiriyor” diye ekledi.
Önyargı daha da ileri gitti: “İnsanlar bunların HPC iş yükleri olduğunun farkında değiller”, AI ve ML’nin süper bilgisayara benzer sorunları paylaştığı gerçeğine atıfta bulunuyorlar. Yetkili, AI ve ML esnekliği sorununun, süper bilgisayar merkezlerinin onlarca yıldır ele aldığı aynı sorun olduğunu söyledi. “Tekerleği yeniden icat etmek zorunda değiliz,” dedi Bias. “Sadece geri dönüp HPC nişinde olan bilgiyi almalıyız.”
Küresel baskı
Kod yazmanın ve yönetmenin ötesinde, panel tartışması sırasında sorulan sorular arasında jeopolitik gerginliğin açık kaynak ve Linux Vakfı’nı nasıl etkilediğine bakan bir şeydi. “Önümüzde bir ton tehlike ve tuzak var,” dedi Bias.
Hong Kong’daki CNCF etkinliğinde, sunum yapan kişilerin Çin’de geliştirilen projeleri tartışan Mandarin konuşmacıları olduğunu söyledi. “Bölgesel fraksiyonelleşme tehlikesi var,” dedi Bias.
Ancak, jeopolitik bir perspektiften, açık kaynak tarafsız olma eğilimindeyken ve topluluk uluslararası sınırlar boyunca faaliyet göstermeye çalışırken, siyaset bu açıklığı etkileyebilir.
Linux Vakfı’nın Kasım 2024’te Rus Linux çekirdek koruyucularının bir kohortunu dışlama kararına atıfta bulunarak, “Linux Vakfı gibi bir kuruluş için jeopolitik gerçekler var” dedi.
Bias, ABD’den dayandığı göz önüne alındığında, Linux Vakfı artık küresel açık kaynak topluluğunu denetlemek için iyi yerleştirilmediğini öne sürdü. Bunun yerine, ihtiyaç duyulan şeyin coğrafi olarak nötr bir bölgede faaliyet gösteren bir Birleşmiş Milletler olduğunu söyledi.