Agile Cat — in the cloud

2008年夏 Azure 前夜:David Chappell _1

Posted in David Chappell by Agile Cat on November 13, 2009

A SHORT INTRODUCTION TO CLOUD PALTFORMS – Aug 2008

David Chappell-2 160-45b

AN ENTERPRISE-ORIENTED VIEW
DEVID CHAPPELL
AUGUST 2008

SPONSORED BY MICROSOFT CORPORATION
COPYRIGHT 2008 CHAPPELL & ASSOSIATES

—————————————————————

このドキュメントは、まだ Azure とうい名前もなく、Strata という名前もない、2008年の夏に David Chappell 氏が作成した、いわば Azure の原型を説明するためのホワイト・ペーパーです。 Agile_Cat 自身は、このドキュメントを見て、David Chappell という人を知り、また、Microsoft のクラウド戦略を心に思い描いていたわけですが、”おぉ そうだ 抄訳が会ったはずだ !” と、つい先ほど気づきまして、今日から何回かに分けて掲載していくことにしたところです。

この抄訳を持って、何人かの Microsoft の 方々ともお会いしたのですが、そのときは、おおむね "David Chappell って誰?" みたいな反応でして、なんとなくサミシイ思いをした記憶があります。 ただ、私としては、これがベースにあったため、PDC 2008 での Introducing Azure Platform を素早く見つけ、抄訳に取り掛かることができたのです。そして、またしても懲りずに、その対訳を初台へと持ち込んだのでした。

話は、このドキュメントに戻りますが、Microsoft のクラウド戦略に関する具体論はありません。 考えてみれば、MIX 08 で Ray Ozzie 氏がクラウド構想を語ってから、まだ、数ヶ月後というタイミングです。 もちろん、Redmond では、Azure(名前はまだ無い) の開発が着々と進んでいたのでしょうが、それについて言及するわけにはいきません。いきおい、語る視点抽象度の高いものとなってしまいますが、読み手としてクラウドの本質を考えるためには、それも 、また良しです。

さて、来週は PDC 2009 です。 みなさんも楽しみにしていることでしょうが、こうした 1年以上も前の資料を引っ張り出し、Windows  Azure と、それを取り巻くクラウド全般に、どのような進化があったのか、振り返るもの面白いものです。 --- A.C.

—————————————————————

CONTENTS  

Defining Terms: What is a Cloud Platform?

Cloud Platforms in Context: Three Kinds of Cloud Services
A General Model for Application Platforms
From On-Premises Platforms to Cloud Platforms

 

Examining Cloud Platforms

Cloud Foundation
     Operating System
     Local Support
Cloud Infrastructure Services
    Storage
    Integration
    Identity
Cloud Application Services
    SaaS Application Services
    Search
    Mapping
    Other Application Services

Conclusion

About the Author

—————————————————————

DEFINING TERMS: WHAT IS A CLOUD PLATFORM?

The coming shift to cloud computing is a major change in our industry. One of the most important parts of that shift is the advent of cloud platforms. As its name suggests, this kind of platform lets developers write applications that run in the cloud, or use services provided from the cloud, or both. Different names are used for this kind of platform today, including on-demand platform and platform as a service (PaaS). Whatever it’s called, this new way of supporting applications has great potential.

来るべきクラウド・コンピューティングへの移行は、私たちの業界に大きな変化をもたらす。この移行において、クラウド・プラットフォームの到来が、最重要パートのひとつになる。この名前が示唆するように、この種のプラットフォームはデベロッパーに対して、クラウド上で動作するアプリケーションを書かせる場合もあれば、クラウドから提供されるサービスを使わせる場合もある。この種類のプラットフォームには、オン・デマンド・プラットフォームや、PaaS (platform as a service )などの呼び方が含まれる。 どのような名前であろうが、このアプリケーション・サポートの新しい方式は、大きい可能性を持っている。

To see why, think about how application platforms are used today. When a development team creates an on-premises application (i.e., one that will run within an organization), much of what that application needs already exists. An operating system provides basic support for executing the application, interacting with storage, and more, while other computers in the environment offer services such as remote storage. If the creators of every on-premises application first had to build all of these basics, we’d have many fewer applications today.

その根本的な理由を確認するために、今日のアプリケーション・プラットフォームで用いられる方式について考えるべきだ。 開発チームがオン・プレミスのアプリケーション(つまり、組織内で実行される)を開発するとき、そこで必要とされる多くの要素が、すでに存在している。アプリケーションの実行や、ストレージとの相互作用といった基本的なサポートを、オペレーティング・システムが提供する一方で、同じ環境内に存在する別のコンピュータが、リモート・ストレージなどのサービスを提供する。もし、これらすべての基本要素を、すべてのオンプレミス・アプリケーション開発者が最初に構築せざるを得なかったとすれば、利用できるアプリケーションの数は、ずっと少なくなっていたはずだ。

Similarly, if every development team that wishes to create a cloud application must first build its own cloud platform, we won’t see many cloud applications. Fortunately, vendors are rising to this challenge, and a number of cloud platform technologies are available today. The goal of this overview is to categorize and briefly describe those technologies as they’re seen by someone who creates enterprise applications.

同様に、クラウド・アプリケーションを望む全ての開発チームが最初に、自身のクラウド・プラットフォームを構築せざるを得ないなら、数多くのクラウド・アプリケーションを目にすることは無くなるだろう。幸いなことに、この課題に取り組むベンダーは増えつつあり、また、数多くのクラウド・プラットフォーム・テクノロジーが利用できるようになってきた。このドキュメントの目的は、エンタープライズ・アプリケーション開発者の視点から、それらのテクノロジーを分類し、簡潔に記述することにある。

CLOUD PLATFORMS IN CONTEXT: THREE KINDS OF CLOUD SERVICES

David Chappell 2008_1 Figure 1: Cloud services can be grouped into three broad categories.

To get a grip on cloud platforms, it’s useful to start by looking at cloud services in general. As Figure 1 shows, services in the cloud can be grouped into three broad categories. Those categories are:

クラウド・プラットフォームについて把握するためには、クラウド・サービスの種類を確認するところから始めるのが、一般的には有用である。 Figure 1 に示されるように、クラウド上のサービスを大まかなところで、3 つのカテゴリーにグループ化することができる。それらのカテゴリーとは、以下のものである:

· Software as a service (SaaS): A SaaS application runs entirely in the cloud (that is, on servers at an Internet-accessible service provider). The on-premises client is typically a browser or some other simple client. The most well-known example of a SaaS application today is probably Salesforce.com, but many, many others are also available.

· Software as a service (SaaS): SaaS アプリケーションの全体が、クラウド上で動作する(つまり、インターネット・アクセスが可能な、サービス・プロバイダのサーバー上のものとなる)。 オンプレミスなクライアントは、一般的にはブラウザあるいは、別のシンプル・クライアントとなる。現時点で、最も知られている SaaS アプリケーションは、おそらく Salesforce.com である。 しかし、きわめて多数の、他のアプリケーションも利用できる。

· Attached services: Every on-premises application provides useful functions on its own. An application can sometimes enhance these by accessing application- specific services provided in the cloud. Because these services are usable only by this particular application, they can be thought of as attached to it. One popular consumer example of this is Apple’s iTunes: The desktop application is useful for playing music and more, while an attached service allows buying new audio and video content. Microsoft’s Exchange Hosted Services provides an enterprise example, adding cloud-based spam filtering, archiving, and other services to an on-premises Exchange server.

· Attached services: この種の全てのオンプレミス・アプリケーションは、自身が所有する有用な機能を提供する。そして、クラウド上に提供されるアプリケーション固有のサービスに、状況に応じてアクセスすることで、アプリケーション自身が拡張される。それらのクラウド・サービスは、特定のアプリケーションだけに有用であるため、アタッチされたサービスとして考えることができる。コンシューマ市場における有名な例として、Apple の iTunes が挙げあげられる。そのデスクトップ・アプリケーションは、音楽の再生などに有用であるが、オーディオやビデオのコンテンツ購入は、アタッチされたサービスにより実現される。 Microsoft の Exchange Hosted Services は、 エンタープライズにおける事例として、クラウド・ベースのスパム・フィルタやアーカイブなどのサービスを、オンプレミスの Exchange Server に加えている。

· Cloud platforms: A cloud platform provides cloud-based services for creating applications. Rather than building their own custom foundation, for example, the creators of a new SaaS application could instead build on a cloud platform. As Figure 1 shows, the direct users of a cloud platform are developers, not end users.

