Hizmet olarak platform (PaaS) ortaya çıktı yazılım geliştirmeyi kolaylaştırmak için sürekli gelişen arayışta lider bir güç olarak. PaaS’ın geçmişi 2006 yılında Force.com’a kadar uzanır, bunu Heroku, AWS Elastic Beanstalk ve daha sonra Docker’a dönüşen DotCloud takip eder.
PaaS sektörü önemli bir pazar payına sahip olsa da 170 milyar dolarlık pazar Bulut endüstrisindeki paya rağmen şirketler bugün hâlâ manuel dağıtım ve iş yükü yaşam döngüsü yönetimiyle boğuşuyor. Peki neden hizmet olarak platform daha geniş çapta benimsenmiyor?
Tüm iş yüklerinde PaaS deneyimi sağlama
PaaS platformları daha çok yönlü olabilir ve ben dil ve çerçeve uyumluluğundan bahsetmiyorum. PaaS genellikle herhangi bir uygulamanın dağıtımı için tek durak noktası olarak tanımlansa da, burada bir sorun var. Burada uygulamalardan kastedilen genellikle 12 faktörlü uygulamalardır.
Ancak çoğu iş yükü tipik web uygulamalarının kalıbına tam olarak uymaz; toplu işleme işleri, yüksek performanslı bilgi işlem (HPC) iş yükleri, GPU yoğun görevler, veri merkezli uygulamalar ve hatta kuantum bilgi işlem iş yükleri gibi benzersiz gereksinimlerle birlikte gelirler.
PaaS’ın sağladığı tüm avantajların üzerinden geçmeyeceğim. Yine de şirketlerin tüm iş yüklerini mümkün olan en kolay şekilde yönetmesi gerekiyor ve dağıtım ve yönetimlerini soyutlamak da gidilecek yol.
Bir değişime ihtiyaç var. Öncelikle PaaS paradigmasını benimseyen şirketlerin, herkese uygun tek bir iş yükü çözümünün olmayacağını kabul etmesi gerekiyor. Konuyla ilgili yakın zamanda yapılan bir konuşmada, eski Google mühendisi Kelsey Hightower, her şeyi kapsayan tek bir PaaS’ın var olduğu fikrini güçlendiriyor. ihtimal dışı kalıyor.
PaaS paradigmasını benimseyen şirketler, herkese uygun tek bir iş yükü çözümünün olmayacağını kabul etmelidir.
O da kullandı iş yükü API’si Bu kusursuz “işte benim uygulamam, onu benim için çalıştır” deneyimini sağlayan bir araç belirlemek. “İş yükü API’si” terimini seviyorum çünkü amacı açıkça belirtiyor: belirli bir iş yükünü çalıştırmak. Daha doğru olması gereken ve PaaS’ın her şeyi çalıştırmak için sihirli bir değnek olduğu kafa karışıklığına yol açan hizmet olarak platform (PaaS) ile karşılaştırıldığında. Yazının geri kalanında bu terimi kullanacağım.
Tüm iş yükleri için kusursuz bir dağıtım ve yönetim deneyimi sağlamak isteyen şirketler için ikinci değişiklik, her iş yükünün kendi iş yükü API’sine sahip olması gerektiğini düşünmektir. Örneğin, Amazon Lambda toplu işler için kullanılabilir, Versel ön uç için, Vertex AI makine öğrenimi modelleri için ve Korifi web uygulamaları için.
Şimdi iş yükü API’lerinin nasıl seçileceğini keşfedelim.