パブリッククラウドの選択肢として Microsoft Azure を採用する３つの理由
2021/05/27
はじめに
fwywd（フュード） では主にバックエンドを構築するためのインフラ環境として、パブリッククラウドである Microsoft Azure を採用しています。
現在パブリッククラウドのシェアが１位である Amazon Web Service (AWS) や元々利用していた Firebase と繋がる Google Cloud Platform (GCP) ではなく、Microsoft Azure を選択した理由をこの記事では紹介します。
現在パブリッククラウドのシェアが１位である Amazon Web Service (AWS) や元々利用していた Firebase と繋がる Google Cloud Platform (GCP) ではなく、Microsoft Azure を選択した理由をこの記事では紹介します。
先日投稿した Vue.js & Nuxt.js から React & Next.js へ移行した理由 が賛否両論はあるも多くの方に読んでいただき、その中で『バックエンドとして Azure を採用した理由を知りたい』といった声が寄せられたことが本記事を執筆したきっかけとなりました。
TL;DR
長文になるため、最初に結論を書いておくと以下が Microsoft Azure 採用するを３つの理由です。
- プロジェクトに必要なリソース管理を柔軟に細かく行える
- 開発に不可欠なツール群に Microsoft 製が多い
- 今後のパブリッククラウドシェア１位が期待される
これらの詳細な理由を今回は紹介していきます。
Microsoft とキカガクの関係性
まず前提として Microsoft Azure を選択するという記事を書く時に、私が代表であるキカガクと Microsoft 社の関係性をちゃんと書いておく必要があります。
キカガクが創業１年目の頃から日本マイクロソフト社と一緒に ディープラーニングハンズオンセミナー を共同開催してきた私にとってはなくてはならないパートナー企業の１社です。
Microsoft Azure が普及するということは私たちのビジネスにとって間接的ではありますが、メリットがあることは間違いありません。
Microsoft Azure が普及するということは私たちのビジネスにとって間接的ではありますが、メリットがあることは間違いありません。
その一方で、自社のインフラ環境を企業間の付き合いだけで決めるほど、私はエンジニアとしてプライドを捨ててはいません。
自分たちのビジネスとして一番良い選択肢はどれかと他の選択肢も当然考慮して技術調査を半年ほど進めてきました。
Vue.js & Nuxt.js から React & Next.js へ移行した理由 の記事にも書いていますが、最初のスモールスタートのプロダクトには Google 社が提供する Firebase を使う方が良いという結論を出して Firebase でインフラ環境を構築していました。
この記事でも書いていますが、プロダクトが大きくなってくるとリソースや権限管理などを細かく柔軟に調整できる必要性が出てきたため、次の選択肢を探し始めました。
自分たちのビジネスとして一番良い選択肢はどれかと他の選択肢も当然考慮して技術調査を半年ほど進めてきました。
Vue.js & Nuxt.js から React & Next.js へ移行した理由 の記事にも書いていますが、最初のスモールスタートのプロダクトには Google 社が提供する Firebase を使う方が良いという結論を出して Firebase でインフラ環境を構築していました。
この記事でも書いていますが、プロダクトが大きくなってくるとリソースや権限管理などを細かく柔軟に調整できる必要性が出てきたため、次の選択肢を探し始めました。
そして、今回紹介する要件を考えた時に、Microsoft Azure を採用することが現状の私たちにとってベストであると結論付けました。
だからこそ、多少の利害関係は拭いきれないですが、基本的には忖度なしで一エンジニアとして、みなさんにとって良い選択肢であることを一番優先して考えています。
だからこそ、多少の利害関係は拭いきれないですが、基本的には忖度なしで一エンジニアとして、みなさんにとって良い選択肢であることを一番優先して考えています。
Microsoft Azure が本当に良い製品だと伝えたいのにも関わらず、キカガクが Microsoft 推しだから Azure でしょ？と思われてしまいたくないため、先に前置きをしておきました。
Microsoft Azure を採用する３つの理由
結論でも書きましたが、以下３つの理由をそれぞれ紹介します。
- プロジェクトに必要なリソース管理を柔軟に細かく行える
- 開発に不可欠なツール群に Microsoft 製が多い
- 今後のパブリッククラウドシェア１位が期待される
理由１：プロジェクトに必要なリソース管理を柔軟に細かく行える
この理由は Microsoft Azure をパブリッククラウドとして採用する理由というよりも、Firebase を離れる理由という方が適切です。
Firebase は本当に使いやすくて個人開発からある程度大きなプロダクトまで対応することができ、今でも素晴らしいサービスだと思っていますし、多くの方の技術記事のおかげでスピード重視で開発を進めることができました。
Firebase は本当に使いやすくて個人開発からある程度大きなプロダクトまで対応することができ、今でも素晴らしいサービスだと思っていますし、多くの方の技術記事のおかげでスピード重視で開発を進めることができました。
そのような中、プロダクトが成熟していくとともに、Firebase ではいくつかの問題に遭遇するようになりました。
最も大きな問題は Firebase がプロジェクトという単位でリソースを管理していることでした。
具体的には１プロジェクトに以下のようなリソースがそれぞれ１つずつ紐づいています。
最も大きな問題は Firebase がプロジェクトという単位でリソースを管理していることでした。
具体的には１プロジェクトに以下のようなリソースがそれぞれ１つずつ紐づいています。
- プロジェクト
- Authentication
- Firestore（データベース）
- Storage
- Hosting
- Functions
- etc...
これは最初はリソース管理の手間を省いてくれるので助かると感じていました。
その一方で、現在 キカガク (kikagaku.ai) に加えて、fwywd というこの新サービスを持ったときに、このリソースの管理方法では良くないと気づきました。
キカガク (kikagaku.ai) ではログインを行う認証機能があり、fwywd でも近々認証機能を実装する予定です。
この時に、それぞれのプロジェクトで認証機能を実装するのであれば良いのですが、共通の機能を別々に実装することは良い判断とは言えません。
したがって、各プロダクトが共通で利用する認証機能を作っておくことで、情報の一元した管理が行えます。
また、実際にプロダクトを運用していて思うのが、認証機能の箇所は個人情報流出などに関わる攻撃の対象になる可能性が高く、専門性の高い人が関わっておかないと危険性が高いという問題があります。 Firebase では各プロジェクトに対して Authentication の機能が付随しているため、このように複数プロジェクトの共通リソースとして実装することができません。
※ そうとはいえ、認証用のプロジェクトを Firebase で作成してそれを参照させれば良いだけですので、工夫不足ではないかという指摘はごもっともです。どのような選択肢でも極めれば工夫のしようがあると思いますので、私の勉強不足をご容赦ください。
この時に、それぞれのプロジェクトで認証機能を実装するのであれば良いのですが、共通の機能を別々に実装することは良い判断とは言えません。
したがって、各プロダクトが共通で利用する認証機能を作っておくことで、情報の一元した管理が行えます。
また、実際にプロダクトを運用していて思うのが、認証機能の箇所は個人情報流出などに関わる攻撃の対象になる可能性が高く、専門性の高い人が関わっておかないと危険性が高いという問題があります。 Firebase では各プロジェクトに対して Authentication の機能が付随しているため、このように複数プロジェクトの共通リソースとして実装することができません。
※ そうとはいえ、認証用のプロジェクトを Firebase で作成してそれを参照させれば良いだけですので、工夫不足ではないかという指摘はごもっともです。どのような選択肢でも極めれば工夫のしようがあると思いますので、私の勉強不足をご容赦ください。
Microsoft Azure の場合は Azure Active Directory という ID as a Service (IDaaS) という機能があり、この認証から認可、情報の一元管理まで複数プロジェクトをまとめて行うことができます。
他の選択肢としては Auth0 が有名でしょうか。
AWS や GCP の IDaaS 系のサービスを調べきれていないのですが、おそらく同じような機能のものはあると思います。
だからこそ、この理由は Microsoft Azure を選択するというよりも、複数プロジェクトにまたがるリソースの管理を柔軟に行うことができれば良いため、AWS や GCP でも良いという話です。
基本的に必要な機能は３サービスともほぼ同程度に充実している印象で機能面では優劣つけがたいというのが本音です。
他の選択肢としては Auth0 が有名でしょうか。
AWS や GCP の IDaaS 系のサービスを調べきれていないのですが、おそらく同じような機能のものはあると思います。
だからこそ、この理由は Microsoft Azure を選択するというよりも、複数プロジェクトにまたがるリソースの管理を柔軟に行うことができれば良いため、AWS や GCP でも良いという話です。
基本的に必要な機能は３サービスともほぼ同程度に充実している印象で機能面では優劣つけがたいというのが本音です。
ちなみに余談ですが、fwywd で利用している IDaaS は Azure Active Directory B2C (AADB2C) というサービスで、これが本当に使いやすくて最高です。
AWS や GCP のサービスとは情報不足で比較できないのですが、Firebase の Authentication と比較すると、ログイン周りの UI を作らなくて良いという点で開発者体験としてかなり大きな差が出ます。
Firebase ではログインに関する機能が SDK として提供されており、比較的簡単に認証機能を実装できますが、ある程度コードを書く必要があり、簡単とはいえ少し学習コストが高い印象でした。
また、ログインのためのフォームなどの UI は基本的にフロントエンド側で作る必要があります。 たとえば、Firebase を採用している キカガク (kikagaku.ai) では、以下の画像のようにフォームは自前で作っていました。
AWS や GCP のサービスとは情報不足で比較できないのですが、Firebase の Authentication と比較すると、ログイン周りの UI を作らなくて良いという点で開発者体験としてかなり大きな差が出ます。
Firebase ではログインに関する機能が SDK として提供されており、比較的簡単に認証機能を実装できますが、ある程度コードを書く必要があり、簡単とはいえ少し学習コストが高い印象でした。
また、ログインのためのフォームなどの UI は基本的にフロントエンド側で作る必要があります。 たとえば、Firebase を採用している キカガク (kikagaku.ai) では、以下の画像のようにフォームは自前で作っていました。
それに対して、AADB2C ではこの UI を作る必要がありません。
ログインボタンに認証用の URL をつけて、ログイン画面へ遷移させるだけで設定完了です。
正直にいうと、この AADB2C が使いたいというのが Microsoft Azure を使いたいという理由の大半を占めているといっても過言ではありません。
ログインボタンに認証用の URL をつけて、ログイン画面へ遷移させるだけで設定完了です。
正直にいうと、この AADB2C が使いたいというのが Microsoft Azure を使いたいという理由の大半を占めているといっても過言ではありません。
しかも、この AADB2C を認証で使っておくと、API サーバーの認可時に Azure API Management と連携して、簡単にユーザーの認証情報をベースとした認可のセキュリティ対策もほとんどコードを書かずにできちゃいます。
理由２：開発に不可欠なツール群に Microsoft 製が多い
ここからは Micrsoft Azure を採用していく理由をどんどん絞って考えていきます。
Microsoft Azure のようなパブリッククラウドの選択はユーザー数（情報）の多さとエコシステムの充実度で私は考えるようにしています。
他には、社内での実績や稟議の通しやすさといった制約に近い問題もありますが、それを言い始めると制約＝選択肢になってしまうため、今回はこの観点は除きます（これが一番クリティカルかもしれませんが...）
ユーザー数の話は理由３で書きますので、理由２ではエコシステムの充実度を取り上げます。
他には、社内での実績や稟議の通しやすさといった制約に近い問題もありますが、それを言い始めると制約＝選択肢になってしまうため、今回はこの観点は除きます（これが一番クリティカルかもしれませんが...）
ユーザー数の話は理由３で書きますので、理由２ではエコシステムの充実度を取り上げます。
パブリッククラウドに付随するエコシステムとなると何があるか難しいところですので、私が開発時に使っているアイテムやツールを列挙してみることにします。
- Mac mini / iPhone
- Visual Studio Code
- Git / GitHub
- React / Next.js
- Tailwind CSS
- TypeScript / Node.js
他にもあると思いますが、ざっとこんな感じでしょうか。
余談ですが、私は昔から Mac 派でスティーブ・ジョブズを尊敬しているため、手元のデバイスは全て Apple 製、ジョブズ氏の評価したニューバランスの靴まで真似して履いているほどです。
Microsoft 製 の Surface Laptop のタイピングの心地よさは秀逸ですが、やはりメイン機は Apple 製から譲れません。
こう眺めてみると、太字で書いた Visual Studio Code, GitHub, TypeScript と私の中ではなくてはならない存在の３つが Microsoft 製（もしくは OSS 開発の中心という方が適切かも知れません）です。
それに対して、シェア１位の AWS が開発の手元に何か影響しているかというと意外とありませんでした（もちろん、Amazon をありがたく利用させていただいており、私は Amazon の超ヘビーユーザーです）。
それに対して、シェア１位の AWS が開発の手元に何か影響しているかというと意外とありませんでした（もちろん、Amazon をありがたく利用させていただいており、私は Amazon の超ヘビーユーザーです）。
まだまだこれだけでは決定打にならないことはわかりますが、手元に Microsoft 製が多いほど、他の Microsoft 製の製品との相性が良い可能性が高まると予想しています。
現に Visual Studio Code と GitHub の相性は最高ですし、Visual Studio Code と TypeScript の相性は言語化できないほど素晴らしいです。
Visual Studio Code と Azure の相性も良く、Azure Functions のデプロイは信じられないほど簡単です。
さすがは Microsoft 製であるため TypeScript への対応も早いのも魅力のひとつと言えます。
現に Visual Studio Code と GitHub の相性は最高ですし、Visual Studio Code と TypeScript の相性は言語化できないほど素晴らしいです。
Visual Studio Code と Azure の相性も良く、Azure Functions のデプロイは信じられないほど簡単です。
さすがは Microsoft 製であるため TypeScript への対応も早いのも魅力のひとつと言えます。
こう考えると、エコシステムという観点では AWS よりも豊富です。
Google と比較すると Web 開発は Google にお世話になりっぱなしですので、Google > Microsoft > AWS といったところでしょうか。
ただし、Visual Studio Code や GitHub, TypeScript の魅力は凄まじいため、私の中では Microsoft が１位といっても過言ではない気がしています。
Google と比較すると Web 開発は Google にお世話になりっぱなしですので、Google > Microsoft > AWS といったところでしょうか。
ただし、Visual Studio Code や GitHub, TypeScript の魅力は凄まじいため、私の中では Microsoft が１位といっても過言ではない気がしています。
理由３：今後のパブリッククラウドシェア１位が期待される
エコシステムともうひとつの要因であったユーザー数という視点で考えます。
現状のユーザー数の多さでいうと、間違いなく AWS でしょう。
書籍も AWS 系の方が圧倒的に多く、学びやすさは AWS の方が高いと思います。
今すぐ学んで活用したいという人は AWS の方が良い選択肢かもしれません。
また、社内に聞ける人の技術選定に合わせるという選択も良いでしょう。 ここは現在と将来を天秤にかける必要があるのではないでしょうか。
書籍も AWS 系の方が圧倒的に多く、学びやすさは AWS の方が高いと思います。
今すぐ学んで活用したいという人は AWS の方が良い選択肢かもしれません。
また、社内に聞ける人の技術選定に合わせるという選択も良いでしょう。 ここは現在と将来を天秤にかける必要があるのではないでしょうか。
私は近い将来 Micrsoft Azure がシェア１位になるのではないかと予想しています。
以下の画像は 2020 年までのパブリッククラウドのシェア比率の変遷です。
2020 4Q の時点で、AWS が 30% を少し上回り、Microsoft Azure が 20% を超えました。
ここで、将来といった観点で大事なところはやはり成長率です。
AWS のシェア自体はそこまで変化がないように見えますが、Microsoft Azure の成長率の高さが明らかですよね。
特にこの１年の成長の傾きが著しく、両サービスがこの成長率の変化を維持すれば、２〜３年すれば立場の逆転がありえると予想するのも現実的です。
AWS はそこまでシェアが減っていなかったり、GCP の成長もほとんど変わらないことを考えると、AWS や GCP 以外のサービス (Others や IBM) から Microsoft Azure への移行が行われていそうですね。
ここで、将来といった観点で大事なところはやはり成長率です。
AWS のシェア自体はそこまで変化がないように見えますが、Microsoft Azure の成長率の高さが明らかですよね。
特にこの１年の成長の傾きが著しく、両サービスがこの成長率の変化を維持すれば、２〜３年すれば立場の逆転がありえると予想するのも現実的です。
AWS はそこまでシェアが減っていなかったり、GCP の成長もほとんど変わらないことを考えると、AWS や GCP 以外のサービス (Others や IBM) から Microsoft Azure への移行が行われていそうですね。
また、もうひとつシェアが伸びそうだと予想する要因がオンプレミスからの移行です。
Microsoft は Windows OS で動くオンプレミスのマシンが日本中や世界中にまだまだ山ほど存在しています。
PC の OS シェアも Windows が圧倒的に１位です。
いまでこそ、クロスプラットフォーム対応や Web アプリケーションが増えたので使用する OS を意識する必要が少なくなっていますが、一昔前は Windows で動くアプリケーションを作るためには Visual Studio で .NET 系のフレームワーク (C#) を使うのが王道で、サーバーは Linux ではなく Windows 製品と互換性の良い Windows OS、DB は MySQL や PostgreSQL ではなく SQL Server が使われていました。
今もエンタープライズ領域で現役バリバリで使っている方は多いです。
まさに、エコシステムを Microsoft 製で固めた Microsoft ワールドだったのかなと当時を予想しています。
Microsoft は Windows OS で動くオンプレミスのマシンが日本中や世界中にまだまだ山ほど存在しています。
PC の OS シェアも Windows が圧倒的に１位です。
いまでこそ、クロスプラットフォーム対応や Web アプリケーションが増えたので使用する OS を意識する必要が少なくなっていますが、一昔前は Windows で動くアプリケーションを作るためには Visual Studio で .NET 系のフレームワーク (C#) を使うのが王道で、サーバーは Linux ではなく Windows 製品と互換性の良い Windows OS、DB は MySQL や PostgreSQL ではなく SQL Server が使われていました。
今もエンタープライズ領域で現役バリバリで使っている方は多いです。
まさに、エコシステムを Microsoft 製で固めた Microsoft ワールドだったのかなと当時を予想しています。
余談ですが、私が出会った頃（2017 年）の Microsoft 社は Linux を全面的に受け入れ、OSS に世界一コミットしている企業でしたので、この頃の Microsoft 社の存在の感覚がわかっておらず、予想で Microsoft ワールド風に脚色しています。
時代の変遷とともに、とくにサーバー側で有償の Windows OS から、無償の OS である Linux, 特に Dibian 系の Ubuntu を使うのが標準となってきている気がします。
Microsoft Azure も Linux を OS としたサービスが多く存在し、全面的に Linux で構築できるように支援されています。
OS を提供するビジネスモデルからインフラを提供するビジネスモデルへの転換があったのではないかと予想します。
Microsoft Azure も Linux を OS としたサービスが多く存在し、全面的に Linux で構築できるように支援されています。
OS を提供するビジネスモデルからインフラを提供するビジネスモデルへの転換があったのではないかと予想します。
本題に戻りますが、AWS はオンプレミスからではなく、クラウドから誕生した企業であるため、新興企業の選択肢として普及している印象です。
特に Linux を採用する企業に好まれて成長してきたので、Linux の普及と AWS の成長はリンクしていると思います。 本題とはそれますが、AWS 誕生秘話がとっても面白いのでぜひ読んでみてください。
特に Linux を採用する企業に好まれて成長してきたので、Linux の普及と AWS の成長はリンクしていると思います。 本題とはそれますが、AWS 誕生秘話がとっても面白いのでぜひ読んでみてください。
AWS の成長を横目に見ながら、Microsoft Azure も時代に適応した方向へとシフトしていきます。
そこから Azure の本気の巻き返しが始まります。 ちなみに私が AWS を認知していたのが 2012 年頃に対して、日本マイクロソフトとの協業の提案がある 2017 年まで Microsoft Azure の存在をほとんど知らず、選択肢としてはありませんでした。
そこから Azure の本気の巻き返しが始まります。 ちなみに私が AWS を認知していたのが 2012 年頃に対して、日本マイクロソフトとの協業の提案がある 2017 年まで Microsoft Azure の存在をほとんど知らず、選択肢としてはありませんでした。
さきほどの図を再掲すると、2017 年はじめには 10% 程度のシェアが、2020 年の Q4 には 20% を超えるところまで跳ね上がっています。
体感的にもこの５年でその存在感が大きくなっていると感じます。
体感的にもこの５年でその存在感が大きくなっていると感じます。
これまでの 成長の事実 と、これから起こりうる オンプレミスからの移行（リプレイス） を考えると、近い将来、Microsoft Azure のシェアが１位になる日が来る確率は高いのではと予想しました。
おわりに
Microsoft Azure の学び方
将来的なシェアの話を最後は書きましたが、AWS 系と比較すると、まだまだ Microsoft Azure 系の技術記事は少ない印象です。
私が Microsoft Azure の使い方を学んでいて気づいたことは、公式のドキュメントがいちばんわかりやすいということです。
各サービスに ドキュメント というリンクがついているため、それを見るのが一番早いです。
また、まだ使ったことがない人が多いかも知れませんが、Microsoft Learn という無料で学べる Microsoft 公式のサービスが素晴らしいです。
私が Microsoft Azure の使い方を学んでいて気づいたことは、公式のドキュメントがいちばんわかりやすいということです。
各サービスに ドキュメント というリンクがついているため、それを見るのが一番早いです。
また、まだ使ったことがない人が多いかも知れませんが、Microsoft Learn という無料で学べる Microsoft 公式のサービスが素晴らしいです。
fwywd としての取り組み
fwywd としては、React や Next.js の記事を技術速報として書いているように、Microsoft Azure の使い方もどんどん記事として公開していきます。
公式のドキュメントはその特性上、機能自体の説明が多くなります。
その一方で、私たち fwywd ではユーザーシナリオに重きを置いて、そのサービス群をどのように組み合わせるとどのようなことができるのかを伝える立場だと良い役割を果たせると思っています。
公式のドキュメントはその特性上、機能自体の説明が多くなります。
その一方で、私たち fwywd ではユーザーシナリオに重きを置いて、そのサービス群をどのように組み合わせるとどのようなことができるのかを伝える立場だと良い役割を果たせると思っています。
これから伸びるサービスだと予想するからこそ、企業の戦略としても伸びた時に『Microsoft Azure を勉強するなら、まず fwywd のチュートリアル見ると良いよ！』というポジションを取りに行きたいです。
そして、その行動がこれからの多くのプロダクト開発者に貢献できると嬉しいです。
そして、その行動がこれからの多くのプロダクト開発者に貢献できると嬉しいです。
再度になりますが、この記事は私個人の意見として書いたものです。
根拠の少ない直感的な予想も含まれていますので、参考程度で捉えていただけますと幸いです。
ただし、Microsoft Azure は予想ではなく、素晴らしい製品ですので、この点はご安心ください。
根拠の少ない直感的な予想も含まれていますので、参考程度で捉えていただけますと幸いです。
ただし、Microsoft Azure は予想ではなく、素晴らしい製品ですので、この点はご安心ください。
今回はエコシステムやユーザー数といった一般的な話で終始しましたが、次回以降では具体的な実装方法を紹介していきますので、ぜひ楽しみにしていてください。
毎度、長文へお付き合いいただきまして、誠にありがとうございました。
毎度、長文へお付き合いいただきまして、誠にありがとうございました。
関連記事
著者