· Cloud platforms: このクラウド・プラットフォームは、アプリケーション開発用のクラウド・ベース・サービスを提供する。独自のカスタム・ファンデーションを構築すると言うよりは、新規の SaaS アプリケーション開発者が、クラウド・プラットフォームを構築する代わりに使用すると言った方が、事例としては相応しい。 Figure 1 に示されるように、クラウド・プラットフォームの直接のユーザーは、エンド・ユーザーではなく、デベロッパーとなる。

Understanding cloud platforms requires some agreement on what the word “platform” means in this context. One broad way to think about it is to view a platform as any software that provides developer-accessible services for creating applications. The next section looks at this idea in a bit more detail.

クラウド・プラットフォームを理解することは、前述のコネテキストにしたがいながら、単語としての「プラットフォーム」の上に、なんらかの追加の合意を要求するかもしれない。それについて、ゆとりを持って考えていく方式は、アプリケーション開発のためにデベロッパーがアクセスできるサービスが、ソフトウェアとしてのプラットフォームにより提供される、と見なすことである。そのためには、デベロッパーがアプリケーション開発のためにアクセスするサービスが、ソフトウェアとしてのプラットフォームにより提供されると見なす方が、柔軟な発想をもたらすだろう。次のセクションでは、この発想の細部を見ていく

—————

2008年夏 Azure 前夜:David Chappell _1
2008年夏 Azure 前夜:David Chappell _2
2008年夏 Azure 前夜:David Chappell _3
2008年夏 Azure 前夜:David Chappell _4
2008年夏 Azure 前夜:David Chappell _5

2008年夏 Azure 前夜:David Chappell _2

Posted in David Chappell by Agile Cat on November 12, 2009

A SHORT INTRODUCTION TO CLOUD PALTFORMS – Aug 2008

David Chappell-2 160-45b

A GENERAL MODEL FOR APPLICATION PLATFORMS

Our experience with application platforms today comes mostly from on-premises platforms. A useful way to think about cloud platforms is to see how the services an application developer relies on in the on-premises environment translate to the cloud. To help do this, Figure 2 shows a general model that can be applied to both worlds.

アプリケーション・プラットフォームのエクスペリエンスにおいては、その大半がオンプレミスのプラットフォームに基づいているという現実がある。クラウド・プラットフォームについて効率よく考えるためには、オンプレミス環境でアプリケーション開発者が頼るサービスを、クラウドに展開するための方式を確認すべきである。その方式を促進するために、この2つの世界に適用できる汎用モデルを、Figure 2 に示す。

David Chappell 2008_2

Figure 2: A modern application platform can be viewed as having three parts.

Whether it’s on-premises or in the cloud, an application platform can be thought of as comprising three parts:

オンプレミスであろうが、クラウドであろうが、アプリケーション・プラットフォームは、3つのパートで構成されるものとして考えることができる:

· A foundation: Nearly every application uses some platform software on the machine it runs on. This typically includes various support functions, such as standard libraries and storage, and a base operating system.

· Foundation: ほとんど全てのアプリケーションが、自身を実行するマシン上で用いる、いくつかのプラットフォーム・ソフトウェアのことである。 一般的には、標準ライブラリや、ストレージ、基本となるオペレーティング・システムといった多様なサポート機能が、そこには含まれる。

· A group of infrastructure services: In a modern distributed environment, applications frequently use basic services provided on other computers. It’s common to provide remote storage, for example, integration services, an identity service, and more.

· Group of Infrastructure Services: 最先端の分散環境において、アプリケーションが頻繁に使用することになる、他のコンピュータから提供される基本サービスのことである。一般的には、リモート・ストレージや、インテグレーション・サービス、アイデンティティ・サービスの提供などがある。

· A set of application services: As more and more applications become service- oriented, the functions they offer become accessible to new applications. Even though these applications exist primarily to provide services to end users, this also makes them part of the application platform. (It might seem odd to think of other applications as part of the platform, but in a service-oriented world, they certainly are.)

· Set of Application Services: 多数のアプリケーションがサービス指向になるにつれて提供されていく、新しいアプリケーションへのアクセスを実現するサービスのことである。 これらのアプリケーションは、エンド・ユーザーへのサービス提供を第一義とするにもかかわらず、アプリケーション・プラットフォームの一部にもなり得る(他のアプリケーションのことを、プラットフォームの一部として考えるのは奇妙かもしれないが、サービス指向の世界では、確かにあり得る)。

And while they’re not shown in Figure 2, development tools are another important part of this story. Modern tools can help developers build applications using all three parts of an application platform.

Figure 2 には開発ツールが記載されていないが、このストーリーにおける、もうひとつの重要なパートである。最新のツールは、アプリケーション・プラットフォームにおける 3つのパートの全てを用いて、デベロッパーによるアプリケーション構築を支援するだろう。

To make this abstract model more concrete, think about how it fits with today’s most popular on-premises platforms. The on-premises foundation looks like this:

この抽象モデルを、より具体的なものにしていくために、現時点で最も一般的なオンプレミス・プラットフォームとの、適合性について考えてみる。オンプレミスの基本を、以下のように見なすことができる:

· Operating system: The dominant choices are Windows, Linux, and other versions of Unix.

· Operating system: 主要な選択肢は、Windows と Linux、そして、Unix の各種バージョンとなる。

· Local support: Different technologies are used depending on the style of application. The .NET Framework and Java EE application servers provide general support for Web applications and more, for instance, while other technologies target specific kinds of applications. For example, Microsoft’s Dynamics CRM product includes a platform designed for creating a particular type of business application. Similarly, different kinds of storage are used for different purposes. Raw byte storage is provided by the file systems in Windows, Linux, and other operating systems, while more structured storage is provided by a range of database technologies, including the Oracle DBMS, MySQL, Microsoft SQL Server, and IBM DB2.

· Local support: アプリケーションのスタイルに応じて、各種のテクノロジーが用いられる。たとえば、.NET Framework と Java EE Application Server は、Web アプリケーションなどのために、汎用的なサポートを提供する。 それに対して、特定アプリケーションに目標を定めた他のテクノロジーなどが、この場合の例として挙げられる。たとえば、Microsoft の Dynamics CRM は、特定タイプのビジネス・アプリケーション開発のために、設計されたプラットフォームを含んでいる。それと同様に、異なる種類のストレージが、異なる目的のために用いられる。 また、未加工のバイト・ストレージは、Windows や Linux といったオペレーティング・システムや、ファイル・システムで提供される。 その一方で、より以上に構造化されたストレージが、Oracle DBMS/MySQL/Microsoft SQL Server/IBM DB2 などを含む、データベース・テクノロジーの領域で提供される。

For on-premises infrastructure services, typical examples include the following:

オンプレミスのインフラストラクチャ・サービスには、一般的に以下の事例が含まれる:

· Storage: Like storage in the foundation, infrastructure storage comes in various styles. A remote file system might provide simple byte-oriented storage, while a Microsoft SharePoint document library provides a more structured remote storage service. Applications can also access a database system remotely, allowing access to another kind of structured storage.

· Storage: このファンデーションにおけるストレージのように、多様なスタイルのインフラストラクチャ・ストレージが登場してきた。リモート・ファイル・システムは、単純なバイト指向のストレージを供給するかもしれないが、Microsoft SharePoint のドキュメント・ライブラリは、それ以上に構造化されたリモート・ストレージ・サービスを提供する。さらにアプリケーションは、データベース・システムへのリモート・アクセスも実現し、その結果として、他の構造を持つストレージにアクセスする。

· Integration: Connecting applications within an organization usually depends on a remote service provided by some integration product. A message queue is a simple example of this, while more complex scenarios use products such as IBM’s WebSphere Process Server, Microsoft’s BizTalk Server, and others.

· Integration: 一般的に、組織内でのアプリケーション接続はリモートサービスに依存するが、それらは、いくつかの統合化のためのプロダクトにより提供される。メッセージ・キューは、こうした状況を示すシンプルな事例である。 その一方で、IBM の WebSphere Process Server や Microsoft の BizTalk などの製品を用いた、さらに複雑なシナリオも存在する。

· Identity: Providing identity information is a fundamental requirement for most distributed applications. Common on-premises technologies that address this include Microsoft’s Active Directory and other LDAP servers.

