Yeni kurulumlardan büyük organizasyonlara kadar, her endüstrideki müşteriler verilerinde üstsel büyüme yaşıyorlar. Bu verinin önemli bir bölümüne nadiren erişilebilir ancak iş sürekliliği ve uyumluluk gereksinimlerini karşılamak için uzun bir süre saklanmalıdır. Örnekler arasında çalışan verileri, tıbbi kayıtlar, müşteri bilgileri, mali kayıtlar, yedekler vb. yer almaktadır. Ayrıca, yapay zeka ve veri analizinde yeni olan gelişmeler, daha önce atıl olan veya saklanması gereken verilere ihtiyaç duyuyor. Bu yüzden firmaların çoğu, bu veri setlerinden daha fazla zaman saklamak istiyor ancak bunun için ölçeklenebilir ve düşük maliyetli bir çözüme ihtiyaç duyuyorlar.

Geçen yıl içerisinde Microsoft "Azure - Cool Blob Storage" hizmetini duyurmuştu. Müşterilerin erişilen verilerini "Cool Tier" adında bir katmanda saklayarak depolama maliyetlerini azaltmalarına yardımcı oldu. Bunu malasef Azure Storage Account oluştururken tipine göre belirleyebiliyorduk. Ignite 2017 duyurulan "Archive Storage" sayesinde nadiren erişilen verileri en düşük fiyatlı katmanda saklayarak, kuruluşların depolama maliyetlerini daha da azaltmalarına yardımcı olmak için tasarlanan Archive Blob Storage hizmetini genel önizlemesini duyurdu. Ayrıca, bu katmanlardaki blob düzeyindeki verilerinizin yaşam döngüsü düzeyini kolayca yöneterek depolama maliyetlerini optimize etmenize olanak tanıyan Blob Level Tiering'in özelliğini herkese açık önizlemesini sundu.

Archive Blob Storage Nedir ?​

Azure Archive Blob Storage, esnek gecikme gereksinimleri olan nadiren erişilen veriler için (belirli bir saat içinde erişemde olur dediğiniz), yüksek kullanılabilirliğe sahip ve güvenli bulut depolama alanı olanağı sağlayan düşük maliyetli bir hizmet ile kuruluşları sağlamak üzere tasarlanmıştır. Yukarıdaki resimde görüldüğü gibi artık Azure Blob Storage içerisinde : Hot,Cool ve Archive isimlerinde üç farklı seviye bulunmaktadır. Bu farklı seviyeler arasında doğal olarak fiyat farklılıkları ve erişim methodlar var. Aşağıdaki resimde Archive Blob Storage kullanıldığı senaryoları görebilirsiniz. Fiyat konusunu merak edenleriniz var biliyorum fakat henüz bir resmi bir duyuru yapılmadı.

Archive Blob Storage Nasıl Kullanılır ?​

Archive Blob Storage hizmetini kullanabilmeniz için aşağıdaki adımları gerçekleştirmeniz gerekmektedir. Şimdilik hizmet, Public Preview olduğu için bu işlemleri yapmaktayız. General Available olduğu gün bu dertlerimiz olmayacak. Powershell ve Azure CLI aracılığı ile birkaç istek gönderme sürecimiz var. Talebiniz onaylandıktan (1-2 gün içinde) East US 2'de kaynaklarınız için geçerli olacaktır. Önizleme sırasında yalnızca Storage Replication tipi Locally-redundant storage (LRS) olanlar desteklenecektir, ancak General Available' da GRS ve RA-GRS hesaplarına (yeni ve mevcut) da destek vermeyi planlıyorlar. Bu talebimiz onaylandıktan sonra artık Blob düzeyinde Archive Storage ve Access Tier özelliğine sahip olabileceğiz. Makalemizin ana konusunu barından "Blob Level Tiering" olayı sayesinde mevcut blob'larınız için katmanlama durumunu sizin belirlediğiniz aralıklara göre ( 30 gün boyunca erişmediklerim – Archive Tier seviyesine geçsin.) gibi aksiyonlar alabileceksiniz.

Yukarıda bulunan Powershell satıları içerisinde Archive Blob Storage özelliğini aktif etmek için istek gönderdik. Son satırda ise gerekli talebi yaptıktan sonra "Registered" yazısını görmeyi beklemeniz gerekmektedir.

