Merhaba,

Ülke gündemi o kadar meşgul ki, bir çoğunuzun Salı günü olanlardan haberi olmadığına eminim.

Salı günü ABD’de, dünyanın en büyük bulut sağlayıcısı olan Amazon Web Services (AWS), birkaç saat çevrimdışı kaldı!

Yaşanan AWS  kesintisi, Kuzey Virginia’da barındırılan ve Boston, Houston, Newyork ve Chicago gibi şehirleri kapsayan ABD-Doğu-1 bölgesinde yaşandı ve dünyanın en önde gelen bir çok şirketi de dahil olmak üzere binlerce işletmeyi etkiledi.

Öyle ki, Amazon’un kendi müzik yayın hizmeti Prime Music, video konferans aracı Chime, depolarındaki operasyonlar ve ev güvenlik sistemi Ring dahil olmak üzere birçok Amazon hizmeti de verilemedi.

Arıza, Web sitesi kesintilerini izleyen Downdetector tarafından tespit edildi. Bunun üzerine AWS, sorunun küresel konsol açılış sayfasından kaynaklandığını açıkladı.

Burada Yönetim Konsolu konusuna çok kısa değinmekte fayda var. Çünkü konsol sorunu her AWS müşterisini aynı şeklide etkilemez. AWS kullanan bir çok site veya uygulama yapılandırıldıkları gibi çalışmaya devam edebilir, fakat ileri düzey müşteriler(artık birçok müşteri) yönetim konsoluna erişime güvenir ve sürekli olarak altyapı yapılandırmalarında otomatik değişiklikler yapar. (Auto Scale)

Yani AWS’nin altyapısı çalışmaya devam ederken, hizmet alan şirketler ihtiyaçlarına göre kaynakları azaltıp arttırırlar. Bu tür ayarlamaları genellikle otomatize edilmiş programlar ile yaparlar. Sistemlerinizin sürekliliği ve çalışması AWS arayüzündeki basit birkaç değişikliğe bağlı olabilir. 

Şirketler Dependency Matrix yapmayı çoğunlukla gözardı ederler. Oysa hizmetlerinizin hangi hizmetlere bağlı şekilde çalıştığı ve neleri by-pass edebileceğinizi bilmek bu tür durumlarda son derece önemlidir.

Bir örnek ile açıklayalım: Mesela şirketin fiziksel kasa anahtarı, şirketin CEO’sunda olsun. Network ekipmanlarında çıkan acil bir durumda sunucuların konsollarına ulaştıracak şifre de, bir zarf içinde bu kasada duruyor olsun. Eğer kasanın anahtarı, CEO ile birlikte Bahama’larda ise bir fiziksel anahtarın şirketin geleceği için ne kadar kritik olabileceğine gözlerinizle şahit olursunuz.

Kısacası bu sadece teknik bir konu değil. Disaster planları ciddi biçimde senaryoların oluşturulması gereken ve “Dependency Matrix” ile bu kilit pozisyonların kişilere tanımlanması gereken bir süreçtir.

Herşeye rağmen AWS’de yaşanan sorunun son derece normal olduğunu düşünüyorum. Sonuçta AWS’nin kesintisizlik taahüdü %99.5 (instance için), yılda neredeyse 2 günlük kesinti demek bu. Dolaysıyla benzer, hatta çok daha vahim sorunlar Azure, Google ve Alibaba’da ve diğer tüm bulut sağlayıcılarında da yaşanabilir.

Bence bu olaydaki easas sorun, işletmelerin tüm yumurtalarını aynı sepete koyma alışkanlığından kaynaklanıyor. Çünkü firmalar hala bulut stratejilerini, bir iş sürekliliği ve kurtarma (recovery) planları olmadan tamamladıklarını zannediyorlar.

Firmalar, özellikle genel bulut sağlayıcıların kurumsal kimliğine güvenerek; yaygın deyişle: “sırtlarını kurumsal bir firmaya dayayarak” buluta ilişkin yapılması gerekenlerin yapıldığını varsayıyorlar.

Öyle ki, on yıldan fazla bir süredir firmalarda bulutun sihirli bir biçimde çalıştığı ve asla başarısız olmadığı yönünde genel bir yanlış varsayım var. Kullanılan buluta o kadar çok güveniliyor ki, buluta geçişten sonra bir çok firma iş sürekliliği ve kurtarma planlarına artık yatırım yapmıyor.