· Identity: アイデンティティ情報の提供は、大半の分散アプリケーションにおける基本的な要件となる。 それに取り組むための、一般的なオンプレミス・テクノロジーには、Microsoft の Active Directory などの LDAP サーバーが含まれる。

On-premises application services, the third category shown in Figure 2, vary widely across different organizations. The reason for this is simple: Different organizations use different applications, which in turn expose diverse services. One way to think about these applications in the on-premises platform is to divide them into two broad categories:

Figure 2 における 3番目のカテゴリーとして示される、オンプレミスのアプリケーション・サービスは、それぞれの組織に応じた多様なものとなる。その理由は単純である。つまり、それぞれの組織が個々のアプリケーションを使うからであり、言い換えると、多様なサービスをエクスポーズするからとなる。 オンプレミス・プラットフォームにおいて、それらのアプリケーションについて考えるひとつの方式は、2つの大まかなカテゴリーに、それらを切り分けることである:

· Packaged applications: This includes business software such as SAP, Oracle Applications, and Microsoft Dynamics, along with a myriad of other off-the-shelf products. While not all packaged applications expose services to other applications, more and more of them do.

· Packaged Applications: この項目には、無数の既製品ソフトウェアに加えて、SAP/Oracle Applications/Microsoft Dynamics などのビジネス・ソフトウェアが含まれる。 すべてのアプリケーション・パッケージに該当するわけではないが、大半のケースにおいて、他のアプリケーションへ向けたサービスのエクスポーズが実現されている。

· Custom applications: Many organizations have a large investment in custom software. As these applications increasingly expose their functionality through services, they become part of the on-premises application platform.

· Custom Applications: 多くの組織において、カスタム・ソフトウェアに対して、膨大な投資が行われている。それらのアプリケーションによる、サービスを介した機能のエクスポーズが増えるにつれて、オンプレミスのアプリケーション・プラットフォームが拡張されていく。

When it’s described like this, the on-premises application platform can seem quite complex. The truth, though, is that this platform has evolved over time. In the early days of computing, the application platform consisted of nothing more than an on- premises foundation. (Think of MVS and IMS on an IBM mainframe, for example.) In the 1980s and 1990s, as distributed computing spread, on-premises infrastructure services were added, with remote storage, integration, and identity becoming common. Today, with the advent of service-oriented applications, on-premises application services have become part of the platform. The next step in this evolution is clear: providing cloud versions of all three.

このように記述すると、オンプレミスのアプリケーション・プラットフォームを、きわめて複雑ものと見なすことができる。 しかし真実は、このプラットフォームが、長い時間をかけて進化してところにある。コンピューティングの時代が始まったころ、アプリケーション・プラットフォームを構成するものとして、オンプレミス・ファンデーション以外の何ものも存在しなかった。 (たとえば、IBM メインフレーム上の MVS と IM について考えるべきだ) 1980年代から1990年代にかけて、分散コンピューティングが広まるにつれて、リモートストレージ/インテグレーション/アイデンティティを用いることで、オンプレミスのインフラストラクチャ・サービスが一般的になってきた。そしていま、サービス指向アプリケーションの到来により、オンプレミスのアプリケーション・サービスがプラットフォームの一部になった。 この進化における次のステップは明確である。つまり、それら 3 つの全てを、クラウド・バージョンとして提供することである:

FROM ON-PREMISES PLATFORMS TO CLOUD PLATFORMS

Along with describing on-premises platforms, the general model just described can also be used to think about cloud platforms. And since on-premises and cloud platforms can be used together, it’s important to understand how the two work in concert. Figure 3 illustrates this new world.

オンプレミス・プラットフォームを記述することで、クラウド・プラットフォームを考えるための汎用モデルも記述され、その活用が可能となる。さらに、オンプレミスとクラウドのプラットフォームを、つなぎ合わせて使用することが可能になるため、双方が協調して動作する方式の理解が重要になる。 Figure 3 が例証するのが、この新しい世界である。

David Chappell 2008_3

Figure 3: On-premises platforms and cloud platforms can be
viewed in similar ways, and they can also be used together.

As the figure shows, a cloud application can be built on a cloud foundation, just as an on-premises application is built on an on-premises foundation. Both kinds of applications can access infrastructure and application services provided on-premises and in the cloud. Just as on-premises platforms support today’s applications, cloud platforms provide services for the applications we’re likely to build tomorrow.

上記の図が示すように、オンプレミス・アプリケーションがオンプレミス・ファンデーション上に構築されるように、クラウド・アプリケーションもクラウド・ファンデーション上に構築される。そのため、オンプレミスとクラウドで提供される、インフラストラクチャとアプリケーションのサービスに、二種類のアプリケーションがアクセスできることになる。まさに、オンプレミス・プラットフォームが現時点のアプリケーションをサポートするように、これから構築することになるアプリケーションのためのサービスを、クラウド・プラットフォームが提供していく。

—————

2008年夏 Azure 前夜:David Chappell _1
2008年夏 Azure 前夜:David Chappell _2
2008年夏 Azure 前夜:David Chappell _3
2008年夏 Azure 前夜:David Chappell _4
2008年夏 Azure 前夜:David Chappell _5

 

2008年夏 Azure 前夜:David Chappell _3

Posted in David Chappell by Agile Cat on November 12, 2009

A SHORT INTRODUCTION TO CLOUD PALTFORMS – Aug 2008

David Chappell-2 160-45b

EXAMINING CLOUD PLATFORMS

Understanding cloud platforms means looking at each of their parts: the cloud foundation, cloud infrastructure services, and cloud application services. This section walks through these three areas, using some of today’s most visible cloud platform technologies as examples.

クラウド・プラットフォームを理解するために、クラウド・ファンデーション/クラウド・インフラストラクチャ・サービス/クラウド・アプリケーション・サービスといった、それぞれのパートに注目していく。このセクションでは、現時点で注目されている、いくつかのクラウド・プラットフォーム・テクノロジーを例として用いて、これらの 3 つのエリアをウォーク・スルーしていく。

Before we begin, one important note: While it’s useful to look at on-premises platforms and cloud platforms through the same lens, the two aren’t identical. When platform functions move into the cloud, they sometimes change in significant ways. For example, on-premises platforms are designed to support (at most) enterprise-scale applications. Applications that run in the cloud, by contrast, can potentially operate at Internet scale, which requires handling many more simultaneous users than any enterprise application. While the same kinds of platform functions might be needed in both cases, achieving this high scalability can force a cloud platform to provide them in a quite different way. In what follows, expect to see some differences from the on-premises world.

そのための考察を開始する前に、注意すべき重要なポイントがある。 つまり、オンプレミスとクラウドのプラットフォームを、同一の視点から見ることは有用であるが、その 2 つが同一ではないことを再認識する必要がある。プラットフォーム機能がクラウドへと移行するとき、特筆すべき方向へ向けて、変化していく場合がある。たとえば、オンプレミス・プラットフォームは、(せいぜい)エンタープライズ・スケールのアプリケーションを、サポートするようにデザインされる。それとは対照的に、クラウド上で動作するアプリケーションは、インターネット・スケールで運用される可能性を持ち、あらゆるエンタープライズ・アプリケーションよりでも、ずっと多くのユーザーを、同時にサポートする必要がある。同種類のプラットフォーム機能が、双方のケースで要求されるかもしれない。 しかし、クラウド・プラットフォームの場合は、ハイ・スケーラビリティを達成するために、きわめて異なる方式を要求される可能性をもつ。それ以外にも、オンプレミスの世界から見ると、いくつかの相違点が見出されると予測すべきである。

CLOUD FOUNDATION

Like their on-premises cousins, cloud foundations provide the basic local functions an application needs. These can include an underlying operating system and local support. Yet how cloud platforms provide these functions differs from what we’re used to, as this section shows.

オンプレミスの従兄弟ともいえるクラウド・ファンデーションは、アプリケーションにとって 必要な、基本的なローカル機能を提供する。そこには、基本的なオペレーティング・システム と、ローカル・サポートを含むことができる。 それにしても、このセクションで示されるよう に、クラウド・プラットフォームがを提供する機能は、これまでに慣れ親しんだものとは異なる。

Operating System

From a platform point of view, an operating system provides a set of basic interfaces for applications to use. By far the most well-known example of an operating system in the cloud today is Amazon’s Elastic Compute Cloud (EC2). EC2 provides customer-specific Linux instances running in virtual machines (VMs). From a technical perspective, it might be more accurate to think of EC2 as a platform for VMs rather than operating systems. Still, a developer sees an operating system interface, and so viewing it in this light makes more sense here.

