IaaS PaaS SaaS Nedir? Bulut Hizmet Modellerinin Farkı

IaaS PaaS SaaS nedir?

IaaS, PaaS ve SaaS, bir bulut hizmetinin ne kadarını sağlayıcının, ne kadarını sizin yönettiğinizi anlatan üç hizmet modelidir. IaaS sanal sunucu, ağ ve depolama gibi altyapıyı, PaaS uygulamanızı çalıştıracak hazır platformu, SaaS ise tarayıcıdan doğrudan kullandığınız bitmiş yazılımı sunar.

Kısacası bu üç kısaltma, mutfaktaki işi kimin yaptığını söyler. Altyapıyı kiralıyorsanız IaaS, kodunuzu hazır bir platforma teslim ediyorsanız PaaS, bitmiş uygulamayı abonelikle açıyorsanız SaaS konuşuyorsunuz. Bu ayrım bütçeyi, güvenliği ve ekibinizin iş yükünü doğrudan etkiler.

Bu rehber tek bir terime odaklanır ve IaaS PaaS SaaS nedir sorusunu başlangıç seviyesinden teknik ayrıntıya kadar açar. Komşu konulara kısa değiniriz; örneğin API nedir ve DevOps nedir yazıları bu modellerin üzerine oturan kavramları ayrıca anlatır.

Pizza benzetmesi IaaS PaaS SaaS nedir sorusunu nasıl açıklar?

Pizza örneği üç modeli bir dakikada oturtur. Evde yapıyorsanız fırın, malzeme, hamur ve masa sizdedir. Bu, şirket içi (on-premise) modele denk gelir. Diğer üç seçenek ise işin ne kadarını başkasına bıraktığınıza göre ayrılır.

• Evde yapmak (şirket içi): Her şeyi siz alır, siz pişirir, siz temizlersiniz. Kontrol tamdır, ama iş yükü de tamamen sizdedir.
• Mutfak kiralamak (IaaS): Fırın ve tezgâh hazırdır. Malzemeyi, tarifi ve pişirmeyi siz üstlenirsiniz.
• Hamuru hazır almak (PaaS): Hamur ve fırın hazırdır. Siz yalnızca üstüne ne koyacağınıza karar verirsiniz.
• Sipariş vermek (SaaS): Pizza sofraya hazır gelir. Sadece yersiniz, tarifi değiştiremezsiniz.

Benzetmenin sınırı şudur: gerçek yazılımda "tarif" sizin verinizdir ve hangi modeli seçerseniz seçin veri sorumluluğu sizde kalır. Bunu aşağıdaki tabloda ayrıntılı göreceksiniz.

Bulut bilişim NIST tanımına göre nedir?

Bulut bilişim, yapılandırılabilir bilişim kaynaklarından oluşan ortak bir havuza ağ üzerinden, talep üzerine ve az çabayla erişme modelidir. Bu tanım, ABD Ulusal Standartlar ve Teknoloji Enstitüsü'nün (NIST) SP 800-145 belgesinde yer alır ve sektörde en çok atıf yapılan kaynaklardan biridir.

NIST bulutu beş temel özellikle tarif eder:

• Talep üzerine self servis: Kaynağı sağlayıcıyla konuşmadan kendiniz açarsınız.
• Geniş ağ erişimi: Telefon, dizüstü bilgisayar gibi farklı cihazlardan ulaşırsınız.
• Kaynak havuzlama: Sağlayıcı aynı donanımı birçok müşteriye paylaştırır.
• Hızlı esneklik: Kaynağı ihtiyaca göre büyütür ya da küçültürsünüz.
• Ölçülebilir hizmet: Kullandığınız kadarı ölçülür ve buna göre ödersiniz.

Aynı belge üç hizmet modelini (SaaS, PaaS, IaaS) ve dört dağıtım modelini (özel, topluluk, genel ve hibrit bulut) ayırır. Bu yazı hizmet modellerine odaklanır; dağıtım modelleri ise "bulutun kime ait olduğunu" anlatır.