Archive Blob Storage özelliğini açıldı. Bu sayede hem Archive Blob Storage hemde Blob Level Tiering özelliğine sahip olduk. Archive Blob ve Blob Level Tiering konusundaki erişim methodlarına yoğunlaşabiliriz.

Azure Storage içerisinde bulunan Hot, Cool ve Archive detayına bir önceki yazımızda değindik. Şimdi ise Archive Blob hizmetinin işleyişine bakalım. Eğer bir blob Archive Tier seviyesine olduğu zaman okunamaz, kopyalanamaz, üzerine yazılamaz veya değiştirilemez. Ayrıca Archive Storage bulunan bir blob'un snapshot özelliğinden faydalanamazsınız. Bu operasyonlar dışında, varolan bloblarınız için silmek, listelemek, blob özelliklerini / meta verileri elde etmek veya blob'unuzun katmanını değiştirmek için ilgili özellikleri kullanabilirsiniz. Archive Blob Storage içerisindeki verileri okumak için, Blob'un Tier (katmanını hot veya cool olarak) değiştirmeniz gerekir. Bu işlem, rehydration(rehidrasyon) olarak bilinir ve 50 GB'dan daha küçük blob'lar için 15 saate kadar sürebilir. Daha büyük bloblar için ise ek süre gerekebilir.

Rehidrasyon türkçe de yeniden yapılandırma anlamına gelmektedir. Mevcut Blob için rehidrasyon işlemi sırasında katmanın değişip değişmediğini teyit etmek için "Access Tier" özelliğini kontrol edebilirsiniz. İşlem tamamlandığında "Arşiv Durumu" özelliğinden görüntüleyebilirsiniz. Access Tier özeliiğine göre aslında data erişim sıklığı için tutulan bloblar için Storage hizmetinin bedeli değişmektedir.

Yukarıda bulunan örnekte Azure Storage Account içerisinde bulunan Blob seviyesinde katmanlamayı Azure Portal üzerinden yapmış bulunuyoruz. Rehidrasyon işlemini manuel yapmak pek hoş gözükmesede programatic olarak ".NET, Phyton, Java Client Library, Node.Js Client Library ve Azure API" ile süreci yönetme şansınız var.

Yukarıdaki örnekte ".NET" ile mevcut bir blob'un Access Tier seviyesini değiştirilmesini görüyoruz. Dilerseniz yukarıdaki yazılım dilleri ile aynı süreci gerçekleştirebilirsiniz. Şimdi ise ben biraz daha işin programatic tarafı için yapılan çözümleri aktarmaya çalışacağım. Bunların başında ilk aklıma gelen Logic Apps oluyor.

Hemen Logic Apps örneğini açmaya çalışalım. Storage Account içerisinde çok fazla blob'unuz olduğunu varsayalım. Son 30 gün içerisinde erişmeyen var ise (Modified Time gibi değerlere bakarak ) "Access Tier" kısmında gerekli değişimi Logic Apps içerisindeki bir flow ile değiştiğini düşünün. Gerçekten kulağa çok hoş geliyor. Hatta biraz daha ileri gidip firma çalışanları Office 365 Forms üzerinden talep edip "Access Tier" değişimleri yönetebilsek kestirmeden nirvanaya ulaşabiliriz.

Yukarıda bulunan örnekte "Logic Apps" içerisinde Data Lifecyle Management örneği gerçekleştirilmiş. Hergün düzenli olarak çalışan bir flow sayesinde "LastModified" 30 gün önce olan tüm blob'ların "Access Tier" özelliği Archive olarak değiştirililiyor.Logic Apps bir kenara bırakıp bunu analizin yapacak ve tarafınıza "Cost Saving" gibi bir çıktı veren bir araçtan bahsetmek istiyorum. Ignite içerisinde gösterilen "Azure Storage - Blob Tier Analysis Tool" sayesinde mevcut Storage Account içerisinde bulunan Blob'lar için analiz yapıp ilgili katmanlar arasında geçişi yönetmenize destek olacaktır.

Blob Tier Analysis Tool sayesinde yukarıdaki resim içerisinde desteklenen özelliklerden yararlanabilirsiniz. Yine kısa bir görüntü ile nasıl bir çıktı verdiğini görelim.

