- Microsoft Azure'da her gün yaşanan tuhaf şeyleri paylaşan bir hesap. Şu anda 400 günü geçmiş durumda
- Day 403: Kısa süre önce #Microsoft Cloud for Sustainability Technical Summit vardı. Ancak gerçekte, sürdürülebilirliğe biraz odaklanan bir #Copilot zirvesi gibi hissettirdi. (Bu ekran görüntüsü yalnızca ilk üç oturumdan alınmıştır)
- Day 402: Azure CLI'nin yeni #AI özelliği şu ana kadar harika çalışıyor (hata ekran görüntüsü)
- Day 401: Bağlantı hata görseli. Var olmayan bir bölüme giden #Azure dokümantasyon bağlantılarının sayısız örneğinden sadece biri
...
1 yorum
Hacker News yorumları
Eskiden Mojang’da çalışırken, Microsoft tarafından satın alınınca AWS’den Azure’a geçmeyi denedik.
Yüzeyde mantıklı görünüyordu; AWS maliyetimiz ayda altı haneli dolar seviyesindeyken Azure’u ücretsiz kullanabiliyorduk.
Ancak yaklaşık bir yıl sonra, ekibimiz ve Azure organizasyonunun bize atadığı çözüm uzmanları sayısız saat harcadıktan sonra, hepimiz Microsoft’un büyük rakiplerinden birine ödediğimiz altı haneli maliyeti sürdürmemiz gerektiği konusunda hemfikir olduk.
O zamandan beri Azure’u gerçek kullanım için uygun bir bulut sağlayıcısı olarak görmedim; belki bir gün yeniden değerlendirmem gerekir, ama ilk kez yanılıyor olmayabilirim.
Genel olarak fena değildi, ama CosmosDB’yi, o zamanki adıyla DocumentDB’yi kullanmaya başlayınca sorunlar çıktı.
İlk dönem DocumentDB gerçekten berbattı; fiyatı tahmin etmek çok zordu, her hafta sonu saçma sapan faturalar geliyordu ve sağlanan .NET SDK da hatalarla dolu ve korkunçtu.
En kötüsü, web UI’ın belirli bir CosmosDB örneğine doğrudan bağlı gibi görünmesiydi.
Veritabanı kaynaklarını yetersiz ayırırsanız yavaşlıyordu; kaynakları artırmak için kullanmanız gereken web arayüzü de onunla birlikte gecikiyordu.
Bu yüzden Cosmos kaynaklarını artırmak için tüm uygulamayı kapatmak zorunda kaldığımız durumlar oldu ve Microsoft tamamen amatörce görünüyordu.
Şimdi Cosmos’un çok daha iyi hale geldiğini anlıyorum, ama o zamandan kalan tat çok kötüydü.
Ücretsiz kredi gibi bir şey olursa Azure’u tekrar deneyebilirim, ama şu anda kesinlikle tavsiye etmem.
Dünyanın en büyük e-posta hizmetini Windows stack’i üzerinde çalıştırmak muazzam bir referans olurdu, ama başarmaları yıllar aldı.
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
AWS’nin serverless işleme biçimi gibi AWS’ye özgü özellikler yüzünden Azure’a doğrudan taşınamayan şeyler olduğunu tahmin ediyorum, ama X’ten Y’ye geçişin neden başarısız olduğunu öğrenmek her zaman isterim.
Bu arada oyun tarafındaki teknolojilerin daha olgunlaşması da yardımcı olmuş olmalı.
Düzeltme: AWS -> Azure :)
AWS genel olarak önde olduğu için o dönemde bir teknoloji farkı vardı; sanırım daha sonra o fark kapandı.
Sorun değil, Microsoft gelecek hafta adını değiştirip yönetici UI’ını ve API’sini tamamen baştan aşağı yenileyecek.
Artık adı Dynamics CoPilot OneAI 365 for Business OneCloud olacak.
live.com, bazılarıoutlook.com, bazıları dasharepoint.com,msbinbows.comgibi kalacak.Ama belgeler ve diğer tüm referanslar eski adı kullanmaya devam edecek elbette.
Benim deneyimime göre, on-premises sunucu rack’lerinden Linode, AWS ve Azure’a kadar kullanan organizasyonlar gördüm; bulut altyapısıyla ilgili şikâyetler yönetilen servis kullanımıyla orantılıydı.
Çoğunlukla sanal makinelere, en fazla da yönetilen ilişkisel veritabanlarına dayanan ekipler neredeyse hiç şikâyet etmiyordu.
Biraz daha fazla script bakımını üstlenmek gerekiyor, ama yönetilen servislerin sorunları ve tuhaf davranışlarıyla boğuşmaya kıyasla bu küçük bir rahatsızlık.
Elbette sıradan bir sanal makinenin bakımını yapmak yönetilen servisten daha kolaydır; zaten bunu kendimiz yapmamak için bulut sağlayıcısına yönetilen servis için çok daha fazla para ödüyoruz.
Sonuçta bu çabanın özünde anlamsız olduğu mu söyleniyor?
Birçok şirketin buluta geçmesinin ana nedeni yönetilen servisler olduğu için, bu ifadenin hiç tartışmalı olmadığını söylemek zor.
Bir müşterinin prodüksiyon sunucularının bulunduğu VPC’ye IPsec tüneli gerekiyordu; tek bir müşteri için böyle bir yapılandırmayı kendimiz sürdürmek istemediğimizden AWS’nin sunduğu servislere baktık ve yönetilen bir IPsec çözümü vardı.
Sonra müşteri tünelin düştüğünü söyledi; çözüm de bağlantının yeniden kurulması için müşterinin kendi tarafında yeniden başlatma yapması gerektiğiydi.
Nedenini görmek için S3 logging’i açabiliyorsunuz, ama AWS tarafının açıklamasına göre her şeyin normal olması gerekiyordu.
Sadece EC2 kullansanız bile tuhaf şeyler oluyor.
Yakın zamanda bir EC2 instance’ı yanıt vermeyi kesti, ama Auto Scaling Group onu değiştirmedi; ne işlem yapsak instance’ın çalışır durumda olmadığına dair hata alıyorduk, fakat durumu çalışıyor görünüyordu.
Neyse ki yöneticim aynı fikirde, ama tam yetkili değil.
Vendor lock-in ve açık kaynakla neredeyse uyumlu ama tamamen uyumlu olmayan API uyumluluğu yüzünden, daha fazla ekip benimsedikçe endişeleniyorum.
“Ama daha kolay!” diyorlar; bekleyip göreceğiz.
2014 civarından önce AWS, büyük servislerin fiyatlarını düzenli olarak düşürerek teknoloji maliyetlerindeki azalmayı yansıtıyordu.
Azure bundan hoşlanmadı ve AWS fiyatlarıyla eşleşmeye başladı; aynı servisteki aynı indirimleri anında takip etti.
Bunun amacı, rakip fiyat düşürse bile pazar payı kazanamamasını sağlayarak fiyat indirme teşvikini öldürmekti; bu da yıkıcı fiyatlandırmanın bir biçimi.
Araçlarla iyi entegre olduğu için Azure’u gerçekten sevmek istemiştim, ama sürekli sanal makine kullanılabilirliği kısıtlarına ve UX’teki tuhaflıklara çarptım
AWS’te makine bulamadığım ya da yaptığım işlemin gerçekten uygulanıp uygulanmadığından şüphe ettiğim hiç olmadı
Azure’un FaaS’ini de birkaç kez düşündüm ama şu anda kesin şekilde “kullanma, hızla kaç” tarafındayım
Azure Functions çevresindeki deneyim o kadar tuhaf ki rahat edemiyorsunuz; loglara veya diğer ikili çıktılara erişmek de inanılmaz acı verici
Boş bir Windows/Linux sanal makinede kendi kendine yeten bir .NET derlemesi çalıştırmak o kadar kolay ki, tüm bu ek karmaşıklığa bulaşmak için hiçbir neden yok
Ayrıca SQL Server’ın aslında hazır olması için 20 dakika daha geçmesi gerekirken çalışıyor diye callback göndermesi gibi otomasyonu bozan davranışlar da var
terraform time_sleep’in özellikle Azure sorunlarını engellemek için yapılmış olduğuna yarı yarıya eminimFunction App basit fonksiyonların ötesine geçip daha uzun çalışma süresi veya cold start gecikmesinin olmaması gerektiğinde sonunda kullandığın aynı servis bu
App Services alışmak için zaman istiyor ama yerleşik FTPS, kendi kendini iyileştirme için sağlık kontrolü endpoint’i, depolama alanını belirten dağıtım, otomatik ölçeklendirme seçenekleri ve %99,95 SLA’sı olan kilitlenmiş bir Win Server/IIS konteyneri
Birkaç yıl önce performans açısından pek iyi değildi ama modern CPU’lu 2 veya daha fazla vCPU’lu Premium SKU’larda sorun yaşamadım
Sanal makinelerden pahalı ama web sunucusu sanal makinelerinin güvenliği ve güncellemeleriyle uğraşmak çok iş
Azure’da barındırılan bir şirketi satın aldık
Barındırılan Postgres ve Windows üzerinde .NET servisleri kullanıyorlardı; altyapı küçüktü, yaklaşık 200~300 çekirdek ve 1 TB bellek
Microsoft birkaç günde bir bakım diyerek rastgele instance’ları keyfi şekilde kapatıyor ve ağı 10 dakikadan uzun süre kesiyordu
Barındırılan Postgres’in performansı trajikti, bu yüzden taşıdık; Hindistan merkezli bir uzman farklı bir volume türü kullanmamızı önerdi ve instance yeniden başlatıldıktan sonra I/O gecikmesi yüzünden veritabanı ayağa kalkmadı
Uzman meşgul olduğunu söyleyip üç gün üst üste toplantıdan kaçtı; RCA ise muhtemelen LLM’in yazdığı yarım yamalak bir belgeyle bunun kendi hataları olmadığını söylüyordu, ama grafikler başka şey anlatıyordu
GCP ve AWS’yi yendiği tek nokta dashboard’un hızlı yüklenmesi
Ancak benzer iki ağ işlemini paralel çalıştırırsanız ya başarısız oluyor ya da sıralı çalıştırmaya göre 10 kat daha uzun sürüyor; üzücü
Kaçın, kullanmayın
Tüm PaaS sağlayıcıları arasında Azure’un soyutlamaları ve servisleri en kötüsü
Genel olarak herkesin böyle tuhaf servisleri tüketmeyi kabul etmesi, bulut mimarı ve uzmanı işleri yaratılması üzücü
Partnerleri sürekli ilgili tutmak gerektiği için kötü tasarımı ve gevşek bağlantıları besliyorlar
Aslında kurumsal IT’nin tamamı hakkındaki düşüncem de bu
Yaklaşık 30 geliştiricisi olan küçük bir şirkette Azure karmaşasını devraldım; gereken servisler için geliştirme araçlarında sektörel standarda daha yakın soyutlamalar oluşturduk ve birkaç yıl sonra Hetzner’e taşındık
Buradaki geliştiriciler farkı fiilen bilmiyor
Araçlarımız workflow’ları ve servis soyutlamalarını yönetiyor; bunlar sağlayıcı değişince değişmemeli
Aylık fatura onda birine düştü ve o paranın bir kısmını hayal edilebilecek en iyi geliştirici deneyimini oluşturmaya harcadık
Bunun çok iyi bir takas olduğunu düşünüyorum
Büyük bulut kullanmanın mantıklı olduğu yalnızca iki durum var
Ya gerçekten küçük MVP ölçeği ya da elastikiyet gerektiren devasa, küresel dağıtık ortam
Çoğu şirkete bakıldığında ikisi de istisnaya yakın
Her Azure kullanıcısı Azure’u kullanmamak için 100 neden çıkarabilir gibi geliyor; büyük yazılımların çoğu için de aynı şey geçerli
Diğer bulutlara maruziyeti az olan biri olarak bile Azure kullanıcı deneyiminin doğru yönetilmediği için geride kaldığını görmek kolaydı
Filtre çubuğunun düzgün çalışması için “daha fazla göster”e basmak gereken sayfa sayısı artık açıkça 0 olmalı
Bu nesnel olarak kötü bir pattern, yıllardır var ve düzeltmesi “kolay olmalı”; ama muhtemelen asla öncelik olmayacak
Sonuçta böyle sorunları çözmek kuruluşun temel değeri olmadıkça ya da gelire açıkça zarar vermedikçe düzeltilmiyor
Kullanıcı topluluğu için bu tür sorunların kamuya açık ve görünür olması her zaman önemli
Hem AWS hem Azure kullanıyorum; Azure’da gerçekten sevdiğim tek şey portal
AWS 2.0 gibi: bulutun gereksiz karmaşası soyutlanmış, geriye gerçekten kurcalamanız gereken ayarlar ve bunların birbirleriyle ilişkileri kalmış
AWS’yi de seviyorum ama yabancı bir ortama girip tüm bağlantıları tersine mühendislikle çözmem gerektiğinde iş bitince içkiye ihtiyaç duyuyorum
Azure’u birkaç gün denediğimde portal gerçekten acı vericiydi
Her tıklamada yanıt 5~10 saniye sürüyordu; basit ayar değişikliklerinde bile 2 dakikadan fazla Ajax spinner’ı izlemem gereken zamanlar oldu
Bu şekilde çalışmaktan nasıl keyif alınabilir?
Sanki biri kasıtlı olarak olabildiğince kafa karıştırıcı hale getiriyor; amacını tahmin bile edemiyorum
Görüşün geçersiz ya da yalan olduğunu söylemiyorum, ama Azure ekosisteminin içinde her saat yaşayanlar dahil Azure portalını seven birini hiç görmedim
Değilse komik
Ben tamamen karşı taraftayım; demek ki zevk meselesi diye bakmak gerek
İkisini de epey kullandım; Azure dashboard’u hâlâ sinir bozucu ama kullanılabilirlik açısından AWS’den çok daha iyi
Üstelik Microsoft’un dokümantasyona zaman ve para harcadığı açıkken, AWS dokümantasyonu her zaman vasattı
Küçük bir şirketseniz ve konteyner çalıştırmıyorsanız Cloudflare büyük ölçüde hafife alınan bir bulut
Başka nedenlerle eleştirildiğini biliyorum, ama büyük 3 ya da 4'ten bıktıysanız geliştirici deneyimi gerçekten harika
[1]: https://blog.cloudflare.com/container-platform-preview/
Svelte siteleri için seviyorum, ama bir dile ve istek-yanıt temelli kısıtlamalara bağlı kalmak çok büyük bir sınırlama
En azından konteynerler ve kalıcı volume'lar olmalı ki ilgimi çeksin
Azure'dan gerçekten tutkuyla nefret ediyorum
Bulut sağlayıcısı bazında proje/hesap/abonelik oluşturmayı otomatikleştiren bir araç geliştiren ekipteyim
Ana sağlayıcımız GCP ve implementasyon oldukça kolaydı
Birkaç küçük tuzak vardı ama kolayca aşılabiliyordu
Şimdi çoklu bulut kapsamında Azure'u desteklememiz gerekiyor
Eskiden AWS'teydik ama %95 oranında çıktık; hâlâ birkaç ekip kalsa da Terraform modülleri dışında neredeyse hiç araç geliştirmiyoruz
Ama Azure API, MS Graph API ve ikisinin Go SDK'ları şimdiye kadar uğraştıklarım arasında en büyük çöp yığını
Her şey pointer ve string literal'ları bile pointer'a çevirmeniz gerekiyor; ama bazen de gerekmiyor
Dokümantasyon hatalı; bazı API'ler yalnızca ID alırken diğerleri tam yolu alıyor
Bazıları belgelenmiş ama birçok API'de yanlış format yazıyor
Hiçbir API ilgili kaynak ID'sini döndürmediği için hepsini aramak zorunda kalıyorsunuz ve isim tabanlı arama çok fazla
Oluşturma sırasında aynı kaynakları tekrar tekrar sorgulamamak için bir ID önbellekleme katmanı bile eklemek zorunda kaldık
Oluşturma için state machine kullanıyoruz ve ortadan devam edebildiğimiz için çok fazla doğrulama ve devam ettirme temelli koda ihtiyaç duyuyoruz
Genel olarak tasarımı ve implementasyonu en kötü bulut sağlayıcısı; seçme şansım olsa asla tavsiye etmez ya da seçmezdim
İçeride Go ile yazılan şeyler genelde harika oluyor
Biz şirket içinde bir tane yaptık ama üçüncü taraf seçeneklerle de ilgileniyoruz
Yine de kurum içi iş kuralları nedeniyle satın almak yerine kendimiz yapmak daha doğru olabilir