こんにちは、Azure サポータビリティチームの平原です。現在、私はグローバルエスカレーションチームに所属しており、世界の各国からのエスカレーションや、サポートプロセス改善、製品改善について仕事していますが、2010 年の Azure リリース当初から一貫してビジネスに関わってきました。
今回は通常の技術ブログとは毛色が異なる内容となりますが、2022 年 12 月の Advent Calender 用に、 Microsoft Azure の歴史 (主にコンピュートとネットワークのコアサービス観点)、私の仕事やキャリアの話を絡めてお話しできたらな、と思います。私の所属がサポートですので、恐縮ながらその観点での記述が多くなってしまいますが、少しでもクラウドコンピューティングに関わる方々の参考になれば幸いです。また Microsoft もしくは外資系でサポートエンジニアを考えられている方は、どういう仕事をするのかも、参考になるのではと思います。
黎明期 (2008 – 2012)
現在 Microsoft Azure と呼ばれているもののコアとなるサービスは、2008 年の PDC (Professional Developer Conference) にて初めて公に発表されました。コードネームは Reddog 、私もおぼろげながらの当時の印象は、インターネット上にある Windows OS/Server という印象でした。当時私はデベロッパーサポートにおり、C/C++/C# のコンパイラーやライブラリ、.NET Framework や Visual Studio、開発アドバイスの技術者支援をしておりました。サポートエンジニアというポジションで、主にお客様からの .NET や Visual Studio を使った際の開発時の質問やアドバイスをする仕事でした。今のサポートエンジニアも製品は違えど、基本的にはお客様からの質問を電話・メールでお受けして、対応するというものです。その当時の私が、まさか自分が Azure を担当することになるとは全く思っていませんでした。
2009 年の暮れごろでしょうか、当時の私のマネージャーから打診があり、新サービスのサポートをしてみないかとのことでした。それが Azure であり、当時言われたこととして覚えているのは、「全く新しいものなので、もしかしたら今のチームには戻れないかもしれない」、という話でした。当時の印象では、「インターネット上の Windows OS/Server」という認識しかなかったものの、内容自体は面白そうでしたので、二つ返事で引き受けました。その後、まさか本当に元の担当に戻らずに、それから 10 年以上も Azure のビジネスに関わる仕事をすることになるとは、その時は、全く考えていませんでした。その後、すぐに米国での出張が手配されトレーニングが開始され、Beta エンジニアとしてまず 1 人から Beta サポートを開始したのでした。
2010 年秋ごろになり、Azure が Beta から正式リリースされました。当初「Windows Azure」という製品名でリリースされ、主に 4 つのサービスからスタートしました。これらは、Cloud Service (当時の名前では Hosted Service )、SQL Azure、Storage Service、AppFabric (Service Bus、Access Control Service; ACS など)です。すべて、PaaS のサービスであり、当初の利用方法はユーザーに Visual Studio を利用して、.NET ベース テクノロジーで配置パッケージを作成してもらい、それを Azure 上にアップデート・配置して使ってもらう、という形でリリースされました。今から考えると、当時の PaaS サービスは少し時代を先取りしすぎており、またアプリケーションの乗り換え (マイグレーション) のハードルがかなり高かったのだと思います。
Microsoft では、この期間、上記サービスをベースに様々な面から継続的な機能拡張をしており、トラブルシュート用に RDP 機能を追加したり、OS の初期構成できるようになったり、VM Role (ユーザーが自身でイメージを作成してそれをイメージとして利用) が Beta として利用できるようになったりとしましたが、依然IaaS の要望は根強かったように感じます。
補足：Cloud Service 上に展開できたVM Roleは、IaaS製品とは違い事前に作成したイメージから仮想マシンが作成されますが、仮想マシン内部に恒久的なデータを保存できません (non-persistent)。恒久的なデータは別途ストレージサービス等に保存する必要があります。
サポートチームの観点で言うと、当時はまだチームの規模も小さいものでした。営業チームやマーケティングチームとも案件関連で頻繁にやり取りしており、パートナー支援・営業支援、他企業とアライアンスなどもあり、それらも含め様々やり取りが多かったです。その当時かかわったお客様・社内の皆さんには大変お世話になりました。また、ご利用いただくお客様はほぼ固定化されており、お客様とも仲良くなったりして対応を進めていましたが、新規のお客様はなかなかに開発コンセプトを受け入れていただくのは難しそうでした。オンプレミスのサービスを移行するとなると、イメージとして一番しやすいのは、IaaS 製品をイメージするようで、「OS を自分で構成したい」、というお客様が多い印象でした。PaaS 環境は基本的に、OS はサービスプロバイダー (Azure の場合は Microsoft) が管理しており、ユーザー側でカスタマイズするというのは当初は NG でした (後ほど機能拡張で構成する方法がリリースされます)。PaaS のようにパッケージと構成ファイルを作ってデプロイする、というのは、かなりのパラダイムシフトが必要なようでした。しばらくして 2012 年ごろには、自ら進んで名乗りを上げてくれた意欲のある同僚や、興味を持ってサポートチームに新しく入社した方、マネージャーとで比較的小さなサイズでサポートチームは運営されていました。
余談ですが、2010 年は「日本のクラウド元年」と呼ばれています。各所でクラウド関連のイベントや社内マーケティングイベントなどがあり、私も何度か参加したりはしましたが、まだ当時は一部のアーリーアダプターで使われている状況であり、世の中広く使われているとはいいがたい状況でした。当時、「クラウドコンピューティング」に関するトレーニングにも参加してみたのですが、既存のホスティングサーバービジネスを焦点においた話題が多く、あまり概念として社会で固定化されていなかったのではと思います。文字や定義という意味では、Eric Schmidt が 2006 年に言及した Cloud Computing という概念 (*1) や、NIST の Cloud Computing の定義 (*2) などもその当時からもありました。10 年以上経って 4 度にわたるポータルの変遷などを経て、現在、此処其処で利用されている状況を見ると、それがイメージできるようになるのは、ある程度、時間をかけた市場でのデザインの洗練化が必要なものだったのかもしれません。
*1 MIT Technology Review - Who coined ‘Cloud Computing’
*2 The NIST Definition of Cloud Computing
また当時日本マイクロソフト株式会社独自のマーケティング施策の一環として「クラウディア」というキャラクターがいましたが、古くから Azure に携わられている方には覚えている方もいらっしゃるかもしれません。社員がコミックマーケットに参加したりなどして、コミュニティ活動では JAZUG (Japan Azure User Group) 活動 (*3) があったりと、日本マイクロソフトとしては、自由な発想で様々な活動しておりました。
転換期 (2013 – 2015)
2013 年から 2015 年までの期間は Azure と Microsoft にとっても、大きなニュースが多いのではないかと思います。
2013 年にリリースされた IaaS 関連の製品群である仮想マシン (Virtual Machine: Persistent VM Role) や仮想ネットワーク (Codename: Brooklyn) は製品としてかなり大きな転換となる製品でした。これまでの PaaS 製品群では OS 内部にデータを保存しても、再イメージ化などでOSの内部がリフレッシュされデータが削除されてしまうものでしたが、IaaS 仮想マシンでは、指定されたディスク内に恒久データの保存が可能になりました。仮想ネットワークでは、それまではロードバランサーから直接仮想マシンに接続していたものが、(ある程度は制約がありましたが) 多くのユーザーが直接仮想マシンやネットワークを操作・構成できるようになりました。また、仮想ネットワークを構成することにより、関連するコンピュートリソースをネットワーク的に分離することが可能となり、VPN や専用線 (Express Route) 等も使ってより自由度が高く、複雑なネットワーク構成が可能となりました。
2013 年には、Backup サービスや復旧サービス (Recovery Service) などが提供開始されました。それ以前にはバックアップする場合には、ストレージデータのコピーにて対応していたものが、バックアップの観点で可用性のオプションが増えました。
2014 年には、日本では新たにデータセンターが開設になりました。お客様によっては、データを日本国内に配置しなければいけないビジネス要件等もあるため、日本にデータをおけないことに懸念を示すお客様にとっては大きな朗報になったと思います。またこの年は、Azure の名称が Windows Azure から Microsoft Azure に変更になりました (*4)。
Today we are announcing that Windows Azure will be renamed to Microsoft Azure, beginning April 3, 2014. This change reflects Microsoft’s strategy and focus on Azure as the public cloud platform for customers as well as for our own services Office 365, Dynamics CRM, Bing, OneDrive, Skype, and Xbox Live. Our commitment to deliver an enterprise-grade cloud platform for the world’s applications is greater than ever. ..
*4 Upcoming Name Change for Windows Azure
ただの名称変更のようにも見えるのですが、これは Azure が Microsoft にとって今後の戦略的位置付けになる決意表明のようなものでもありました。「Windows Azure」は、当初のコンセプトとして Windows テクノロジーとの結びつきが強いものでしたが、2010 年代から Microsoft はオープンソース活動にもかなり力を入れていました。実際、仮想マシンでも Linux OS を利用することが可能でした。Windows だけでなく、他社開発プロバイダーやオープンソース業界含めたプラットフォームとなる決意でありました。
またいろいろなサービスがより様々なサービスが Azure の名のもとにオンライン展開、再ブランディングされていくことになります。特に新たなサービスとして、Azure Active Directory (AAD) や AI 関連の技術 (Machine Learning) なども、この時期に登場しています。
2015 年に 4 代目となる現在のポータル (Codename: Ibiza, 2022 現在のポータル) がリリースされ、Azure のリソース管理システムも Azure Resource Manager (ARM) をベースとしたリソース管理システムに移行しました。それ以前は RDFE (Reddog Frontend)、Azure Service Management (ASM) と呼ばれるものでリソース管理されていましたが、Role Base Access Control (RBAC) によるユーザー管理などがなく、非常に限られたユーザー権限でしか操作ができず、またリソース管理機能も内部的な制限が多かったため、この ARM による新しいリソース管理システム、および、AAD のユーザーにより、Azure リソース管理の自由度がかなり上がりました。
また仮想マシンの可用性の観点で言えば、以前はホスト OS のメンテナンスが定期的に停止を伴うものでありましたが、2013 年ごろからメモリ保護メンテナンス (Memory-Preserving Maintenance) (*5) や、新たに Live Migration (*5) なども導入し始め、現状では一部の大きなメンテナンスを除き、大きな停止のないメンテナンスが主流となっています。可用性面については、外部のお客様の声を真摯に受け止めて製品改善を進めていきました。この点は、サポートチームによるお客様の声のフィードバックと、継続的な製品改善プロセスが大きく貢献したと思います。
*5 Azure での仮想マシンのメンテナンス - 再起動を必要としないメンテナンス
サポート部門では、この当時、私も IaaS 製品が Beta の頃にちょうど米国での出張が重なりサポート体制の刷新や、新たな製品サポートの準備をしていました。当時はまだサポート部門としては小さくはありましたが、各人やる気に満ち溢れていました。私自身はリードとして、課金のシステムからコンピュート系のサービスにわたるまで見ていましたが、ここから急激に拡大していくことになり、サポートのチームの体制もより大きなものに変わっていきます。
Azure とは直接関係はありませんが、2014 年に Satya Nadera が新しい Microsoft の CEO になりました。対外的にもニュースになりましたが、これに伴って Microsoft のカルチャーが大きく変わる転換点となりました。このあたりの話は、Satya 自身が「Hit Refresh」という本を出して当時の状況についても説明しているので、ここで言及するよりも、そちらを読むことをお勧めします。Microsoft Teams が社内ハッカソンにて構築されたのは有名な話ではありますが、このカルチャーの転換がイノベーションの誘発に少なからず関連しているのではと思います。
成長期 (2016年 – 現在)
これ以降はさらに Azure が様々製品に拡張されていっており、新たな機能拡張や新製品の提供などを継続しています。コンピュート系の話題で言えば、ユーザー自身で再デプロイ (Redeploy: 2016) が実装されたり、Azure Monitor / Resource Health (2017)、管理ディスク (Managed Disk: 2017)、Azure Kubernetes Services (2018)、VM 用Serial Console (2018)、可用性 ゾーン (Azure Availability Zone: 2018)、専用ホスト (Dedicated Host: 2019) 等々、可用性と拡張性をベースに機能拡張されています (もちろんこれ以外にもたくさんの製品が出ています)。またこれからさらに多くのサービスが Azure 上に展開されてくるのではないかと思います。
サポート観点からは IaaS、Network、データベース、AI 系、など複数の部門に分かれ、Microsoft 365 のサポートも含めると、現在は多くの人がオンライン製品系のサポートに従事するようになっています。
補足：テクニカルサポートについて
また、最後にせっかくの機会なので、テクニカルサポートの宣伝をさせていただこうと思います。
以上、みていただいた通り、テクニカルサポートエンジニアの仕事は多岐にわたり、もちろん電話・メール・Web を使っての技術支援をしますが、それと同時に製品改善やチーム貢献の機会があり、自分から申し出れば (それがビジネス上有用であれば)、新しい取り組みを自分で始めることも可能です。単純にサポート担当の窓口として人を置いているわけではなく、戦略的な位置付けとしてチームを配置しお客様へお役に立つ情報の提供や、トラブルシュート、製品改善に役立てています。また製品のスペシャリストになれるので (場合によっては社内で一番)、その後キャリアを積むうえでも利点が多く、コンサルティングやテクニカルセールス、営業 (アカウントマネージャー)、ピープルマネージャー、開発部門、海外のサポートチーム、等々、多くの方が当サポートエンジニアの仕事を経験したうえで、社内外で活躍されています。
一方、最近はなかなか先を見通すことができない時代になってきており、実際、クラウドに対するサポート体制が各社でここまで大きく転換をするというのは、2009 年当時、どなたも想像もできていなかったのではと思います。これはおそらく今後も同じで、キャリアを考える上では、「どれが正解」というのが見えづらくなっており、まだ見ぬ製品やサービス・新たな形態でのビジネスが登場してくることも考えられ、むしろキャリアの方向性をよりレジリエントかつ柔軟に考える必要があるのかなと思います。最近の話題として、AIの発展により一部職業がなくなるのではという話があります。テクニカルサポートに関して言うと、将来的にAIが発展しても、一部サポートオペレーションは自動化をできる可能性はもちろんあります。しかし、我々の取り扱う内容は基本的に「人」をベースとしたものであり、技術的に複雑な未知の問題、表出されて来なかった要望、などについては、継続して人の手を介する必要があり、今後はより専門性と問題把握力、コミュニケーション力が必要になっていくものになるのではと思います。
ご本人の嗜好や方向性もあるので、一概にすべての方におすすめできる仕事ではありませんが、長年の経験から技術職の1つの可能性として考えていただくのもよいのかなと思います。
※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。