Yukarıdaki resim içerisinde Azure Storage Account içerisinde 779 GB veri olduğu gözlenmektedir. Blob Storage Analysis Tool, Storage Account içerisinde bulunan blobları inceleyerek gerekli senaryoları bizlere çıkarttı. Bir console uygulaması olarak gözüksede güzel bir analiz yapmış gözüküyor. Dilerseniz şu sayfa üzerinden ilgili uygulamaya erişip kendiniz build ederek analiz parametrelerini belirtebilirsiniz.

Blob Storage Analysis Tool yaptığı analizler sonra aldığı aksiyonlara dahil görüntüyü yukarıdaki resim içerisinde görebilirsiniz.

Powershell meraklıların özellikle katılmasını tavsiye ettiğim, Azure Cloud Shell hizmetinin detaylarının derinlemesine konuşacağım WebCast davetlisiniz.

WebCast içeriği ve katılım detayları aşağıda bulabilirsiniz. WebCast Adresi için tıklayınız.

Başlangıçta ulaşacağım hedefleri düşlemek kolaydı. Yaptığım işlerin başına geçmek, içimdeki dinmeyen azimle cazip bir hale geliyordu. Vizyona olan inancım, en büyük ileri görüşün kendim olmaktan geçtiğini çoğu kez hatırlatıyordu. Vazgeçebilirdim, sınırların üzerini karalamaktansa onlarla iyi anlaşıp içlerinde kalabilirdim. Fakat biliyordum ki hayaller her zihni ziyaret etmiyordu, pes etmekse sadece kapıları ardına kadar kapatmaktan ibaretti.

Microsoft tarafından MVP ünvanına sahip olduğumu belirten bir e-posta aldım. İşte o an, kalabalığın arasındaki biriyken, o her gün yaptığı işin başına geçen ve ilerisini büyük bir ümitle düşleyen geçmişteki halimle karşılaştım. Eğer etrafına dikkatlice bakarsan, ya da öyle bakmaya alıştırırsan kendini güzellikler ortaya çıkar.

Bu başarımda bana destek veren Emre Aydın ve Anıl Eduran'a teşekkürlerimi sunarım.

Sevgilerle

Azure Security Center'a başlamak için Microsoft Azure aboneliğiniz olmalıdır. Azure Security Center aboneliğinizle etkinleştirildi. Aboneliğiniz yoksa, ücretsiz deneme için kayıt olabilirsiniz. Azure Security Center, Microsoft Azure Ibıza portalından erişilir. Azure Ibıza portalından, Azure Security Center'a erişmek için şu adımları izleyin:

Browse sekmesini seçin ve Azure Security Center seçeneği ile ilerleyin.

Azure Security Center'ı seçin. Bu size Azure Security Center sekmesini açar. Azure Portal eriştiğiniz zaman kolayca tekrar erişebilmek için Azure Security Center blade'indeki Gösterge içerisinde bulunan pin butonuna basın.

"Launch Security Center" butonuna basalım ve artık Azure Hesabınız için, Security Center hizmetini kullanmaya başlayabiliriz. Hizmeti aktif hale getirdikten sonra yukarıda bahsettiğimiz politikalar otomatik olarak çalışmaya başlayacaktır.

Yazımızın başında belirttiğimiz gibi isteğiniz üzere Azure abonelikleriniz veya kaynak gruplarınız için güvenlik ilkelerini yapılandırabilirsiniz. Örnek olarak hemen Azure Aboneliğiniz için bir güvenlik politikası yapılandıralım. Security Policy sekmesine bastığınız zaman karşınıza – yetkili olduğunuz Azure Abonelikleri ve kaynak grupları çıkacaktır.

Örnek üzerinde Abonelik dediğimiz için, Aboneliğiniz adını seçiyoruz. Seçtikten sonra ekrana hemen yeni bir sayfa açılıp bu abonelik için gerekli ayarları gösterecektir.