IaaS nedir ve neleri kapsar?

IaaS, yani "hizmet olarak altyapı" (Infrastructure as a Service), sanal makine, depolama ve ağ gibi temel bilişim kaynaklarını kiralamanızı sağlar. NIST'e göre bu modelde fiziksel altyapıyı yönetmezsiniz, ama işletim sistemi, depolama ve üzerinde çalışan uygulamalar üzerinde kontrol sahibi olursunuz.

Pratikte bu şu anlama gelir: sunucunun fiziksel bakımını, elektriğini ve ağ donanımını sağlayıcı üstlenir. İşletim sistemi güncellemelerini, güvenlik yamalarını, güvenlik duvarı kurallarını ve yedeklemeyi ise siz yönetirsiniz. Dolayısıyla esneklik en yüksek, operasyon yükü de PaaS ve SaaS'a göre en ağır modeldir.

IaaS şu durumlarda mantıklıdır: eski bir uygulamayı olduğu gibi buluta taşımak, özel bir işletim sistemi ya da yazılım kombinasyonu çalıştırmak ya da kaynak yapısını ince ayarlamak istiyorsanız. Bir VPS (sanal özel sunucu) kiralamak da özünde IaaS kullanmaktır; farkları merak ediyorsanız VPS, VDS ve bulut sunucu farkı yazımıza bakın.

Bir IaaS paketinde genellikle şu parçalarla karşılaşırsınız:

• Sanal makineler: İşlemci ve bellek miktarını seçip işletim sistemini kendiniz kurduğunuz sunucular.
• Depolama: Disk, nesne depolama ve yedek alanı gibi veri saklama seçenekleri.
• Ağ: Sanal ağlar, güvenlik duvarı kuralları ve yük dengeleyici gibi trafik yönetim parçaları.

Bu parçaları birleştirmek ve doğru ayarlamak size kalır. Başka bir deyişle IaaS, size boş bir ofis katı kiralar; masaları, internet bağlantısını ve düzeni siz kurarsınız.

PaaS nedir ve geliştirici neyi kazanır?

PaaS, "hizmet olarak platform" (Platform as a Service), uygulamanızı çalıştıracak hazır ortamı sunar: çalışma ortamı, veritabanı bağlantısı, otomatik ölçekleme ve dağıtım hattı gibi parçalar paketin içindedir. NIST'e göre kendi yazdığınız ya da satın aldığınız uygulamayı bu ortama yüklersiniz, altındaki sunucu, ağ ve işletim sistemini yönetmezsiniz.

Kazanç açıktır. Sunucu yamalamak, ölçekleme ayarlamak ya da işletim sistemi sürümü izlemek gibi işler azalır. Böylece ekip zamanını ürün geliştirmeye ayırır. Küçük ekipler için bu fark, haftalık iş yükünde belirgin hissedilir.

Bedeli ise esneklikten ödersiniz. Platformun desteklediği dil, sürüm ve veritabanı türleriyle çalışmanız gerekir. Ayrıca platforma özgü özellikleri çok kullanırsanız başka yere taşımak zorlaşır. Bu nedenle container (uygulamayı bağımlılıklarıyla paketleyen taşınabilir kutu) mantığı bu riski azaltmak için sık tercih edilir; ayrıntı için Docker nedir yazısına göz atın.

Tipik bir PaaS paketinin içinde şunlar bulunur:

• Çalışma ortamı: Seçtiğiniz programlama diline göre hazır, güncel tutulan ortam.
• Dağıtım hattı: Kodu bağladığınızda uygulamayı otomatik yayına alan akış.
• Yönetilen servisler: Veritabanı, önbellek ve kuyruk gibi hazır bileşenler.
• Ölçekleme ve izleme: Trafik arttığında kaynağı büyüten ve durumu gösteren araçlar.

Dolayısıyla PaaS, "ben yalnızca kodumla ilgilenmek istiyorum" diyen ekiplerin doğal tercihidir.

