- Sebuah akun yang membagikan hal-hal aneh yang dialami setiap hari di Microsoft Azure. Saat ini sudah melewati 400 hari
- Day 403: Baru-baru ini ada #Microsoft Cloud for Sustainability Technical Summit. Namun, kenyataannya terasa lebih seperti summit #Copilot dengan sedikit fokus pada keberlanjutan. (Tangkapan layar ini diambil hanya dari tiga sesi pertama)
- Day 402: Fitur #AI baru di Azure CLI sejauh ini bekerja dengan sangat baik (tangkapan layar error)
- Day 401: Gambar error tautan. Ini hanyalah salah satu dari tak terhitung banyaknya contoh tautan dokumentasi #Azure yang mengarah ke bagian yang bahkan tidak ada
...
1 komentar
Pendapat Hacker News
Dulu saat bekerja di Mojang, setelah diakuisisi Microsoft, kami mencoba berpindah dari AWS ke Azure
Di permukaan itu masuk akal; biaya AWS kami mencapai enam digit dolar per bulan, sementara Azure bisa dipakai gratis
Namun setelah sekitar satu tahun, setelah tim kami dan para spesialis solusi yang ditugaskan organisasi Azure menghabiskan waktu tak terhitung banyaknya, semua sepakat bahwa kami harus tetap mempertahankan biaya enam digit yang dibayarkan ke salah satu pesaing besar Microsoft
Sejak itu saya tidak lagi memandang Azure sebagai penyedia cloud yang layak dipakai secara nyata, dan meski suatu hari mungkin perlu dievaluasi lagi, mungkin ini bukan pertama kalinya saya keliru
Secara umum lumayan, tetapi masalah muncul ketika kami mulai memakai CosmosDB, yang saat itu bernama DocumentDB
DocumentDB awal benar-benar buruk; biayanya sangat sulit diprediksi sehingga setiap akhir pekan muncul tagihan yang tidak masuk akal, dan .NET SDK yang disediakan juga penuh bug dan mengerikan
Yang terburuk adalah UI web-nya tampak seperti terikat langsung ke instance CosmosDB tertentu
Jika resource database ditetapkan terlalu kecil, ia menjadi lambat, dan antarmuka web yang harus dipakai untuk menaikkan resource itu ikut tersendat
Jadi pernah ada situasi ketika kami harus mematikan seluruh aplikasi hanya untuk menaikkan resource Cosmos, dan Microsoft terasa benar-benar amatiran
Saya paham sekarang Cosmos sudah jauh lebih baik, tetapi pengalaman saat itu meninggalkan rasa yang sangat buruk
Kalau ada kredit gratis atau semacamnya, saya mungkin akan mencoba Azure lagi, tetapi saat ini saya sama sekali tidak akan merekomendasikannya
Menjalankan layanan email terbesar di dunia di stack Windows tentu akan menjadi jaminan yang sangat besar, tetapi butuh beberapa tahun sampai berhasil
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
Saya menduga mungkin ada fitur khas AWS, seperti cara AWS menangani serverless, yang tidak bisa langsung dipindahkan ke Azure, tetapi saya selalu ingin belajar mengapa perpindahan dari X ke Y gagal
Kemungkinan perkembangan teknologi di sisi game selama periode itu juga membantu
Koreksi: AWS -> Azure :)
Karena AWS secara umum lebih unggul saat itu, ada kesenjangan teknologi, dan tampaknya kesenjangan itu kemudian tertutup
Tidak apa-apa, minggu depan Microsoft akan mengganti namanya dan merombak total UI admin serta API-nya
Namanya nanti akan menjadi Dynamics CoPilot OneAI 365 for Business OneCloud
live.com, sebagianoutlook.com, dan sebagian lagisharepoint.com,msbinbows.com, dan semacamnyaNamun dokumentasi dan semua referensi lain pasti tetap mempertahankan nama lama
Dari pengalaman saya melihat organisasi yang memakai berbagai hal mulai dari rak server on-premises, Linode, AWS, hingga Azure, keluhan terhadap infrastruktur cloud berbanding lurus dengan tingkat penggunaan layanan terkelola
Tim yang terutama mengandalkan mesin virtual, paling jauh database relasional terkelola, hampir tidak pernah mengeluh
Memang harus memelihara sedikit lebih banyak skrip, tetapi itu ketidaknyamanan kecil dibandingkan bertarung melawan masalah dan perilaku aneh layanan terkelola
Tentu saja mesin virtual biasa lebih mudah dipelihara daripada layanan terkelola, dan karena itulah orang membayar jauh lebih mahal kepada penyedia cloud untuk layanan terkelola agar tidak perlu melakukannya sendiri
Jadi apakah maksudnya upaya ini pada dasarnya sia-sia?
Karena alasan utama banyak perusahaan pindah ke cloud adalah layanan terkelola, pernyataan ini jelas tidak bisa dibilang tidak kontroversial
Seorang pelanggan membutuhkan tunnel IPsec ke VPC tempat server produksi berada, dan karena kami tidak ingin memelihara konfigurasi seperti itu sendiri hanya demi satu pelanggan, kami mengecek layanan AWS dan menemukan solusi IPsec terkelola
Namun pelanggan menghubungi kami karena tunnel turun, dan solusinya adalah pihak pelanggan harus me-restart agar koneksi tersambung kembali
Kami bisa menyalakan logging S3 untuk melihat penyebabnya, tetapi menurut penjelasan dari pihak AWS semuanya seharusnya normal
Bahkan hanya memakai EC2 pun hal aneh bisa terjadi
Baru-baru ini sebuah instance EC2 berhenti merespons, tetapi Auto Scaling Group tidak menggantinya, dan tindakan apa pun menghasilkan error bahwa instance tidak sedang berjalan, padahal statusnya berjalan
Untungnya atasan saya setuju, tetapi ia tidak punya wewenang penuh
Karena vendor lock-in dan kompatibilitas API yang hampir sama dengan open source tetapi tidak sepenuhnya sama, saya makin khawatir seiring makin banyak tim mengadopsinya
Mereka bilang, “Tapi ini lebih mudah!”; ya, kita lihat saja nanti
Sebelum sekitar 2014, AWS secara berkala menurunkan harga layanan-layanan utama dan meneruskan penurunan biaya teknologi kepada pelanggan
Azure tidak menyukai itu, sehingga mulai menyamai harga AWS, dan segera mengikuti diskon yang sama untuk layanan yang sama
Ini adalah bentuk predatory pricing karena tujuannya membunuh insentif penurunan harga dengan memastikan pesaing tidak memperoleh pangsa pasar meski menurunkan harga
Saya benar-benar ingin menyukai Azure karena terintegrasi baik dengan berbagai tool, tetapi terus saja terbentur batasan ketersediaan mesin virtual dan keanehan UX
Di AWS, saya tidak pernah gagal mendapatkan mesin, atau meragukan apakah tindakan yang saya lakukan benar-benar diterapkan
Saya juga beberapa kali mempertimbangkan FaaS Azure, tetapi sekarang sikap saya tegas: “jangan pakai, segera kabur”
Pengalaman di sekitar Azure Functions terlalu aneh sehingga sulit dibuat nyaman, dan mengakses log atau artefak biner lain juga luar biasa menyakitkan
Menjalankan build .NET yang self-contained di mesin virtual Windows/Linux kosong itu sangat mudah, jadi tidak ada alasan untuk terlibat dengan semua kompleksitas tambahan ini
Ada juga perilaku yang merusak otomasi, seperti mengirim callback bahwa SQL Server sudah berjalan padahal sebenarnya baru siap 20 menit kemudian
Saya setengah yakin
terraform time_sleepdibuat khusus untuk menangkal masalah AzureJika function app membutuhkan lebih dari fungsi sederhana, seperti waktu eksekusi lebih panjang atau tidak ada latensi cold start, pada akhirnya layanan yang dipakai adalah layanan yang sama
App Services butuh waktu untuk dibiasakan, tetapi ini adalah kontainer Win Server/IIS yang terkunci, dengan FTPS bawaan, endpoint health check untuk self-healing, deployment yang menunjuk ke storage, opsi autoscaling, dan SLA 99,95%
Beberapa tahun lalu performanya kurang bagus, tetapi SKU Premium dengan 2 vCPU atau lebih pada CPU terbaru tidak bermasalah
Lebih mahal daripada mesin virtual, tetapi mengurus keamanan dan update mesin virtual web server itu pekerjaan yang sangat banyak
Kami mengakuisisi perusahaan yang di-hosting di Azure
Mereka memakai Postgres terkelola dan layanan .NET di atas Windows, dan infrastrukturnya kecil, sekitar 200–300 core dan memori 1 TB
Setiap beberapa hari Microsoft, dengan alasan maintenance, menurunkan instance acak sesuka hati dan memutus jaringan lebih dari 10 menit
Performa Postgres terkelolanya tragis sehingga kami migrasikan, tetapi seorang spesialis berbasis di India menyarankan memakai tipe volume lain, dan setelah instance direstart, database tidak bisa naik karena latensi I/O
Spesialis itu menghindari rapat selama 3 hari berturut-turut dengan alasan sibuk, dan RCA-nya berupa dokumen setengah matang yang tampak mungkin ditulis LLM, menyatakan itu bukan kesalahan mereka, tetapi grafik berkata lain
Satu-satunya hal yang mengalahkan GCP dan AWS hanyalah dashboard-nya dimuat cepat
Namun kalau menjalankan 2 operasi jaringan serupa secara paralel, hasilnya gagal atau memakan waktu 10 kali lebih lama daripada dijalankan berurutan, jadi menyedihkan
Kabur, jangan pakai
Di antara semua penyedia PaaS, Azure punya abstraksi dan layanan yang paling buruk
Sedih melihat semua orang pada umumnya sepakat untuk mengonsumsi layanan aneh seperti ini, lalu terciptalah pekerjaan untuk cloud architect dan spesialis
Karena harus terus membuat para partner tetap relevan, desain buruk dan coupling longgar itu terus diberi makan
Sebenarnya ini juga pendapat saya tentang seluruh IT enterprise
Di perusahaan kecil dengan sekitar 30 developer, kami mewarisi kekacauan Azure, lalu membuat abstraksi yang lebih mendekati standar industri untuk layanan yang dibutuhkan di tool pengembangan, dan beberapa tahun kemudian pindah ke Hetzner
Para developer di sini praktis tidak merasakan perbedaannya
Tool kami menangani workflow dan abstraksi layanan, dan hal-hal seperti ini seharusnya tidak berubah hanya karena providernya berganti
Tagihan bulanan menjadi sepersepuluhnya, dan sebagian uang itu kami pakai untuk membangun pengalaman developer terbaik yang bisa dibayangkan
Menurut saya itu pertukaran yang sangat bagus
Hanya ada dua kasus ketika cloud besar layak dipakai
Skala MVP yang benar-benar kecil, atau lingkungan terdistribusi global raksasa yang membutuhkan elastisitas
Dilihat dari kebanyakan perusahaan, keduanya lebih mirip pengecualian
Saya rasa siapa pun pengguna Azure bisa membuat 100 alasan untuk tidak memakai Azure, dan hal yang sama mungkin berlaku untuk sebagian besar software besar
Bahkan sebagai orang yang paparan ke cloud lain tidak banyak, mudah terlihat bahwa pengalaman pengguna Azure tidak dikelola dengan baik dan tertinggal
Jumlah halaman yang harus menekan “lihat selengkapnya” agar bilah filter berfungsi dengan benar seharusnya sekarang jelas-jelas 0
Ini pola yang secara objektif buruk, sudah ada bertahun-tahun, dan “seharusnya” mudah diperbaiki, tetapi mungkin tidak akan pernah menjadi prioritas
Pada akhirnya, masalah seperti itu tidak akan diperbaiki kecuali menyelesaikannya merupakan nilai inti organisasi atau jelas-jelas menghantam pendapatan
Bagi komunitas pengguna, keterbukaan dan visibilitas masalah seperti ini selalu penting
Saya memakai AWS dan Azure, dan satu hal yang benar-benar saya suka dari Azure adalah portalnya
Seperti AWS 2.0, keruwetan cloud diabstraksikan, dan yang tersisa hanya pengaturan yang memang perlu dioperasikan serta hubungan satu sama lain
Saya juga suka AWS, tetapi setiap kali masuk ke lingkungan yang asing dan harus merekayasa balik semua koneksinya, setelah selesai saya butuh minum alkohol
Saat mencoba Azure selama beberapa hari, portalnya benar-benar menyiksa
Setiap klik butuh 5–10 detik untuk merespons, dan kadang untuk mengubah pengaturan dasar saja harus menatap spinner Ajax lebih dari 2 menit
Bagaimana mungkin ada yang bisa menikmati bekerja seperti ini?
Rasanya ada orang yang sengaja membuatnya sebingung mungkin, tapi saya bahkan tidak bisa menebak tujuannya
Bukan berarti pendapatnya tidak valid atau bohong, tetapi bahkan termasuk orang-orang yang hidup setiap jam di dalam ekosistem Azure, saya belum pernah melihat orang yang menyukai portal Azure
Kalau bukan, lucu juga
Saya berada di sisi yang sepenuhnya berlawanan, jadi sepertinya harus dianggap selera masing-masing
Saya sudah cukup banyak memakai keduanya, dan dashboard Azure memang masih menjengkelkan, tetapi kalau melihat usability saja, jauh lebih baik daripada AWS
Selain itu, Microsoft jelas menghabiskan waktu dan uang untuk dokumentasi, sedangkan dokumentasi AWS selalu kurang bagus
Jika perusahaannya kecil dan tidak menjalankan container, Cloudflare adalah cloud yang sangat diremehkan
Saya tahu Cloudflare dikritik karena alasan lain, tetapi kalau Anda sudah lelah dengan 3 atau 4 besar, pengalaman developernya benar-benar luar biasa
[1]: https://blog.cloudflare.com/container-platform-preview/
Saya menyukainya untuk situs Svelte, tetapi terikat pada bahasa dan batasan berbasis request-response adalah keterbatasan yang sangat besar
Minimal harus ada container dan persistent volume baru saya tertarik
Saya benar-benar sangat membenci Azure
Saya berada di tim yang membuat tool untuk mengotomatiskan pembuatan project/account/subscription per penyedia cloud
Penyedia utama kami adalah GCP, dan implementasinya cukup mudah
Ada beberapa jebakan kecil, tetapi mudah dilewati
Sekarang kami harus mendukung Azure untuk multicloud
Dulu kami ada di AWS, tetapi 95% sudah keluar, dan meskipun masih ada beberapa tim yang tersisa, kami hampir tidak membuat tool selain modul Terraform
Namun Azure API, MS Graph API, dan Go SDK untuk keduanya adalah tumpukan sampah terbesar yang pernah saya tangani
Semuanya berupa pointer, bahkan string literal pun harus dibuat menjadi pointer, tetapi kadang juga tidak
Dokumentasinya tidak akurat; sebagian API hanya menerima ID, sementara API lain menerima path lengkap
Sebagian didokumentasikan, tetapi banyak API mencantumkan format yang salah
Tidak ada API yang mengembalikan ID resource terkait, jadi semuanya harus dicari, dan terlalu banyak pencarian berbasis nama
Kami bahkan harus menambahkan layer caching ID agar tidak terus-menerus mengambil resource yang sama selama proses pembuatan
Kami memakai state machine untuk pembuatan dan bisa melanjutkan dari tengah, sehingga diperlukan banyak kode berbasis verifikasi dan resume
Secara keseluruhan, ini adalah penyedia cloud dengan desain dan implementasi terburuk, dan jika ada pilihan, saya sama sekali tidak akan merekomendasikan atau memilihnya
Hal-hal yang ditulis secara internal dengan Go biasanya bagus
Kami membuat satu secara internal, tetapi juga tertarik pada opsi pihak ketiga
Namun karena aturan bisnis internal, membuat sendiri mungkin memang lebih tepat daripada membeli