Security Policy sekmesinde, Data Collection ( Veri Toplama) özelliği otomatik olarak açık geliyor. Data Collection çalışma mantığı Azure üzerinde bir sanal makine provisioning ettiğiniz zaman onuna beraber kurulu gelen VM Agent eklentisidir. Abonelikteki tüm ve yeni VM'ler için kurulu bir şekilde geldiği için veri toplamanın burada geçtiğini hatırlatmakta fayda olduğunu düşünüyorum. Data Collection seçeneğini "Off" olarak ayarlarsanız veri toplamayı iptal edebilirsiniz. Ancak bu, Security Center'ın size güvenlik uyarıları ve önerileri vermesini önler. Bu senaryoyu isteğe bağlı olarak abonelikleriniz arası veya kaynak grupları arasında kapatma durumunda kullanabilirsiniz."Choose a storage account per region" sekmesi önem taşımaktadır. Bu kısımda veri topladığınız hizmetlerin loglar'ını region bazında Storage Account hizmet seçerek belirtmeniz gerekmektedir.

Security Policy sekmesine gelin ve Prevention Policy özelliğini seçin. Bu sayede yukarıda bahsetmiş olduğum önleme politikası detaylarını görmenizi sağlayacaktır.

Yukarıdaki resimde gördüğünüz gibi önerilen olarak tüm Prevention Policy yapısı açık olarak gelmektedir. Tasarladığınız güvenlik ilkesinin bir parçası olarak görmek istediğiniz önerileri açıp kapatabilirsiniz.

Prevention Policy sekmesinin özelliklerini inceledikten sonra, Email Notification kısmı oldukça önemli olduğunu söylemek istiyorum. Siz belirli güvenlik ilkeleri için kurallar yazdığınız Azure Security Center sizin için gerekli bildirimleri vermeye başlayacak. Buraya kadar herşey yolunda gözüküyor, fakat Bu bilgilere erişebilmeniz için devamlı Azure Portal içerisinden kontrol etmeniz gerekmiyor. İşte tam bu kısımda yardımınıza "Email Notification" özelliği koşuyor. Security Center tarafından kaynakların tehlikeye girdiğini tespit etmesi durumunda sizinle iletişime geçmek için kullanılacaktır. Ayrıca, yüksek şiddetli uyarılarla ilgili e-posta almak ilgili seçenekleri aktif hale getirmeyi unutmayın.

Bir sonraki sekme olan Pricing Tier konusuna değinmek istiyorum. Azure Security Center hizmetini aktif ederken herhangi bir ücretlendirme gibi bir bilgilendirme karşımıza çıkmadı.

İşte bu kısımda karşımıza farklı satın alma modelleri çıkmaktadır. "Free" olarak kullanmakta olduğunuz Azure Security Center ile Standart model arasında bir takımı farklılıklar var. İsteğe bağlı olarak 60 gün boyunca Standart Tier seviyesinde Azure Security Center'ı kullanma şansına sahipsiniz. Tüm farklıkların detaylarına şu adres üzerinden bakabilirsiniz.

Bilgi Teknolojileri yöneticileri, altyapı operasyon ekipleri tarafından sıklıkla yönetilen, abonelikleri arasında hızlı bir şekilde deploy edilen sanal makinelerin veya bir hizmet olarak satın aldıkları (PaaS) bulut kaynaklarının güvenliğini değerlendirmek için günümüzde zorlanmaktadırlar. Güvenlik içeriklerinden yoksun oldukları için bugüne kadarki yaklaşımları bulut dağıtımlarını yavaşlatmak veya engellemek olmuştur. Artık odak noktası değişti ve Bilgi Teknolojileri yöneticileri bulut dağıtımlarını yöneten, ancak bulut güvenlik uzmanları olmayan altyapı operasyon ekiplerine, kaynakların doğru korunmasının gerçekleşmesi ve sağlanması için yardım etmenin yollarını aramaktadırlar. Bu yazı serisinde, Microsoft Azure Security Center'ın sürekli ve güvenilir bir izleme için nasıl kullanılabileceğini ve yapılan bir çok entegrasyon ile BT yöneticilerinin Azure kaynaklarının görünürlüğünü ve kontrolünü kazanmasına nasıl yardımcı olabileceğini açıklamaktadır.

Azure Security Center, Azure SQL Veritabanı gibi PaaS hizmetlerinize destek verebilirken, ek olarak Azure Sanal Makineleri ve Azure Virtual Network gibi (IaaS) kaynakları da izlemek için kullanılabilen bir Azure hizmetidir. Security Center, Azure kaynaklarınızın güvenliğini kontrol altına alıp tehditleri önlemeye, algılamaya ve bunlara yanıt vermenize yardımcı olabilir. Bilgi Teknolojileri yöneticileri, tüm Azure kaynaklarınızın güvenlik durumunu görüntülemek için tek bir kontrol paneli kullanabilirler. Bu sayede uygun güvenlik denetimlerinin yapıldığını ve hangi kaynakların dikkat gerektirdiğini belirlemelerini yardımcı olur.