Aslında bu bakış açısı sadece bulut sağlayıcısı seçiminde değil, kurumsal BT’deki çoğu teknolojinin seçiminde karşımıza çıkıyor ve mutlaka satıcı kilitlenmesinden (vendor lock-in) kaynaklanan bir dizi ciddi sorunla sonuçlanıyor.

Peki yapılması gereken nedir?

Öncelikle şirketlerin bir adım geri çekilerek, bulutun sunduğu riskler ve fırsatlar hakkında bütünsel olarak düşünmek için yeterli zamanı ayırması gerekiyor.

Tüm işletmelerin hangi uygulamaların korunacağını, nasıl korunacağını ve değerin nerede olduğunu düşünmesi kritik derecede önemli. Çünkü ancak bu şekilde her şirketin elinin altında bulunması gereken, kendi koşullarına göre hazırlanmış, tutarlı ve fonksiyonel “Bulut Migration” planları hazırlanabilir.

Yani her hangi bir çözümü, sadece “herkes öyle yapıyor” diye irdelemeden uygulamaya geçirmemek ve ne kadar güçlü olursa olsun tek bir firmanın kurumsallığına bel bağlamamak gerekli.

Elbette her firmanın ihtiyacına göre seçilecek bulut stratejisi farklılıklar gösterebilir. Bazı firmalar için hibrit bulut kullanımı mantıklıyken, bazıları için şirketin kendi şirket içi veri merkezini bulut hizmeti ile birleştirmek uygun olabilir. 

Fakat unutulmamalı ki, geçiş (migration) süreci oldukça yavaş ilerleyen bir süreç olabilir ve farklı bir yere taşınan uygulamaların daha yüksek gecikme süreleri ile çalıştığı görülecektir.

Multi Cloud çözüm kullanalım demek de işleri daha karmaşık hale getirebilir. Herhangi bir Bulut sağlayıcıda sorun çıktığında, sorunun nerede olduğunu bulmanız ve kırılganlığınızı azaltmanız daha zor olabilir.

Ayrıca örneğin AWS gibi bir sağlayıcıdan diğer bölgelere geçiş ek bir maliyet gerektirir ve geçiş yeteneğine sahip uygulamalar oluşturmak için de ek bir iç yatırıma ihtiyaç duyulabilir.

Tüm bu zor taraflarına rağmen işletmeler, data gravity konusunda kendilerini çok iyi analiz etmeliler. Bütün zamanını ve bilgisini bu tür altyapılar kurmaya harcayan insanlara bunları danışmaları gerekir. Saatlik iş kaybı milyon dolar olan birçok işletme var.

Unutmadan bu akşam saat 21:00’de bu konuları Twitter/Spaces görüşmemizde ele alalım istiyorum, 

görüşmek üzere,

Şenol

Amazon Web Services Outage Takes Businesses, Services Offline | WSJ
Bulutun Gerçek Maliyeti | Açık Kaynak Fikirler

BULUT

AWS re: Invent Konferansı

Geçen hafta, Amazon’un AWS re:Invent konferansı gerçekleşti. AWS, ekosistemine katılan yeni ürünleri, hizmetleri ve özellikleri duyurdu.

Kişisel ve tamamen afaki tahminim, giriş yazısında bahsettiğim gecikme olayının, bu konferansta sözü edilen yeni özelliklerle ilgili AWS tarafında yapılan bir çalışmadan veya meraklı kullanıcıların aşırı yüklenmesinden olmuş olabileceği yönünde.

Şaka bir yana, en çok dikkatimi çeken 3 konu:

• Yeni çıkan ARM işlemciler, bu konuya 27 Ekim raporumuzda değinmiştik. ARM sunucular konusu çok ilginç bir konu. Son dört aydır ARM sunucular kullanıyorum ve hiç performans sorunu yaşamadım.
• “Karpenter” Kubernetes ile ilgili bir açık kaynak proje 
• CTO Verner Vogels’dan iyi bir API için 6 kural

Top Announcements of AWS re:Invent 2021 | AWS

2030’da Bulut’un Geleceği İçin Bir Tez

Geçen gün başarılı bir IT’ci olan Erik Bernhardsson’un bulutun geleceğine ilişkin oldukça aykırı bir makalesine denk geldim. Fikirlerine tamamıyla olmasa da büyük oranda katılıyorum.