プラットフォームの観点からすると、オペレーティング・システムは、アプリケーションが用いる基本的なインターフェイス・セットを提供している。クラウドにおけるオペレーティング・システムとして、現時点で認識されている有名な事例は、Amazon の Elastic Compute Cloud(EC2)である。 EC2 が提供する、顧客に固有の Linux インスタンスは、バーチャルマシン上で動作する。 テクニカルな視点に基づくと、EC2 はオペレーティング・システムというよりは、VM 用のプラットフォームと見なすほうが正しいかもしれない。しかし、開発者は依然としてオペレーティング・システムのインターフェイスを参照する。つまり、その視点で EC2 見る方が、いまの時点では、意味を持つことになる。

Each development team is free to use whatever local support it likes in this VM.Amazon doesn’t care. The creators of one application might choose a Java EE app server and MySQL, for example, while another group might go with Ruby on Rails. EC2 customers are even free to create many Linux instances, then distribute large workloads across them in parallel, such as for scientific applications. While the service EC2 provides is quite basic, it’s also very general, and so it can be used in many different ways.

この VM 上で、それぞれの開発チームは、あらゆるローカル・サポートを自由に使用するが、そのことを Amazon は気にかけていない。 たとえば、アプリケーション開発者は Java EE アプリケーション・サーバーと MySQL を選択するかもしれないが、別のグループは Ruby on Rails を使うかもしれない。 さらに EC2 のカスタマは、Linux インスタンスを自由に作成した後に、極端なたとえで言うと、科学計算アプリケーションのための膨大な作業負荷を、並列的に振りまく可能性すらもつ。 EC2 が提供するサービスが、きわめて基本的なものである一方で、上記の運用も一般的である。その結果として EC2 は、数多くの方式で運用されるという可能性を生じる。

Local Support

In an on-premises platform (and in EC2), a developer can mix and match parts of the foundation as she sees fit. Choosing to use the .NET Framework on Windows doesn’t mandate using a particular database, for example. Similarly, an on-premises application using the .NET Framework is free to access the underlying Windows operating system, as is an application built on a Java EE server.

オンプレミス・プラットフォームにおいて(そして EC2 において)、開発者が適切と判断するときに、ファンデーションの一部が使い回される。たとえば、Windows 上の .NET Framework を用いることで、特定データベースの利用が決定されたりはしない。同様に、.NET Framework を用いるオンプレミス・アプリケーションは、Java EE サーバー上に構築されたアプリケーションのように、基本となる Windows オペレーティング・システムに自由にアクセスできる。

The local support functions in today’s leading cloud foundations don’t work this way. Instead, a cloud local support technology typically includes its own storage, and it hides whatever the underlying operating system might be. A developer choosing to build on a particular local support option must accept the limitations it imposes.

今日のクラウド・ファンデーションをリードする、ローカル・サポート機能は、この方式では上手くいかない。 その代わりに、クラウドのローカル・サポート・テクノロジーに、独自のストレージを含む方式が、一般的には用いられる。そして、基本となるオペレーティング・システムが何であっても、そのテクノロジーが隠蔽してしまう。特定のローカル・サポート・オプションを用いる構築においては、それにより強要される制約を受け入れなくてはならない。

There are good reasons for these limitations, of course. One of the things that makes cloud computing so attractive is its potential for scalability, but to make an application built on a cloud foundation handle Internet-size loads requires limiting it in some ways. By making the local support functions more specialized, a cloud platform provider has more freedom to optimize the application environment. Accordingly, each set of local support functions in cloud foundations today focuses on supporting a particular kind of application.

もちろん、これらの制約については、充分な理由がある。 スケーラビリティに関する潜在能力は、クラウド・コンピューティングを魅力的なものにする、ひとつの事柄である。しかし、インターネット・レベルの負荷を取り扱う、クラウド・ファンデーション上に構築されたアプリケーションは、いろいろな意味で、その能力に対する制約を要求される。さらに、目的を絞り込んだローカル・サポート機能を提供することで、クラウド・プラットフォームのプロバイダは、アプリケーション環境を最適化するための自由を得る。したがって、今日のクラウド・ファンデーションにおける、それぞれのローカル・サポート機能のセットは、特定された種類のアプリケーションを、サポートすることに焦点を当てている。

For example, Google’s AppEngine provides local support for running Python Web applications. Along with a standard Python runtime, AppEngine also includes a hierarchical data store with its own query language. Another example of a cloud platform providing local support is Force.com, offered by Salesforce.com. Rather than targeting general Web applications, however, Force.com is aimed at creating data- oriented business applications. Toward this end, it provides its own focused support for data storage. And rather than adopt an existing programming language, this platform’s creators invented their own, a language called Apex.

たとえば、Google の AppEngine は、Python Web アプリケーションを実行するためのローカル・サポートを提供する。 AppEngine には、標準的な Python ランタイムが含まれ、さらに、自身のクエリー言語を用いる、階層的なデータストアも含まれる。クラウド・プラットフォームにおいて、ローカル・サポートを提供する別の例は、Salesforce.com の Force.com となる。 Force.com は、一般的な Web アプリケーションに目標を定めるというより、データ指向のビジネス・アプリケーション開発を目的とし、データ・ストレージに焦点を合わせた独自のサポートが提供される。そして、このプラットフォームの開発者は、既存のプログラム言語を採用するよりも、Apex と呼ばれる独自の言語を考案する道を選んだ。

Microsoft also provides local support for applications in the cloud as part of its CRM Live offering. Based on the Dynamics CRM platform mentioned earlier, this technology targets data-oriented business applications, much like Force.com. And like both Force.com and AppEngine, it includes both run-time application support and a data store. Microsoft has also talked about its plans to go further in this area, with a platform that will support standard .NET development languages and tools. The intent, Microsoft says, is to allow portability of both applications and developer skills between the company’s on-premises foundation and its cloud foundation.

Microsoft も、自身が供給する CRM Live のパートとして、クラウド・アプリケーションのためのローカル・サポートを提供する。 以前から述べられている Dynamics CRM プラットフォームに基づき、このテクノロジーは、データ指向のビジネス・アプリケーションに向けられたものとなり、また、Force.com ときわめて似たものとなる。 そして、Force.com や AppEngine のように、ランタイム・アプリケーション・サポートとデータ・ストアの両方が、そこには含まれる。さらに Microsoft は、スタンダードな .NET 開発言語とツールをサポートするプラットフォームを用いて、このエリアに参入するという計画について述べている。こうした Microsoft の発言における意図は、企業内でオンプレミスとクラウドのファンデーションをつなぐポータビリティを、アプリケーションとデベロッパー・スキルの双方において実現することにある。

—————

2008年夏 Azure 前夜:David Chappell _1
2008年夏 Azure 前夜:David Chappell _2
2008年夏 Azure 前夜:David Chappell _3
2008年夏 Azure 前夜:David Chappell _4
2008年夏 Azure 前夜:David Chappell _5

 

2008年夏 Azure 前夜:David Chappell _4

Posted in David Chappell by Agile Cat on November 11, 2009

A SHORT INTRODUCTION TO CLOUD PALTFORMS – Aug 2008

David Chappell-2 160-45b

CLOUD INFRASTRUCTURE SERVICES

Whether they run on-premises or in the cloud, some applications don’t need anything beyond a foundation. Still, many can benefit from distributed storage, common identity, and other infrastructure services. We’re accustomed to having these services provided on-premises today, but analogous services are also provided in the cloud.

オンプレミスでの実行であっても、クラウドでの実行であっても、いくつかのアプリケーションは、ファンデーション以上のものを何も必要としない。それでもなお、多くのアプリケーションは、分散ストレージ/共通アイデンティティ/インフラ・ストラクチャサービスなどからメリットを得る。 今日のオンプレミス環境で提供される、これらのサービスを利用することに私たちは慣れているが、類似するサービスがクラウドでも提供される。

As Figure 3 showed, cloud infrastructure services can be accessed by applications running on either an on-premises foundation or a cloud foundation. Initially, the most common users of cloud infrastructure services will be on-premises, because there aren’t yet many applications built on a cloud foundation. Over time, expect this to change, as more and more cloud-based applications also use cloud infrastructure services.