Yukarıdaki şekilde görüleceği gibi, Azure Security Center çözümünün mimari yapısının genel bir diyagramı gösterilmektedir. Security Center, Microsoft tarafından dizayn edilen bir dashboard aracılığıyla tüm kaynakların merkezi bir görünümünü sağlarken ayrıca onları korumanıza yardımcı olabilir. Yine sizin yönetiminizle beraber bir veya daha fazla aboneliği izleyebilir durumdadır. Azure Security Center, tehditleri tespit etmek için Microsoft ürünleri ve hizmetlerini, Microsoft Dijital Suçlar Birimi (Microsoft Digital Crimes Unit), Microsoft Güvenlik Yanıt Merkezi (Microsoft Security Response Center) ve harici kaynaklardan oluşan küresel tehdit istihbaratını kullanmaktadır. Machine learning, advanced analytics ve behavioral analysis gibi yöntemlerde dahil olmak üzere uygular.

Bilgi Teknolojileri yöneticileri, Azure aboneliklerinizin veya kaynak gruplarınız için kuruluşunuzun güvenlik gereksinimlerine göre, kullandığınız uygulamanın türlerine ve verilerinizin hassaslığına dayalı ilkeler tanımlayabilir. Bilgi Teknolojileri yöneticileri, bu ilkeleri kullanarak tehditleri önleyebilir ve hafifletebilme şansına sahip olacaktır. Kuruluşunuzda zaten bir Security Incident Response çözümü var ise Azure Securtiy Center dilenirse bu sürecin bir parçası olarak davranabilir. Çünkü Güvenlik Merkezi, saldırının kaynağı ve etkilenen kaynaklar hakkında bilgi verir, olayların veya uyarıların güvenliğini önceliklendirir ve iyileştirme adımlarını önerir.

Algılama yetenekleri

Azure Security Center, tüm saldırı tehditlerini tespit etmek için gerekli olan gelişmiş algılama yeteneklerinin bir kombinasyonunu kullanmaktadır. Aşağıdaki tabloda, tehditleri tespit etmek için Azure Security Center tarafından kullanılan dört yöntem gösterilmektedir.

Yukarıdaki algılama yöntemleri dinamiktir. Microsoft içindeki farklı alanlar arasındaki işbirliğine dayanmaktadır. Microsoft tehdit istihbarat izleme merkezi, Microsoft güvenlik ürünleri ve hizmetleri gibi farklı ekipler sürekli olarak uzmanlaşmış alanlarda çalışmaktadır. Bunun sonucunda, doğrulanmış ve ayarlanmış yeni algılama algoritmalarının doruk noktasıdır. Bu süreç akışı genellikle güvenlik araştırmalarını bildiren yeni güvenlik içerikleri ile sonuçlanır.

Azure Security Center'ı aboneliğiniz için etkinleştirmenin ilk adımı, veri toplamayı etkinleştirerek devreye sokmaktır. Abonelikte veri toplamayı etkinleştirdiğinizde, tüm kaynak grupları aynı güvenlik ilkesini devralır. Bununla birlikte, kuruluşunuz kaynak grubu başına farklı politikalar isterse, devralmayı devre dışı bırakabilir ve benzersiz ilkeler yapılandırabilirsiniz.

Yeni kaynaklara giriş yaparken, tüm politikaları etkinleştirmeniz önerilir; Bu, tüm güvenlik önerilerinin değerlendirilmesini sağlar. Bilgi teknolojileri yöneticileri, genellikle, buluttaki VM'lerde neler olduğunu tam olarak bilmiyorlar. Tüm önleme politikalarını etkinleştirdiğinizde, kaynaklarınızın güvenlik durumu ile ilgili doğru bilgileri alırsınız.

Mevcut önleme politikaları başlıca şöyledir.

