Platform As A Service (PaaS)
Bulut bilişimin geliştirici tarafına bakan katmanı olan PaaS'i bileşenleriyle ele alıyorum: Google App Engine, Windows Azure, Force.com, Heroku, Engine Yard ve diğerleri üzerinden bugünkü manzara.
Bulut bilişimin üç ana servis katmanından ortadakini, Platform as a Service (PaaS) yani Hizmet Olarak Platform modelini bu yazıda biraz daha derinlemesine ele almak istiyorum. Daha önce IaaS yazımda altyapı katmanını incelemiştim; PaaS bu altyapının bir adım üzerinde, geliştiricinin doğrudan iş yaptığı katman.
PaaS Nedir?
IaaS’te sağlayıcı size sanal sunucu, disk ve ağ veriyor; üzerine işletim sistemini siz kuruyor, veri tabanını siz yapılandırıyor, uygulama sunucusunu siz koşturuyorsunuz. PaaS’te ise sağlayıcı tüm bu katmanları soyutlayarak doğrudan bir uygulama çalıştırma ortamı veriyor. Siz sadece kodunuzu yazıyor, sağlayıcının istediği biçimde paketleyip yüklüyorsunuz; ölçeklenme, yedekleme, yama yönetimi, veri tabanı operasyonu büyük ölçüde platformun sorumluluğunda.
Bir analojiyle açıklamak gerekirse: IaaS size boş bir arsa veriyor, üzerine evi siz inşa ediyorsunuz; PaaS ise size tüm tesisatı, mutfağı ve banyosu hazır bir daire kiralıyor, siz sadece mobilyalarınızı (uygulama kodunuzu) getirip yerleştiriyorsunuz.
PaaS’in Temel Özellikleri
Bir hizmetin gerçekten PaaS sayılabilmesi için bence şu unsurları taşıması gerekiyor:
- Yönetilen çalışma ortamı: Uygulama sunucusu, dil çalışma zamanı ve gerekli kütüphaneler hazır.
- Entegre veri tabanı servisleri: Genelde sağlayıcının kendi managed veri tabanı çözümü mevcut (App Engine’in Datastore’u, Azure’un SQL Azure’u gibi).
- Otomatik ölçeklenme: Trafik arttığında platform yeni instance’ları kendi başına ayağa kaldırır.
- Deploy basitliği: Tipik olarak git push, hazır bir komut satırı aracı veya web tabanlı bir yükleme akışıyla.
- Geliştirme araçları entegrasyonu: Eclipse, Visual Studio gibi IDE’ler için eklentiler.
- Faturalandırma kullanıma dayalı: CPU saati, istek sayısı, veri tabanı işlem hacmi gibi metriklerle.
Bugün PaaS Manzarası
Google App Engine
2008’de duyurulduğunda yalnızca Python’u destekliyordu; geçen yıl Java desteği eklendi. App Engine’in mantığı oldukça katı: kodunuzu sandbox bir ortamda çalıştırıyor, dosya sistemine yazamıyor, uzun süren işlemler için Task Queue mantığını öğrenmeniz gerekiyor, veri tabanı olarak BigTable üzerine kurulu Datastore’u kullanmak zorundasınız. Karşılığında ücretsiz kotanın oldukça cömert olması ve gerçekten otomatik ölçeklenebilmesi App Engine’i deneyimli geliştiriciler için cazip kılıyor.
Microsoft Windows Azure
Bu yıl şubat ayında genel kullanıma açılan Azure, Microsoft’un PaaS cephesindeki büyük hamlesi. .NET öncelikli olsa da PHP, Java ve Ruby için de SDK’lar mevcut. İki rol modeli sunuyorlar: web role ve worker role. Veri tabanı tarafında SQL Azure ile bildiğiniz SQL Server’a oldukça yakın bir managed servis veriyorlar. Azure’un ilginç bir tarafı IaaS ile PaaS arasında hibrit bir yerde durması; VM Role gibi yeni eklenecek özelliklerle (CTP aşamasında) daha klasik sanal makine senaryolarını da destekleyecekleri konuşuluyor.
Salesforce Force.com
Salesforce CRM’in altında yatan multi-tenant platformu doğrudan geliştiricilere açan bir ürün. Apex adında kendi diline ve Visualforce adında kendi sayfa şablonlama sistemine sahip. Apex Java sentaksına yakın olsa da tamamen Salesforce platformuna özgü; bu nedenle Force.com en sert vendor lock-in örneklerinden biri sayılabilir. Buna rağmen kurumsal CRM ekosistemine entegre uygulamalar geliştirmek isteyenler için son derece üretken bir ortam.
Heroku
Ruby ve özellikle Ruby on Rails geliştiricileri için fiili PaaS standardı haline geldi. git push heroku master ile uygulamanızı dakikalar içinde production’a alabiliyorsunuz. “Dyno” ve “addon” gibi kendine has bir kavram setiyle çalışıyor; PostgreSQL, Memcached gibi servisleri eklenti pazarı (add-on marketplace) üzerinden bağlıyorsunuz. Geliştirici deneyimi tarafında çok iyi bir referans ortaya koydular; pek çok yeni PaaS başlangıcı Heroku’yu örnek alıyor.
Engine Yard
Engine Yard de Ruby on Rails odaklı, ama Heroku’dan farklı bir konuma sahip. Daha kontrollü, müşteriye sunucu seviyesinde görünürlük veren, kurumsal Ruby müşterilerini hedefleyen bir ürünleri var. AppCloud denen yeni nesil ürünleri bu yıl genel kullanıma açıldı.
Joyent SmartPlatform
Joyent’in Node.js öncülerinden olduğu ve Twitter’ın erken dönem altyapısında rol oynadığı biliniyor. SmartPlatform, Joyent’in JavaScript tarafı için açtığı PaaS girişimi; henüz erken aşamada ama önümüzdeki dönemde dikkat çekecektir.
VMforce
Bu yılın nisan ayında VMware ile Salesforce’un birlikte duyurduğu VMforce, kurumsal Java geliştiricilerine yönelik bir PaaS olacak. SpringSource framework’ü ve vSphere altyapısı üzerine kurulu; Salesforce’un servislerine de doğrudan entegre. Henüz GA değil ama duyurulduğunda Java PaaS pazarındaki en güçlü oyuncu adayı haline gelmesi muhtemel. Bu konuya ayrı bir yazıda değindim.
PaaS Neden Tercih Edilir?
Geliştirici tarafından konuşursak: hız. Sıfırdan başlayan bir projede sunucu, işletim sistemi, veri tabanı, load balancer, monitoring kurulumu rahatlıkla haftalar alır. PaaS’le aynı işi öğleden önce bitirebiliyorsunuz. Yeni başlayan ekipler için bu çok büyük bir kaldıraç.
Operasyon tarafından konuşursak: standardizasyon ve azalan operasyonel yük. Tüm uygulamalar aynı platformun tanımladığı çerçevede koştuğunda yedekleme, izleme, ölçeklenme tekrar tekrar çözülen sorunlar olmaktan çıkıyor.
İş tarafından konuşursak: öngörülebilir maliyet ve daha hızlı pazara çıkış. Bir startup için bu üç madde hayati.
PaaS’in Zayıf Yanları
Tabii ki PaaS her sorunun çözümü değil. Üzerinde durduğum başlıca konular:
Vendor Lock-in
PaaS hizmetlerine bağımlılık ciddi bir mesele. App Engine için yazdığınız kodu olduğu gibi başka bir platformda koşturmak çoğu zaman mümkün değil; Datastore’a yazıldığı şekilde veri PostgreSQL’e aktarılamaz, Apex kodu Force.com dışında çalışmaz. Heroku gibi nispeten açık platformlarda bile uygulamanız özgür ama veri tabanı taşıması yine de planlama gerektiriyor.
Esneklik kısıtlamaları
Kendi binary’nizi koşturmak, belirli bir C kütüphanesini bağlamak, özel TCP portlarında dinlemek gibi senaryolar pek çok PaaS’te ya yasak ya da çok kısıtlı. İhtiyaçlarınız platformun sunduklarının dışına çıkıyorsa IaaS’e dönmek zorunda kalabilirsiniz.
Veri yerleşimi ve uyum
Verilerinizin hangi coğrafyada saklandığı, üçüncü taraf erişim ihtimalleri ve düzenleyici uyum (özellikle finans ve sağlık sektörlerinde) PaaS değerlendirmesinin görünmez ama kritik kısmı.
Maliyetin tahmin edilemezliği
Saf saatlik instance modeli yerine PaaS’lerin çoğu istek sayısı, CPU saati, depolama işlem hacmi gibi pek çok metrik üzerinden faturalandırma yapıyor. Ay sonunda gelen faturanın baştan kestirilmesi zor olabiliyor.
Geliştirici Deneyimi: Kazanan Burada Belirlenecek
Pazarda öne çıkan PaaS’leri yan yana koyduğumda bence rekabetin asıl belirleyicisi geliştirici deneyimi olacak. Heroku’nun başarısı sadece teknoloji seçiminden değil, dağıtım akışının basitliğinden geliyor. Google’ın yeni nesil dilleri (özellikle Go gibi henüz çıkan diller) ve Microsoft’un IDE entegrasyonunu derinleştirmesi bu cephedeki yarışı kızıştıracak.
Türkiye Perspektifi ve Öngörü
Türkiye’de PaaS, IaaS’e kıyasla daha yavaş yayılacak gibi görünüyor. Sebebi basit: Java ve .NET ekosistemlerinin yerel kullanımı güçlü ama bu ortamlardaki geliştirici alışkanlıkları kurumsal sunucu yönetimine kilitlenmiş durumda. PaaS modelinin yaygınlaşması için ölçek ekonomisinden yararlanmak isteyen yeni nesil internet girişimlerinin ve mobil uygulama ekiplerinin yıldızının parlaması gerekiyor.
Bana sorarsanız PaaS, önümüzdeki bir-iki yılda özellikle Heroku tarzı geliştirici dostu deneyim sunan oyuncuların büyümesiyle hız kazanacak. LAMP tarafında hâlâ ortada güçlü bir PaaS oyuncusu yok; bu boşluğu doldurmaya kimin cesaret edeceği önümüzdeki dönemin ilginç sorularından biri.