ハイブリッドクラウドバーストはなぜ発生しなかったのでしょうか?

何年も前にハイブリッド クラウドについて議論されていたとき、クラウド バーストが大流行していました。しかし、今日では、それについて話す人はほとんどいません。

数年前、ハイブリッド クラウド バーストの概念は非常に魅力的でした。プライベート クラウドとパブリック クラウドの両方にワークロードを配置し、通常の運用中はそれらのワークロードをプライベート クラウドで実行し、プライベート クラウドのリソースが少ないときにパブリック クラウドにバーストできたらどれほどすばらしいことでしょうか。

しかし、2018 年にはハイブリッド クラウドがほとんど発生しませんでした。

[[223213]]

不在の理由はいくつか考えられますが、たとえば次のとおりです。

プライベートクラウドはもはや存在しません。一部の企業はパブリック クラウドを使用しており、プライベート クラウド企業もまだ存在していますが、大部分はパブリック クラウドが成長しています。企業が抜け出すにはプライベート クラウドが必要ですが、そのようなプライベート クラウドは多くありません。

ハイブリッド クラウド バーストが適切に機能するには、企業はプライベート クラウドとパブリック クラウドの両方でワークロードを維持する必要があります。通常、パブリック クラウドとプライベート クラウドは異なる機能とネイティブ API セットを提供するため、両方のクラウドにソフトウェアをローカライズするには時間がかかり、コストがかかり、リスクが増大します。

明らかなのは、ハイブリッド クラウドの概念が急速に拡大し、主に企業が最善のユース ケースを最大限に活用するために、テクノロジー スタック (クラウド) に過度の複雑さとコストが追加されているということです。

ハイブリッド クラウド バーストが機能しないということではありませんが、ほとんどの組織にとって実用的でも望ましくもありません。

それでも、クラウド バーストのコンセプトには、実際に使用されるものもあります。たとえば、パブリック クラウド (Stack) を模倣したプライベート クラウド プラットフォームを構築した Microsoft や、ミドルウェアを使用して従来のオンプレミス システムをパブリック クラウドに緩く結合することがバーストの最良の方法であると判断した企業などがその例です。

疎結合アプローチは、企業がオンプレミスのシステムをプライベート クラウドに置き換える必要がないため魅力的です。オンプレミスのワークロードを、処理の一部を引き受けることができるパブリック クラウドと簡単に組み合わせることができます。ユースケースとしては、データをパブリック クラウドに保存しながらオンプレミスで処理したり、その逆を行ったりすることなどが挙げられます。この場合、企業は同じワークロードを 2 つの異なる場所で実行するのではなく、機能ごとにワークロードを分離します。そのため、この方法は人気を集めています。