• System Updates : Bu politika, VM'lerde çalışan işletim sisteminin Güvenlik Merkezi tarafından izlenen tüm güncellemelerdir.
• OS vulnerabilities : Sanal makineyi saldırıya karşı daha savunmasız hale getirebilecek tüm OS yapılandırmalarını tanımlar ve bunun için desteklenen tüm sanal makineleri tarar.
• Baseline Rules : Bu ilke, VM'lerin önerilen yapılandırmayı kullanıp kullanmadığını doğrulamak için VM ayarlarını bir dizi güvenlik temel kuralına karşı doğrular. Azure Security Center, yapılandırma kuralları için benzersiz tanımlayıcılar atamak için Common Configuration Enumeration (CCE) kullanır.
• Endpoint Protection : Bu ilke, VM'nin üzerinde bir koruma çözümü yüklü olup olmadığını doğrular. Değilse, Endpoint Protection kurmayı önerir
• Network Security Group : Bu ilke, Network Security Grubunuzu değerlendirir ve mevcut yapılandırmaya göre öneriler yapar.
• Wep Application Firewall : Bu politika, güvenlik açıklarına maruz kalan web uygulamalarının olup olmadığını değerlendirir ve bir WAF çözümünün kurulmasını önerir.
• Next Generation Firewall : Bu politika, geçerli ağ yapılandırmasını doğrular ve geçerli konfigürasyona dayanarak, bir güvenlik duvarı çözümü yüklemeyi önerebilir.
• SQL Auditing: Bu ilke, yapınız bulunan SQL Azure PaaS çözümünüzü değerlendirir ve denetimi veritabanında etkinleştirilip etkinleştirilmediğini doğrular. Etkinleştirilmemişse, SQL Denetimi, etkinleştirmenizi önerir.
• SQL Transparent Data Encryption : Bu ilke, geçerli SQL Azure PaaS çözümünüzü değerlendirir ve veritabanının "transparent data encryption" özelliğinin etkinleştirilip etkinleştirilmediğini doğrular.

MSHOWTO olarak 2017 senesinin ilk Üniversite etkinliğini Bahçeşehir Üniversitesinin Yazılım Bilişim Kulübünün organizasyonu ile gerçekleştirdik. Konuşmacı olarak yer aldığım seminerde gün boyunca Microsoft Cloud Vision konularından bahsettik. Keyifli bir organizasyon oldu. Katılım gösteren öğrenci arkadaşlarımıza teşekkür ediyorum.

]

Azure platformunun detay servislerini inceleyeceğimiz "Mind Blown Sessions #2" etklinliğimize davetlisiniz.! Kayıt Olmak İçin info@peakup.org Adresimizden İletişime Geçin!

Microsoft Azure platformunun detay servislerini inceleyeceğimiz "Mind Blown Sessions #1" etklinliğimize davetlisiniz.!

Uzun zamandır bloğumda Azure Stack ile ilgili hiçbir paylaşımda bulunmadım ve sadece sessizce takip ettim. Birkaç ayda pek çok yenilik gerçekleşti ve bu paylaşımımda yeniliklerde en çok etkin olan özellikleri açıklayacağım.

Azure Stack geçen yıl TP1 ( Teknik önizlemesi 1 ) adı verilen proof of concept ile beklenilenden daha önce bir sürede tanıtıldı. Bizlere sunulan bu teknik önizlemenin hedefi müşterilere, danışmanlara ve ilk deneyimleyenlere Microsoft'un private ve hybrid cloud ortamının geleceğinin nasıl ne gibi ne tür yeniliklerinin geldiğinin ilk denemesinin yapıldığını göstermekti. Ama, sahiden nedir bu Azure Stack?

Sade Bir Anlatım ile Azure Stack

Azure Stack Microsoft Azure servisleri, özellikleri ve kullanıcı tecrübesi benzerine sahip olmak için on-premise(Datacenter) yapınıza deploy edebileceğiniz bir yazılımdır. Eğer Microsoft Azure kullanıyorsanız (yeni portal, İbiza Portal olarak bilinen portal.azure.com) kendi veri merkezinize Azure Stack deploy ettiğinizde elde edeceğiniz hizmet yukarıdaki cümlelerimde geçmektedir. Böylece lokal tesislerinizde Azure teknolojisini geliştirebilecek, deploy edebilecek, yönetebilecek ve Azure Virtual Machine, Web Application, Virtual Network gibi sayısı daha da artan Azure servislerinden faydalanabileceksiniz. Sadece tarayıcı üzerinden portal.azure.com'u yazmak yerine, size özel Azure Portal'a (kendi veri merkeziniz üzerindeki ) yönlendiren kendi alan adınız ile rastgele bir URL tuşladığınızı düşünün. Oldukça inanılmaz gözüküyor.

