Kubernetes アプリケーション向けアプリケーション サービス: 同じ古い新しい
VMS VAX のトラブルシューティングからサーバーレス マイクロサービスの作成までには長い道のりがあります (ただし、re:Invent でのAWS Lambdaでの COBOL サポートの発表により、ITレムニスケートの最初のラップは完了するかもしれません)。
途中で多くのことが変化しました。 Perl でスクリプトをハックすることができて、存在しない場所にディレクトリを変更できるオペレーティング システム (おまけに、その場所にたどり着いたらディレクトリを作成できる) にイライラしていたことを覚えているような気がします。 今では、実際に問題を解決するのと同じくらい、問題を解決するためのアプローチを決定するのに多くの時間を費やすことができるようです。 そしてこれは素晴らしいです。 さまざまなアーキテクチャ、開発のペース、デジタル化の機会、そして新しいおもちゃが私たちに与えてくれる開発者の創造性の解放は素晴らしいものです。 プロセニアム アーチのどちら側にいるかは関係ありません。開発者と消費者の両方が、それほど昔には SF の世界の産物だった速度と機能で、新しくて優れたアプリを楽しんでいます。
コンテナとそれを監視している Kubernetes マインダーは適切な例です。 コンテナ テクノロジーは、間違いなくアプリケーション開発の爆発的な増加を促進する重要な要因となっています。
今週、晴天のシアトルでは（本稿執筆日の午前 10 時 46 分現在 [更新 – 午後 1 時 36 分現在も晴れ]）、8,000 人を超える人々が集まり、Kubernetes やその他のオープンソース関連テクノロジーについて話し合い、耳を傾け、学んでいます。 会話、実践的な学習、刺激のミックスは、イノベーションの原始的なスープです。 これを読んでいる間にも、12 個の素晴らしい新しいアイデア (および 37 個のひどいアイデア) が思い浮かぶでしょう。
これらのアプリの中には、人々の生活を変えるもの、建築に革新をもたらすもの、ユーザー インターフェイスを進化させるもの、そしておそらく、若者文化から自分がいかに切り離されているかを示す単なる別の方法となるものもあるでしょう。
しかし、いくつかのニーズによって、これらの多様なアプリケーションとそれらが使用するフレームワークが統合されます。 解決策はそれぞれ異なるように見えるかもしれませんが、誰もが解決する必要がある重要な要素があります。
規模– 大きくするつもりなら、途中で（そしておそらく時々再び）大きくなれる必要があります。
安定性- すべてのアプリには、ステージ上のデモを問題なくこなすことから生命を脅かす稼働時間要件まで、適切なレベルの安定性が必要です。
セキュリティ– 悪意のある人が存在し、アプリケーションを攻撃することがあります。 現代のシステムの複雑さにより、心配しなければならない攻撃対象領域が絶えず拡大しているようです。
観察可能性– 百聞は一見に如かず、これは問題がある場合、さらに重要です。 OSI レイヤーから適切な情報を適切な人に素早く届けることで、障害を減らし、回復を迅速化し、「自分で構築し、自分で実行する」世界をより快適にすることができます。
これらのニーズはそれほど独特なものではありませんが、理想的には問題になる前、そしてコードが 1 行も書かれる前に、適切に設計されたすべてのアプリで対処する必要がある基本的な懸念事項です。
私の尊敬する雇用主であるF5 Networks は、こうしたニーズを満たす数十億ドル規模のビジネスを構築しており、正直に言って、私たちはその点でかなり優れています (ただし、これは私の意見です)。 こうしたニーズを満たすために私たちが作っているものをアプリケーション サービスと呼んでいます。 アプリケーション トラフィックを保護し、検査し、誘導するアプリケーション サービス。 クライアントを適切な場所にルーティングするアプリケーション サービス、主要なアプリケーション テレメトリを抽出、転送、表示するアプリケーション サービス。 これらは、お客様のアプリケーションを稼働させ続けるための中核的なサービスであり、アプリケーションがどこでどのように作成されたかに関係なく、アプリケーションが引き続き必要とする種類のサービスです。
ベンダーの売り込みに戻りますか?
これまでのところ、それは「自分の古い技術がまだ有効であると私を説得しようとしている無愛想な老人」です。 さて、これがひっくり返って、空中でねじれ、逆さまに着地した物です。 まずは最も重要なところから始めましょう: サービスの展開方法。
プラットフォームと業務慣行の採用を支える技術の 1 つは、意図と行動を自動化された統合的な方法で結び付けるシステムです。 アプリケーション サービスはこのチェーンの一部である必要があり、これは単なるランタイムの変更よりも根本的な変化を表しています。
場合によっては、 Aspen Mesh がIstioに追加する優れた可視性と制御のように、既存のコンポーネントにサービスを挿入する必要があります。 あるいは、 F5 Container Connectorなどの接続ツールを使用すると、環境をサービスにリンクできるため、Kubernetes ポッドが追加または削除されたときに、それらを保護、スケーリング、および監視できます。
理想的には、アプリケーション サービスを作成するコードは、そのアプリケーションのコードと同じリポジトリに存在し、同じ方法でデプロイされる必要があります。 アプリケーション サービス定義 (Web アプリケーション ファイアウォール サービスなど) はコードとして存在し、コードとして扱われる必要があります。これにより、ソース コード管理でサービス定義を変更してコミットすると、人による入力なしで実稼働の Web アプリケーション ファイアウォール展開が生成されます。 最新ニュースでは、Airbnb の早口なMelaine Cebula 氏が、 Kubeconでの水曜日の基調講演で、まさにそのモデルについて説明しました。彼女は、インフラストラクチャ定義を含むサービスのすべてのコンポーネントを単一のプロジェクトに保持する (さらに、アプリ開発者の作業を楽にするために彼らが行っている約 50 のその他の優れた機能) と説明しました。
サービスのインスタンス化におけるこの変化は（長い IT チケット キューの解消という嬉しい結果と相まって）劇的で明白です。
2 番目の変更は、おそらくもう少し平凡ですが、それでも重要です。 Kubernetes とコンテナの利点の 1 つは、環境間の移植性です。 Kubernetes で管理されるマイクロサービスは、サポートされているコンテナ エンジンが実行される場所であればどこでも (ヒント: どこでも) 実行され、同じアプリ サービスもそこに存在するはずです。ただし、「ほぼ同じ」や「わずかに異なるインターフェースで異なる方法で同じことを実行する」ということはありません。 同じ。 つまり、展開する必要がある場所の数は増え続けています。
現在および将来のすべての Kubernetes デプロイメントと同じ方法、同じ場所で作業する必要性は、F5 の指針となっています。
これは極めて重要です。なぜなら、お客様は、既存のアプリの拡張性と安全性の維持を当社に依頼するだけでなく、この記事の執筆時点では、昼食後の活力を必要とする幸運なアデノシン受容体に結合する不正なカフェイン分子として考えられているアプリを当社が保護し、監視していることを知る必要があるからです。