国内で Windows Azure の実証実験が始まる
2009 TechED の初日に wipse（Windows Plus Services）コンソーシアムから、Windows Azure をベースにした実証実験を行うとのアナウンスがありました。 マイクロソフトの鈴木章太郎さんのセッションで、インターオペラビリティ部会の小野和俊部会長と、サービス部会の玉木栄三郎部会長から、デモを交えた説明がありました。同コンソーシアムは、昨年に OpenXML の実証実験を成功させており、今年も面白いことをやってくれるのでは、と期待しています。
今回は、動画配信サイトのデモが行われましたが、これは、あくまでもダミーであり、eラーニングや ESB 接続など、幅広いアプリケーション･モデルに対応可能とのことです。オンプレミス接続や課金サービスなどを実現するための、フレームワークを開発中とも説明されていました。
詳しくは、ココ をご参照ください。 また、右ペインの wipse からもアクセスできます！ －－－ A.C.
Introducing Amazon Virtual Private Cloud (VPC)
From <http://aws.typepad.com/aws/2009/08/introducing-amazon-virtual-private-cloud-vpc.html>
ついに Amazon が、オンプレミス連携に関するベータを出しましたね。 Windows Azure のサービスインに先行して、エンタープライズのためのクラウドという領域がヒートアップしてきますね。地域としては Availability Zone in the US-East に限定されているようですが、エンタープライズだからこそ、回線の品質が重視されるのでしょう。 Amazon も Azure も、はやく日本に来て欲しいです。 ーーー A.C.
Amazon Virtual Private Cloud (Amazon VPC) lets you create your own logically isolated set of Amazon EC2 instances and connect it to your existing network using an IPsec VPN connection. This new offering lets you take advantage of the low cost and flexibility of AWS while leveraging the investment you have already made in your IT infrastructure.
Amazon Virtual Private Cloud (Amazon VPC) により、Amazon EC2 インスタンスの論理的に分離されたセットの作成と、IPsec VPN 接続を用いた既存のネットワーク接続が実現される。 この新しいオファーは、すでに投資された ITインフラストラクチャにテコ入れする一方で、AWS における低コストと柔軟性をいうアドバンテージを促進する。
This cool new service is now in a limited beta and you can apply for admission here.
この斬新なサービスはベータであるが、ココから登録できる。
Here’s all you need to do to get started:
以下の手順により、このベータの利用が可能となる：
1: Create a VPC. You define your VPC’s private IP address space, which can range from a /28 (16 IPs) up to a /18 (16,384 IPs). You can use any IPv4 address range, including Private Address Spaces identified in RFC 1918 and any other routable IP address block.
2: Partition your VPC’s IP address space into one or more subnets. Multiple subnets in a VPC are arranged in a star topology and enable you to create logically isolated collections of instances. You can create up to 20 Subnets per VPC (you can request more using this form). You can also use this form to request a VPC larger than a /18 or additional EC2 instances for use within your VPC.
3: Create a customer gateway to represent the device (typically a router or a software VPN appliance) anchoring the VPN connection from your network.
4: Create a VPN gateway to represent the AWS end of the VPN connection.
5: Attach the VPN gateway to your VPC.
6: Create a VPN connection between the VPN gateway and the customer gateway.
7: Launch EC2 instances within your VPC using an enhanced form of the Amazon EC2 RunInstances API call or the ec2-run-instances command to specify the VPC and the desired subnet.
1: VPC を作成する。その VPC のプライベート IP アドレス空間を定義することで、 /28 (16 IPs) から /18 (16,384 IPs) までのレンジに対応。つまり、 RFC 1918 で識別されるPrivate Address Spaces と、ルーティングに対応する IP アドレス･ブックを含む、あらゆる IPv4 アドレス･レンジの利用が可能。
2: 定義された VPC の IP アドレス空間を、1つのサブネットもしくは、複数のサブネットに振り分ける。VPC のマルチ･サブネットはスター･トポロジーに割り当てられるため、複数のインスタンス上で論理的に分離されるコレクションの作成が可能。VPC ごとに、20 までのSubnet の作成が可能（それ以上のリクエストにも対応）。さらに、定義された独自の VPC 内で。 /18 以上のVPC もしくは、追加の EC2 インスタンスの利用も可能。
3: VPN と顧客のネットワークを接続するデバイス（一般的にはルーターもしくはソフトウェアVPNアプライアンス）を、表現するためのカスタマー･ゲートウェイを作成。
4: その VPN コネクションの AWS エンドを表現する、VPN ゲートウェイを作成。
5: そのVPN ゲートウェイを、作成された VPC にアタッチ。
6: VPN ゲートウェイとカスタマー・ゲートウェイの間で、VPN コネクションを作成。
7: Amazon EC2 RunInstances API コールもしくは、ec2-run-instances コマンドから、特定の VPN と指定されたサブネットへの拡張を用いて、作成された VPC 内の EC2 インスタンスを起動。
Once you have done this, all Internet-bound traffic generated by your Amazon EC2 instances within your VPC routes across the VPN connection, where it wends its way through your outbound firewall and any other network security devices under your control before exiting from your network.
IP addresses are specified using CIDR notation, where the value after the slash represents the number of bits in the routing prefix for the address. You’re currently limited to one VPC per AWS account, however, if you have a use case requiring more, let us know and we’ll see what we can do.
Because the VPC subnets are used to isolate logically distinct functionality, we’ve chosen not to immediately support Amazon EC2 security groups. You can launch your own AMIs and most public AMIs, including Microsoft Windows AMIs. You can’t launch Amazon DevPay AMIs just yet, though.
The Amazon EC2 instances are on your network. They can access or be accessed by other systems on the network as if they were local. As far as you are concerned, the EC2 instances are additional local network resources — there is no NAT translation. EC2 instances within a VPC do not currently have Internet-facing IP addresses.
上記の処理を行うと、VPC 内の Amazon EC2 インスタンスにより生成された、インターネットにバインドされた全てのトラフィックが、VPN 接続の向こう側にルーティングされる。それらのトラフィックは、オンプレミスのネットワークを抜け出す前に、アウト･バウンド･ファイアウォールや、他のネットワーク･セキュリティ･デバイスをくぐり抜けることになる。
IP アドレスは、CIDR 表記法を用いて指定される。つまり、スラッシュに続く値は、そのアドレスに対するルーティング･プリフィックスにおけるビット数を表す。現時点では AWS アカウントごとに、1 つの VPC と限定されているが、さらに多くの VPC を使用するケースにおいては、その要望を聴かせて欲しい。
機能を論理的に分離するための VPC サブネットを用いるため、Amazon EC2 セキュリティ･グループに関しては、ただちにサポートすることはない。 現時点で使用している AMI や、Microsoft Windows AMI などを含む、最も一般的な AMI を開始できる。 ただし、Amaazon DevPay AMI については、まだ、開始できない。
Amazon EC2 インスタンスは、個別のネットワーク上にある。そこからのアクセスや、反対に、ネットワーク上で他のシステムからのアクセスは、それらがローカルであるかのように実行される。 そのように運用する限り、 EC2 インスタンスは追加のローカル･ネットワーク･リソースであり、NAT トランスレーションは存在しない。 VPC 内の EC2 インスタンスは、現時点において、インターネットと直結する IP アドレスを持たない。
Requirements to interoperate with our VPN implementation include:
この VPN 実装と相互運用される要件は、以下の項目を含む：
Optional capabilities that we recommend include:
We’ve confirmed that a variety of Cisco and Juniper hardware/software VPN configurations are compatible; devices meeting our requirements as outlined in the box at right should be compatible too. We also plan to support Software VPNs in the near future. If you want us to consider explicitly validating a device not on this list, please add your request to the Customer Gateway support thread located here.
我々は、Cisco と Juniper のハードウェア／ソフトウェア VPN コンフィグレーションとの互換性を確認した。つまり、図内の右側のボックスで概説されるように、我々の要件を満たしているデバイスも、互換性を持つべきである。さらに、近い将来において、ソフトウェア VPN をサポートすることも計画している。このリストで明示される以外の、デバイスについて検証を望むなら、Customer Gateway サポート･スレッドにリクエストして欲しい。
Amazon VPC functionality is accessible via the EC2 API and command-line tools. The ec2-create-vpc command creates a VPC and the ec2-describe-vpcs command lists your collection of VPCs. There are commands to create subnets, customer gateways, VPN gateways, and VPN connections. Once all of the requisite objects have been created, the ec2-attach-vpn-gateway connects your VPC to your network and allows traffic to flow. While most organizations will likely leave the VPN connection (and VPC) up and running indefinitely, you can drop the connection, terminate the instances, and even delete the VPC if you would like.
Amazon VPC は、EC2 API とコマンドライン･ツールによりアクセスできる。 ここでいう、 ec2-create-vpc コマンドが VPC を作成し、 ec2-describe-vpcs コマンドが VPC のコレクションをリストアップする。さらに、サブネットや、カスタマー･ゲートウェイ、VPN ゲートウェイ、VPN 接続などを作成するコマンドが提供される。すべての必要とされるオブジェクトが作成された後に、ec2-attach-vpn-gateway により VPC とオンプレミスが接続され、その間でトラフィックが流れ始める。おそらく、大半の組織が、VPN 接続（そして VPC）を制限することなく、また、動いたままにしておくだろうが、その接続を遮断し、インスタンスを終了することが可能であり、必要に応じて VPC を削除することさえ可能となる。
You only pay for what you use. Pricing is on a pay-as-you-go basis. VPCs, subnets, customer gateways, and VPN gateways are free to create and to use. You simply pay an hourly charge for each VPN connection you create, and for the data transferred through those VPN connections. EC2 instances within your VPC are priced at the normal On-Demand rate. We’ll honor the hourly rate for any Reserved Instances that you have but during the beta we cannot guarantee that Reserved Instances will always be available for deployment within your VPC.
支払いは、使用に応じたものとなる。 その価格は、pay-as-you-go に基づいたものとなる。 つまり、VPC や、サブネット、カスタマー･ゲートウェイ、VPN ゲートウェイの作成と使用じゃ無料である。つまり、それぞれの VPN 接続に対する１時間あたりの料金と、 VPN 接続を介して転送されるデータ量に対して、支払うことになる。また、VPC 内の EC2 インスタンスに関しては、標準的な On-Demand レートで課金される。 この Reserved Instances について、時間単位での課金が行えることを嬉しく思うが、ベータの期間内においては、個別の VPC 内で Reserved Instances が常に利用できるとは限らない。
Imagine the many ways that you can now combine your existing on-premise static resources with dynamic resources from the Amazon VPC. You can expand your corporate network on a permanent or temporary basis. You can get resources for short-term experiments and then leave the instances running if the experiment succeeds. You can establish instances for use as part of a DR (Disaster Recovery) effort. You can even test new applications, systems, and middleware components without disturbing your existing versions.
既存のオンプレミス･サイトにある静的なリソースと、Amazon VPC の動的なリソースを、どのようにして結合するのか、その方式についてイメージを膨らませて欲しい。自社のコーポレート･ネットワークを、恒久的に、あるいは、一時的に、拡張できる。短期的な実験としてリソースを利用し、もし成功したのなら、そのまま実運用へと進むことが可能となる。 また、DR（Disaster Recovery）の一部として、インスタンスを確立することもできる。さらには、新しいアプリケーションや、システム、ミドルウェア、コンポーネントなどのテストを、既存のバージョン体系を乱すことなく、実施することが可能となる。
As is the case with many of our betas, this one is launching in a single Availability Zone in the US-East region. You can use Amazon CloudWatch to monitor your instances, but you can’t use Elastic IP addresses, Auto Scaling or Elastic Load Balancing just yet.
これまでの、数多くのベータと同様に、Availability Zone in the US-East で開始される。 インスタンスをモニターするために Amazon CloudWatch は利用できるが、 Elastic IP アドレス／Auto Scaling／Elastic Load Balancing は、まだ使用できない。
Recall that all traffic from your instances routes through the VPN connection. For now, this includes traffic to other Amazon Web Services such as EC2 instances outside of your Amazon VPC, Amazon S3, Amazon SQS, and Amazon SimpleDB. You can create Elastic Block Store (EBS) volumes and attach them to your instances. EBS volumes created within your cloud can be moved to standard EC2 instances and vice-versa.
実行されているインスタンスからの、すべてのトラフィックに対する Recall は、VPN 接続を介してルーティングされる。 今のところ、Amazon VPC 外の EC2 インスタンスや、Amazon S3、Amazon SQS、Amazon SimpleDB といった、Amazon Web Services へ向けたトラフィックも含まれる。Elastic Block Store（EBS）ボリュームを作成し、対象となるインスタンスにアタッチすることもできる。クラウド内で作成された EBS ボリュームを、標準的な EC2 に移動すること、そして、反対方向での移動も可能となる。
I do want to mention a few of the things on our road map as well. First, we’re planning to let you directly reach the Internet from your VPC. In early discussions with potential users, we learned that most of them wanted to completely isolate their EC2 instances, routing all of the traffic back to their data center, so we gave this feature the highest priority. Later on, we’ll let you decide if and how you want to expose your VPC to the Internet. Second, we’re planning to let you specify the IP address of individual Amazon EC2 instances within a subnet. During this beta, Amazon EC2 instances are automatically assigned a random IP from the subnet’s designated IP address range. Third, we’re evaluating ways to allow you to filter traffic per subnet, kind of like how you might implement router ACLs. We’re already working on these items and on other additions to the core functionality we’re releasing today. If you have opinions on these items, or anything else you’d like to see in the service, e-mail us or post to the forum. This service is for you; we really need your feedback!
ここで、ロードマップについても、少し説明しておきたい。あなたの VPC からインターネットへ向けて、直接的に接続することを、最初の目標としている。パワー･ユーザーとの初期のディスカッションで我々が学んだことは、EC2 インスタンスを完全に分離するここと、そして、オンプレミス･データセンターへ向けて、すべてのトラフィックをルーティングすることを、彼らの大半が望んでいることだった。そのため、この機能に対して、最高の優先順位を与えた。この後、あなたの VPC をインターネットに公開するための、方式について決定していく。 第二に、サブネット内の個々の Amazon EC2 インスタンスにおける、IP アドレス指定について計画している。 このベータ期間において、Amazon EC2 インスタンスは、サブネットで指名された IP アドレス･レンジに基づき、ランダムかつ自動的に割り当てられる。 第三に、ルーター ACL の実装のように、サブネットごとのトラフィック･フィルタリングを実現するための方式を評価している。今日リリースしたコア機能に対して、すでに、それらの項目などに関する作業を進めている。これらの項目や、その他について意見があるなら、対象となるサービスを参照すことが可能であり、また、電子メールやフォーラム･ポストも可能である。これらのサービスは、あなたのためにある。つまり、我々は、あなたのフィードバックを必要とする！
We think you can put Amazon VPC to immediate use and can’t wait to hear about new and imaginative use cases for it. Please feel free to leave a comment on this blog or to send us some email.
Amazon VPC を使用すると、それらの新しい機能が待ちきれなくなると推測している。 このブログへのコメントや、電子メールなどで、遠慮なく意見を聴かせて欲しい。
– Jeff;
The future of ITIL® V2
A market exploring survey – February 2009
Internet www.exin-exams.com
そう言えば、ITIL ってどうなっているのでしょうかね？クラウドが注目されるにつれて、マネージメントに関する興味が薄れがちですが、インシデントまでは Azure も面倒を見てくれません。また、オンプレミスではツールも自身で用意しなければなりません。 ITIL は すべてが V3 に行ってしまうのでしょうか？ 今年の 2月のレポートですが、V2 と V3 に関する面白いレポートがありましたので、以下に抄訳を掲載します。 －－－ A.C.
1. Introduction
1.1 The growth of ITIL®
EXIN は、1993年に設立されて以来、ITIL V2 に関する試験を提供し続けていますが、当初は Service Manager 試験だけでした。その後、この試験のための財団と、1つの科目は、オランダで導入され、また、1997 年からは国際的に導入されました。 2000 年の ITIL V2 の後には、急速な普及が世界的規模で始まり、また、2005 年以降は、その傾向が更に強まっています。
2007 年の ITIL V3 の導入により、IT Service Management にかかわる多くの人々が、「今後における ITIL V2 での証明」について質問しました。 世界の主要国で、まさに ITIL V2 が導入され、ローカライズされたところでした。 現時点において、ITIL® Qualification Board が ITIL V2 の中断を検討しているため、この調査では、マーケット･サイドからの見解を集約していきます。
1.2 The survey
この調査が目指すのは、ITIL に対するマーケット･サイドからの要求を調査することです。つまり、ITIL V2 フレームワークを、販売／推奨／使用する人々の意見を集約します。現時点において、ITIL が、数多くの「ITIL 先進国」で取り入れられているという事実は、否定することができません。 しかし、それぞれの理由により、ITIL V2 を継続して使いたいという、マーケットからの声があるように思われます。 主な問題は、そのようなグループの規模でしょうか？
1.2.1 Respondents regional representation
全体で 547人の回答者が、このオンライン･アンケートに匿名で参加しました。地域により分類すると、ヨーロッパとアジア･パシフィックの比率が高いと分かります。 この調査で特筆すべきことは、こうした地域による相違が少なかったことです。
1.2.2 Research population’s relation to ITIL®
この調査に参加した大多数の人々は、ITIL の販売および推進に関与しています。その一方で、その販売と推進に関与していない、圧倒的に多数の人々は、現時点において V2 フレームワークを使用しています。 この調査は、きわめて正確です。なぜなら、ITIL の販売と利用に関与していない人は、調査対象者の 2.9％に過ぎないからです。
2. Results
2.1 The perceived benefits of ITIL® V2 & V3
Trainers & consultants
今のところ、マーケットの大半において、ITIL V2 が販売され、推奨されています。 トレーナーとコンサルタントの約 70% が、その顧客により、ITIL V2 が利用されていると主張しています。 それにもかわらず、ITIL マーケットにおいては、きわめて短期間のうちに V3 の導入が増えています。この調査の対象者のうち、約 60％ の回答者が、同時に双方のフレームワークに取り組んでいます。
ITIL V3 の トレーナー とコンサルタントは現時点において、V3 が V2 の延長線上にある最新バージョンであるため、そちらをメインとして考えているようです。だたし、それだけではなく、どれぐらい期間において、ITIL V2 がパブリックなかたちで利用できるかという危惧もあるようです。
Corporations and users
この調査において、ITIL のトレーニングの提供者は、その顧客における ITIL V2 のメリットについて、査定するように求められました。さらに、ユーザーに対しても、そのメリットに関する認識が、ダイレクトに尋ねられました。この方式により、直接的な需要と、派生的な需要に対して、クロス･チェックが可能になります。ユーザーからは、試験と書籍に関するローカリゼーションといった理由が付け加えられましたが、双方のグループにおける認識は、完全に一致していました。
ユーザーにおける ITIL V2 の主要なメリットは、その有効性が証明されたことだけではなく、より抑制された追加投資にあります。
この調査における、2.6％ の ITIL ユーザーだけが、 ITIL V3 に切り替えたと答えていますが、その理由は「最新バージョン」にあります。
2.2 How long does the market want ITIL® V2 to stay?
この調査では、直接的な需要（企業、利用者）だけではなく、派生的な需要（トレーナー、コンサルタント）も、ITIL V2 の寿命について、同じような見解を示しています。つまり、早急に終わるべきではない、というものです。
半数以上の トレーナー とコンサルタントが、ITIL V2 と ITIL V3 の共存を望んでいます。その一方で、より以上の企業と利用者が、ITIL V2 と ITIL V3 の共存を望んでいます。
3. Conclusions
今回の調査対象者である 547人は IT Service Management において活動しており、ITIL V2 が終了する可能性について、EXIN が市場動向を把握するための、アンケートへの記載に協力しました。この 市場とは、最終的な需要（ユーザー）と、派生的な需要（トレーナー / コンサルタント）という観点で定義されています。
これらの人々の半数以上が、今後の長期間にわたり、ITIL V2 を ITIL V3 が安定して共存していくことを望んでいます。また、この調査対象者のうち、5％ 以下の人々が、ITIL V2 を直ちに終了すべきと考えています。
トレーナーとコンサルタントのうち、約 70％ が主張するのは、彼らの顧客が ITIL V2 をを求めていること、そして、この要求についてユーザーと共にクロス･チェックしたいということです。 ITIL V2 の継続に関する主な理由は、V2 における実績、および、V2 で証明された記録の追跡、そして、フレームワークのアップデート･バージョンに対して、新たな追加投資が不要だという事実です。
現時点において、主として ITIL V3 の販売／推進に関わるトレーナー とコンサルタントは、その理由として、以下の二点を挙げています。それは、V3 が V2 の延長線上にある最新バージョンであること、そして、どれぐらい期間において、ITIL V2 がパブリックなかたちで利用できるかという危惧です。
ITIL が情報セキュリティを変える _1
ITIL が情報セキュリティを変える _2
ITIL が情報セキュリティを変える _3
ITIL が情報セキュリティを変える _4
ITIL が情報セキュリティを変える _5 (最終回)
Google’s PUE Numbers Slip Slightly
Data Center Knowledge より
July 20th, 2009 : Rich Miller
From <http://www.datacenterknowledge.com/archives/2009/07/20/googles-pue-numbers-slip-slightly/>
数多くの企業がPower Usage Effectiveness (PUE) を基準とし、そのデータセンターのエネルギー効率について情報を提供していますが、Google 以上に精密なデータは無いようです。以下のグラフは、その Google のPUE 値ですが、下がり続けるものではないようですね。
Many companies have released information about their data center energy effiency using the Power Usage Effectiveness (PUE) metric. But none have received more scrutiny than Google, whose exceptional PUE numbers have been widely discussed in the data center industry. The latest data from Google show that the company’s numbers can go up as well as down.
Google’s quarterly energy-weighted average PUE rose to 1.20 in the second quarter, up from 1.19 in the the first quarter of 2009. The best-performing facility had a PUE of 1.15 for the quarter, compared to 1.11 for the most efficient site in Q1.
What’s behind the increase, which followed two quarters of improvement? Three new Google data centers met the inclusion criteria for the company’s public PUE reporting, expanding the number of facilities to nine.
“The PUE of the new facilities is elevated due to commissioning and bring-up activities,” Google said. “The combined impact of partially-commissioned facilities and traditional seasonal effects resulted in a (quarter-on-quarter) increase of our quarterly energy-weighted average PUE, bringing it to 1.20. ”
The latest report reinforces the value of efficiency reporting over time to track seasonal fluctuations and changes in a company’s data center environment. In response to industry questions about its disclosures, Google has made several presentations at industry events providing details about its efficiency strategies and how it measures and calculates its PUE. The company will continue to provide public updates on its data center energy efficiency on a quarterly basis.
Microsoft to cut Live Framework and Services from its Azure cloud platform
All about Microsoft – August 21st, 2009 より
Posted by Mary Jo Foley @ 12:58 pm
From <http://blogs.zdnet.com/microsoft/?p=3777>
あまり良いニュースではありませんが、こうした状況にあることは、理解しておかなければなりませんね。 Windows Azure を支える三本柱のうちの、一本が欠けることになるのかも知れませんが、Relational DB へシフトしたときに、すでに Live Services （＝コンシューマ）の意味合いが変化していたのかもしれません。 クリティカルな内容なので、抄訳は参考程度にして、本文もよく読んでください。 それにしても、最近の Mary Jo Foley さんは、かなり手厳しいですね ーーー A.C.
When Microsoft showed off its comprehensive Azure cloud “layer cake” diagram back at the Professional Developers Conference (PDC) in 2008, to me, it had somewhat of a slapped-together feeling.
Professional Developers Conference (PDC) in 2008 において、Microsoft が Azure の包括的なレイヤー･ダイヤグラムを示したとき、ケーキのようにデコレートはされていても、いかにも寄せ集めという感覚を持っていた。
Up until last fall, Microsoft was building two “cloud” developer platforms in parallel that were meant to provide programmers with a consistent set of programming interfaces and services: The Azure services platform and the Live Framework platform. At the PDC Microsoft officials made a case for a unified cloud platform, with Live Framework/Services and Azure’s .Net Services happily coexisting.
その発表のあった昨年の秋まで、Microsoft は 2つのクラウド･デベロッパー･プラットフォームを平行して構築しており、それぞれが一貫したインターフェイスとサービスのセットを、プログラマーたちに提供していた。つまり、Azure サービス･プラットフォームと、Live Framework プラットフォームのことである。そして Microsoft は PDC で、 Live Framework/Services と Azure .Net Services を共存させるための、統一されたプラットフォームを論証して見せたわけである。
It now looks like the unified-platform vision didn’t hold together once the frosting dried. Via an August 21 blog post by Corporate Vice President of Live Services David Treadwell, Microsoft officials shared the news that they are shifting gears. Microsoft is rejiggering its Live Framework and Live Services platform, somehow making it part of the Windows Live Wave 4 set of consumer-focused Web services that is expected to go to testers in the coming months. (Microsoft is telling developers it will provide specifics about how it plans to integrate the Live Framework into Windows Live in the coming months.)
しかし、今になってみると、その統一されたプラットフォームは、インターフェイスとサービスを統合することはなく、出来そこないのケーキみたいに見える。Live Services の Corporate Vice President である David Treadwell が、8月 21日にポストしたブログによると、Microsoft が方針変更したことが公に確認されている。つまり、来月以降にテスターたちに提供される予定の、コンシューマを対象とした Web サービスにおける Windows Live Wave 4 の一部が、何らかのかたちで、そのことを示すことになる（Microsoft がデベロッパーに伝えているのは、 Live Framework を Windows Live に統合する計画であり、そのための仕様を提供するということになる）。
Meanwhile, developers who’ve been using the existing Live Framework/Services infrastructure are going to have to download any data and/or code from the service prior to September 8, the date on which Microsoft is planning to phase out the current Live Framework. Company officials also are telling developers to remove any devices and controls making use of the Framework/Services platform.
その一方で、既存の Live Framework/Services インフラストラクチャを使用しているデベロッパーは、9月 8日より前に、対象となるサービスから、あらゆるデータとコードをダウンロードしなくてはならなくなる。その日付とは、現在の Live Framework を、Microsoft が終了しようと計画している日のことである。さらに同社は、その Framework/Services プラットフォームで使用するデバイスとコントロールを削除せよと、デベロッパーたちに伝えている。
Microsoft is telling testers that Live Mesh, its online synchronization and collaboration service, won’t be affected by the change — at least in terms of its availability to testers. Back at PDC, Microsoft officials positioned the Live Services platform as the underpinning for the Live Mesh developer stack… but it seems the two aren’t as tightly joined as Microsoft execs may have hinted.)
また、Microsoft は、少なくともテスターが利用できるという意味において、Live Mesh のオンライン同期とコラボレーション･サービスが、今回の影響を受けることはないと説明している。 昨年の PDC の時点に戻ってみると、Microsoft はオフィシャルに、Live Mesh デベロッパー･スタックの下に、 Live Services プラットフォームを位置づけていたが、同社の経営陣が匂わせたように、その2つが緊密に結合されることは無かったようだ。
From the Microsoft-provide Q&A on the Live Framework changes, posted on August 21:
8月21日にポストされた、Live Framework の変更に関する Q&A によると：
“Q: What is changing in the Live Services developer portal (live.azure.com)?
“A: The ability to create Live Framework-enabled web sites and Mesh-enabled web applications will be removed. It will not be possible to edit the settings of Live Framework-enabled web sites and Mesh-enabled web applications and Analytics because these applications won’t be available any longer. Live Framework CTP tokens will no longer be valid and can be discarded.”
“Q: Live Services developer portal (live.azure.com)では、何が変わる?
“A: Live Framework 対応の Web サイトと、Mesh 対応の Web アプリケーションを作成するための機能が失われる。つまり、Live Framework 対応の Web サイトと、Mesh 対応の Web アプリケーションと、Analytics における設定を、編集することができなくなる。なぜなら、それらのアプリケーションが利用できなくなるからだ。Live Framework CTP の tokens は有効ではなくなり、廃棄されることになる。
A Microsoft spokesperson sent me the following statement when I asked about the company’s long-term commitment to the Live Framework:
Live Framework に対する Microsoft の長期的な責務について尋ねたときに、同社のスポークスマンから以下の声明が送られてきた：
“Microsoft is very committed to the Live Framework. Our goal is to integrate this rich technology into one of the largest online offerings from Microsoft, Windows Live. This will enable developers to connect and create compelling solutions across the web and devices for the more than 500M users of Windows Live. Our goal is to give developers a great developer experience going forward with a more consistent programming interface for our services.”
"Microsoft は Live Framework を、強くコミットしていきます。私たちのゴールは、 Microsoft Windows Live が提供する大規模なオンラインの中に、リッチなテクノロジーを統合することです。それにより、デベロッパーは、5 億人以上の Windows Live ユーザーに提供される Web やデバイスを横断するかたちで、魅力的なソリューションを作成し、また、結合していくことが可能になります。私たちのゴールは、私たちのサービスのためのプログラミング･インターフェイスを用いて、偉大なデベロッパーたちのエクスペリエンスを促進していくための、環境を提供することです”
I had been thinking Microsoft might roll out the final version of Live Mesh at this year’s PDC in November, given that the company is planning to remove the “beta” tag from Azure around that time. But with all these under-the-hood changes, now I’m starting to wonder…
11月に開催される PDC において、Azure からベータ･タグを取り除こうと Microsoft が計画しているなら、Live Mesh の最新バージョンが完了するのだろうと思える。しかし、こんなに安易な変更があってよいものかと、新しい疑問が湧きつつある・・・
Anyone have any observations, thoughts or guesses about what these latest moves mean for Azure and Windows Live?
Azure と Windows Live に起こった最近の変化について、どのような人が、何を見て、何を考え、何を推測しているのだろうか？
 |
 |
 |
 |
 |
 |
|  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Agile_Cat Tumblr
Theme: Rubric. Blog at WordPress.com.
