クラウドで柔軟性を維持

5分 読む

企業がクラウドに移行したり、プロバイダーを変更したりすると、しばしば不快な真実が明らかになります。つまり、applicationを迅速に導入しようと急いでいるため、開発者は気づかないうちに企業に代わってビジネス上の決定を下す立場に置かれることが多いのです。 これまで CIO または CTO の独占領域であったこれらの決定は、企業の将来に大きな影響を与える可能性があります。

さらに悪いことに、経営陣は何かが変わるまで、基本的な設計上の決定が開発者によって行われたことに気づかないことがよくあります。 クラウド プラットフォームの切り替え、新しい国での顧客の獲得 (これにより追加の規制に準拠する必要が生じる)、パブリック クラウドからプライベート クラウドまたはハイブリッド クラウドへの移行はすべて、以前の決定によって生じた柔軟性の欠如を露呈する可能性のある変更であり、膨大な技術的負債につながる可能性があります。

推奨事項1: 「もしも」をプレイする

管理者と経営幹部は、潜在的なビジネスおよび規制のシナリオが自社の開発にどのような影響を与えるかを明らかにするための演習を実施する必要があります。 これらの「what-if」演習の目的は、潜在的な問題を特定することです。

新しいプライバシー法が可決されたり、企業やapplicationがヨーロッパの顧客のデータを処理しなければならない場合はどうなるでしょうか? 最近の Ponemon Institute のレポートによると、クラウドを担当する管理者のほぼ 4 分の 3 が、プライバシーとデータ保護規制の管理はクラウドではより複雑になると考えています。

企業がapplicationsを新しいクラウド インフラストラクチャ プロバイダーに移行するとどうなるでしょうか? クラウド プロバイダーの移行にかかるコストを測定する適切な数値はほとんど存在しませんが、企業にとっての最大の課題はクラウドの使用コストを最適化することです。 あるクラウド プロバイダから別のクラウド プロバイダーに移行するコストを削減できないと、企業は既存のプロバイダーに縛られてしまいます。

引用/中断: 企業の 53% がクラウドの使用を最適化することでコスト削減に取り組んでいます。

これらの「what-if」ゲームは、企業が開発および運用プラットフォームにどの程度の柔軟性と抽象性を組み込む必要があるかを判断するのに役立ちます。 通常、開発者は何かを実行する方法を担当し、運用はそれを管理する方法を担当しますが、重複する作業を減らし、将来の落とし穴を回避するために、両方に包括的なフレームワークが必要です。

推奨事項2: 決断ポイントを探す

経営幹部とクラウド アーキテクトは、開発プロセスにおいて特定のテクノロジーまたはプロセスを置き換える必要があるポイントを探す必要があります。 これらの代替ポイントを特定することで、企業は将来に備えることができます。

将来も柔軟性を維持するために、企業はセキュリティ、パフォーマンス、監視ツールなど、さまざまなサービスで動作するように設計全体を設計する必要があります。 現在、Amazon Web Services が市場を支配し、革新を続けている一方で、Microsoft Azure、Google Cloud などのサービスも、強力で差別化された魅力的な製品で勢いを増しています。 たとえば、マイクロソフトの Azure クラウド サービスは、2016 年の 20% から 34% の企業をサービスに引き付けています。

推奨事項3: 柔軟性を可能にするサービスを特定する

潜在的な落とし穴を特定し、それをテクノロジーとポリシーの決定ポイントにマッピングした後、クラウド管理者は問題を解決できる技術的なソリューションを特定する必要があります。 多くの場合、application配信コントローラーなどの追加レイヤーを使用することで、インフラストラクチャを抽象化し、制御ポイントを追加できます。

企業の 69% がクラウドを使用してビジネス プロセスを再構築しています。 企業は常に、サービスがより高いセキュリティを提供するのか、より優れた機能を提供するのかを選択する必要がありますが、経営者はそれらの考慮事項と柔軟性の必要性とのバランスを取り、不確実な将来に備える必要があります。

開発者は独力で物事を考えることがほとんどありません。 そのため、エンタープライズ アーキテクトと CXO は、行き詰まった開発の選択を防ぐアーキテクチャ原則を通じて、ビジネスの優先順位を適用する必要があります。 仮説シナリオをブレインストーミングし、開発プロセスにおける代替可能なポイントを特定し、柔軟なソリューションを見つけることで、企業は将来大きな問題を防ぐことができます。

クラウド アーキテクトがいると、application開発を正しい方向に進めることができます。 より多くの企業が活用している役割です。 RightScale によると、毎年実施されるクラウド調査の回答者の 56% 以上が、自らをクラウド アーキテクトであると認識しており、これは 2016 年の 40% から増加している。

開発者は組織の真空状態の中でエンジニアリングを行うことはできませんし、また行うべきでもありません。 むしろ、将来に向けて発展できる枠組みが提供されるべきです。

結局のところ、クラウドの導入は価値の計算に帰着します。単一のプラットフォームの使用はいくつかのプラスのメリットをもたらすかもしれませんが、applicationの将来は予想よりも長く、より困難です。

Robert Haynes は、IT 分野で 20 年以上の経験を持つソリューション アーキテクトです。 ヘルプデスクアナリストとして下っ端からスタートした彼は、UNIX システム管理、バックアップとストレージ、そして最終的にはapplicationネットワーキングへと、冴えないキャリアを歩んできました。 さまざまな業界と数大陸にわたる複雑な IT システムのサポート、設計、販売に携わってきた Robert は、常にテクノロジーの実用的な実装と実際の使用に重点を置いています。 これは、F5 ネットワークのマーケティングにおける現在の彼の役割とはまったく矛盾しているように思えるかもしれませんが、彼は、主にフォースにバランスをもたらすために雇われていると考えています。

ロバートは、ウェールズ大学カーディフ校で応用生物学の理学士号を取得しており、ドライビング・ダイナミクス・インタラクティブ上級ドライビング・スクールで「バックおよび駐車中の衝突回避」の認定証を取得しています。後者の認定証は前者の認定証よりもかなり役立つことが証明されています。