SaaS nedir ve neden en yaygın model?

SaaS, "hizmet olarak yazılım" (Software as a Service), bitmiş bir uygulamayı genellikle tarayıcı ya da mobil uygulama üzerinden abonelikle kullanmanızdır. E-posta ve takvim, ofis uygulamaları, müşteri ilişkileri yönetimi (CRM), proje takibi ve e-ticaret altyapıları tipik örneklerdir.

Bu modelde sağlayıcı altyapıdan uygulama güncellemesine kadar her şeyi yönetir. Siz hesapları, kullanıcı yetkilerini, uygulama ayarlarını ve içine koyduğunuz veriyi yönetirsiniz. Kurulum beklemeden, aynı gün kullanmaya başlayabilirsiniz.

SaaS'ın en yaygın model olmasının nedeni, işletmelerin çoğunun yazılım yazmak değil, işini yürütmek istemesidir. Ancak sınırı vardır: özelleştirme sağlayıcının izin verdiği kadardır. Bu yüzden iyi bir SaaS ürününün API sunması, verinizi dışa aktarabilmeniz ve başka sistemlerle konuşabilmesi büyük avantajdır.

SaaS ürünlerinin çoğu çok kiracılı (multi-tenant) çalışır. Yani aynı yazılım örneği birçok müşteriye hizmet verir, verileriniz mantıksal olarak ayrılır. Bu yapı maliyeti düşürür ve güncellemeleri herkese aynı anda ulaştırır. Karşılığında, bir özelliğin ne zaman değişeceğine siz değil sağlayıcı karar verir. Bu yüzden büyük bir değişiklik duyurusunu izlemek ve kritik iş akışlarınızı bu açıdan gözden geçirmek iyi bir alışkanlıktır.

Kim neyi yönetir? Paylaşılan sorumluluk modeli nasıl işler?

Her modelde sorumluluk katmanlara bölünür. Alttaki fiziksel katmanları sağlayıcı, üstteki katmanları siz yönetirsiniz; modelden modele çizgi yukarı ya da aşağı kayar. Aşağıdaki tablo bu dağılımı gösterir.

Tablonun en önemli satırı ikincisidir: verinizin ve kimin neye erişeceğinin sorumluluğu hiçbir modelde sağlayıcıya geçmez. Sağlayıcılar bu yaklaşımı "paylaşılan sorumluluk modeli" olarak yayımlar; örneğin AWS paylaşılan sorumluluk modeli sayfası bunu kendi hizmetleri için anlatır. Ayrıntılar sağlayıcıya göre değiştiği için sözleşmedeki güncel ayrıma bakmanız gerekir.

Tabloyu okurken iki noktaya dikkat edin. Birincisi, soldan sağa gittikçe sizin yönettiğiniz katman sayısı azalır, ama sıfıra inmez. İkincisi, "Sağlayıcı" yazması işin kendiliğinden doğru yapıldığı anlamına gelmez. Yama ve yedekleme sağlayıcının sorumluluğunda olsa bile hangi seviyede ve hangi sıklıkta yapıldığını sözleşmeden ve hizmet açıklamasından kontrol etmeniz gerekir.

Bu üç model neden ortaya çıktı ve neden önemli?

Eskiden her şirket kendi sunucu odasını kurar, donanımı satın alır ve bakımını üstlenirdi. Bu yaklaşım yüksek ön yatırım ve uzun kurulum süresi demekti. Bulut, kaynağı kiralık hale getirerek bu engeli azalttı. Hizmet modelleri ise bu kiralamanın hangi katmandan başladığını standartlaştırdı.

Önemi üç noktada toplanır:

• Konuşma dili: Ekipler, sağlayıcılar ve yöneticiler aynı kelimelerle aynı şeyi kastettiğinde toplantılar kısalır.
• Sorumluluk netliği: Bir arıza ya da güvenlik olayında kimin neye bakacağı baştan bellidir.
• Karar kalitesi: Maliyet ve risk karşılaştırması, doğru kategoride yapıldığında anlamlı hale gelir.

