Bulut Hizmet Sağlayıcısı Seçerken Nelere Dikkat Edilmeli?

Bulut hizmetleri artık Dünya genelinde kabul görmüş ve gerek gelişmiş ülkeler gerekse gelişmekte olan ülkeler tarafından çok yoğun bir şekilde kullanılmaya başlanmıştır. Her ülke ve bu ülke içerisindeki şirketler için bu seçimin farklı sebepleri olduğu kadar, rekabet, fiyat avantajı, kullandığın kadar öde modeli, sorumluluk paylaşımı, uzman personel ihtiyacının az olması başta olmak üzere hepimizin bildiği pek çok ortak sebepte bulunmaktadır.

Bende 2010 yılından bu yana ülkemiz içerisinde bulut bilişim ve bulut hizmetlerini anlatan bir insan olarak özellikle pandemi ile bu konuda çok yoğun direnç gösteren şirketlerin dahi bulut bilişimin gücünü anladığı ve bu dönemde geçiş yaptığına şahit oldum. Tabi hızlı bir geçiş sürecinde insanların en çok sorduğu soruların başında “bulut hizmet sağlayıcısını seçerken nelere dikkat etmeliyim?” oldu. Burada tabi ki her zaman olduğu gibi benim cevabım öncelikle iş ihtiyaçlarınızın belirlenmesi gerektiği şeklinde oluyor. Yani “bulut” dediğimiz zaman herkesin farklı bir anlayışı ve bakış açısı olabilir. Örneğin şirket içerisindeki veri merkezleri iş yükünün Türkiye lokasyonunda barındırılan veri merkezlerine taşınması ve buradan sunucu barındırma dışında tabi ki Azure, AWS veya Google Cloud’ ın sunduğu benzer hizmetlerin alınması yaygın bir modeldir. Buna daha çok “özel bulut” ismini veriyoruz. Bu işi Türkiye de çok profesyonelce yapan butik veya büyük bulut hizmet sağlayıcı şirketler bulunmaktadır. Ya da ihtiyaç duyulan servislerin Türkiye sınırlarında hizmet sunan yerel bulut hizmet sağlayıcılarının karşılayamaması durumunda ya da başka bir iş ihtiyacı nedeni ile (Örneğin global projelerde genelde iş ortakları global veri merkezlerinde barındırma talep edebiliyor) global ve bizim “public cloud” yani herkese açık bulut hizmet alt yapısını sunan Microsoft, Amazon ya da Google gibi şirketlerin veri merkezlerini kullanabilirler.

Şimdi olaya böyle bakınca buluta geçiş stratejisi nasıl olmalıdır? Nelere dikkat etmemiz gerekiyor? Bu seçimi nasıl yapmalıyız?

Bu konuda öncelikle şirketinizin iş ihtiyaçlarını belirlemeniz gereklidir, bu iş ihtiyaçlarına göre seçeceğiniz bulut alt yapısı genel bir bulut veya özel bir bulut olabilir. Bazen hem kendi veri merkeziniz hem de genel ve özel bulut ile Hibrit bir model kurabilirsiniz. Hatta hepsinin bir arada olduğu yani hem kendi şirketinizdeki veri merkezi hem genel hem de özel bulut olmak üzere 3 farklı platformu aynı anda çalıştırabilirsiniz. Burada karar verici en önemli faktörler sizin iş ihtiyaçlarınızdır. Örneğin KVKK veya network gecikmesi gibi konular öncelikli ise genel bulut seçimi zorlaşır, ancak genel bulut üzerinde örneğin yapay zekâ çalıştırma, makine öğrenmesi, IoT veya benzeri yerel bir bulut sağlayıcıda bulamadığınız bir hizmet içinde verilerin Türkiye sınırlarında olan ama hizmet veya servisin genel bulut üzerinde çalışan bir Hibrit modeli seçebilirsiniz.

Peki genel veya özel bulut seçimi yaparken endüstri standartları nelerdir? Her uzmanın mutlaka ufak tefek farklı yorumları olsa da genel kabul görmüş kriterler aşağıdaki gibidir;

  • Sertifikasyon ve Standartlar
  • Veri Güvenliği, Veri yönetimi ve İş Politikaları
  • Kullanılan Teknolojiler & Yenilikler için Yol Haritaları
  • Hizmet Bağımlılıkları ve Ortaklıklar
  • Sözleşmeler ve SLA Şartları
  • Güvenilirlik ve Performans
  • Taşınma ve Çıkış Planı Desteği
  • Şirket Profili