Figure 3 で示されるように、オンプレミスとクラウドのファンデーション上で稼動するアプリケーションから、クラウド・インフラストラクチャ・サービスに対するアクセスが可能である。クラウド・インフラストラクチャ・サービスを利用する大半のユーザーは、そこへの移行の始まりにおいて、オンプレミスにいるだろう。その理由は、クラウド・ファンデーション上に、まだ、数多くのアプリケーションが構築されていない点にある。 長い期間をかけて、クラウド・ベースのアプリケーションが、クラウド・インフラストラクチャ・サービスも使うようになるにつれて、前述の状況が変化していくと予想すべきだ。

Storage

Applications commonly use some kind of local storage, which is why storage is part of both on-premises and cloud foundations. Remote storage is also useful, however, as the popularity of this service in the on-premises world shows. Accordingly, it’s reasonable to expect that providing a storage service in the cloud will be attractive for many applications.

一般的に、アプリケーションは何種類かのローカル・ストレージを使用する。 そこに、オンプレミスとクラウドの双方のファンデーションにおいて、ストレージがパートとなる理由がある。しかし、リモート・ストレージが有用であることも、オンプレミスの世界において、このサービスが広く用いられることで証明されている。したがって、合理的な考え方とは、クラウド・ストレージ・サービスの提供が、多くのアプリケーションにとって魅力的になると、予測することになる。

As with on-premises platforms, remote storage in the cloud comes in different styles. For example, Amazon’s Simple Storage Service (S3) provides basic unstructured remote storage. The model it exposes to developers is straightforward: objects, which are just bunches of bytes, are stored in buckets.

オンプレミス・プラットフォームと同じように、クラウド上のリモート・ストレージも到来するだろうが、そのスタイルは異なるものとなる。たとえば、Amazon の Simple Storage Service(S3)は、基本的に非構造型のリモート・ストレージを提供する。開発者にエクスポーズされるモデルは、単なるバイトの固まりのであるオブジェクトが、バケツの中にストアされるという簡潔なものとなる。

Applications can create, read, and delete objects and buckets. Objects can’t be updated, however – they can only be entirely replaced. This is another example of how platform services must change to support Internet-scale usage, something that Amazon is clearly focused on. This simple but limited storage service is much easier to make scalable than a more fully featured offering would be. The trade-off is clear: Application developers get cheap storage in the cloud, but they might need to do more work in their applications to use it effectively.

アプリケーションによる create/read/delete が、オブジェクトとバケツに対して実行できる。 しかし、オブジェクトの update は実行できず、その代わりに全体的な replace が許される。これは、明らかに Amazon が注目されている理由であり、インターネット・スケールでの用法をサポートするために、プラットフォーム・サービスが変化すべき、ひとつの方向性を示している。この、単純であるが限定されたストレージ・サービスは、より以上の完全性を求める機能よりも、スケーラビリティをはるかに簡単に実現する。そこでのトレードオフは明確である。 つまり、アプリケーション開発者はクラウド上に安価なストレージを得るが、それを効果的に使用するためには、アプリケーション側の機能を増やさなければならないだろう。

Another approach to cloud storage is to support more structured data. In Microsoft’s SQL Server Data Services (SSDS), for example, a container includes one or more entities, each of which holds some number of properties, as shown in Figure 4. An application can issue queries against a container’s data with operators such as ==, !=, <, >, AND, OR, and NOT.

クラウド・ストレージに対する、もうひとつのアプローチは、より以上に構造化されたデータをサポートすることである。 たとえば、Microsoft の SQL Server Data Services(SSDS)では、Figure 4 に示されるように、複数のエンティティをコンテナに含むことができる。そして、個々のエンティティが、いくつかのプロパティを保持する。アプリケーションは、「==、!=、<、>、AND、OR、NOT」といったオペレーターを用いて、コンテナ内のデータに対して、クエリーを発行できる。

David Chappell 2008_4

Figure 4: In SQL Server Data Services, a container holds entities with properties.

It’s important to note that this isn’t a relational database, and the query language isn’t SQL. Once again, we’re seeing an illustration of how application platform technologies change when they’re moved into the cloud. This simpler approach is easier to use than a relational database – there’s no need to define a schema up front – and it’s also easier to make scalable.

ここでの重要な指摘は、SSDS がリレーショナルなデータベースではなく、また、クエリー言語がSQL ではないことである。 もう一度、このドキュメントの目的を確認するが、アプリケーション・プラットフォーム・テクノロジーが、クラウド上に移行するときに生じる変化を、私たちは例証している最中である。その視点からまとめてみると、このより単純なアプローチは、リレーショナル・データベースよりも簡単に使用できる。 つまり、前もってスキーマを定義する必要がない。 そして、スケーラビリティも容易に達成できる。

Amazon’s SimpleDB provides one more example of the value of structured storage in the cloud. The way SimpleDB organizes information is similar to SSDS – it’s a hierarchy of domains, items, and values – and it also provides a non-SQL query language. Like SSDS, no up-front schema definition is required, and so the approach provides a mix of flexibility and scalability.

Amazon の SimpleDB は、クラウド上で構造化されるストレージの価値について、もうひとつの例を提供する。 SimpleDB が情報を整理する方式は、SSDS に類似している。 それは、domains/items/values の階層を持ち、非SQL のクエリー言語を提供する。 SSDS のように、前もってスキーマを定義する必要がない。 したがって、このアプローチは、フレキシビリティとスケーラビリティのミックスを提供する。

Integration

Is there any application left that doesn’t talk to at least one of its fellows? Connecting applications has become a staple of computing, and vendors have provided a plethora of on-premises infrastructure services to do it. These range from relatively simple technologies like message queues to quite complex integration servers.

仲間の誰とも交信せず、単体として取り残されるアプリケーションなど、存在するのだろうか? アプリケーション間の接続がコンピューティングの主要素になり、また、それを実現するために、ベンダーたちは過剰なオンプレミス・インフラストラクチャ・サービスを提供してきた。そのレンジは、メッセージ・キューのような比較的単純なテクノロジーから、きわめて複雑なインテグレーション・サーバーにまでいたる。

As integration services move into the cloud, a range of technologies is also appearing. For example, Amazon’s Simple Queue Service (SQS) provides just what its name suggests: a straightforward way for applications to exchange messages via queues in the cloud. Yet SQS once again illustrates what happens when a familiar on-premises service is recast as a cloud service. Because SQS replicates messages across multiple queues, an application reading from a queue isn’t guaranteed to see all messages from all queues on a particular read request. SQS also doesn’t promise in-order, exactly-once delivery. These simplifications let Amazon make SQS more scalable, but they also mean that developers must use SQS differently from an on-premises message queuing technology.

インテグレーション・サービスがクラウドに移行するにつれて、広範囲におよぶテクノロジーが登場してくる。 たとえば、Amazon の Simple Queue Service(SQS)は、まさに、その名前が示唆するサービスを提供する。それは、クラウド上のキューを介して、アプリケーションがメッセージを交換するシンプルな方式である。それにしても、慣れ親しんだオンプレミス・サービスが、クラウド・サービスとして再構成されるとき何が起こるのか、SQS はもう一度例証してくれる。 SQS はマルチ・キューのいたるところにメッセージを複製するが、キューから読込みを行うアプリケーションが、特定のリード・リクエストにおいて、すべてのキューからの、すべてのメッセージを参照するとは保証されない。さらに SQS は、キュー内のメッセージ順序と、一回だけの配信を約束しない。 こうした簡略化により、Amazon は SQS に大幅なスケーラビリティを与えているが、オンプレミスのメッセージ・キュー・テクノロジーと異なる用法を、SQS のデベロッパーに強いている。

BizTalk Services provides another example of cloud-based integration. Rather than using message queuing, BizTalk Services implements a relay service in the cloud that lets applications communicate through firewalls. Cloud-based integration, such as connecting applications in different organizations, typically requires traversing firewalls, and so solving this problem is important. BizTalk Services also provides simple workflow support along with a way for an application to register the services it exposes, then let those services be invoked by any other application that has permission to do so.