FaaS ve serverless bu üçlünün neresinde durur?

FaaS, "hizmet olarak fonksiyon" (Function as a Service), kodunuzu küçük fonksiyonlar halinde yüklediğiniz ve yalnızca bir olay tetiklendiğinde çalışan modeldir. Serverless (sunucusuz) ifadesi çoğu zaman bu yaklaşımı ve onun etrafındaki yönetilen hizmetleri anlatır. Elbette sunucu yoktur demek değildir; sunucuyu sizin yerinize sağlayıcı yönetir.

NIST'in özgün tanımında FaaS ayrı bir model olarak geçmez. Sektör bunu genellikle PaaS'ın daha ince bir hali olarak görür. Fark şudur: PaaS'ta uygulamanız sürekli çalışan bir ortama yerleşir, FaaS'ta ise fonksiyon yalnızca gerektiğinde çalışır ve kullanılmadığında kaynak tüketmez.

Bu modelin bilinen bir sorusu da ilk çağrıdaki gecikmedir. Bunu ve serverless'ın ne zaman uygun olduğunu ayrı bir yazıda ele aldık: serverless nedir ve cold start ne demek. Burada tekrar etmeyeceğiz.

IaaS, PaaS, SaaS ve şirket içi model nasıl karşılaştırılır?

Aşağıdaki karşılaştırma, dört yaklaşımı işletme gözüyle yan yana koyar. Değerler nitelikseldir; fiyat ya da süre içermez, çünkü bunlar sağlayıcıdan sağlayıcıya ve zamana göre değişir.

Tablodan çıkan basit sonuç şudur: kontrol arttıkça sorumluluk da artar. Yani hiçbir model "en iyi" değildir, yalnızca işinize ve ekibinizin gücüne daha uygun olanı vardır.

Her model için örnek senaryolar neler?

Aşağıdaki dört örnek senaryo kurgudur; gerçek bir müşteriyi ya da sonucu anlatmaz. Amaç, modelin hangi ihtiyaçta öne çıktığını göstermektir.

• IaaS senaryosu: Orta ölçekli bir firma yıllardır kendi sunucusunda çalışan özel bir stok yazılımını taşımak istiyor. Yazılım belirli bir işletim sistemi sürümüne bağlı. Sanal makine kiralayarak uygulamayı neredeyse hiç değiştirmeden buluta alıyor.
• PaaS senaryosu: Üç kişilik bir ekip müşteri randevu uygulaması geliştiriyor. Sunucu yönetecek kimse yok. Kodu bir platforma bağlıyor, veritabanı ve ölçekleme hazır geliyor, ekip yalnızca özellik geliştiriyor.
• Karma senaryo: Bir e-ticaret ekibi mağaza yazılımını hazır SaaS olarak kullanıyor, kendi kampanya motorunu PaaS üzerinde çalıştırıyor, yıllardır duran eski bir raporlama aracını ise IaaS'ta tutuyor. Her parça için sorumluluk farklı, ama ekip hepsini aynı tabloda izliyor.
• SaaS senaryosu: Küçük bir butik ofis müşteri takibi ve teklif hazırlama için hazır bir CRM aboneliği açıyor. Aynı gün kullanmaya başlıyor, güncellemeleri izlemek zorunda kalmıyor.

Bu örneklerde ürün adı vermedik, çünkü önemli olan modelin mantığıdır. Aynı mantık hangi sağlayıcıda olursanız olun geçerlidir.

Maliyet öngörüsü açısından modeller nasıl farklılaşır?

Maliyeti yalnızca aylık faturayla ölçmek yanıltıcıdır. Toplam sahip olma maliyeti (TCO) lisansı, kaynak kullanımını, ekibin harcadığı zamanı ve bir arıza anında oluşacak kaybı birlikte içerir. Bu yazıda fiyat vermiyoruz; güncel tarifeleri sağlayıcının resmi sayfasından kontrol etmeniz gerekir.

