Docker ve konteyner teknolojisinin sanallaştırmaya ve sektöre yeni bir bakış açısı kazandırmasının üstünden henüz on yıl geçmedi, ancak hızla gelişen bir ekosistem haline dönüştü.
Konteyner teknolojilerinin ilk zamanlarında 10-15 gün ortalama ömrü olan bir konteyner uygulamasının ortalama ömrü günümüzde birkaç güne düşmüş durumda. Otomasyon ve orkestrasyon araçları devreye girdikçe de bu süre giderek azalıyor.
Hal böyle olunca, konteyner iş yüklerinin de yönetimi için orkestrasyon araçları olmazsa olmaz bir konuma geliyor. Tam da bu sebepten ötürü konteyner orkestrasyon araçlarına muazzam bir ilgi var. Pek çok uygulama geliştirici konteyner dönüşümünü sağlamış olsa da, hangi konteyner platformunu neden kullanabilecekleri konusunda geliştiricilere yol göstermek gerekiyor. Ben de bu sebeple okumakta olduğunuz makaleyi kaleme alma ihtiyacı hissettim.
Benim teknolojik gelişmeleri okurken yıllardır kullandığım ve neredeyse hiç şaşmadığım bir yöntemim vardır. İlgili teknolojinin sektör paylarına geriye dönük birkaç yılı hesaba katarak bakarım. Hangi teknoloji yükselişte hangisi düşüşte tespit eder, sonrasında da nedenlerini araştırmaya başlarım. Bu makalede de aynı düşünce sistemini sizin için işletiyor olacağım.
Bulut Tabanlı Konteyner Servislerinin Pazar Payı %87’nin Üzerinde
RightScale’in 2019 tarihli Bulut Görünümü raporuna göre konteyner orkestrasyon aracı olarak Kubernetes’in hızla yaygınlaştığı ve sadece bir yıl içinde %27’den %48’e yükseldiği görülüyor.
Konteyner ekosisteminin %87’si ise, üç büyük global bulut servis sağlayıcının konteyner servisleri üzerinde çalışıyor.
Kalan %13 ise, diğer bulut servis sağlayıcılarla on-premise kullanım yöntemlerini içeriyor.
Bir başka araştırmada ise, Kubernetes kullanımı %77 olarak görünürken OpenShift kullanımı %9 iken, Docker Swarm %5 dolaylarında.
Bu rakamları okursak, farklı konteyner orkestrasyon araçlarından Kubernetes’e yoğun bir geçişin olduğunu görüyoruz ve Kubernetes servislerinde de çok büyük ağırlığın bulut üzerindeki Kubernetes servislerine yöneldiği de bir başka gerçek.
Küresel bazda durum bu şekilde iken bir de Türkiye için pazar paylarından bahsetmek isterdik. Ancak henüz bu alanda bir araştırma olduğunu göremiyoruz. Ampirik yöntemlerle elde ettiğimiz verilerde ise, Türkiye’nin özellikle KVKK ve BDDK ile ilgili regülasyonlar sebebiyle küresel pazardan farklı olarak on-premise çözümlere eğiliminin fazla olduğunu görüyoruz.
On-premise kullanan işletmelerde de Openshift’in tercih edildiği görülüyor. Ancak son dönemde globalde olduğu gibi Openshift için açılan iş ilanları azalırken Kubernetes ilanlarının öne çıktığını görüyoruz.
Başta belirttiğim gibi tespitleri yaptıktan sonra nedenleri araştırdığımı söylemiştim. OpenShift’in nerelerde problem yaşadığını incelemek için aslında biraz OpenShift’le ilgili makaleleri okumak yeterli oluyor.
Ben bir geliştirme yaparken en fazla dikkat ettiğim konu arkamda teknolojik bir enkaz bırakıp bırakmadığımdır. İngilizce’de Technical Debt de denilen bu enkaz kar topu gibi büyüyüp sonunda içinden çıkılmaz bir hale getirebilir. Üstelik bu kar topunun çığa dönüştüğünü farkettiğinizde de çoktan iş işten geçmiştir.
OpenShift’in öncelikle genel eksikliklerine değinelim. Öncelikle OpenShift sadece Red Hat Linux, Fedora ya da CentOS üzerinde çalışabiliyor. Ayrıca konteynerlarınızı güvenlik politikası sebebiyle root kullanıcısı olarak çalıştırmanız mümkün değil. Bu tür kısıtlamalar sebebiyle her iş yükünü çalıştırabileceğiniz bir platform olmaktan uzaklaşıp kısıtlı iş yüklerini çalıştırabileceğiniz bir platform haline geliyor. Sınırlı bir destek ve esnek olmayan yapı da ayrı bir konu.
Bu olumsuz durumun yanı sıra ülkemizde bir de OpenShift’in çalıştığı ortamlarla ilgili alınmış yanlış kararlara şahit oluyoruz.
Öncelikle OpenShift, bir alt katmanda Kubernetes’i kullanıyor. Kubernetes’in donanım katmanı ile ilişkisi ölçüsünde işlem yapabiliyor. Kubernetes tasarım itibariyle donanımsal bir otomasyon katmanı olmadan verimli bir kullanım sağlayamıyor.
Yani on-premise’de OpenShift kullanmak demek, Kubernetes’in dış dünya ile haberleşmesi için büyük bir engeli de birlikte getiriyor.
Büyük Yükler Altında Ölçeklemesi Kabusa Dönüşebilir
On-premise’de elbette Kubernetes’i dolayısıyla OpenShift’i Load Balancer ile internete çıkarabilirsiniz ancak Load Balancer teknolojisini çok iyi özümsemek, bir Load Balancer oluşturabilmek için gerekli tüm uygulamara hakim olmak ve sayfalar dolusu dokümanları okumak gerekiyor… Tabii ki bolca sabır ve zamanı da yanına koymanız lazım.
Özetle on-premise’de OpenShift’i tercih edecekseniz elinizde çok iyi bir Load Balancer takımı olması gerekiyor.
Burada Load Balancer sayınızın ne olduğunun bir önemi yok. Hatta Load Balancer kullanmasanız bile Load Balancer kullanma ihtiyacınız olduğunda çok geç bile olabilir.
Openshift’i sadece Kubernetes ile karşılaştırdığınızda bir artı yönü olarak gözüken taraf CI/CD gibi duruyor. Ancak derinlere indiğimizde burada da problemler var.
Adı üzerinde geliştirme ve operasyonu birleştiren DevOPS felfesesine OpenShift’in Pipeline kısmı çok fazla uymuyor. Evet, OpenShift üzerinde gerçekten bir CI/CD servisi kurabiliyorsunuz fakat çok miktarda YAML dosyasıyla, OpenShift’e özel pek çok CI/CD komutuyla muhatap olarak bir CI/CD ortamı oluşturmanız gerekiyor.
Load Balancerda olduğu gibi OpenShift’in CI/CD özelliği olan OpenShift Pipelines da belki ayrı bir ekip kurulmasına kadar gidecek karmaşıklıkta. Aslında burada biraz RedHat’in kendi DevOPS aracı olan Ansible’ın da etkisinde kaldığını söylemek mümkün. Ansible Playbooklar’la çok fazla oynamış ve alternatifini aramış biri olarak işin DevOPS’tan çıktığını, DevOPS’un felfesesinden uzaklaştığımı sorgulatan durumları çok yaşamışımdır.
Bu tür durumlar söz konusu olunca da OpenShift’in kullanım oranı hem küresel pazarda hem de Türkiye’de olumsuz etkileniyor.
Peki bu durumda ne yapmak lazım?
Çoğu makalede denk geldiğim gibi sorunu söyleyip çözümü söylememek okuyuculara haksızlık olurdu. Sorunu tespit ettiğimize göre gelin biraz da çözüm üzerine mantık yürütelim.
İlk Çözüm: Maliyetine Katlanıp RedHat’in Best Practice’lerine Başvurmak
OpenShift peki hiç mi tercih edilmemesi gereken bir çözüm. Elbette hayır. Her yazılım gibi onun da doğru çalışabileceği ortamlar elbette var. Zaten ilk akla gelen seçeneklerden biri OpenShift’le beraber RedHat’in private cloud çözümü olan RedHat OpenStack’i de almak.
Ancak zaten OpenShift’e çekirdek başı ödenen ciddi bir lisans maliyeti söz konusuyken bir de private cloud çözümü satın almak çok büyük bir maliyet kapısı oluşturacaktır. Hele ki son dönemlerdeki döviz kurları göz önüne alınırsa. Elbette bunu gerçekleştirebilmek için OpenStack için de şirketinizde bir ekip oluşturmanız gerekecek.
İkinci ve En Popüler Çözüm: Hukuksal ve Mali Riskler Alınarak Global Bulut Sağlayıcıların Kubernetes Servislerine Geçmek
Akla gelen ve şimdiye kadar tercih edilen en popüler seçenek ise, global bulut servisi sağlayıcıların sunduğu bulut üzerinde çalışan Kubernetes as a service çözümleri. Global pazarın %87 gibi ezici bir oranda tercih ettiği çözüm mantıklı gibi gözükse de KVKK gibi hukuksal engellerin yanı sıra bu servislerin dolar bazında ücretlendirilmesi pek çok IT yöneticisinin geceleri rahat uyumamasına sebep olabilir. Ki son yıllarda pek çok firmanın tüm mali ve hukuksal riskleri göze alarak bu servisleri kullandığına defalarca şahit olduk.
Bu soruna kalıcı bir çözüm olarak ise yurtiçinde bir bulut altyapı servisinin oluşması ve Kubernetes ile entegre bir şekilde çalışması görülüyor. Elbette OpenShift’in içinde bulunan ama Kubernetes’in sunmadığı CI/CD, Load Balancer gibi servislerin de bulut sağlayıcı tarafından sunulabilmesi gerekiyor.
Üçüncü Çözüm: Yerel Bir Bulut Sağlayıcının Kubernetes Ekosistemi Çözümlerine Başvurmak
Yakın bir zamana kadar ülkemizde bu soruna bir çözüm maalesef yoktu. Hatta YouTube ya da Twitch gibi platformlarda da 2021 yılına gelinmişken neden hiçbir altyapı sağlayıcının bu yönde servisler sunmadığı yönünde sitem eden geliştirici sohbetlerine de belki şahit olmuşsunuzdur.
Bu serzenişler dinlenmiş olsa gerek, bu yıl ülkemizde salt Kubernetes hizmeti veren birkaç firma ortaya çıkmış olsa da maalesef Kubernetes’i tek başına bir ürünmüş gibi algılandığına ve Kubernetes’in bir şekilde tek başına servise sunulması ile tüm sorunun bertaraf edilebileceği yönünde servis sağlayıcılarda bir inanç olduğunu görüyoruz.
Ben kişisel olarak bu şirketlerin teknik ve karar alıcı ekiplerinin DevOPS ya da yazılım geçmişi olmayan, sistem ve network uzmanı ağırlıklı ekiplere sahip olmalarına bağlıyorum.
Zaten global bulut sağlayıcılara da bakarsanız, hepsinin aslında uygulama geliştiricisi olduklarını, sistem ve network yanlarının daha arka planda olduğunu görürsünüz. Ya bulut sağlayıcının bağlı olduğu şirket bir e-ticaret firmasıdır ya da video yayını, reklam ağı gibi uygulamaları koşturup sorunları çözmekle uğraşmış sonunda da bu ekosistemler ortaya çıkmıştır. Bizde de hikaye benzer şekilde gelişti.
0 Comments