グローバルコラム| 「アウトサイドイン」アプローチによるクラウドアーキテクチャ

私が22か月間取り組んだクラウドアーキテクチャプロジェクトの最後の3週間は残っていました。 多数のクラウドコンピューティングリソースを定義する環境構成を定義および設計しました。 彼は、データベース、人工知能エンジン、アプリケーション開発プラットフォーム、DevOpsツールチェーン、クラウドOPSツール、およびセキュリティとガバナンスを設計しました。

しかし、今日、一部のデータベースは、アプリケーションで必要とされる情報を保存していないことがわかりました。 また、AIエンジンは選択したセキュリティソリューションでは機能せず、cloudopsツールは予算よりもはるかに高価です。 なぜそれが起こったのですか? それは建築家のせいですか?

Ⓒ銀行ゲッティイメージズ

クラウドソリューションの設計段階でこれらのエラーが見つかることがあります。 新しいシステムを構築する場合でも、従来のプラットフォームから移行する場合でも、問題はありません。 残念ながら、クラウドアーキテクトがエラーを最小限に抑えようとしても、同様の問題が常に発生します。

私を悩ませているのは、これらのエラーは実装フェーズが終了するまで発見されないことが多いということです。 ソリューションは機能しますが、根本的な問題はビジネスに悪影響を及ぼし続けます。 これは、これらのソリューションがますます最適化されていないためです。 運用コストが高くなり、会社のメリットが減少します。

たとえば、不正検出システムに電力を供給するために間違ったAIエンジンを選択したとします。 このシステムは、最適化された人工知能エンジンを使用して検出できる不正行為の約3分の1しか検出できません。 結局のところ、システムは不正を検出するので、誰も問題に気づきません。 しかし、後ろからの売り上げの減少により、出血は続いています。

クラウドコンピューティングソリューションがますます使用されるようになるにつれて、クラウドアーキテクトがビジネスに悪影響を与える大きな間違いを犯すことがよくあります。 誰も完璧にはなれません。 しかし、大小を問わず、一部のアーキテクトは、クラウドソリューションのエラーを最小限に抑えるために多大な努力を払っています。 これらの建築家は何をしていますか?

クラウドソリューションの構成と最適なアプローチの選択におけるエラーを100%確実に回避する方法はありません。 ただし、新しいアーキテクトと協力する場合は、最初に、内部または外部のアプローチからクラウドアーキテクチャにアプローチできることを強調します。 2つの方法には異なる利点があります。

インサイドアウトアプローチでは、ストレージ、処理、データベース、ネットワーキング、および運用という最も基本的な概念と技術コンポーネントからアーキテクチャを検討します。 そして、それはより詳細な要件を定義するために外側に拡張します。 これは、データベースモデルまたはパフォーマンス管理、プラットフォーム固有の要件、およびコンテナーやコンテナーオーケストレーションなどの実装テクノロジーを定義します。

つまり、インフラストラクチャなどの基本的な要素から始めて、特定のソリューション要件を拡張します。 全体的なテクノロジーの決定と環境構成が特定のビジネス要件をどのように満たすことができるかを考える必要があります。 これにより、ビジネスをサポートする具体的なソリューションが構築されます。

外部-内部アプローチは反対方向に機能します。 特定のビジネス要件から始めます。 たとえば、特定のソリューションやアプリケーションに適合するビジネスユースケースのようなものから始めます。 次に、インフラストラクチャやその他のテクノロジを含む、ソリューションとアプリケーションの要件をサポートするために必要なインフラストラクチャやその他のテクノロジについて詳しく説明します。

ほとんどのクラウドアーキテクトは、裏返しのアプローチを取ります。 ソリューションの特定の目的を真に理解する前に、インフラストラクチャを選択しています。 クラウドサービスプロバイダーまたはデータベースソリューションプロバイダーとパートナーシップを形成し、特定のビジネスソリューションの要件を満たしていることを前提として、他のインフラストラクチャ関連ソリューションを選択します。 つまり、狭いソリューションを選択する前に、広いソリューションを選択しているということです。

これは、機能するソリューションが作成される方法ですが、上記のすべての驚くべき問題を引き起こすソリューションはますます悪化し、さらに悪化します。 これらの問題を見つけるには時間がかかる可能性があり、通常、技術的な解決策をその場で削除および交換できるチームが必要です。 これらのチームは、必要なデータベースモデルをサポートするためにデータベースを追加する必要がある場合があります。このモデルは、主要なデータベース契約でライセンスの料金をすでに支払っている場合があります。 あるいは、AIと連携するためにセキュリティシステムを交換する必要があるかもしれません。 ほんの数年前にテストして実装するのに50万ドルかかるシステムかもしれません。 私は経験から、多くの企業が現在これを行っていることを知っています。

企業は、最初に既存の仮定に基づいて基盤となるテクノロジーを選択し、次に既存のアプリケーションポートフォリオのニーズを検討する必要があると主張する人もいます。 企業がハードウェアとソフトウェアを購入していた頃はもっと安かったかもしれませんが、現在はクラウドベースのリソースを使用しています。 その仮定はもはや真実ではありません。

企業は、特定のアプリケーションとソリューションの要件を、完全に最適化されたインフラストラクチャオプションに移動して、それらのアプリケーションとソリューションをサポートできるようになりました。 また、各アプリケーションに最適なデータベース、またはセキュリティ、ガバナンス、運用を含む独自のインフラストラクチャを実装することもできます。

このような環境の利点は、特定のビジネス上の課題に最適に対処するために選択および構成できるサポートテクノロジーのインフラストラクチャを確立することです。 アプリケーションに過去のテクノロジーの決定に適応させる必要はなくなりました。 このため、クラウドアーキテクチャを設計するには、アウトサイドインアプローチの方が適しています。 これは、クラウドの力を適切に利用するための1つの方法だからです。
editor@itworld.co.kr

Toyama Jiro

「テレビオタク。情熱的な料理のスペシャリスト。旅行の専門家。ウェブの第一人者。筋金入りのゾンビ好き。謝罪のない音楽狂信者。」

コメントを残す

メールアドレスが公開されることはありません。