The Doppler Quarterly (日本語) 秋 2016 - Page 7

大企業が何らかの侵害を受けた場合は常に、ほとんどの侵害 がクラウドとは無関係であるにもかかわらず、セキュリティ上の 恐怖を声高に広める人が出現し、パブリッククラウドイニシア チブを潰し始めます。 また、ベンダーに対するえこひいきも主要な阻害要因の 1 つで す。私がこれまでに見てきたケースでも、旧来のクラウドベン クラウドへの移行には、実際に大幅な変革が必要となります。 このような理由から、当社では、企業が当社のクラウド導入手 法を活用すると同時に、クラウドイニシアチブによる成功を実 現する道を切り開くものとなる、戦略的な変更計画を作成する ことを推奨しています。 技術的な課題 ダーに対する忠誠を守るために、ベンダー信者が企業を先導 しようとして、最適ではない道に進んでしまった例がありまし 特に、新しいクラウドアプリケーションをオンプレミスソリュー た。このような信者は、間違ったクラウドを実現する自説を推 ションと統合する必要がある場合、クラウドでのソリューション し進めるために、主要クラウドベンダーについて誤解を招くよう の構築には、数多くの技術的な課題が伴う可能性があります。 なことを数多く発言します。また、データセンターおよび自社管 非クラウドテクノロジーとの統合は複雑な作業です。複雑性に 理クラウドに対する投資の継続を余儀なくさせるために、パブ より混乱が生じ、その混乱は進行の鈍化につながります。 リッククラウドに関する誤った認識を広めます。 私がこれまでに担当した多くの取り組みでは、クラウド関連の 責任のあるクラウド提唱者は、クラウドについて誤解を招くよ すべてのネットワークトラフィックを既存のオンプレミスデータ うな発言を助長する社内抗争や、クラウドのビジネス価値に関 セ ターにバックホールするという要件がありました。レガシー する虚説、クラウドイニシアチブを行き詰まらせるクラウド反対 ネットワークのテクノロジーやレガシーツールとの統合には多 派のまったくの誤解と戦う必要があります。 大な作業が伴い、統合により、ソリューションが最適ではなく 文化的な問題 文化的な障壁の存在はおそらく、クラウドイニシアチブを鈍化 させる第一の要因です。多くの企業にとって、従来のコンピュー ティングからクラウドコンピューティングに移行するためには、 考え方の大きな転換が必要となります。クラウドコンピューティ ングを最大限に活用するには、サービスおよびクラウドネイティ ブアプリケーションについて検討し始める必要があります。 企業は従来より、モノリシックアプリケーションの構築や、半年 ごと、または四半期ごとの展開に慣れています。新しいモデル では、小規模な変更セットを提供し、隔週、毎週、または毎日 でさえも展開できます。これを達成するには、ソフトウェア開発 ライフサイクル (SDLC) 全体を再評価する必要があります。頻 繁な展開の基盤となるのは、スタックの完全な自動化です。手 動でのレビューに代わる存在となるのは、自動化されたセキュ リティ、規格の詳細な計画、自動化されたパッチ適用、および なることがしばしばあります。また、レイテンシなどの問題が生 じることもあり、その結果として、計画外の作業が発生すること や、回避策を講じる必要があることも多々あります。 社内のスキルやクラウドネイティブな考え方が不足していると、 アーキテクチャーが最適ではなくなることがよくあります。企業 がクラウドに対してデータセンター中心のアプローチを採用す ることは非常に多く、その結果として、クラウドはアジリティおよ びイノベーションを実現するプラットフォームではなく、単なる 別のデータセンターとなってしまいます。 古いツールをクラウドに導入すると、多くの場合、ソリューショ ンは最適ではないものとなり、四角い釘を丸い穴に強引に打ち 込もうとするような不要な作業が生じます。私はこれまでに、こ のような苦労を何度となく見てきました。ビジネスが新しい機 能を期待しつつも空回りし続ける一方で、 IT 担当者は、ビジネ ス上の付加価値がゼロに等しいものである、最適ではないツー ルやプロセスに無駄に取り組んで、貴重なサイクルを浪費する プロアクティブな監視です。 ことになります。これを機会に、既存のレガシーツールを最新 アプリケーションの構築、管理、および統制のための従来 き換えることを検討することをお勧めします。 の方法は根本的な変化を遂げることになり、このような点か ら、 DevOps が極めて重要となります。誤解されがちですが、 の SaaS ソリューションや新しいクラウドネイティブツールで置 不適切な実行 DevOps は IT の自動化を指すのではなく、それ以上に大きな ものです。DevOps の対象となるのは、プロジェクトの開始か らクラウドにおけるサービスの稼働に至るまでのバリュースト リーム全体です。企業は既存のバリューストリームのボトルネッ クについて評価し、自動化を実行する前に、それらのボトル ネックを修正する必要があります。そうしないと、自動化は単な る無駄な作業となります。ほとんどの企業に共通する大きな間 違いは、 DevOpsの技術的な側面にのみ重点を置き、必要とさ れる人やプロセスの変革への対処を怠っているという点です。 前述の 3 つの問題を適切に処理したとしても、この複雑な変 革のイニシアチブを効果的に管理する必要があることに変わ りはありません。ここで重要となるのは、あまりにも早い時点で あまりにも多くのことに取り組まないことです。当社では、実用 最小限のクラウド (MVC) アプローチを推奨しています。MVC 戦略が目標とするのは小規模なワークロードです。これにより 企業は、必要なセキュリティ、管理、および運用において、構築 を繰り返すことができます。また、完璧なクラウドの立ち上げを 2016 年秋号 | THE DOPPLER | 5