Azure Stack benim şirketim için mi yoksa iş için mi uygun?​

Azure Stack sizin veri merkezinize sanallaştırma platformundan ( basit bir sanal makine) veya gelişmiş bulut özelliklerini Azure App gibi servisleri gerçekleştirmek için bir yol sunar. Teknik olarak baktığımda, Azure Stack hizmetini en azından sanallaştırmayı benimsemiş ve kullanmayı hedef almış her şirket tarafından tercih edilebilir olarak görüyorum. Fakat bu, Azure Stack hizmeti benimsemek için yeterli değildir. Bir danışman ve Azure Mimarı olarak, bence Azure Stack aşağıdaki durumlar içerisindeyseniz sizin için uygun olabilir.

Microsoft Azure tarafından sağlanan farklı servisleri, konseptini deneyimlemiş veya deneyimliyorsanız, eğer Azure hizmetinin şirketiniz için onayladıysanız, ve On-Premises tesislerde aynı deneyimi arıyorsanız ( herhangi bir nedene bağlı olarak) Azure Stack sizin için iyi bir tercih olabilir. Azure Stack ve Azure uyumlu olarak çalışır. Hybrid bir ortama sahip olabileceğinizden kaynaklarınızı Azure Susbscription ve Azure Stack arasında hiçbir ekstra bir yapılandırmaya gerek kalmadan kolay bir şekilde kaydırma şansınız olacak. Bununla beraber Azure ve Azure Stack aynı API kullandıkları için yazılım ekibinin kod tarafında güncelleştirme yapmalarına gerek kalmayacak.( API, Resource Deployment, DevOps)

Güncel bulut teknolojilerini ve konseptini sağlayan özel bir bulut platformu arıyorsanız, Azure Stack, Azure tarafından yaratıldı ve test edilmiş ve yapılacak iyileştirmelerden sürekli olarak yararlanmaya devam edeceksiniz.

Uygulamaları ve Servisleri daha hızlı inşa etmek için modern bir yol arıyorsanız, Paas ve Micro Services yapısını baz almış model olarak Azure Stack tam size göre. İlk versiyonunda ( 2017 ortası ) Azure Web Apps'i destekleyecek, biraz daha ileriye gidersek eğer getirmeyi planladıkları hizmetler arasına Azure Fabric'i de katabiliriz.

Azure Stack Müşterilere Nasıl İletilecek ?​

Bahsetmem gereken asıl tartışma konusu, burada Microsoft kazanan taraf oluyor ve bunu da tabi ki sınıflandırılmış esnekliğine borçlu diyebiliriz. Azure Stack bütünleşmiş Sistem platformları ile 3 farklı donanım sağlayıcılarını seçme konusunda özgürlük hakkı verecek.

Yukarıdaki resimde görüldüğü gibi Hewlett Packard Enterprise, DELL ve Lenovo dışında Azure Stack platformunu kendi donanımınızın üzerine deploy edemeyeceğinizdir.

Bu son açıklama takip ettiğim topluluklar tarafından tepki yarattı ve bu can alıcı noktayı iki başlık altında toplayabilirim.

Microsoft bu modelin istenilen Enterpise level olan private / hybird bulut platformuna erişmek için tek yol olduğunu doğruluyor. Microsoft donanım ile bütünleşmenin oldukça ağır bir görev olduğunu ifade ediyor ve müşteriye bir hazır makine verip platformu onaylamayı tercih ediyor.

Topluluk tarafından önerilen ise Microsoft'un ilk olarak fiyatı makul olmayan donanım sağlayıcıları için çözümü kilitlemesinden ve ikinci olarak ise orijinal sanallaştırma ve bulut ideolojisini takip etmemesinden ki bu da var olan kaynakların ister istemez optimizasyonunu ve yeniden kullanımını reddetmek anlamına geliyor ve hatta makul fiyatlı ve emtia donanımları kullanmamayı tercih etmesinden dolayı şaşırıyor.