Modellerin maliyet davranışı şöyle ayrışır:

• IaaS: Kullanılan kaynağa göre değişir. Boşta bekleyen sanal makine de fatura üretir, bu yüzden izleme ve kapatma disiplini gerekir.
• PaaS: Genellikle uygulama boyutuna ve trafiğe göre ölçeklenir. Operasyon maliyeti düşer, ama platform kullanımı arttıkça fatura da büyüyebilir.
• SaaS: Çoğunlukla kullanıcı sayısına ya da pakete bağlıdır. Öngörmesi en kolay modeldir, ama kullanıcı sayısı büyüdükçe toplam tutar da büyür.

Öte yandan bütçe öngörüsü için bir kullanım üst sınırı ve uyarı eşiği belirlemek her üç modelde işe yarar. Böylece ay sonunda sürpriz fatura görmezsiniz.

Satıcıya bağımlılık riski nedir ve nasıl azaltılır?

Satıcıya bağımlılık (vendor lock-in), bir sağlayıcının özel özelliklerine o kadar bağlanmanızdır ki başka yere geçmek pahalı ya da pratikte imkânsız hale gelir. SaaS'ta veri formatı ve entegrasyonlar, PaaS'ta platforma özgü servisler, IaaS'ta ise sağlayıcıya özel yönetim araçları bu riski doğurabilir.

Riski sıfırlayamazsınız, ama azaltabilirsiniz:

1. Verinizi düzenli aralıklarla standart bir biçimde dışa aktarın ve geri yüklemeyi gerçekten deneyin.
2. Uygulamayı mümkün olduğunca taşınabilir paketleyin; container yaklaşımı burada yardımcı olur.
3. Sağlayıcıya özel bir servisi seçerken "bunu yarın değiştirmem gerekirse ne olur" sorusunu yazılı cevaplayın.
4. Sözleşmede veri iadesi ve hizmet sonlandırma koşullarını okuyun.
5. Açık standartları destekleyen ürünleri, eşit koşulda tercih edin.

Docker ile Kubernetes arasındaki ilişkiyi de merak ediyorsanız Kubernetes ve Docker farkı yazısı iyi bir devam noktasıdır.

Veri yeri, KVKK ve GDPR bulut modelini nasıl etkiler?

Verinizin hangi ülkede, hangi sağlayıcıda ve hangi koşullarla durduğu hukuki açıdan önemlidir. Kişisel veri işliyorsanız Türkiye'de KVKK, Avrupa'da ise GDPR (Avrupa Genel Veri Koruma Tüzüğü) gündeme gelir. Bu bölüm genel bir bilgidir ve hukuki danışmanlık değildir; somut durumunuz için hukuk danışmanınıza başvurun.

Genel çerçeve her modelde benzerdir:

• Veri sorumlusu çoğu zaman sizsiniz. Sağlayıcı, sizin adınıza veri işleyen rolünde olabilir.
• Verinin saklandığı bölgeyi ve yurt dışına aktarım koşullarını sözleşmeden kontrol edin.
• Yedeklerin ve günlük kayıtlarının nerede durduğunu da sorun.
• Alt işleyici (sağlayıcının kullandığı başka firmalar) listesini isteyin.

Web sitesi tarafındaki uyum adımları için KVKK ve GDPR uyumlu web sitesi rehberimize bakabilirsiniz. Resmi metin için GDPR'ın AB mevzuat sayfasını kontrol etmek en güvenli yoldur.

Bulutta güvenlik sorumluluğunun sizde kalan kısmı nedir?

Sağlayıcı fiziksel tesisi ve altyapıyı korur, ama hesabınızın güvenliği sizin elinizdedir. Bulut olaylarının önemli bir kısmı karmaşık saldırılardan değil, yanlış yapılandırmadan ve zayıf erişim denetiminden doğar. Bu yüzden her modelde aynı temel işleri yapmanız gerekir.

