Container teknolojilerinin ve mikroservislerin hayatımıza girmesiyle beraber bu sistemleri büyük ölçekte yönetmek yeni bir sorun haline geldi. İlk etapta bu sorunu çözmek adına Docker Swarm, Mesosphere vb. çözümler ortaya atıldı fakat bu yarışın galibi açık ara farkla Kubernetes oldu. Aslında Google tarafından geliştirilen ve daha sonra Cloud Native Computing Foundation(CNCF)’a aktarılan Kubernetes, sektörün standart aracı haline gelmiş durumda.
Google’ın kendi içerisinde kullandığı Borg sisteminden esinlenilerek geliştirilen Kubernetes, GitHub üzerinde geliştirilen en büyük projelerden biri arasında yer alıyor. Katkı sağlayan kişi sayısı ve açılan issuelar göz önüne alındığında Linux kernel’ın hemen arkasında yer alıyor.
Kubernetes basitliği ve karmaşıklığı bir araya getirmiş nadir projelerden diyebiliriz. Temel olarak ana makinelerde yer alan API’lar ile konuşarak hangi makinede, ne şekilde, hangi yöntemle imajlarımızın çalışacağını belirtiyoruz. Burada ortaya çıkan sıkıntı ise her firmanın, her çözüm ortağının farklı bir yöntem izlemesi ve ortaya bir standartın çıkamaması. En basitinden Kubernetes kurmak için varsayılan bir yöntem bulunmamaktadır. Sadece kurulum için bile farklı topluluklar kurulmuş, farklı projelerde farklı yöntemler denenmiştir. Bulut sağlayıcıları bile bir standart olmaksızın kendilerine has yöntemlerle kurulumu gerçekleştirmektedir.
Öte yandan gözetleme, log kaydını toplama, CI/CD süreçlerini yönetme, güvenlik önlemleri alma gibi birçok konuda tercih kullanıcılara bırakılmıştır. Mikroservis mimarisine ve bulut yerlisi teknolojilere geçmek isteyen şirketler genellikle henüz ilk aşamada takılı kalırlar. Nasıl kuracağız? Nasıl izleyeceğiz? Servisler nasıl haberleşecek? tarzında onlarca soru ortaya çıkar. Service Mesh çözümü için bile onlarca seçenek varken bu konuda tecrübesiz ekiplerin doğru tercih yapmasını bekleyemeyiz. Her seçeneğin kendilerine göre artıları ve eksileri mevcut. Özetle Kubernetes ekosistemi standart eksikliği sebebiyle sürekli değişmekte ve yanlış bir karar sizi sürekli altyapı değişikliğine sürükleyebilir.
Neden OpenShift?
Bu standart sorunlarının çözümü adına Red Hat, OpenShift isimli ürününü ortaya çıkarıyor. OpenShift hali hazırda Kubernetes üzerinde çalışıyor fakat çok önemli farkları mevcut. Standartlaşmış ve varsayılan olarak gelen çözüm ailesi birçok firmayı seçenekleri araştırarak ve test ederek zaman kaybetmekten koruyor. Elbette OpenShift altyapısında istediğiniz bir yapıyı değiştirmek mümkün fakat hali hazırda test edilmiş ve destek verilen özellikleri kullanmak büyük kaynak tasarrufu sağlamaktadır.
Özellikle hibrit bulut teknolojisi için OpenShift biçilmiş kaftan halini alıyor. OpenShift’i kendi ortamınızda çalıştırabileceğiniz gibi birçok bulut sağlayıcısından da bu hizmeti alabilirsiniz. Bulut sağlayıcıları kendilerine has çözümler üretirler. Her sağlayıcının kendi servisleri ve bu servislerle özelleşmiş parametreler mevcuttur. Eğer projeniz AWS’nin farklı servislerini kullanıyor ise aynı projeyi farklı bir ortamda çalıştırmanız çok zor olacaktır zira bütün parametreleriniz ve mantığınız tek bir platforma odaklanmış vaziyette. Öte yandan OpenShift gibi bir çözüm kullanırsanız bütün bulut sağlayıcılarda sadece depolama gibi birkaç parametreyi değiştirerek uygulamanızı sıkıntısız bir şekilde çalıştırabilirsiniz. Verilerinizi ülke sınırları içerisinde tutarken ölçeklenmeniz gereken zamanlarda bulut sağlayıcılarından en avantajlısını seçip OpenShift ortamınızı hibrit olarak kullanabilirsiniz.
Web arayüzü, kendi imaj deposu, CI/CD için özelleştirilmiş Tekton ve ArgoCD gibi projeler, Red Hat ürünleriyle entegrasyon ve otomatikleştirilmiş kurulumu ile OpenShift kurumsal çözümler arasında oldukça avantajlı bir konuma sahip.