Sertifikasyon ve Standartlar

Bulut hizmet sağlayıcı seçerken en çok kontrol edilen konuların başında şirketin sahip olduğu sertifikasyon ve standartlar gelmektedir. Basit anlamda 27001 sertifikası olmayan bir bulut sağlayıcı ile olan bir bulut sağlayıcı arasından bundan sonra sayacağım pek çok madde de ister istemez farklar olacaktır. Verinin nerede tutulduğu, kaç kopyasının olduğu, kimler tarafından erişilebilir olduğu, erişim loğları başta pek çok güvenlik anlamında standarttı içeren 27001 burada geçerli bir sertifikasyon olup global bir şirket için ise yukarıdaki gibi pek çok standarttın olması büyük bir avantaj sağlar.

Veri Güvenliği, Veri yönetimi ve İş Politikaları

GDPR, KVKK gibi veri güvenliğini sağlayan kanunlar düşünüldüğü zaman sizlerin de verilerinizi barındırmak için seçeceğiniz şirketin bu konudaki politikalarını iyi incelemeniz gereklidir.

Belirli gereksinimleriniz ve yükümlülükleriniz varsa, verilerinizin depolandığı, işlendiği ve yönetildiği bu platformlar içerisinden seçim ve kontrol sağlayan sağlayıcılar aramalısınız. Bulut hizmeti sağlayıcıları, veri merkezi konumları konusunda şeffaf olmalıdır, verilerin nasıl saklandığı, işlendiği veya iletildiği ile ilgili mutlaka bir politikaya sahip olmalıdır.

Yine platformun, sağlayıcıdan bağımsız hareket eden veriyi şifrelenmesi yoluyla koruma yeteneğine sahip şirketlere öncelik verebilirsiniz.

Yine seçim yapacağınız sağlayıcının veri kaybı ve ihlal bildirim süreçlerini anlamaya çalışın. Bu süreçler ile sizin veri kaybı ve ihlal süreçlerinizin örtüştüğünden emin olun.

Bulut sağlayıcısının veri ve sistem güvenliği düzeylerini, güvenlik operasyonlarının olgunluğunu ve güvenlik yönetişim süreçlerini değerlendirdiğinizden emin olun.

Kullanılan Teknolojiler & Yenilikler için Yol Haritaları

Sağlayıcının platformunun ve tercih edilen teknolojilerin mevcut ortamınızla uyumlu olduğundan ve/veya bulut hedeflerinizi desteklediğinden emin olun. Sonuçta bu taşıma sonrasında artık sağlayıcının platformu üzerinde çalışacaksınız.

Sağlayıcının bulut mimarileri, standartları ve hizmetleri iş yüklerinize ve yönetim tercihlerinize uygun mu? İş yüklerinizi platformlarına uygun hale getirmek için ne kadar yeniden kodlama veya özelleştirme yapmanız gerekebileceğini değerlendirin. Burada gerek özel bulut gerek genel bulut sağlayıcıları için bazı sorunlar yaşayabilirsiniz. Yani örneğin Google Cloud için özelleştirdiğiniz bir sistem Azure üzerinde çalışmayabilir, benzer şekilde özel bulut olarak seçim yaptığınız bir şirketin alt yapısı için yaptığınız bir geliştirme de yine bir geçiş yapmanız durumunda gerek tekrar yerleşik veri merkezinize dönmeniz gerekse başka bir özel veya genel bulut sağlayıcısına gitmeniz durumunda da yaşanması muhtemeldir. Bunun için tabi ki yazılım katmanında multi Cloud destekleyen mimariler kurulabilir.

