PaaS ve IaaS Üzerinde Geliştirme Süreçleri

Bulut bilişimle birlikte yazılım dağıtımının nasıl yapıldığını yeniden konuşmak zorunda kaldık. Geçen sene piyasada iki temel akım iyice belirginleşti: bir taraf size sanal makine veriyor ve “buyrun, üzerine ne kurarsanız kurun” diyor, buna IaaS (Infrastructure as a Service) diyoruz. Diğer taraf size hazır bir çalıştırma ortamı, veritabanı ve kuyruk veriyor; siz sadece kodu yüklüyorsunuz, buna da PaaS (Platform as a Service) diyoruz. Bu yazıda iki modelin geliştirme sürecini, günlük operasyonları ve gerçek hayat kararlarını karşılaştıracağım.

IaaS Üzerinde Geliştirme

IaaS dünyasının bugünkü iki büyük oyuncusu Amazon Web Services (EC2 + EBS + S3) ve Rackspace (Cloud Servers + Cloud Files). Ek olarak GoGrid, Joyent ve Terremark gibi alternatifler de mevcut.

Sağlama (Provisioning)

EC2’de bir sunucu açmak şuna benziyor: AMI (Amazon Machine Image) seçiyorsunuz; instance tipini (m1.small, m1.large, c1.xlarge gibi) belirliyorsunuz; security group ve key pair eşleştiriyorsunuz; en geç bir-iki dakikada sunucu ayakta. Rackspace tarafında benzer akış var, sadece “flavor” denen RAM odaklı bir boyutlandırma yapıyorsunuz. İki tarafta da self-service portal var, API var, komut satırı araçları var.

Dağıtım (Deployment)

Bu noktada artık sorumluluk tamamen sizde. Bir Linux sanal sunucu açtığınızda üzerine kendi yığınınızı (LAMP, LEMP, Tomcat + JBoss, Mongrel/Passenger, vs.) kurmak zorundasınız. Yapılandırma yönetimi için yaygın seçenekler:

Puppet: 2005’ten beri sahnede, Ruby ile yazılmış. Bildiri tabanlı (declarative) yapılandırma açıklamasıyla onlarca sunucuyu aynı duruma getiriyor.
Chef: Opscode tarafından geliştirilen, 2009’da çıkmış, Puppet’a alternatif. Daha esnek ve Ruby DSL’ine yakın.
Capistrano: Rails dünyasından gelen klasik SSH tabanlı dağıtım aracı.

Bu araçlar olmadan IaaS üstünde 5–10 sunucudan fazlasını yönetmeyi gözümde bile canlandırmıyorum.

Ölçekleme

EC2 tarafında 2009’da gelen Auto Scaling grupları sayesinde CloudWatch metriklerine bağlı olarak otomatik sunucu ekleme/çıkarma yapabiliyorsunuz. Önüne Elastic Load Balancer (ELB) koyup yatay ölçeklemeyi otomatize etmek artık standart pratik. Rackspace tarafında benzer yetenekler henüz CloudKick (Aralık 2010’da Rackspace satın aldı) entegrasyonu üzerinden olgunlaşıyor.

Ölçeklemenin yazılım tarafında size bıraktığı yük şu: uygulamanız stateless olmalı, oturum (session) verisini paylaşımlı bir yere (memcached, Redis, veritabanı) taşımalısınız, dosya yüklemelerini S3/Cloud Files gibi nesne depolama servislerine yönlendirmelisiniz. Yani ölçekleme “düğmesi” var ama uygulamanın o düğmeye uygun yazılması sizin işiniz.

Gözlem (Observability)

CloudWatch (AWS) ve CloudKick (Rackspace) temel metrikleri (CPU, ağ, disk) sağlar. Uygulama tarafı için Nagios, Zabbix, Cacti, Munin gibi açık kaynak araçlar; SaaS tarafında Pingdom, New Relic (henüz çok yeni) gibi seçenekler var. Log toplamak için syslog-ng + bir merkezi sunucu, ya da Splunk gibi ticari çözümler kullanılıyor.

Bakım Yükü

IaaS’in en büyük gizli maliyeti bakım yükü. Güvenlik yamaları (özellikle kernel CVE’leri), veritabanı yedeklemeleri, log rotation, sertifika yenilemeleri… Hepsi sizin sorumluluğunuzda. 24/7 birinin nöbette olması gerekiyor. Küçük takımlar için bu yük gerçekten ağır.

PaaS Üzerinde Geliştirme

PaaS dünyasında bugün konuşulan üç büyük oyuncu var: Google App Engine, Windows Azure (PaaS tarafı; özellikle Web ve Worker Roles) ve Heroku (Aralık 2010’da Salesforce satın aldı). Ek olarak Engine Yard (Ruby/Rails odaklı), Force.com (Salesforce’un kendi platformu) ve VMware’in vFabric tarafı gözlemde tutulması gereken oyuncular.

Sağlama

App Engine için sağlama diye bir konu yok; uygulamayı dağıttığınız anda altyapı sizin için ayarlanıyor. Heroku’da heroku create komutu projeyi platforma kaydediyor; saniye düzeyinde. Azure tarafında biraz daha klasik bir akış var: Azure Portal üzerinden Cloud Service oluşturuyorsunuz, paketinizi (cspkg) yüklüyorsunuz.

Dağıtım

