Amazon Web Services、Google、Rackspace、Microsoftはそれぞれ異なるクラウドサービスを提供していますが、1つだけ共通していることがあります。
次は企業独自のプライベート・クラウドの番です。
組織は、柔軟性、革新性、品質、効率に対するより高い期待に応えるために、クラウド・コンピューティングをどのように利用するかをモデル化する方法を検討する必要があります。多くの組織は、すでに多くのパブリック・クラウド・サービス・プロバイダーと取引しており、社内ユーザーにもクラウド・サービスが必要だと確信しています。新しいITプロジェクトの準備、予算の配分、ベンダーの選定。涅槃の境地に達しているのでしょうか？そうではありません。
2009年、私はクラウドの発表イベントで満席の参加者に、ほとんどの企業のプライベートクラウド構想は失敗するだろうと話しました。私は何度も何度も、大企業が展開するプライベート・クラウドは必ずAmazonやGoogleのエンジニアの鼻をあかすということを発見しました。
プライベートクラウドが犯している間違いとは？
ステークホルダーが求めているのはクラウドサービスではなく、数分でアプリケーションを実行できるように構成できるコンテナです。彼らは、使用するリソースに対してのみ料金を支払うことを望んでいます。また、異なる世代から生じるエンタープライズ・アーキテクチャ、情報セキュリティ、ITILインフラストラクチャ・プロセスの変更を、承認に数週間を要することなく行うことを望んでいます。
プライベートクラウドはAWSではありません。適切なアプリケーション・プログラミング・インターフェースがなく、統合するための管理ツールもありません。AWSやGoogle Cloudの2倍、場合によってはそれ以上のコストがかかります。完全なサービス・カタログがなく、プロダクト・オーナーによる検証がなければ、これらすべてをマネージャーは真っ向から否定する可能性があります。
5分以内に完全に使用可能なコンテナを提供するという、ことわざのようなリトマス試験紙を見てみましょう。企業のプライベート・クラウド管理および情報セキュリティ・スタックには自動化ツールがないため、運用に必要な期限を守ることが困難です。VMは5分でセットアップできますが、情報セキュリティと管理のコンフィギュレーションには翌週以降に着手する必要があるかもしれません。
クラウドは肉切り包丁です。プライベート・クラウドを、15年にわたるIT自動化スイートを備えたアーキテクチャに構築して、その全体を稼働させることも、大手企業ベンダーのようにコンバージド・インフラストラクチャを通じて部分的な自動化フレームワークで稼働させることもできません。
アマゾンに匹敵するオンプレミス・クラウド・スタックを構築する決意を固めているのであれば、以下の5つのステップを踏む必要があります：
1.もっとお金を使う - もっとたくさん
Amazonはクラウドサービスを構築するために数十億ドルを費やしてきました。AWSのような柔軟性と効率性を実現したいのであれば、中途半端なベンダーのサービスに100万ドルだけ投資することは考えにくい。
2.組織変更計画
クラウドの導入が成功すれば、多くのITスタッフの役割が変わったり、なくなったりするでしょう。すべてのプロセスが終了しても、同じ人が同じ仕事をしているのであれば、それは失敗です。大手クラウド・プロバイダーでは、1,000台、あるいは10,000台のサーバーが1人の管理者で構成されていると予想されます。唯一の手作業は、機器の引き抜きと交換だけです。
クラウド・ソリューションが経営幹部レベルで十分な支持を得られるようにすることは、その結果、仕事や重要性を失うことを恐れる否定派の懸念を払拭することです。
最も影響を受けるのは、プライベート・クラウドを介したデプロイに手作業が必要なクラウドスタックが自動化されるようになったことです。ITスタッフにとっては、これが自分の仕事を脅かす可能性があり、結果としてクラウド・プロジェクトに悪影響を及ぼしていることを認識することが重要です。そのため、将来のキャリアについて明確な見通しを与え、自分たちのために仕事を展開し、スキルアップを支援するために留まるようインセンティブを与えることが重要です。
3.導入初期段階でのIT運用保守チームの関与は不要
Forrester社のアナリストであるJames Staten氏は、IT運用チームが企業のプライベートクラウドを支配するというシナリオは失敗に終わる運命にあると述べています。私は多くの実例と教訓を目の当たりにしてきました。ビジネス・アズ・通常」の考え方から脱却しようとしているにもかかわらず、ほとんどのIT運用チームはITIL、COBIT、その他のプロセス主導の標準に過度に洗脳され、クラウドをユーザーにとってより価値のあるものにすることに重点を置いています。
最初のクラウド・ユーザー***は開発チームです。開発チームは、上から下までのアーキテクチャ設計を完成させることができます。これは、日々の開発ツールなどと簡単に統合できるAPIを備えた、開発者に優しい堅牢なサービスカタログを意味します。AWSのためにアプリケーションを構築するのではなく、仮想化されたインフラストラクチャのためにプログラムを構築するのです。
IT運用チームは、最終決定と実装の際に開発者とともに関与する必要があります。ベンダー主導のIT運用チームがプロセスの初期段階で問題を起こさないよう、この期間中も開発者は説明責任を果たす必要があります。
4.自動化の余地を残さない
自動化はたいてい失敗の元です。人は様々な機能を好み、現在のタスクが完了する前に新しいタスクに着手してしまいます。急がば回れ：いくつかの自動化タスクを未解決のままにしておくと、クラウド機能の欠陥につながる可能性があります。
どんなに単純で些細な手作業であっても、可能な限り自動化し、サーバー管理比率を高める必要があります。クラウドサービスプロバイダーが10,000:1というような割合になることはないでしょうが、可能な限りスタッフの作業負荷を最小限に抑える方法で行う必要があります。自動化は、サーバーの電源が投入され、スイッチがオンになった時点から唯一のアクションであるべきです。
5.クラウドのテストとテストの自動化
クラウドは複雑なシステムです。自動化はその複雑さを制御することができますが、同様に大きな失敗につながる可能性もあります。オンプレミスのクラウドをテストするということは、単にワークロードを追加するということではありません。
netflixは、Chaos Monkeyを使ってAWSのサーバーやシステムをクラッシュさせ、自社の耐障害性をテストしました。クラウド・オートメーションの回復力をテストするこの種のツールは、企業環境でも有効に活用できるかもしれません。
AWSのようなキラー・プライベート・クラウドを成功させるためには、慎重な検討が必要です。リソース、予算、テクノロジー、そして政治的な意思を持ち、成功に導くことができるIT部門はほとんどありません。だからといって、プライベート・クラウドをITポートフォリオの一部にすべきではないということではありません。しかし、プライベート・クラウドを自前で構築し運用するには、野心だけでは不十分であることを思い知らされます。