Birçok hizmet sağlayıcı kapsamlı geçiş hizmetleri sunar ve hatta değerlendirme ve planlama aşamalarında yardım sunar. Sunulan desteği iyi anladığınızdan emin olun ve bunu proje görevleriyle eşleştirin ve kimin ne yapacağına karar verin. Çünkü aksi halde hem geçiş sırasında hem de geçiş sonrasında çok fazla sorun yaşayabilirsiniz. Bu nokta da genel bulut sağlayıcıları iş ortaklarına yönlendirme yapar. Yani eğer taşıma yapılacak ortamı bilmiyorsanız tabi ki üretici ile doğrudan çalışabilirsiniz ancak özellikle 3. Parti program veya sizin kodladığınız sistemler ve yine sizde çalışan ancak örneğin Azure geçişi yapıyor iseniz Microsoft’ a ait olmayan sistemler için mutlaka destek almanız gerekebilir. Özel bulut hizmeti sağlayan şirketler ise bu noktada biraz daha avantajlıdır. Çünkü onlar sürekli bu tür geçişler yapan bir teknik kadro ile çalışmaktadır.

Yol haritası ise özellikle sizlerin kendi yol haritanızda gerek altyapı gerek yazılım, hizmet veya verdiğiniz servisler için hazırladığınız yol haritası ile örtüşmelidir. Örneğin siz bugün sunucu sanallaştırması kullanıyor olsanız dahi yazılım ekiplerinizin gelecek 2 yıllık planında konteynır mimarisi ile çalışmak var ise taşınacağınız platformunda yol haritasında bunu görmeniz gerekli, aksi halde sizin yol haritanız ile uyuşmayan bir sağlayıcıya gitmeniz çok mantıklı olmayacaktır.

Hizmet Bağımlılıkları ve Ortaklıklar

Hizmet sağlayıcıların birlikte çalıştığı tedarikçiler sağlayıcının sunduğu hizmeti kesintisiz veya garanti ettiği SLA süreleri içerisinde vermesi için çok önemlidir.

Sağlayıcının kilit tedarikçilerle ilişkisini, akreditasyon seviyelerini, teknik yeterliliklerini ve personel sertifikalarını değerlendirmek gereklidir.

Sunulan hizmetlerin, onu tamamlayabilecek veya destekleyebilecek daha büyük bir diğer hizmet ekosistemine uygun olup olmadığını kontrol etmek yine ilerleyen bir süreçte mevcut sistemleriniz ile daha büyük sistemlerin entegrasyonu için önemlidir. Yani basit bir örnek vermek gerekir ise sistemlerinizin yerel bir bulut sağlayıcısında olmasına karşın genel bir bulut sağlayıcısının sunduğu hizmetler ile konuşabilmesi ve bunun için ek alt yapılar gerekli olmaması önemlidir.

Bazı durumlarda bir bulut hizmetinin sağlanmasında rol oynayan karmaşık bir bağlantılı bileşen ve taşeron ağı olabilir. Sağlayıcının bu ilişkileri açıklamasını ve doğrudan kendi kontrolü altında olmayanlar da dahil olmak üzere hizmetin tüm bölümlerinde detaylı bilgi vermesi gereklidir. Ayrıca, bu alt bileşenlerle ilgili sorumluluk sınırlamalarını ve hizmet kesintisi politikalarını da ayrıca incelemenizi öneririm. Buradaki önerim uzun bir taşeron zincirine sahip tedarikçileri seçerken iki kez düşünün derim, özellikle veri gizliliği sürecinde bu bir sorun olabilir.

Sözleşmeler ve SLA Şartları

Bu madde aslında en kolay ve hemen hemen her bilgi sistemleri karar vericisinin aldığı her hizmet ve donanım için kontrol ettiği bir maddedir. Bulut hizmetleri içinde mutlaka SLA ve detaylarını kontrol etmeniz ve sizin iş ihtiyacınız için en uygun olan sağlayıcıyı seçmeniz gereklidir. Ancak unutmayın ki bazı konularda örneğin felaket durumlarında her türlü erişim, veri güvenliği, bütünlüğü sizin ek hizmet almanız ile doğru orantılı olarak daha pahalı olacaktır. Ancak böyle bir iş ihtiyacının ücreti karşılığında olsa dahi karşılanabiliyor olması bir avantajdır. Bir örnek vermek gerekir ise, eğer siz verilerinizin coğrafi olarak yedeklenmesi hatta farklı bir “kıta” da durmasını istiyorsanız öncelikle sağlayıcının birden çok kıta da veri merkezi olmalıdır, ancak bunun olması bu hizmeti bedavaya verdiği anlamına gelmez.