PaaS’ın esas vaadi burada. Heroku tarafında “git push heroku master” üç kelimesi her şeyi anlatıyor: kodu push ediyorsunuz, Heroku sizin için Bamboo yığınında derliyor, gerekirse bağımlılıkları (gem’leri) çekiyor, dyno’lara yerleştiriyor ve trafik anahtarını yeni sürüme çeviriyor. App Engine’de appcfg.py update benzer bir akış sağlıyor. Azure’da Visual Studio entegrasyonu üzerinden “Publish” yetiyor.

Bu hızın bedeli kısıtlar: App Engine’de yerel dosya yazamazsınız, uzun süren request’ler (30 saniyenin üzerinde) çalıştıramazsınız, sadece desteklenen kütüphaneleri kullanırsınız. Heroku’da benzer kısıtlar var; Azure’da daha esnek bir alan tanınıyor (Worker Role kavramı uzun süreli işler için zaten tasarlandı).

Veri Katmanı

Burada PaaS dünyasının özgün çözümleri devreye giriyor:

App Engine: Datastore, Bigtable üzerinde çalışan NoSQL deposu. SQL beklentilerinizi unutmanız gerekiyor; sorgular ve ilişkiler farklı düşünülmek zorunda.
Azure: SQL Azure (yönetilen SQL Server) ve Table Storage (NoSQL) birlikte sunuluyor. Mevcut .NET kod tabanını taşımak görece kolay.
Heroku: PostgreSQL eklentisi standart. Ek olarak Redis, Memcached, MongoDB gibi add-on’lar marketplace üzerinden tek tıkla devreye alınabiliyor.

Ölçekleme

PaaS’ın çekici yanı: “scale” düğmesi gerçekten var ve hemen çalışıyor. Heroku’da heroku ps:scale web=10 komutuyla on dyno açıyorsunuz. App Engine ölçeklemeyi tamamen otomatik yapıyor ve siz sadece quota’larla uğraşıyorsunuz. Azure’da instance count’u portaldan ayarlıyorsunuz; otomatik ölçekleme için ek bir politika kurmanız gerekiyor.

Uygulama açısından beklenti aynı: stateless yazın, oturumu paylaşımlı bir yere koyun, dosyaları doğru servise koyun. Yani disiplin değişmiyor; sadece altyapı tarafının yükü sırtınızdan iniyor.

Gözlem

PaaS sağlayıcıları temel metrikleri ve log akışını platform içinde sunuyor. Heroku’nun “heroku logs —tail” komutu güzel bir örnek. App Engine’in dashboard’unda istek başına süre, hata oranı, datastore kullanımı görülebiliyor. Derin profil çıkarma ihtiyacı için Heroku tarafında New Relic eklentisi standart hâle gelmiş durumda.

Bakım Yükü

Bu kısımda PaaS belirgin biçimde kazanıyor. Kernel güncellemesi, runtime yaması, veritabanı yedekleme, SSL terminasyonu… Hepsi platformun işi. Küçük ekiplerin geceleri rahat uyuyabilmesinin tek yolu PaaS gibi duruyor.

Karşılaştırma Tablosu

Boyut	IaaS (EC2/Rackspace)	PaaS (App Engine/Azure/Heroku)
Sağlama süresi	1–2 dakika	Saniyeler
Dağıtım	Yapılandırma yönetimi gerekli (Puppet/Chef)	Tek komut
Yığın seçimi	Tamamen serbest	Sağlayıcı sınırlı
Ölçekleme	Auto Scaling kurulumu sizin	Tek düğme / otomatik
Veritabanı	Kendiniz kuruyorsunuz (RDS hariç)	Yönetilen
Bakım yükü	Yüksek	Çok düşük
Birim maliyet	Genellikle daha ucuz	Trafiği kestirmek zor
Kilitlenme (lock-in)	Düşük (Linux + standart yığın)	Yüksek (App Engine API’lerine yapışıyorsunuz)

Hangi Senaryoda Hangisini Seçmeli?

Klasik web uygulaması, küçük ekip, hızlı MVP: Heroku ya da App Engine açık ara öne çıkıyor.
Mevcut on-premise yığınınızı (örneğin .NET + SQL Server) buluta taşımak: Azure neredeyse organik bir seçim.
Özel ihtiyaçlar (örneğin GPU iş yükleri, gerçek zamanlı oyun sunucusu, özel kernel modülleri): IaaS şart.
Geliştirme sürecini hızlandırmak istiyorsunuz ama belirli bir sağlayıcıya bağlanmaktan çekiniyorsunuz: IaaS + Puppet/Chef ile kendi PaaS’ınızı kurabilirsiniz; bu Netflix gibi ekiplerin yıllardır izlediği yol.

Önümüzdeki Yıl İçin Beklentim

PaaS dünyasının önümüzdeki 12 ayda büyük olgunlaşma yaşayacağını düşünüyorum. Salesforce’un Heroku’yu satın alması, VMware’in vFabric ekosistemi, Microsoft’un Azure tarafında VM Role ile IaaS’a yaklaşması, hepsi PaaS ve IaaS arasındaki sınırın bulanıklaşacağına işaret ediyor. Ayrıca özel bulutta (private cloud) çalışabilen açık kaynaklı PaaS çatılarının yıl içinde sahneye gireceğini tahmin ediyorum. Bu Türkiye’deki kurumsal bulut tartışmasını çok daha somut bir yere taşıyacak.

Geliştirici tarafında benim önerim şu: bir kez de olsa hem IaaS hem PaaS tarafında bir küçük proje çıkarın. İki dünyanın tatlı-acı yanlarını yaşamadan, ekibinizdeki bir sonraki teknoloji kararı için sağlıklı bir his geliştirmeniz çok zor.