En azından, herkesin hep bir ağızdan buluta yüklediği “tanrısal” anlamın değişeceğini düşünüyorum. Mutlaka göz atın:

Storm in the stratosphere: how the cloud will be reshuffled | Erik Bernhardsson

SİBER GÜVENLİK

Ağ Modernizasyonu

Bilgisayar korsanlarını engellemek (ve çalışanların üzerindeki baskıyı azaltmak) için şirketler ağlarını modernize etmelidir. Aşağıdaki makale, modernize edilmiş bir ağı desteklerken dikkate alınması gereken adımlar hakkında oldukça güzel noktalara değinmiş.

Kısaca şöyle:

1. Basitleştirin: Kurumsal ağları, yazılıma daha fazla önem veren tek bir küresel ağ haline getirmeyi düşünün. Yazılım tanımlı ağlar, bileşenleri yapılandırmayı, güncellemeyi ve sorunları kontrol etmeyi kolaylaştırır.

2. Otomatikleştirin: Siber olayların çoğu, insanlar tarafından atılan yanlış adımlara kadar takip edilebilir. Yazılımdaki otomasyon ve varsayılan ayarlar, siber güvenlik sorumluluğunun çoğunu kullanıcıdan uzaklaştırarak insan hatası olasılığını azaltabilir.

3. Şifreleri unutun: Parolalar insan hatasını davet eder. Bazı şirketler kriptografik anahtarları kullanan daha modern yöntemler kullanıyor. Örneğin Google, FIDO adlı bir şifreleme anahtarı standardı kullanır.

To Thwart Hackers, Companies Should Focus More on Modernizing Their Networks | WSJ

BT

Yeni kurduğunuz Şirketinizi Büyütebilecek misiniz?

Büyük umut, çaba ve çok parlak bir fikirle şirketinizi yada Startup’unuzu kurdunuz. İlk müşterilerinizi kazandınız. Peki sonra?

Ne yazık ki son 10 yılda kurulan şirketlerin sadece %22’si başarılı bir şeklide büyüyebildi. Mc Kinsey’in makalesi, şirket sahiplerinin büyüme aşamasında karşılaşacağı tümseklerin neler olduğuna ve bunları aşarken ne yapmak gerektiğine detyalıca değiniyor.

How good are you at business building? A new way to score your ability to scale new ventures | Mc Kinsey

Gatrner’in 2022 ve Ötesi İçin 10 Stratejik Tahmini

Gartner gibi şirketlerin, bazı tahminlerini bilinçli olarak Hype yaratmak için eğip büktüğü bir gerçek. Aşağıdaki tahminlerin ne göstereceğini göreceğiz.

TEKNOLOJİDE ÖNE ÇIKAN

DevSpace

“DevSpace, bulutta yerel yazılımları daha hızlı geliştirmenize ve dağıtmanıza olanak tanıyan Kubernetes için açık kaynaklı bir Developer aracı.”

DevSpace, mevcut kube bağlamını kullanan ve yalnızca istemciye (client)yönelik bir CLI aracıdır. Kümenin içine herhangi bir şey yüklemeye gereke kalmadan, her Kubernetes kümesiyle birlikte çalışabiliyor.

Özellikle Developer’lerin bir göz atmasını öneririm.

DevSpace

BAŞKA ŞEYLER

Özellikle Grafikleri Çok Etkileyici Bir 3D Animasyon

Ütopik Piltover ülkesinde ve Zaun’un baskı altındaki yeraltı dünyasında geçen hikaye, iki ikonik şampiyonunun kökenlerini ve onları parçalayacak gücü konu alıyor.

Yapımın IMDB puanı:9.3 ve dediğim gibi özellikle görselliğiyle sıra dışı.

Arcane | IMDB

Bu haftalık bu kadar.

Bize iletmek istediğiniz fikir ve yorumlarınız varsa duymayı çok isteriz. Bunun için, bu maili cevaplayarak bize yazabilirsiniz.

Telegram’daki iletişim platformumuza gelmeyi unutmayın. Ve eğer yayınımız hoşunuza gittiyse, bu bülteni lütfen arkadaşlarınıza da önerin.

Çünkü tarafsız yorum, herkesin hakkı.

Görüşmek üzere,

Açık Kaynak Fikirler

Daha önce yayınladığımız bültenlere buradan erişebilirsiniz.