こんにちは、Azureサポータビリティチームの平原ともうします。現在、私はグローバルエスカレーションチームに所属しており、世界の各国からのエスカレーションや、サポートプロセス改善、製品改善について仕事していますが、2010年のAzureリリース当初から一貫してビジネスに関わってきました。
本日は2022年12月のAdvent Calender用に、Microsoft Azureの歴史 (主にコンピュートとネットワークのコアサービス観点)、私の仕事やキャリアの話を絡めてお話しできたらな、と思います。所属がサポートですので、恐縮ながらその観点での記述が多くなってしまいますが、少しでもクラウドコンピューティングに関わる方々の参考になれば幸いです。またMicrosoft もしくは外資系でサポートエンジニアを考えられている方は、どういう仕事をするのかも、参考になるのではと思います。
黎明期 (2008 – 2012)
現在Microsoft Azureと呼ばれているもののコアとなるサービスは、2008年のPDC (Professional Developer Conference)にて初めて公に発表されました。コードネームはRed Dog、私もおぼろげながらの当時の印象は、インターネット上にあるWindows OSという印象でした。当時私はデベロッパーサポートにおり、C/C++/C#のコンパイラーやライブラリ、.NET FrameworkやVisual Studio、開発アドバイスの技術者支援をしておりました。サポートエンジニアというポジションで、主にお客様からの.NET やVisual Studioを使った際の開発時の質問やアドバイスをする仕事でした。今のサポートエンジニアも製品は違えど、基本的にはお客様からの質問を電話・メールでお受けして、対応するというものです。その当時の私が、まさか自分がAzureを担当することになるとは全く思っていませんでした。
2009年の暮れごろでしょうか、当時の私のマネージャーから打診があり、新サービスのサポートをしてみないかとのことでした。それがAzureであり、当時言われたこととして覚えているのは、「全く新しいものなので、もしかしたら今のチームには戻れないかもしれない」、という話でした。当時の印象では、「インターネット上のWindows OS」という認識しかなかったものの、内容自体は面白そうでしたので、二つ返事で引き受けました。その後、まさか本当に元の担当に戻らずに、それから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 など)です。すべて、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が2017年に言及したCloud Computingという概念や、NISTのCloud Computingの定義などもその当時からもありました。10年以上経って４度にわたるポータルの変遷などを経て、現在、此処其処で利用されている状況を見ると、それがイメージできるようになるのは、ある程度、時間をかけた市場でのデザインの洗練化が必要なものだったのかもしれません。
また当時日本マイクロソフト株式会社独自のマーケティング施策の一環として「クラウディア」というキャラクターがいましたが、古くからAzureに携わられている方には覚えている方もいらっしゃるかもしれません。社員がコミックマーケットに参加したりなどして、コミュニティ活動ではJAZUG (Japan Azure User Group) 活動があったりと、日本マイクロソフトとしては、自由な発想で様々な活動しておりました。
転換期 (2013 – 2015)
2013年から2015年までの期間はAzureとMicrosoftにとっても、大きなニュースが多いのではないかと思います。
2013年にリリースされたIaaS関連の製品群である仮想マシン (Virtual Machine: Persistent VM Role) や仮想ネットワーク (Code name: Brooklyn) は製品としてかなり大きな転換となる製品でした。これまでのPaaS製品群ではOS内部にデータを保存しても、再イメージ化などでOSの内部がリフレッシュされデータが削除されてしまうものでしたが、IaaS仮想マシンでは、指定されたディスク内に恒久データの保存が可能になりました。仮想ネットワークでは、それまではロードバランサーから直接仮想マシンに接続していたものが、(ある程度は制約がありましたが) 多くのユーザーが直接仮想マシンやネットワークを操作・構成できるようになりました。また、仮想ネットワークを構成することにより、関連するコンピュートリソースをネットワーク的に分離することが可能となり、VPNや専用線 (Express Route) 等も使ってより複雑なネットワーク構成が可能となりました。
2013年には、Backup サービスや復旧サービス (Recovery Service) などが提供開始されました。それ以前にはバックアップする場合には、ストレージデータのコピーにて対応していたものが、バックアップの観点で可用性のオプションが増えました。
2014年には、日本では新たにデータセンターが開設になりました。お客様によっては、データを日本国内に配置しなければいけないビジネス要件等もあるため、日本にデータをおけないことに懸念を示すお客様にとっては大きな朗報になったと思います。またこの年は、Azureの名称がWindows AzureからMicrosoft Azureに変更になりました。ただの名称変更のようにも見えるのですが、これはAzureがMicrosoftにとって今後の戦略的位置付けになる決意表明のようなものでもありました。「Windows Azure」は、当初のコンセプトとしてWindowsテクノロジーとの結びつきが強いものでしたが、2010年代からMicrosoftはオープンソース活動にもかなり力を入れていました。実際、仮想マシンでもLinux OSを利用することが可能でした。Windowsだけでなく、他社開発プロバイダーやオープンソース業界含めたプラットフォームとなる決意でありました。
またいろいろなサービスがより様々なサービスがAzureの名のもとにオンライン展開、再ブランディングされていくことになります。特に新たなサービスとして、Azure Active Directory や AI 関連の技術 (Machine Learning)なども、この時期に登場しています。
2015年に４代目となる現在のポータル (Code name: Ibiza、2022現在のポータル) がリリースされ、Azureのリソース管理システムも Resource Manager (ARM) をベースとしたリソース管理システムに移行しました。それ以前はRDFE (Reddog Frontend)、Azure Service Management (ASM)と呼ばれるものでリソース管理されていましたが、Role-Base Access Control (RBAC) によるユーザー管理などがなく、非常に限られたユーザー権限でしか操作ができず、またリソース管理機能も内部的な制限が多かったため、このARMによる新しいリソース管理システムにより、ユーザーによるサービス管理の自由度がかなり上がりました。
また仮想マシンの可用性の観点で言えば、以前はホストOSのメンテナンスが定期的に停止を伴うものでありましたが、2013年ごろからメモリ保護メンテナンス(Memory-Preserving Maintenance)や、新たにLive Migrationなども導入し始め、現状では一部の大きなメンテナンスを除き、大きな停止のないメンテナンスが主流となっています。可用性面については、外部のお客様の声を真摯に受け止めて製品改善を進めていきました。この点は、サポートチームによるお客様の声のフィードバックと、継続的な製品改善プロセスが大きく貢献したと思います。
サポート部門では、この当時、私も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のサポートも含めると、現在は多くの人がオンライン製品系のサポートに従事するようになっています。
＊＊
以上、Azureリリース時期からの昔話でした。製品は多岐にわたるので、すべてを説明できず抜けも多々あるかもしれません。また、サポートの観点からの話になり恐縮ではありますが、なにかの参考になれば幸いです。
補足：テクニカルサポートについて
また、最後にせっかくの機会なので、テクニカルサポートの宣伝をさせていただこうと思います。
以上、御覧いただいた通り、テクニカルサポートエンジニアの仕事は多岐にわたり、もちろん電話・メール・Webを使っての技術支援をしますが、それと同時に製品改善やチーム貢献の機会があり、自分から申し出れば(それがビジネス上有用であれば)、新しい取り組みを自分で始めることも可能です。単純にサポート担当の窓口として人を置いているわけではなく、戦略的な位置付けとしてチームを配置しお客様へお役に立つ情報の提供や、トラブルシュート、製品改善に役立てています。また製品のスペシャリストになれるので(場合によっては社内で一番)、その後キャリアを積むうえでも利点が多く、コンサルティングやテクニカルセールス、営業(アカウントマネージャー)、ピープルマネージャー、開発部門、海外のサポートチーム、等々、多くの方が当サポートエンジニアの仕事を経験したうえで、社内外で活躍されています。
一方、最近はなかなか先を見通すことができない時代になってきており、実際、クラウドに対するサポート体制が各社でここまで大きく転換をするというのは、2009年当時、どなたも想像もできていなかったのではと思います。これはおそらく今後も同じで、キャリアを考える上では、「どれが正解」というのが見えづらくなっており、むしろキャリアの方向性をよりレジリエントかつ柔軟に考える必要があるのかなと思います。最近の話題として、AIの発展により一部職業がなくなるのではという話があります。テクニカルサポートに関して言うと、将来的にAIが発展しても、一部サポートオペレーションは自動化をできる可能性はもちろんあります。しかし、我々の取り扱う内容は基本的に「人」をベースとしたものであり、技術的に複雑な未知の問題、表出されて来なかった要望、などについては、継続して人の手を介する必要があり、今後はより専門性と問題把握力、コミュニケーション力が必要になっていくものになるのではと思います。
ご本人の嗜好や方向性もあるので、一概にすべての方におすすめできる仕事ではありませんが、長年の経験から技術職の1つの可能性として考えていただくのもよいのかなと思います。