F5 は、プラットフォーム上で DevOps と Agile スタイルの開発に移行するにつれて、製品の出荷が成功の基準ではないという原則に一致しました。
今日、私たちはバーを取り除き、ライフサイクル全体、つまり作品を送り出し、構成員(F5 の内外の両方)の意見を聞き、その学習を開発にフィードバックすることに目を向けています。 当社では、お客様からのフィードバックを何よりも優先しており、特に実稼働環境で F5 を実行しているお客様からのフィードバックを重視しています。
私たちの目標は常に、より良い製品を構築し、不足している部分を補うことです。 しかし、高度な機能と使いやすさのバランスを見つけることも重要です。 当社は顧客に高度な機能を提供したいと考えていますが、エンド ユーザーは必ずしも当社が最初から協力しているシステム アーキテクトではないことも理解しています。
複雑な機能をより多くのユーザーに提供するために、私たちはチェーンを遡り、より豊富な新しい API を通じて構成を自動化します。 そして、それが今日の F5 Automation Toolchain につながります。
自動化ツールチェーンにより、私たちが実現できると考えていたことと、実現できる機能の限界を押し広げています。 その多くは API のエクスペリエンスに関係していることがわかり、それが宣言型モデルへの移行につながりました。
API のユーザー エクスペリエンスが重要なのはなぜですか? それが重要なのは、今日それを消費する人々がシステム アーキテクトではないからです。 彼らは、チェーンの 2 ~ 3 段階下にある開発者およびエンジニアです。
当社のお客様は、統合が容易で、専門家でなくても利用できるサービスを求めています。 つまり、API はもはや専門家を念頭に置いて後から設計されるものではなくなります。 私たちは API を非常に明確かつ簡潔に設計しているので、見ただけでインターフェースをどのように使用すべきかを簡単に推測できます。
API を宣言型または意図ベースにすることで、全体的なアプローチが変化します。 2 ページにわたる構成概要をユーザーに提供する代わりに、次のことをユーザーに尋ねます。 どのような結果を望んでいるか教えてください。
そして、私たちはこの自動化によって単純なものだけでなく複雑なサービスも利用できるようにします。 F5 プラットフォームのすべてのパワーはそのままに、複雑な機能を必要とするユーザーに簡単に提供できるようになりました。
さらに、自動化への道のりにおいて、すべての顧客が同じ段階にいるわけではないという事実もあります。 当社にはあらゆる分野のお客様がいらっしゃるため、 Automation Toolchainも、分割して個別に使用し、適切なタイミングで 1 つのユニットとしてまとめることができるコンポーネントのセットとして構築しました。
そのライフサイクルに沿って、自動化ツールチェーンのコンポーネントによってそれぞれ対処される個別のステップがあります。
これらはすべて、望ましい結果を記述するプラットフォームへの単一の API 呼び出しに基づいています。 F5 は、その状態に到達するために BIG-IP デバイスで実行する必要があるすべてのアクションへの呼び出しを処理し、完了した場合は「はい」、問題がある場合は「いいえ」で応答します。 これらはすべて、自動化システムの確立されたパターンと方法論に基づいて、非常に安定した方法で実行されます。
その結果、Automation Toolchain により、当社のプラットフォームとの統合に必要な労力がほとんど考える必要のないレベルまで削減されます。
F5 プラットフォームを将来どのように統合すべきかについての私たちの考えは、エコシステムにとって最も簡単に統合できるプラットフォームになりたいということです。 顧客やパートナーが当社のプラットフォーム用に記述する必要があるコード 1 行ごとに、当社はそのコード行のコストの 100 倍の機能性と使いやすさを実現したいと考えています。
結局のところ、単純なことをすることではありません。 非常に複雑なことを非常に簡単な方法で行うことです。 これが F5 Automation Toolchain が提供するものです。