• Çok adımlı doğrulamayı (MFA) tüm yönetici hesaplarında açın.
• Her kullanıcıya yalnızca işi için gereken yetkiyi verin.
• Genel erişime açık depolama alanlarını ve gereksiz portları düzenli kontrol edin.
• Yedeklerinizi ayrı bir yerde tutun ve geri yüklemeyi test edin.
• Sertifika ve alan adı ayarlarını izleyin; SSL sorgulama aracımız sertifikanızın durumunu hızlıca gösterir.

Uygulamalar arası yetkilendirme kuruyorsanız OAuth 2.0 nedir yazısı, kimlik ve yetki mantığını sade biçimde anlatır.

Genel, özel, hibrit ve çoklu bulut hizmet modelleriyle karışır mı?

Hayır, ama sık karışır. Hizmet modelleri "ne aldığınızı" anlatır; dağıtım modelleri ise "bulutun kime ait olduğunu" anlatır. İkisi birbirinden bağımsız eksenlerdir. Örneğin genel bulutta IaaS de alabilirsiniz, SaaS de.

• Genel bulut: Altyapıyı bir sağlayıcı herkese açık sunar.
• Özel bulut: Altyapı yalnızca tek bir kuruma ayrılır, kurumun kendisi ya da bir üçüncü taraf işletebilir.
• Topluluk bulutu: Ortak gereksinimi olan birkaç kurum altyapıyı paylaşır.
• Hibrit bulut: Birden çok dağıtım modelini birbirine bağlayarak birlikte kullanırsınız.

Çoklu bulut ise farklı sağlayıcıların hizmetlerini bir arada kullanma tercihidir. Satıcıya bağımlılığı azaltabilir, ama yönetim karmaşıklığını artırır. Küçük ekipler için çoğu zaman tek sağlayıcıyla sade başlamak daha sağlıklıdır.

CaaS, DaaS, BaaS ve XaaS gibi kısaltmalar ne anlama gelir?

Sektörde "hizmet olarak" kalıbı çoğalmıştır. Bu kısaltmalar resmi bir standart değil, pazarlama ve mühendislik dilinin ürünüdür. Bu yüzden her biri farklı kaynakta biraz farklı tanımlanabilir.

• CaaS (Container as a Service): Container çalıştırmak ve yönetmek için hazır platform sunar.
• DaaS (Desktop as a Service): Sanal masaüstünü bulutta sunar.
• BaaS (Backend as a Service): Mobil ve web uygulamaları için hazır arka uç parçaları verir.
• XaaS: "Her şey hizmet olarak" demenin şemsiye adıdır.

Çoğu kısaltma, üç temel modelin bir yerine oturur. Bir ürünle karşılaştığınızda "bunda ben neyi yönetiyorum" sorusunu sormak, kısaltmanın ne dediğinden daha güvenilir bir yol gösterir.

Kendi sunucunuzda PaaS kurmak mümkün mü?

Evet, mümkün. Bir IaaS ya da VPS kiralayıp üzerine PaaS benzeri bir katman kurabilirsiniz. Böylece dağıtım, SSL ve veritabanı gibi işleri tek panelden yönetirsiniz, ama altındaki sunucunun bakımı yine size aittir. Yani sorumluluk çizgisini aşağı çekmiş olursunuz.

Bu yaklaşımın cazibesi kontrol ve öngörülebilirliktir. Riski ise yedekleme, güvenlik yaması ve izleme işlerinin sizde kalmasıdır. Küçük bir ekip için bu fazladan yük, hazır bir PaaS'ın bedelinden daha ağır olabilir. Karar vermeden önce kendi zamanınızın maliyetini hesaba katın.

Bu seçeneği ayrıntılı ele alan Coolify nedir ve kendi sunucunda PaaS nasıl kurulur rehberimiz var; burada yalnızca modelin neresine oturduğunu belirtiyoruz. Altyapı seçiminde kullandığınız alan adı kayıtlarını görmek için DNS sorgulama aracı işinize yarar.

Bulut, sanallaştırma, hosting ve container terimleri nasıl ayrılır?

