Microsoft Azureの利用を避けるべき400の理由
(azsh.it)- Microsoft Azureで毎日体験する奇妙な出来事を共有するアカウント。現在400日を超えている
- Day 403: 最近 #Microsoft Cloud for Sustainability Technical Summit があった。しかし実際には、持続可能性に少し焦点を当てた #Copilot サミットのように感じられた。（このスクリーンショットは最初の3セッションからだけ取得したもの）
- Day 402: Azure CLIの新しい #AI 機能は今のところ素晴らしく動作している（エラーのスクリーンショット）
- Day 401: リンクのエラー画像。存在しないセクションにつながる #Azure ドキュメントリンクの無数の事例の1つにすぎない
...
1件のコメント
Hacker News のコメント
以前 Mojang で働いていたとき、Microsoft に買収されたのを機に AWS から Azure へ移行しようとしたことがある
表面的には筋が通っていたし、AWS の費用は月に6桁ドルだった一方で、Azure は無料で使えた
しかし1年ほど経ち、私たちのチームと Azure 組織が付けてくれたソリューション専門家たちが数え切れないほどの時間を費やした末に、Microsoft の大きな競合の一つに払う6桁の費用を払い続けるべきだという点で全員が一致した
それ以来、Azure を実運用に耐えるクラウドプロバイダーとは見なくなった。いつか再評価すべきかもしれないが、自分が間違っていたのは初めてではないのかもしれない
おおむね問題なかったが、CosmosDB、当時の名前で DocumentDB を使い始めてから問題が起きた
初期の DocumentDB は本当にひどく、料金の予測があまりに難しくて週末ごとにとんでもない請求が来たし、提供されていた .NET SDK もバグだらけでひどかった
最悪だったのは、Web UI が特定の CosmosDB インスタンスに直接ひも付いているように見えた点だった
データベースのリソースを少なく見積もると遅くなり、リソースを増やすために使う必要のある Web インターフェースまで一緒に遅延した
そのため Cosmos のリソースを上げるためにアプリケーション全体を止めなければならない状況もあり、Microsoft が完全に素人のように感じられた
今では Cosmos はずっと良くなっていると理解しているが、あのときの後味があまりに悪かった
無料クレジットのようなものがあれば Azure をもう一度試してみるかもしれないが、今は絶対に勧めない
世界最大のメールサービスを Windows スタックで動かすことは大きな保証になったはずだが、成功するまでに何年もかかった
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
AWS のサーバーレス処理方式のように、AWS 固有の機能で Azure に直接移せなかったのではないかと推測しているが、X から Y への移行がなぜ失敗したのかはいつも学びたい
その間にゲーム向けの技術がさらに整ってきたことも役に立ったのだと思う
修正: AWS -> Azure :)
AWS が全般的に先行していた分、当時は技術的なギャップがあり、後にそのギャップが埋まったのだと思う
大丈夫、Microsoft が来週には名前を変えて、管理 UI と API を完全に作り替えるから
今度の名前は Dynamics CoPilot OneAI 365 for Business OneCloud になるはず
live.comのものもあれば、outlook.com、さらにsharepoint.com、msbinbows.comのようなものも残るはずただしドキュメントやその他すべての参照は古い名前のまま残り続けるだろう
私の経験では、オンプレミスのサーバーラックから Linode、AWS、Azure まで使う組織を見てきたが、クラウドインフラへの不満はマネージドサービスの利用量に比例していた
主に仮想マシン、せいぜいマネージドなリレーショナルデータベース程度に依存しているチームは、ほとんど不満を言わなかった
多少スクリプトを余分に保守する必要はあるが、マネージドサービスの問題や特異な挙動と格闘することに比べれば小さな不便だ
当然ながら普通の仮想マシンはマネージドサービスより保守しやすく、だから自分でやらずに済むようクラウドプロバイダーにマネージドサービスの費用をずっと多く払うのだ
結局、この努力は本質的に無意味だということなのか？
多くの会社がクラウドへ移行する主な理由はマネージドサービスなので、この主張がまったく議論の余地がないとは言いにくい
ある顧客が本番サーバーのある VPC への IPsec トンネルを必要としており、顧客1社のためにその構成を自前で維持したくなかったので AWS の提供サービスを確認したところ、マネージド IPsec ソリューションがあった
ところが顧客からトンネルが落ちたと連絡があり、解決策は接続を再開するには顧客側で再起動する必要がある、というものだった
原因を見るために S3 ロギングを有効にすることはできるが、AWS 側の説明ではすべて正常であるはずだということだった
EC2 だけを使っていても奇妙なことは起きる
最近は EC2 インスタンスが応答しなくなったのに Auto Scaling Group が置き換えず、どんな操作をしてもインスタンスは実行中ではないというエラーが出る一方で、状態は実行中だった
幸い上司は同意しているが、全権を持っているわけではない
ベンダーロックインと、オープンソースとほぼ合っているが完全には一致しない API 互換性のせいで、より多くのチームが導入するほど不安になる
「でも簡単じゃないか！」と言われるが、様子を見るしかない
2014年ごろ以前は、AWS は主要サービスの価格を定期的に下げ、技術コストの低下分を還元していた
Azure はそれを嫌い、AWS の価格に合わせ始め、同じサービスの同じ割引に即座に追随した
これは競合が価格を下げても市場シェアを得られないようにして値下げの誘因を潰すことを目的としたもので、略奪的価格設定の一形態だ
ツール群とうまく統合されているので、Azureを本当に好きになりたかったが、ずっと仮想マシンの可用性制限やUXの奇妙な点にぶつかっていた
AWSでは、マシンを確保できなかったり、自分の行った作業が実際に反映されているのか疑ったりしたことはなかった
AzureのFaaSも何度か検討したが、今ではきっぱり「使わずに早く逃げろ」という側にいる
Azure Functionsまわりの体験があまりに奇妙で、快適になりようがないし、ログや他のバイナリ成果物にアクセスするのもひどく苦痛だ
空のWindows/Linux仮想マシンで自己完結型の.NETビルドを動かすのはあまりに簡単なので、こうした追加の複雑さすべてに関わる理由がない
さらにSQL Serverが実際にはあと20分経たないと準備できないのに、稼働中だとコールバックを送ってくるような、自動化を壊す挙動もある
terraform time_sleepはAzureの問題を避けるために特別に作られたのではないかと、半ば確信しているFunction Appが単純な関数を超えて、より長い実行時間やコールドスタート遅延なしを必要とするようになると、結局使うことになる同じサービスだ
App Servicesは慣れるのに時間がかかるが、組み込みFTPS、自己修復用のヘルスチェックエンドポイント、ストレージを指定するデプロイ、自動スケーリングオプション、99.95%のSLAを備えた、ロックダウンされたWin Server/IISコンテナだ
数年前は性能面でいまひとつだったが、最新CPUの2 vCPU以上のPremium SKUでは問題なかった
仮想マシンより高いが、Webサーバー仮想マシンのセキュリティと更新を扱うのはものすごく手間がかかる
Azureでホスティングしていた会社を買収した
彼らはホスティングPostgresとWindows上の.NETサービスを使っており、インフラは小さく、200〜300コアとメモリ1TB程度だった
数日ごとにMicrosoftがメンテナンスだとして任意のインスタンスをランダムに落とし、ネットワークを10分以上切断した
ホスティングPostgresは性能が悲劇的だったので移行したが、インド拠点の専門家が別のボリュームタイプを使うよう案内し、インスタンス再起動後にI/O遅延のせいでデータベースが立ち上がらなかった
その専門家は忙しいと言って3日連続で会議を避け、RCAはおそらくLLMが書いたような中途半端な文書で、自分たちの落ち度ではないとしていたが、チャートは別のことを示していた
GCPとAWSに勝っている唯一の点は、ダッシュボードの読み込みが速いことだけだ
ただし似たようなネットワーク作業を2つ並列に実行すると、失敗するか、逐次実行より10倍長くかかるので悲しい
逃げろ、使うな
すべてのPaaSプロバイダーの中で、Azureは抽象化とサービスが最悪だ
たいてい皆がこうした奇妙なサービスを消費することに同意し、クラウドアーキテクトや専門家の仕事が生まれているのが悲しい
パートナーたちを関係ある存在に保ち続けなければならないので、悪い設計と疎結合を食わせ続けている
実のところ、これはエンタープライズIT全体に対する自分の考えでもある
開発者30人ほどの小さな会社でAzureの混乱を引き継ぎ、必要なサービスについて、より業界標準に近い抽象化を開発ツールに作ったうえで、数年後にHetznerへ移った
ここの開発者は実質的に違いを知らない
我々のツールがワークフローとサービス抽象化を扱っており、こうしたものはプロバイダーが変わったからといって変わるべきではない
月額請求は10分の1になり、そのお金の一部を、考え得る最高の開発者体験を作ることに使った
非常に良い交換だったと思う
大手クラウドを使う価値があるケースは2つだけだ
本当に小さなMVP規模か、弾力性を必要とする巨大なグローバル分散環境かだ
ほとんどの会社に照らすと、どちらも例外に近い
Azureユーザーなら誰でもAzureを使うべきでない100の理由を作れそうだし、大半の大きなソフトウェアも同じだろう
他のクラウドにあまり触れてこなかった人間としても、Azureのユーザー体験がきちんと管理されておらず遅れていることは簡単に見て取れた
「さらに表示」を押さないとフィルターバーが正しく動作しないページの数は、今や明らかに0であるべきだ
これは客観的に悪いパターンで、何年も存在しており、修正するのは「簡単なはず」なのに、おそらく決して優先されないだろう
結局、そうした問題を解決することが組織の中核的価値であるか、収益に明確な打撃を与えない限り、修正されない
ユーザーコミュニティにとっては、こうした問題の公開性と可視性が常に重要だ
AWSとAzureの両方を使っているが、Azureで本当に気に入っている点が1つあり、それはポータルだ
AWS 2.0のようにクラウドの雑多なものが抽象化され、実際に操作しなければならない設定と、それら相互の関係だけが残っている
AWSも好きだが、見知らぬ環境に入ってすべての接続をリバースエンジニアリングしなければならないたびに、終わったら酒が必要になる
Azureを数日使ってみたとき、ポータルは本当に苦痛だった
クリックするたびに応答に5〜10秒かかり、基本設定の変更でもAjaxスピナーを2分以上眺めなければならないことがあった
こんなやり方で仕事をするのをどうやって楽しめるのか？
誰かがわざと最大限混乱するように作っているように見えるが、目的は想像もつかない
意見が無効だとか嘘だという意味ではないが、Azureエコシステムの中で毎時間を過ごしている人たちを含めても、Azureポータルを好きだという人を見たことがない
そうでないなら笑える
私は完全に反対側にいるので、人それぞれの好みだと見るべきなのだろう
どちらもかなり使ってきたが、Azureダッシュボードは相変わらず苛立たしいものの、使いやすさだけを見ればAWSよりずっと良い
それにMicrosoftがドキュメントに時間とお金をかけているのは明らかな一方で、AWSのドキュメントはいつもいまひとつだった
小規模な会社で、コンテナを運用していないなら、Cloudflare はかなり過小評価されているクラウドだと思う
別の理由で批判されているのは知っているが、ビッグ3あるいは4に疲れているなら、開発者体験は実際かなり優れている
[1]: https://blog.cloudflare.com/container-platform-preview/
Svelte のサイトには気に入っているが、言語とリクエスト・レスポンスベースの制約に縛られるのは非常に大きな制限だ
少なくともコンテナと永続ボリュームがなければ興味は湧かない
Azure が本当に情熱的に嫌いだ
クラウドプロバイダーごとのプロジェクト／アカウント／サブスクリプション作成を自動化するツールを作るチームにいる
メインのプロバイダーは GCP で、実装はかなり簡単だった
多少の落とし穴はあったが、簡単に乗り越えられた
いまはマルチクラウド対応として Azure をサポートしなければならない
以前は AWS にもいたが、95% は抜け出しており、まだ数チーム残ってはいるものの、Terraform モジュール以外にはほとんどツールを作っていない
ところが Azure API、MS Graph API、そしてその両方の Go SDK は、これまで扱った中で最大級のゴミの山だ
すべてがポインタで、文字列リテラルでさえポインタにしなければならないのに、場合によってはそうではない
ドキュメントは不正確で、ある API は ID だけを受け取るが、別の API は完全なパスを受け取る
一部は文書化されているが、多くの API には間違った形式が書かれている
どの API も関連リソース ID を返さないため、すべて検索しなければならず、名前ベースの検索が多すぎる
作成中に同じリソースを繰り返し照会しないよう、ID キャッシュ層まで追加する必要があった
私たちは作成にステートマシンを使い、途中から再開できるため、確認と再開を前提にしたコードが大量に必要になる
全体として、設計も実装も最悪のクラウドプロバイダーであり、選択肢があるなら絶対に勧めないし選ばない
社内で Go で書かれたものはたいてい素晴らしい
うちは社内で1つ作ったが、サードパーティーの選択肢にも興味がある
ただし社内のビジネスルールのせいで、購入するより自作するほうが合っているかもしれない