Yine SLA karşılaştırmaları için ISO/IEC 19086-1:2016 referans alabilirsiniz.

Burada genel bulut sağlayıcılarının imkanları her zaman daha yüksek olmak ile özel bulut sağlayıcılarının da esnekliğini göreceksiniz. Sonuçta size özel birtakım yapılar kurarak esneklik sağlayabilirler.

Hizmet erişilebilirliği ve kullanılabilirliği ile ilgili yine politikaların gözden geçirilmesi gereklidir. Sağlayıcının hizmet veya sözleşme şartlarını ne ölçüde tek taraflı olarak değiştirebileceği veya fes edebileceğini incelemeniz gerekli.

Yasal koruma, tazminat, fikir mülkiyeti, veri sorumluluğu gibi çok kritik sözleşmeleri çok iyi incelemeniz gerekli. Genel bulut sağlayıcıları için bu sözleşmeler birbirine çok yakın olmasına karşın özel bulut sağlayıcıları için bu konu ne yazık ki hala Türkiye de çok ciddi farklılıklar içeriyor, bu nedenle özellikle ülkemiz sınırları çerisinde hizmet veren bir şirket ile çalışmayı düşünüyorsanız bu sözleşmeleri çok iyi incelemenizi tavsiye ederim.

Güvenilirlik ve Performans

Bir servis sağlayıcının güvenilirliğini ölçmek için kullanabileceğiniz birkaç yöntem vardır.

İlk olarak, hizmet sağlayıcının son 6-12 aylık SLA’larına göre performansını kontrol edin. Bazı hizmet sağlayıcılar bu bilgileri yayınlar bazılarından ise siz isteyebilirsiniz.

Mükemmellik beklemeyin: Kesinti süresi kaçınılmazdır ve her bulut sağlayıcısı bunu bir noktada deneyimleyecektir. Sağlayıcının önemli olan bu aksama süresiyle nasıl başa çıktığıdır. Sunulan izleme ve raporlama araçlarının yeterli olduğundan ve genel yönetim ve raporlama sistemlerinize entegre edilebildiğinden emin olun.

Seçtiğiniz sağlayıcının planlı ve plansız duruş süreleriyle başa çıkmak için oluşturulmuş, belgelenmiş ve kanıtlanmış süreçlere sahip olduğundan emin olun. Kesinti zamanlarında müşterilerle nasıl iletişim kurmayı planladıklarını belgeleyen planlara ve süreçlere sahip olmalıdırlar.

Hizmet sorunları ortaya çıktığında bulut sağlayıcısı tarafından sunulan çözüm yollarının ve sorumluluk sınırlamalarını kontrol edin.

Olağanüstü durum kurtarma gibi senaryolar için kurtarma hükümlerini, süreçlerini ve veri koruma beklentilerini inceleyin.

Roller ve sorumluluklar, eskalasyon süreçleri ve ispat yükünün kimde olduğu, hizmet sözleşmesinde açıkça belgelenmelidir. Bu çok önemlidir, çünkü çoğu durumda bu süreçlerin bazılarının uygulanmasından ekibiniz sorumlu olabilir. Bunun için tabi ki sizin de bulut teknolojileri ve ortak sorumluluk gibi konularda bilgi sahibi olmanız gereklidir.

Bir de yine saha tecrübesi olarak kurtarma ile ilgili maliyetler sağlayıcının genel hüküm ve koşulları kapsamında değilse ek risk sigortası satın almayı düşünün.

Taşınma ve Çıkış Planı Desteği

