Microsoftのレイ・オジー氏、オープンソースやAzureなどを語る（2/4 ページ）

[Darryl K. Taft，eWEEK]

AzureにとってMicrosoftのモデリング戦略が意味すること

――　ツールとアプリケーション開発に興味があります。そこでOsloとMicrosoftのモデリング戦略が、Windows Azureのクラウド環境においてどのような意味を持つのでしょうか？　また、あなたのモデリングに対する全般的な考え方はどのようなものでしょうか？

オジー　抽象化という点では、最終的なゴールはアナリストから開発者まで、すなわち解決すべきビジネスの問題を理解している人からそれらをコードとして記述できる人までが、運用環境においてどのように展開し、管理をするか、可能な限り範囲を広げてライフサイクル全体をモデリングに抽象化できるようにすることになります。

　Osloの開発チームは、最先端のアーキテクチャをベースに卓越したビジョンでスタートし、そのビジョンからOsloを構築したのです。

　もしAzureのフードを開けて中を見ることができれば、基本的にモデルドリブンな仕組みであることが分かるでしょう。ソーセージ工場のように、それぞれの工程が密接に連携しているのです。シンタックス的にマッピングされているわけではありませんが、それが問題ではありません。ドン（ボックス氏、Microsoftの有名なエンジニア）が、それらをマッピングする方法を示しています。

　重要な点は、Azureが本質的にはサービスモデルであり、非常に堅牢なサービスモデルであるということです。基本的には、スイッチがあり、多重化機能があり、ロードバランサーがあって、Webのフロントエンドがあります。それぞれの役割と、それらの役割の関係を定義し、適正なシステムには何をどれくらい置くか、マキシマムとミニマムを明示し、それぞれの役割の結合性や類似性、あるいはそういう言葉があるかどうか分かりませんが、非結合性を決定して、どの程度のものを遠隔地のデータセンターに置くのか決めるのです。例えば3分の2を近くのデータセンターにまとめて置き、3分の1は遠くの場所に置くといったことです。そうした洗練されたディスクリプションがあってこそ、サービスやオペレーションは正確にコードを実行できるようになります。

　われわれは、今多くのことを学んでいるところです。来年には実際に利用する人々からもっと多くのことを学ぶことができるでしょう。しかし、そのレベルに到達するためには、モデリング無しでは絶対に不可能でした。

　例えば、レプリケーションに関するインテリジェントな意思決定を行うためにコードを追加するということなどは、手続き的にそれらを味付けすることができるでしょうか。もちろん可能ですし、そうするつもりですが、今のところは単に宣言的なものにとどまっています。

　しかし、目標は完全なツールチェーンの実現です。ビジネスアナリストからスタートし、あらゆる段階の人々をカバーします。われわれは今、少なくともインハウスの複数のプロジェクト間で共通のレポジトリを持つ段階にあり、さらに前進しているところです。

　しかし、少なからず困難も伴います。足を踏み外してしまうようなものではありませが、われわれはAzureにおいて、いくつかの問題に直面しました。例えばデータベースをリポジトリとして、クラウド上の環境でも障害がないという、非常に基本的な要求に対処しなければなりません。パッケージ化されたサブシステムでない限り、それは非常に複雑なものとなるのです。なぜなら、実際にはコントロールがされているべきなのですが、要求が複数だったり、織り交ぜられたサーバ群だったりした場合に、どうやって方向性を示せばよいのでしょうか……。