BizTalk Services は、クラウド・ベースのインテグレーションにおいて、別の例を提供する。 BizTalk Services はメッセージ・キューを使うというより、クラウド上にリレー・サービスを実装し、ファイアウォールを介したアプリケーション通信を実現する。組織間を接続するアプリケーションのような、クラウド・ベースのインテグレーションは、一般的にファイアウォールの横断を必要とするため、この問題の解決は重要である。さらに BizTalk Services は、シンプルなワークフロー・サポートを提供し、そこには、アプリケーションがエクスポーズするサービスの記録が取り込まれる。続いて、権限を与えられたアプリケーションが、それらのサービスの呼び出しを行わせる。

Going forward, expect to see more integration services offered in the cloud. Given the importance of integration as an on-premises service, it shouldn’t be surprising to see its functions become part of the cloud infrastructure.

先へ進むにつれて、クラウド上に提供される、さらに多くのインテグレーション・サービスが見出されると予測すべきだ。 オンプレミス・サービスの場合と同様に、インテグレーションの重要性を前提とし、その機能がクラウド・インフラストラクチャのパートになるのを見ても、驚くべきではない。

Identity

Whether an application runs on-premises or in the cloud, it typically needs to know something about its users. Toward this end, the application commonly demands that each user provides a digital identity, a set of bytes that describes that user. Based on what these bytes contain and how they’re verified, the application can determine things such as who this user is and what they’re allowed to do.

アプリケーションがオンプレミスで動作するにしても、クラウドで動作するにしても、いつもどおりに必要とされることは、そのユーザーについて知ることである。この目的に向かって、アプリケーションは通常、それぞれのユーザーが提供するデジタル・アイデンティティと、ユーザー情報を記述するバイト・セットを要求する。 これらのバイトに含まれる情報と、その検証方法に基づいて、ユーザーが誰であり、どのような権限を持つのか、アプリケーションは判断する。

Many on-premises applications today rely on an on-premises infrastructure service, such as Active Directory, to provide this identity information. When a user accesses a cloud application, however, or an on-premises application accesses a cloud service, an on- premises identity usually won’t work. And what about an application built on a cloud foundation? Where does it get its identity information?

現時点におけるオンプレミス・アプリケーションは、このアイデンティティ情報を提供するために、Active Directory のようなオンプレミス・インフラストラクチャ・サービスに依存している。しかし、ユーザーがクラウド・アプリケーションにアクセスするとき、あるいは、オンプレミス・アプリケーションがクラウド・サービスにアクセスするとき、オンプレミス・アイデンティティは普通どおりに機能しないだろう。それに加えて、クラウド・ファンデーション上に構築されたアプリケーションは、どうなるのか?そのアイデンティティ情報を、どこで手に入れるのか?

An identity service in the cloud can address these issues. Because it provides a digital identity that can be used by people, by on-premises applications, and by cloud applications, a cloud identity service can be applied in many different scenarios. In fact, one indication of the importance of this kind of identity service is the number of cloud identity services available today. Accessing Amazon cloud services such as EC2 or S3 requires presenting an Amazon-defined identity, for instance, while using Google AppEngine requires a Google account. Microsoft provides Windows Live ID, which can be used for Microsoft applications and others, while BizTalk Services also offers its own identity service, which can be federated with others. Developers don’t have complete freedom.cloud platforms are frequently tied to a particular identity provider.but the need for identity as a cloud service is clear.

クラウド上のアイデンティティ・サービスにより、これらの問題に取り組むことができる。 人々が使用でき、そして、オンプレミスとクラウドのアプリケーションが使用できる、デジタル・アイデンティティを提供することで、クラウド・アイデンティティ・サービスの適用が、多様なシナリオで実現されていく。実際に、この種のアイデンティティ・サービスにおける重要性は、現時点で利用可能なクラウド・アイデンティティ・サービスの数に表れている。 EC2 や S3 といった、Amazon のクラウド・サービスにアクセスするためには、Amazon が定義するアイデンティティの提出が必要となる。その一方で、Google AppEngine を使うためには、Google アカウントが必要となる。 Microsoft が提供する Windows Live ID は、Microsoft や他社のアプリケーションで使用できる。その一方で BizTalk Services は、自身のアイデンティティ・サービスを提供し、他のアプリケーションとの連携を実現する。クラウド・プラットフォームと、特定のアイデンティティ・プロバイダが頻繁に結びつけられるため、デベロッパーが完全な自由を持つわけではないが、クラウド・サービスとしてのアイデンティティの必要性は明確である。

—————

2008年夏 Azure 前夜:David Chappell _1
2008年夏 Azure 前夜:David Chappell _2
2008年夏 Azure 前夜:David Chappell _3
2008年夏 Azure 前夜:David Chappell _4
2008年夏 Azure 前夜:David Chappell _5

2008年夏 Azure 前夜:David Chappell _5

Posted in David Chappell by Agile Cat on November 11, 2009

A SHORT INTRODUCTION TO CLOUD PALTFORMS – Aug 2008

David Chappell-2 160-45b

CLOUD APPLICATION SERVICES

What’s the difference between an application service and an infrastructure service? To answer this question, think first about the obvious distinction between applications and infrastructure: Applications are designed to be used by people, while infrastructure is designed to be used by applications. It’s also fair to say that infrastructure usually provides a general, relatively low-level service, while applications provide more specific, higher-level services. An infrastructure service solves a broad problem faced by many different kinds of applications, while an application service solves a more targeted problem. And just as it’s possible to identify different kinds of infrastructure services, it’s also possible to distinguish different categories of application services, as this section illustrates.

どこに、アプリケーション・サービスとインフラストラクチャ・サービスの、相違点があるのか? この質問に答えるために、アプリケーションとインフラストラクチャの、明白な特質について最初に考えてみる。その答えは、アプリケーションが、人々により使われるようにデザインされるのに対し、インフラストラクチャは、アプリケーションにより使われるようにデザインされるところにある。また、一般的に、インフラストラクチャが汎用性と、相対的に低レベルのサービスを提供するのに対して、アプリケーションは特殊性と、相対的に高レベルのサービスを提供すると言うのも、公正な見方である。インフラストラクチャ・サービスは、多様なアプリケーションが直面する、広範囲におよぶ問題を解決する。その一方で、アプリケーション・サービスは、さらに絞り込まれた問題を解決する。そして、このセクションで例証するように、多種多様なインフラストラクチャ・サービスの識別が可能であるのと同様に、多種多様なアプリケーション・サービスのカテゴリーの識別も可能となる。

 

SaaS Application Services

Users in most enterprises today rely on both purchased and home-grown applications. As these applications expose their services to remote software, they become part of the on-premises platform. Similarly, SaaS applications today frequently expose services that can be accessed by on-premises applications or by other cloud applications. Salesforce.com’s CRM application, for example, makes available a variety of services that can be used to integrate its functions with on-premises applications. As organizations begin to create their own SaaS applications running on a cloud foundation, those applications will also expose services. Just as packaged and custom on-premises applications today are part of the on-premises platform, the services exposed by packaged and custom SaaS applications are becoming part of the cloud platform.

今日における大半のエンタープライズ・ユーザーは、購入するアプリケーションと、内製するアプリケーションに依存している。それらのアプリケーションが、リモート・ソフトウェアに対してサービスをエクスポーズするとき、オンプレミス・プラットフォームのパートに組み入れられるる。同様に、今日における SaaS アプリケーションは、そのサービスをエクスポーズし、オンプレミスとクラウドのアプリケーションからの、頻繁なアクセスが可能となっている。たとえば、 Salesforce.com の CRM アプリケーションは、自身の機能とオンプレミス・アプリケーションを統合するために利用できる、各種のサービスを提供している。クラウド・ファンデーション上で実行する SaaS アプリケーションを、各種の組織が作り始めるにつれて、それらのアプリケーションもサービスをエクスポーズするようになるだろう。今日において、パッケージやカスタムとして提供されるオンプレミス・アプリケーションが、オンプレミス・プラットフォームの一部になっている。 それと同じように、パッケージやカスタムとして提供される、SaaS アプリケーションによりエクスポーズされるサービスが、クラウド・プラットフォームの一部になっていく。

Search

Services exposed by SaaS applications are useful, but they’re not the whole story. Other kinds of cloud application services are also important. Think, for example, of search engines such as Google and Live Search. Along with their obvious value to people, why can’t they also offer cloud application services?

SaaS アプリケーションがエクスポーズするサービスは有用であるが、すべてのストーリーをカバーするわけではない。また、他類のクラウド・アプリケーション・サービスも、同様に重要となる。 たとえば、 Google や Live Search のような、サーチ・エンジンについても考えるべきだ。しかし、何故に、人々が見出している明白な価値にしたがって、クラウド・アプリケーション・サービスとして提供することができないのだろうか?