Bu kavramlar sık karışır, çünkü hepsi "sunucu kiralamak" fikrinin etrafında dolanır. Kısa bir ayrım, kafa karışıklığını çoğunlukla çözer.

• Bulut bilişim: Kaynakları ağ üzerinden, talep üzerine ve kullanım ölçümüyle sunan genel model. IaaS, PaaS ve SaaS bunun hizmet katmanlarıdır.
• Sanallaştırma: Tek fiziksel makineyi birden çok sanal makineye bölen teknoloji. Bulutun yapı taşlarından biridir, ama tek başına bulut değildir.
• Hosting (barındırma): Web sitenizi çalıştıracak alanı kiralamak. Paylaşımlı hosting çoğu zaman PaaS ile SaaS arasında bir yerde konumlanır.
• Container: Uygulamayı bağımlılıklarıyla paketleyen taşınabilir birim. Hangi modelde olursanız olun uygulamayı taşınabilir kılar.
• Kubernetes: Çok sayıda container'ı yöneten orkestrasyon sistemi. Genellikle IaaS ya da PaaS üzerinde çalışır.

Sitenizin hangi altyapıyı kullandığını merak ediyorsanız site altyapı tespit aracımız ilk ipucunu verir.

API, DevOps ve veritabanı seçimi bu modellerle nasıl ilişkilidir?

Bulut modelini seçmek tek başına yeterli değildir; üstüne konan parçalar da önemlidir. API, SaaS ürünlerini kendi sisteminize bağlayan köprüdür. Örneğin CRM'inizdeki bir müşteri kaydı API üzerinden faturalama sisteminize akabilir.

DevOps ise geliştirme ve işletme ekiplerinin ortak çalışma kültürüdür. IaaS ve PaaS tercihinde, dağıtımı otomatikleştirme ve izleme alışkanlıkları sonucu belirler. Yani modeli seçmek kadar, onu nasıl işlettiğiniz de önemlidir.

Veritabanı tarafında da benzer bir ayrım vardır. Veritabanını kendiniz kurup yönetirseniz bu IaaS mantığıdır; sağlayıcının yönettiği bir veritabanı kullanırsanız PaaS mantığına yaklaşırsınız. Hangi veri türüne hangi veritabanının uyduğunu görmek için NoSQL nedir ve SQL farkı yazısına bakabilirsiniz.

İşletme için IaaS PaaS SaaS nedir ve hangisi ne zaman seçilir?

Pratik bir sıra önerisi şudur: önce hazır bir SaaS işinizi karşılıyor mu diye bakın. Karşılamıyorsa PaaS, PaaS de yetmiyorsa IaaS düşünün. Bu sıra, en az operasyon yüküyle başlayıp yalnızca gerektiğinde kontrolü artırmanızı sağlar.

• SaaS seçin: İhtiyacınız yaygın bir iş süreciyse (e-posta, takvim, müşteri takibi, proje yönetimi) ve özel bir kuralınız yoksa.
• PaaS seçin: Kendi yazılımınızı geliştiriyorsanız, sunucu yönetecek ekibiniz küçükse ve hızlı yayına çıkmak istiyorsanız.
• IaaS seçin: Özel bir işletim sistemi, lisans ya da ağ yapısı gerekiyorsa veya mevcut bir uygulamayı hızlıca taşıyorsanız.
• Şirket içini seçin: Mevzuat, gecikme ya da çok özel donanım gereksinimi başka seçenek bırakmıyorsa.

Şirket içi model hâlâ geçerlidir. Özellikle ağ gecikmesinin kritik olduğu, yerel mevzuatın veriyi belirli bir tesiste tutmayı gerektirdiği ya da çok özel donanım kullanılan durumlarda mantıklı kalır. Ancak bunu bilinçli bir tercih olarak seçin, alışkanlıktan değil.

Çoğu işletme tek model kullanmaz. Örneğin ofis işleri için SaaS, ürününüz için PaaS, eski bir sistem için IaaS birlikte yaşayabilir. Önemli olan her parçada sorumluluğun kimde olduğunu bilmektir.

