業務の商品化

昔は、自動車のトランスミッションは手動でした。 ギアをシフトする機構のおかげで、これを「スティック」と呼ぶ人もいるかもしれません。 当時、オートマチックトランスミッションは特別なものであり、注文しなければならないことが多かった。 その名前は、車が自動的にギアをシフトする方法に由来しています。 正直に言うと、それはちょっといいことだ。 結局のところ、手動でギアをシフトしようとするときには、管理すべき変数がたくさんあります。 

今日では、オートマチックトランスミッションが標準です。 マニュアルはほとんどの人にとって謎です。 私は上の3人の子供たちにそれぞれ車の運転の仕方を教えようとしました。 もし検討中であれば、試してみることはお勧めしません。 あなたの車のトランスミッションが正常に機能していることを望むなら、そうではありません。 

運用に関する議論の前提として、この期待と基準の変化について言及します。 主にネットワークとアプリケーション サービスのインフラストラクチャに関するものですが、それらの領域外にも当てはまります。 

運用上の期待 

確かに、自動化へのシフトは進んでいますが、それはインフラストラクチャの運用に必要な知識に関する期待の変化でもあります。 

トランスミッションの例えに戻ると、マニュアルトランスミッションを運転している場合、管理すべき変数がたくさんあります。 クラッチとアクセルを調整する必要があります。 エンジンの音を聞いて、いつギアを変えるべきかを認識する必要があります。 また、現在どのギアに入っているか、どのギアに移動するか、そしてそこに到達するために「スティック」をどのように動かすかを知っておく必要があります。 

これらは、ネットワークおよびアプリケーション サービス インフラストラクチャを手動で展開するために必要な種類の知識を反映しています。 トラフィックが確実にある場所から別の場所に到達するためには、ネットワークの動作について詳しく知っておく必要があります。 

クラウドの導入により、この「標準」からの期待が変わり始めました。 いくつかの基本的なネットワーク概念を理解する必要はありますが、必ずしもその仕組みを理解する必要はありません。 コンテナの導入により、期待はさらに右に移動し、IP アドレスについて考える必要はほとんどまたはまったくなくなりました。 

これにより、運用上の期待が変化します。 私たちは、専門家による運用経済から商品化された運用経済へと移行しています。 今日では、ネットワークおよびアプリケーション サービス インフラストラクチャの展開の運用面は、組織内のより広範な役割にアクセスできるようになることが期待されています。 そこに到達するには、簡素化が必要です。 

具体的には、業務の簡素化です。 ネットワークおよびアプリケーション サービスをセルフサービス オプションで提供するだけでは十分ではなく、それらを利用するユーザーが使用できるものでなければなりません。 今よりもさらにシンプルにする必要があります。 

つまり、操作性を優先して構成可能性を犠牲にする必要があることになります。 

設定可能性と操作性 

クラウドやコンテナと同様に、ネットワークおよびアプリケーション サービス インフラストラクチャ上に構築された抽象化は、それらの抽象化の使用にまで拡張されます。 つまり、俗語のことです。 用語。 データ モデル。 実際の構成。 

プログラマー以外の読者にとって、私が言いたいのは、各構成要素には「オブジェクト」を構成する一連の属性が関連付けられているということです。 仮想サーバー オブジェクトには、IP アドレス、アプリケーションのプール、イベント、名前、その他さまざまな特性があります。 これらの特性の一部は、実際にはオブジェクト、またはオブジェクトのリストです。 これらの構造を走査することは複雑になる可能性があります。 インフラストラクチャを微調整する際には、構成可能性が不可欠だからです。 パフォーマンスや容量を最適化するために、Nagle アルゴリズムを切り替えたり、TCP ウィンドウ サイズを変更したりするなど、非常に具体的な特性を微調整する機能が必要です。 

現在、私たちが向かっているコモディティ化された運用モデルでは、構成可能性よりも操作性が重要です。 オプションが少ないほど、稼働時間が速くなります。 

しかし、これは単に選択肢をなくすという意味ではありません。 オプションを微調整する機能を排除するだけでは、操作性の基本要件を満たすだけで、簡素化された操作エクスペリエンスの期待には応えられません。 オブジェクト モデルを理解する必要があります。 必要なのは、モデルをより単純なものに抽象化することです。 たとえば、仮想サーバーを IP アドレス、名前、およびアプリケーション インスタンスのリストに縮小します。 

商品化には標準化が必要

アプリケーション サービス インフラストラクチャが動作する共通モデルが存在しないため、これは重要な取り組みとなります。 仮想サーバー、イングレス制御、セキュリティ ポリシーの表現方法は、製品やサービスによって異なります。 

開発側であれ IT 側であれ、運用担当者は、アプリの配信とセキュリティ保護に使用される平均 14 個のアプリケーション サービスを展開および運用するために、事実上、多数のモデルを理解する必要があります。 多様性に富んでいるため、過去にはこれらのサービスの管理に必要な専門知識を証明するために無数の証明書が必要になりました。 

もう一つの運用上の変化は、このアプローチからの脱却です。 デバイス固有の運用モデルによって生じる技術的負債を軽減する方法として、シンプルさ、使いやすさ、および製品全体の共通性が期待されます。 これは標準化に対する期待であり、ネットワーク インフラストラクチャ領域にすでに存在するプロトコルやネットワーク動作に基づくものではありません。 しかし、それらのプロトコルとネットワークの動作をどのように表現するかが問題です。

このことはコンテナ化に関する調査でも明らかで、回答者のほぼ 4 人に 1 人 (24%) が必要なスキルを採用の大きな阻害要因として挙げており、33% は中程度の阻害要因であると回答しています。 インフラストラクチャ (今日の運用環境でのコンテナとコンテナ オーケストレーション システムが普及していることを考えると、インフラストラクチャにはコンテナとコンテナ オーケストレーション システムも確実に含まれる) は、スキル不足と、コモディティ化された運用へのスピードへの欲求によって推進されています。 

その要望とニーズは、インフラストラクチャ サービスを記述しようとする Kubernetes リソース ファイルの有機的な採用に表れています。 これらのリソースは、特定のサービスの展開と構成を記述するための共通の（商品化された）データ モデル（形式）の使用をすべてのオペレーションに強制します。 IT 運用は、今日の組織におけるコンテナ導入の最大の推進力 (35%) であり ( Diamanti の 2019 年コンテナ導入調査による)、開発者 (16%) のほぼ 2 倍、統合 DevOps チーム (9%) の 4 倍の影響力があるため、この変化を認識し、新しいインフラストラクチャがコモディティ化された運用環境にどのように適合するか (または適合しないか) を慎重に検討することが重要です。 

公式（作業グループまたは財団）の取り組みの有無にかかわらず、商品化によって事実上の標準が運用に導入されることになります。 そして、その事実上の標準は、構成可能性よりも操作性を重視するものになるでしょう。