The answer, of course, is that they can. Microsoft’s Live Search, for example, exposes services that allow on-premises and cloud applications to submit searches and get results back. Suppose a company that provided a database of legal information wanted to let customers search both its own data and the Web in a single request. They could accomplish this by creating an on-premises application that both searched their proprietary data and, via the Live Search application service, the entire Web. It’s fair to say that not many applications are likely to need this kind of service, but that’s one reason why it’s most accurate to think of search as an application service rather than an infrastructure service.

その答えは、もちろん「可能」である。たとえば、Microsoft の Live Search は、オンプレミスとクラウドのアプリケーションによる、検索のサブミットと結果のリターンを実現する、サービスをエクスポーズしている。法律情報データベースの提供を望む企業が、顧客からのシングル・リクエストにおいて、自社内のデータと Web 上のデータへの検索を実現できると考えるべきだ。プロプライエタリなデータを検索し、Live Search アプリケーション・サービスを介して Web 全体を検索するための、オンプレミス・アプリケーションを開発することで、この目的を達成できるだろう。あまり多くのアプリケーションが、この種のサービスを必要としないだろうという見方は公正である。検索サービスを、インフラストラクチャというよりアプリケーションとして考えることが、最も正確な見方であるという、ひとつの理由が、そこにある。

Mapping

Many Web applications today display maps. Hotel Web sites plot their locations, retailers provide store locators, and more. The people who create these applications probably don’t have the time, interest, or budget to create their own mapping database. Yet enough applications need this function to justify creating a cloud application service that provides it.

今日における、多くの Web アプリケーションがマップを表示する。ホテルの Web サイトや、小売りストアの Web サイトが、マップを使って所在地を提供している。おそらく、これらのアプリケーションを作成する人々は、自身のマッピング・データベースを作成するだけの、時間も予算も持っていない。 このサービスを必要とするだけで、個別の機能を要求しないアプリケーションの存在が、マップのためのクラウド・アプリケーション開発を正当化する。

This is exactly what’s done by mapping services such as Google Maps and Microsoft’s Virtual Earth. Both provide cloud-based services that application developers can use to embed maps in Web pages and more. And as with search, these mapping services are adjuncts to existing Web sites that target users directly, i.e., they’re cloud application services.

こうした考え方が、Google Maps や Microsoft Virtual Earth といった、マッピング・サービスが行うことを正確に示している。 どちらも、クラウド・ベースのサービスを提供し、Web ページなどにマップを埋め込むために、アプリケーション開発者による利用が可能となる。そして、検索の場合と同様に、これらのマッピング・サービスは、ユーザーを対象とした既存 Web サイトの付属物である。 すなわち、クラウド・アプリケーション・サービスである。

Other Application Services

Many other application services are available today. In fact, almost any Web site can expose its functionality as a cloud service for developers to use. Photo-sharing sites such as Google’s Picasa and Microsoft’s Windows Live Photo Gallery do this, for example, as do online contacts applications such as Google Contacts and Microsoft’s Windows Live Contacts. One big motivation for exposing services is to make it easier to create mash-ups that exploit the functions of diverse Web applications.

これまでに説明した他にも、数多くのアプリケーション・サービスが、現時点において利用可能となっている。 実際に、大半の Web サイトにおける機能を、開発者が利用するクラウド・サービスとしてエクスポーズできる。たとえば、Google Picasa や Microsoft Windows Live Photo Gallery といった写真共有のサイトが、それに該当する。そして、Google Contacts や Microsoft Windows Live Contacts といった、コンタクト・アプリケーションも同様である。サービスのエクスポーズにおける大きなモチベーションは、多様な Web アプリケーションの機能を利用するための、mash-up の作成を容易にする点にある。

Vendors sometimes group cloud application services together under a common umbrella. The services for accessing information in Google Contacts, Picasa, and more are all part of the Google Data APIs, for instance. Similarly, Microsoft groups several of its services together under the Live Platform brand, including Live Search, Virtual Earth, Windows Live Contacts, Windows Live ID, an Alerts service, a specialized storage service called Application-Based Storage, and several more.

いくつかのベンダーが、クラウド・アプリケーション・サービスを、共通の傘の下に集めることがある。 たとえば、Google の Contacts や Picasa などにおける情報アクセス・サービスは、Google Data API のすべてのパートに相当する。 Microsoft も同様に、Live Platform ブランドの下で、いくつかのグループにサービスを分類している。 そこには、Live Search、Virtual Earth、Windows Live Contacts、Windows Live ID、Alerts などのサービスに加え、Application-Based Storage と呼ばれる、特別なストレージ・サービスなども含まれる。

The line between cloud infrastructure services and cloud application services can sometimes be fuzzy. General cloud storage services such as S3 and SSDS are clearly infrastructure, for example, as are cloud identity services. A mapping service such as Google Earth is just as clearly application-centric – only certain kinds of apps need it – as is a service like Live Search. But an Alerts service might be considered infrastructure, since it’s more generally useful, and Windows Live ID is definitely infrastructure, even though Microsoft views both services as part of its Live Platform.

クラウドのインフラストラクチャ・サービスとアプリケーション・サービスの境界線は、はっきりしない状態に、時としてなり得る。たとえば、S3 や SSDS のような汎用クラウド・ストレージサービスは、明確なインフラストラクチャであり、クラウド・アイデンティティ・サービスも同様である。Google Earth などのマッピング・サービスが、まさにアプリケーション・セントリックなことは明らかであり、特定のアプリケーションだけが必要とする。また、Live Search のようなサービスも同様である。 しかし、Alerts サービスは汎用的な有用性を持つため、インフラストラクチャと考えることができ、また、Windows Live ID は明確なインフラストラクチャである。それにもかかわらず、Microsoft は 2つのサービスを、Live Platform の一部と見なしている。

Cloud platforms are a relatively new area, and so it shouldn’t be surprising that defining a firm taxonomy is challenging. However you choose to view them, it’s clear that cloud application services have an important role to play. Knowing what’s available in the cloud should be a core competency today for everyone who designs and builds software.

クラウド・プラットフォームは、相対的に新しいエリアである。そのため、厳密な分類法の定義が、大きな課題となっても驚くべきではない。さまざまな視点から眺めるにしても、クラウド・アプリケーション・サービスが、果たすべき重要な役割を持つことは明確である。クラウドで利用できる事柄を知ることが、今日のソフトウェアを設計と構築に従事する、すべての人々のコア・コンピテンシーであるべきだ。

CONCLUSION

A new kind of application platform doesn’t come along very often. But when a successful platform innovation does appear, it has an enormous impact. Think of the way personal computers and servers shook up the world of mainframes and minicomputers, for example, or how the rise of platforms for N-tier applications changed the way people write software. While the old world doesn’t go away, a new approach can quickly become the center of attention for new applications.

新しい種類のアプリケーション・プラットフォームは、頻繁に登場するものではない。 しかし、進化したプラットフォームが成功を収めるときには、巨大な影響を生じる。たとえば、メインフレームとミニコンピュータの世界に、パーソナル・コンピュータとサーバーが与えた衝撃を考え、また、N 階層アプリケーション用プラットフォームの興隆が、ソフトウェアの記述方式に与えた変化を考えるべきである。 古い世界が立ち去らなくても、新しいアプローチが瞬く間に、新しいアプリケーションのための中心を占めることがあり得る。

Cloud platforms don’t yet offer the full spectrum of an on-premises environment. For example, business intelligence as part of the platform isn’t common, nor is support for business process management technologies such as full-featured workflow and rules engines. This is all but certain to change, however, as this technology wave continues to roll forward.

まだ、クラウド・プラットフォームは、オンプレミス環境の全領域を提供しているわけではない。 たとえば、プラットフォームのパートとしての、ビジネス・インテリジェンスは共通化されていない。また、フル機能のワークフローやルール・エンジンといった、ビジネス・プロセス・マネージメント・テクノロジーもサポートされていない。 しかし、テクノロジーの波が前へ向けてうねり続けるにつれて、それらが変化することは、ほとんど確実である。

Cloud platforms aren’t yet at the center of most people’s attention. The odds are good, though, that this won’t be true five years from now. The attractions of cloud-based computing, including scalability and lower costs, are very real. If you work in application development, whether for a software vendor or an end user, expect the cloud to play an increasing role in your future. The next generation of application platforms is here.