Karar vermeden önce IaaS PaaS SaaS nedir kontrol listesi neleri içerir?

Aşağıdaki liste, sağlayıcı ya da model seçmeden önce ekibinizle birlikte cevaplayabileceğiniz soruları toplar. Cevapları yazılı tutmak, altı ay sonra neden o kararı verdiğinizi hatırlatır.

1. Bu iş için hazır bir SaaS ürünü var mı ve gerçekten ihtiyacımızı karşılıyor mu?
2. Ekibimizde sunucu, yama ve izleme işini yürütecek kişi var mı?
3. Özel işletim sistemi, belirli bir yazılım sürümü ya da lisans zorunluluğumuz var mı?
4. Verimiz hangi ülkede duracak ve hangi kişisel veri türlerini içeriyor?
5. Sağlayıcıdan çıkmak istesek veriyi hangi biçimde, ne kadar kolay alırız?
6. Ölçek büyürse maliyet nasıl davranır ve harcama uyarısı kurabiliyor muyuz?
7. Yedekleme ve geri yükleme sorumluluğu kimde?
8. Kimlik doğrulama ve yetkilendirmeyi hangi yöntemle yöneteceğiz?

Bu soruların çoğuna net cevap veremiyorsanız, bu normaldir. O durumda küçük bir deneme projesiyle başlayıp öğrendikçe modeli güncellemek akıllıca olur.

Bulut modeli seçerken en sık yapılan hatalar neler?

Aynı hatalar farklı ekiplerde tekrar eder. Bunları bilmek, zaman ve emek kazandırır.

• "Bulut otomatik olarak güvenlidir" varsaymak: Hesap güvenliği ve yapılandırma sizde kalır.
• Kullanılmayan kaynakları kapatmamak: Özellikle IaaS'ta boşta kalan makine masraf yazar.
• Yedeği hiç geri yüklemeyi denememek: Yedek, ancak geri döndüğünde yedektir.
• Tek bir sağlayıcının özel servislerine çıkış planı olmadan bağlanmak.
• SaaS ürününü seçerken veri dışa aktarma ve API desteğine bakmamak.
• Model seçimini yalnızca ilk ay faturasına göre yapmak.
• Sorumluluk dağılımını sözleşmeden okumadan "sağlayıcı hallediyor" demek.

Bu listedeki hataların hiçbiri teknik olarak zor değildir; çoğu, acele edilen bir karar anında atlanan basit bir kontrolden doğar. Çoğunun ortak kökü şudur: kim neyi yönetiyor sorusu baştan netleşmemiştir. Bu yazıdaki tablo, o sorunun cevabını sormak için iyi bir başlangıçtır.

Özel yazılım projenizde bulut modelini nasıl netleştirirsiniz?

Özel yazılım geliştirirken bulut modeli, mimari kararın erken parçalarından biridir. Çünkü seçtiğiniz model, kodun nasıl paketleneceğini, hangi hizmetlerin hazır alınacağını ve ekibin neyle uğraşacağını belirler. Sonradan değiştirmek mümkündür, ama maliyetlidir.

Talha Aslan ve ekibi olarak yazılım projelerinde işe, iş hedefini ve ekip kapasitesini konuşarak başlarız. Ardından hangi parçanın hazır SaaS ile, hangisinin kendi geliştireceğiniz yazılımla karşılanacağını ayırırız. Bu planı özel yazılım geliştirme hizmetimiz çerçevesinde birlikte netleştirebiliriz.

Sonuç olarak IaaS, PaaS ve SaaS bir yarış değil, bir sorumluluk dağılımı tercihidir. Doğru model, işinizin ihtiyacıyla ekibinizin gücünün kesiştiği yerdedir. Resmi kaynaklara dayanmak için Google Cloud'un model karşılaştırma sayfası ve Azure IaaS açıklaması iyi tamamlayıcı okumalardır.