ブログ

ソフトウェアは依然として IT を食い尽くしている: 次のコースはapplicationサービス

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

2015 年に、私は「ソフトウェアが IT を飲み込んでいる」と指摘しました。 これは、RightScale、HBR、PWC など、さまざまな業界のソースから収集されたデータに基づいています。 開発から展開、配信まで、あらゆるところでソフトウェアが利用されるようになりました。

しかし、当時でも、制作側におけるネットワークへのソフトウェアの侵入は最小限にとどまっていました。 ああ、兆候はありましたし、必要なツールや API も多数ありました。 しかし、パイプラインの幅広さが豪華な食事だとしたら、開発はメインコースであり、展開と配信は単なるデザートに過ぎません。

それは昔のこと、これは今です。 そして、現在では、デプロイメントと配信がapplicationパイプライン メニューの 3 つの主要コースの 1 つになっています。

データですか? 過去 2 年間の F5 の調査から抜粋。 デジタル トランスフォーメーションは、こうした自動化と変化の原動力として注目されていますが、パブリック クラウド全般の破壊的な影響を見逃してはなりません。

ソフトウェアが有利になったことの功績が誰にあるのか(あるいは誰が責任を負うのか?)に関係なく、ソフトウェアが依然としてIT を食い尽くしていることはほぼ議論の余地がありません。

発達

applicationパイプラインの開発セグメントは常にソフトウェアによって推進されてきました。 さまざまなライブラリと実行可能ファイルを構築するためにソフトウェアを使用しました。 Git が登場したり、CI/CD が一般的な用語になるずっと前から、私たちはソフトウェアを使用してコードのバージョンを保存していました。

必ずしも自動化されていなかったのは、開発セグメント全体です。 自動テスト、構成管理、イベント駆動型ビルド システムは、今日ほど一般的ではありませんでした。

クラウドと DevOps のおかげで、applicationパイプラインの開発セグメントは、主に「ソフトウェアを構築するソフトウェア」の取り組みになりました。

展開

クラウドと DevOps は、デプロイメント セグメントにおけるさらなる自動化の必要性を推進していることで再び高く評価されています。 この「本番環境の壁の反対側」セグメントは、ビルドとテストのプロセスを自動化するだけでなく、アプリ インフラストラクチャの展開も自動化する運用担当者が中心となっています。 これは実際には問題ではありませんでした。 問題は「パイプラインの残りの部分」でした。 アプリの拡張、セキュリティ保護、高速化に必要なapplicationサービス用のプラットフォームを提供するネットワーク インフラストラクチャで構成されたパイプラインの一部。

applicationパイプラインのこのセグメントは、現在、ネットワークの自動化に使用されるツール、テクニック、方法論に影響を与えてきた (そして影響を与え続けている) DevOps の動きに賛同して、NetOps と呼ばれる知識豊富なネットワーク エンジニアのグループの増加により、自動化が爆発的に増加しています。

ネットワーク運用における自動化の使用と重要性の点では、過去 3 年間で大きな進歩が見られました。 applicationパイプラインのデプロイメント セグメントは、「ソフトウェアをデプロイするソフトウェア」の取り組みになりつつあります。

配達

applicationパイプラインの配信セグメントは、最も混乱を招くものとなることが予想されます。 その理由の 1 つは、20 年間にわたって、ネットワークにおける私たちの主な頼みの綱が光沢のある鉄の箱だったからです。 全体的に、拡張性があり、容量があり、ソフトウェアよりも高速です。 しかし、マルチクラウド組織の必然性と、最も重要なエンタープライズapplicationsにもパブリック クラウドがオプションとして採用されるようになったことで、ゲームのルールは変わりました。

ハードウェアはクラウドに移行しません。 ハードウェアは、配信に不変のインフラストラクチャ・アズ・コード・アプローチを採用するために必要な、アプリごとのアーキテクチャをサポートするのに実際は適切なプラットフォームではありません。 ソフトウェアはクラウドに移行します。 ソフトウェアは、アプリごと、不変性、およびインフラストラクチャをコードとしてサポートします。

問題は、実際にはハードウェアかソフトウェアかということではありません (アプリごとのクラウド アーキテクチャの場合、答えは明らかにソフトウェアです)。コンテナか仮想ソフトウェアかという問題です。 コンテナがデータセンターやクラウドを急速に利用し始めており、コンテナで提供されるapplicationサービスの需要が 2 倍に増加しています。 公平を期すために言うと、この倍増は 2017 年の約 4% から 2018 年の 9% への増加ですが、それでも、採用率が 1 桁かどうかにかかわらず、かなり大きな増加です。

また、仮想ソフトウェアの需要が大幅に高まり、ハードウェアの好みは年々低下しています。 さて、それがいつかゼロになると考えているのであれば、そもそもなぜソフトウェアからハードウェアに移行したのか(はい、私たちは以前にもこの道を歩んできました)と、企業内の配信セグメントの一部(コア、共有ネットワーク)が今後も大部分がハードウェアであり続ける可能性が高い理由を本当に理解していないことになります。

しかし、配信セグメントの大部分はソフトウェアになります。 すでにそうです。 しばらく経ちました。 これは、パブリック クラウドへの移行の摩擦を軽減し、従来の展開スケジュールと需要主導のアプリ配信スケジュールの増大する摩擦に対処する唯一の方法です。 コンテナと仮想ソフトウェアは、オンプレミスとパブリック クラウドの両方で、application配信セグメントの少なくとも 3 分の 2 を占めることになります。

配信セグメントは、「ソフトウェアを配信し、保護するソフトウェアを配信するソフトウェア」の取り組みになりつつあります。

それは、ソフトウェアが依然としてIT を食い尽くしており、今後も当面その状態が続くからです。

 

*あなたの家族が主に開発者で構成されている場合(私の家族もそうです)、CI/CD は一般的な用語です。 人によって違います。