まだ、クラウド・プラットフォームは、人々の意識の中心にはいない。 賭けをするなら、今から5年でものになるのか、ならないのか、という辺りが、ちょうど良いオッズになるだろう。 クラウド・ベース・コンピューティングの魅力は、スケーラビリティと低コストの実現を含めて、まさに本物である。もし、アプリケーション開発の世界に従事するなら、その立場がソフトウェア・ベンダーあろうがエンド・ユーザーであろうが、あなたの未来において、クラウドの占める役割が増加すると予測すべきだ。アプリケーション・プラットフォームの、次世代は、そこにある。

ABOUT THE AUTHOR

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, he helps software professionals around the world understand, use, and make better decisions about new technology.

————

以上で、David Chappell の A SHORT INTRODUCTION TO CLOUD PALTFORMS – AN ENTERPRISE-ORIENTED VIEW というシリーズは終わりです。 その 1回目でも述べましたが、このホワイトパーパーが書かれたのは、また、Azure が明らかにされていない頃であり、そこから 5年後くらいにクラウドは人々の意識の中心にくるという言葉で、David は締めくくっています。

そこから 1年と少しが経過し、2009/11/13 には HCJ 2009 が開催され、11/17 からは PDC 2009 が始まるいうところまできました。 私としては、クラウドが人々の意識の中心にくるというのは、どのようなことなのかと、その点を反芻しながら、この加速しつつある流れを凝視していきたいと思います。 --- A.C.

—————

2008年夏 Azure 前夜:David Chappell _1
2008年夏 Azure 前夜:David Chappell _2
2008年夏 Azure 前夜:David Chappell _3
2008年夏 Azure 前夜:David Chappell _4
2008年夏 Azure 前夜:David Chappell _5

 

David Chappell インタビュー

Posted in David Chappell, Interviews, Microsoft by Agile Cat on November 10, 2009

とにかくお読みくださいな

David 09_03_16

http://twitter.com/isshiki をフォローしている勘の良い人は、コレが来るのではないかと予測していたでしょうね。 何の説明も不要です。ちょっとだけ、導入部を紹介しますが、とにかく本文を、お読みくださいな。

Issiki David

特集:デビッド・チャペル氏への特設インタビュー
クラウドとWindows Azureの“もやもや”解消!
デジタルアドバンテージ 一色 政彦

2009/11/10

2009年10月13日~14日、デビッド・チャペル(David Chappell)氏(以降、チャペル氏)が来日し、クラウド・コンピューティングおよびWindows Azureに関するさまざまな講演を行った。

チャペル氏は、米マイクロソフト技術にかかわるコンサルティングを主業務としているチャペル&アソシエイツ(Chappell & Associates Principal)という会社の代表である。米マイクロソフトからの信頼が厚く、事実、マイクロソフトが公開しているWindows Azure Platform(従来はAzure Services Platformと呼称)のホワイト・ペーパー(日本語版はこちら)の多くは、チャペル氏によるものだ。昨年のWindows Azure(CTP版)の発表時点でそのホワイト・ペーパーは公開されていた。つまり公式発表される前から、Windows Azure Platformに深くかかわってきたということになる。米マイクロソフトにとってチャペル氏は、それほど重要なコンサルタントなのである。

本文はコチラです ↓

From <http://www.atmarkit.co.jp/fdotnet/dnfuture/intvwdavidchappell_01/intvwdavidchappell_01_01.html>

<関連>
http://www.davidchappell.com/
http://agilecat.wordpress.com/category/david-tracker/

David Chappell のヒミツ

Posted in David Chappell by Agile Cat on October 15, 2009

10月14日の神楽坂の某所で、、、

Windows Azure の普及のために来日したDavid Chappell さんを囲む夕食会がありました。 Agile Cat も末席に加えて頂き、かなり突っ込んだ話を聴かせてもらい、一杯やりながら勉強してきましたが、NDA があるため、ここでは話せなないのが残念です。そして、宴もたけなわ、座もくだけたあたりで、David Chappellさんとは、どういう人なのか、どんな経歴を持つ人なのか、というクエッション・タイムに突入しました。ここは、ご本人も了解していますので書かせていだだきます。

David Chappell 09_10_14

某 M氏から名前入りの提灯をもらって、ご満悦の Chappell さん

 

 

一同: いまの仕事をするまえに、何をしていたのですか?

D.C: ミュージシャンです。クラブなどで、キーボードを弾いていました。

一同: WoW!

D.C: 大学で経済学を学びましたが、なぜかと言うと、ピアノを練習する時間が取れ取れたからです。

一同: なるほど。でも、なんでミュージシャンをやめてしまったのですか?

D.C: 退屈してしまったのです。想像がつきますか? 毎晩、クラブで同じ曲を弾く退屈さを。

一同: 確かに、なかなか想像できませんね。でも、それで、いきなり、IT コンサルタントになったのですか?

D.C: ちょっとだけ、一般的な会社にはいりました。ファイナンシャル系の会社です。

一同: ほう。

D.C: でも、そこも退屈でした。そして、暇をもて余しているときに、君はプログラムを書けるかと上司に聴かれました。

一同: そ、それで?

D.C: 書いたことはなかったのですが、そのときの退屈さから逃れたく、Yes と答え、週末に勉強しました。

一同: どうなりました?

D.C: Fortran と Cobol のプログラムが書けるようになり、仕事ははかどりましたが、じきに、それにも退屈してしまいました。

一同: それで、いまのコンサルティングの道に?

D.C: そうなんです、それが私の、これまでに生きてきた道筋です。そしていま、Microsoft を手伝いながら、世界中で Azure を普及していくという、とてもエキサイティングな仕事をしています。最先端の IT は、ほんとうに面白い世界です。

こうして書いてしまうと、サラッとしてしまいますが、その場は、もう、たいへんな盛り上がりで、その雰囲気を文書で伝え切れないのが残念です。 今回、短い時間でしたが、こうして Chappell さんと話す機会を持ち、感じたのは、すべてに対して、正面から取り組むことで解決できるという、自信に満ち溢れていることです。 大切なことだと思います。 それと、ステージに立つという意味を、さすがはミュージシャンだけあって、とても深く理解しているんだなぁという印象がありました。

個人的な質問として MapReduce について聴きましたが、とても Cool であると言っていました。 それ自体が、Fabric であるとも。。。。。 Hadoop World に行ってきたと話したら、Azure と Hadoop に興味があるとは、ヘンなやつだと笑っていました。

来年も日本に来てくれますかという、皆さんのリクエストに対して、「日本は好きでしたが、今回でもっと好きになったので、もちろん、できる限りそうしたいです」と答えてくれました。 期待しましょう!

Futuer Technology Days については、砂子さんの Azureの鼓動で詳しく説明されています。また、カテゴリ David Tracker もご参照ください --- A.C.

Azure White Paper の SDS 部分が改変

Posted in David Chappell, Microsoft by Agile Cat on June 2, 2009

INTRODUCING THE AZURE SERVICES PLATFORM の第2版

David 09_03_16 

今年 1月の TechDays で配布された、David Chappell さんの INTRODUCING THE AZURE SERVICES PLATFORM ですが、その SDS の部分が改変されました。この TechDays サイトでダウンロードできる PDF 版の、主として P33~P36 あたりに修正が加えられています。MIX 09 で発表された、Relational SDS に合わせた改変と捉えて良いのかと思います

おおよそのことは、Relational SDS を考える:February 27, 2009 の内容と一致していますので、そちらもご覧ください。そのほかにも、ちょっとした加筆修正が、全般的に行われているようですが、だいたいは SDS を参照する部分のようです(ナナメ読みですが)。

気になるところとしては、"The current expectation is that the maximum size of a single database in SQL Data Services will be between 5 and 10 gigabytes.” という一文があげられます。 つまり、5GB~10GB あたりに、ひとつのデータベースとしての容量制限が設定されるだろうと予測されているようです。つまり、これ以上の容量が必要な場合には、Azure Storage Table で考えてくださいというメッセージなのでしょう。図としては、以下の2つが加えられています

Relational SDS 1

Relational SDS 2

それと、今回は Huron についても言及されています。

Relational SDS Huron

これを使って、オンプレミスやモバイル・デバイスからの、Azure 上の Relational SDS との同期を取ってくださいという考え方が提起されています。

Tagged with: ,
%d bloggers like this: