ブログ

継続的デプロイメントによるクラウドの混乱は続く

ロリ・マクヴィッティ サムネイル
ロリ・マクヴィッティ
2016 年 5 月 26 日公開

クラウドが初めて登場した当時、組織に激動の影響を及ぼすと予測した人は多くいました。 多くの人は、目に見える製品から本質的にほとんど一時的なものに移行するのは非常に難しいため、今後の混乱が従来のインフラ市場に与える影響の観点から見ていました。 それは事実ですが、インフラ市場がクラウドに目を向けたソフトウェアベースの視点に戻る(これは変革ではなく回帰であることに注意してください)につれて、困難な状況になってきました。

混乱は物理的な世界だけでなく、ビジネスの世界にも及ぶと指摘した専門家は少数だった。 アプリケーション (および API) 経済で成功するために必要なネットワークとインフラストラクチャを構築するためのクラウドと、よりソフトウェア指向のアプローチには、ビジネス モデルの転換も必要でした。 具体的には、ライセンスを含め、無数のネットワークおよびインフラストラクチャ コンポーネントがどのように管理されていたかです。

ご存知のとおり、単一のボックスのライセンス取得は (比較的) 簡単です。 ライセンスを購入して適用すれば、完了です! それはあなたのものです。 しかし、ソフトウェアはこれまで(本当にこれまで)それほど単純ではありませんでした。 皆さんの中には、2000 年代初頭に、長年使用してきたシングル CPU ライセンス モデルから、マルチ CPU、マルチコアの「新しい数学」でも簡単には解けない数学的悪夢へと必死に適応しようとした、あるソフトウェア大手による激しい論争を覚えている方もいるかもしれません。

同じことがクラウドでも起こりました。クラウドのユーティリティ課金モデルでは、仮想またはクラウドベースのハイパーバイザーに適合するようにコードを微調整するだけよりも、ソフトウェアに戻ることがはるかに困難になりました。

今では、すべてを「継続的」にするという概念を持つ DevOps が登場し、突然、ライセンスがネットワークおよびインフラストラクチャ市場が乗り越えなければならない大きなハードルとなっています。 問題となるのは、ネットワークおよびインフラストラクチャ サービスを突然プロビジョニングおよび構成しなければならない速度だけではなく、変化の速度です。 昔は、インフラストラクチャ コンポーネントを展開すると、そのままの場所に留まりました。 しかし現在では、多くのインフラストラクチャ コンポーネントを、場合によっては 1 日/週/月に何度もデプロイすることになります。 変更の頻度が増加し、その変更の要求が(必然的に)ネットワークに浸透しつつあります。 継続的インテグレーション (CI) と継続的デリバリー (CD) は、アプリの開発と運用の管轄範囲です。 しかし、継続的なデプロイメントには、ソフトウェア デプロイメントの全範囲にわたるコラボレーションが必要であり、これには運用も含まれます。

パイプラインの早い段階でのテスト (本番環境ではなく、テストや QA など) は、迅速なデプロイメントだけでなく、信頼性の高いデプロイメントを実現するためにも重要です。 ネットワークとインフラストラクチャのアーキテクチャの違いにより本番環境で問題が発生し、開発者の時間が浪費されることのないデプロイメント。

CD制作中

ライセンスに対する柔軟なソフトウェア主導のアプローチにより、その課題を軽減できるだけでなく、実稼働ネットワークの俊敏性を高める必要性も軽減できます。 ライセンスをプールし、一元的に管理し、API 呼び出しの容易さで配布できる手段を提供することで、組織は開発と本番環境を均等化できる (信頼性と一貫性にとって重要)だけでなく、ネットワークおよびインフラストラクチャ プラットフォームのソフトウェア バージョンを使用する際に本番環境でスケールアウトする必要性もサポートできます。

そのため、 BIG-IQ 5.0iWorkflow 2.0 はどちらも、何千もの BIG-IP インスタンスに対するアジャイル ライセンスをサポートしています。 ライセンスを管理する必要性(ただし、ライセンスされたインスタンスを管理する必要はない)は、開発と運用が実稼働前の展開フェーズの早い段階で統合およびテストできるようにするために非常に重要です。 BIG-IQ 5.0 は確かに BIG-IP の管理に重点を置いていますが、今日の DevOps によって構築されている、よりペースの速い、俊敏な開発環境をサポートする柔軟なモデルで、最大 5000 個の BIG-IP インスタンスのライセンスを管理することもできます。 アーキテクチャが進化し、負荷分散などのアプリ サービスが外部の「追加」エンティティではなくアーキテクチャの一部としてアプリ (およびマイクロサービス) とより密接に結合されるようになるため、これは特に重要です。 

クラウドに内在する運用面とビジネス モデル面の混乱は、今日でも依然として感じられます。 しかし、単に「コードを VM/コンテナに配置する」というアプローチだけでは不十分です。 また、クラウドによって導入され、おそらくは予見可能な将来にわたって「主流」となるように意図せずに推進されている、変化するビジネス モデルにも適応する必要があります。 F5 BIG-IP 5.0 と iWorkflow 2.0 は、「方法」に適合するように設計されており、組織が独自のデータ センター (物理データ センターか一時データ センターかに関係なく) にその基盤を導入すると、必要なアプリケーション サービスが迅速に提供されるようになります。