Bulut teknolojilerine geçiş için en sık gördüğümüz endişe “vendor lock” olarak İngilizce ifade edilen, Türkçesi üretici, sağlayıcı veya bazen satıcı diye görürsünüz “sağlayıcı bağımlılığı” dir. Bu terim, bir ürün veya hizmeti kullanan müşterinin kolayca bir rakibe geçiş yapamaması durumudur. Bu genellikle kullanılan teknolojilerin her ne kadar tescilli veya endüstri standart’ ı olsa da rakip üretici veya sağlayıcı ile aynı olmadığı için geçişi çok zorlaştırır. Aslında herkes istediğinde başka bir üretici veya sağlayıcıya iyi ya da kötü bir şekilde geçer, ancak bu seçim kriteri kötü günde bu sürecin nasıl yönetileceği ile ilgili. Profesyonel hayatımda benzer pek çok geçiş yaptım. Özellikle geçiş desteği sunan alt yapılar ile sunmayan alt yapılar arasındaki en büyük fark, ücret, süre ve kesinti. Yani bizim gibi uzman bir danışmana ihtiyaç olduğu için öncelikle ek bütçe çıkarmanız gerekli ya da uzman bir personeliniz olmalı. Ancak her gün yapılan işler olmadığı için bir müşterideki yazılım ya da sistem uzmanının genellikle bu tür taşıma projelerinde çok tecrübesi olmuyor. İkinci sorun süreç çok uzuyor yani zaman kaybediyor müşteriler, son olarak ise bir şekilde kesinti yaşanıyor. Bu noktada eğer büyük bir alt yapınız var ve gene olsun, özel olsun bir bulut platformu seçerken mutlaka olası bir değişiklik veya birden çok bulut sağlayıcı ile aynı anda çalışmak istiyorsanız kullandıkları teknolojiler, geçiş ve taşınma desteği hakkında bilgi sahibi olun.

Bu arada bazen teknolojik olarak sorun olmasa bile sağlayıcının sözleşmeleri can sıkıcı olabilir. Bu nedenle vendor lock konusunda teknoloji yanında sözleşmelerin de bu konuyu nasıl ele aldığını inceleyin.

Şirket Profili

Potansiyel bir tedarikçinin teknik ve operasyonel yeteneklerini değerlendirmek elbette önemlidir, ancak muhtemel çalışmayı planladığınız kısa listeye giren sağlayıcılarınızın mali durumunu ve profilini değerlendirmek için zaman ayırmanızı öneririm. Eğer şirketin mali yapısı, müşteri referansları güçlü değil ise size en uyumlu ve rekabetçi bulut alt yapısını sunmasının bir önemi yoktur. Burada örneğin Microsoft’ un sitesini incelerseniz çok beğendiğim bir yorum yapmaktadır;

“Sağlayıcının geçmiş performansı istikrarlı ve mali durumu uzun vadede faaliyet göstermesi için yeterli sermayeyi elinde bulunduracak düzeyde olmalıdır” yazar bence çok doğru bir yorum.

Yine kuruluşun geçmişte herhangi bir yasal sorunu olup olmadığını, dava edilip edilmediğini ve yasal zorluklara nasıl yanıt verdiklerini öğrenmeniz sizin yararınıza olacaktır.

Planlanan kurumsal değişiklikler, birleşme veya satın almalar ya da şirketin satılması hedefleri gibi planları da sormayı unutmayın.

Yine şirketin Pazar payı bence seçim için önemlidir. Ancak rekabet içerisinde alt yapı, teknoloji, SLA, sözleşme ve finansal açıdan sorunu olmayan bir şirketin Pazar payını büyütmek için size daha iyi olanaklar sunacağını da unutmayın. Aksi halde hep Pazar lideri şirketi seçmek bir yerde bu konuyu tekele dönüştürür. Örnek Amazon veya Google olmasa Microsoft bu pazarda tekel olsa eminim ki sunacağı hizmet kalitesi, fiyatlar, sla vb. çok farklı olurdu.

Eğer mümkün ise bence en etkili yöntem müşteri referansları ile doğrudan görüşün, en iyi geri bildirimi buradan alabilirsiniz.

Ben bu konuda profesyonel danışmanlık yapan bir insan olarak her zaman bu ve birkaç teknik kriteri bir araya getiren tablolar kullanırım. Her bir bileşenin bir çarpanı olur ve müşteri isterse bu bileşenleri kendisi için istediği gibi değiştirebilir. Bu sayede örneğin coğrafi yedekleme veya network gecikmesi gibi farklı öncelikleri daha düşük veya daha yüksek puanlayarak kendisi için en ideal bulut sağlayıcıyı bulabilir.

Size de tavsiyem benzer bir çalışma yaparak aslında bulut geçiş projelerinizde en doğru sağlayıcıyı kolaylıkla seçebilirsiniz.

Umarım faydalı bir yazı olmuştur.