クラウドの導入により、applicationsの展開方法、作業方法、そして IT 部門が「あらゆる障害を阻止する」という責任を果たす方法が変わります。 自動展開、テンプレート化されたサービス、セルフサービス ツールは、クラウド時代の IT 組織で働く際の新しい現実の一部です。
だからこそ、ほとんどの IT プロフェッショナルが生まれつき継続的な学習者であるというのは良いことです。 学ぶべき新しいツールやテクニックがあるだけでなく、対処すべきまったく新しい作業方法もあるからです。
運用チームが「ボタンを押す人」から「ボタンを作成する人」に移行すると、ボタンを作成するスキルと、どのようなボタンを作成するかを知る知識の両方を習得する必要があります。
長々と話すのはもう十分です。作成する必要があるボタンの種類について話しましょう。 簡単に答えると、自動化とセルフサービスの世界では、顧客がサービスの作成に必要な手順を知らなくても、必要なサービスを指定できる宣言型インターフェースを作成する必要があるということです。 これにより、開発者 (またはその他の要求者) は、インフラストラクチャの最終状態がどうあるべきかの表現を作成し、それを実現するためのツールと統合を利用できるようになります。 この単純な(?)目標の背後には、かなりの複雑さと、ネットワーク運用が変革し、実装者ではなくネットワーク自動化の専門家になるために適応することでクラウド環境にもたらす真の価値が隠れています。 宣言型インターフェイス(GUI、API エンドポイント、またはテキスト ファイルを取り込んでそこから完全に機能するインフラストラクチャを構築するシステム)の背後では、バックグラウンドで多くの命令型の作業が実行されています。 「カフェイン抜きの豆乳ラテにキャラメルソースをかけたラージサイズ」のリクエストの背後には、テキスト ファイルの 1 行の背後に、applicationに WAF 保護を組み込むための多くの手順 (前者の場合、バリスタが少し首を振る程度) があり、また、applicationを効果的に保護する構成を実現するために、途中で確認しながら、正しい順序で実行する必要がある API 呼び出しと実装手順が多数あります。
これがプログラマーに適した仕事のように思えるなら、それは正しいと同時に間違っている。 そうです。プログラミング スクリプトと API のスキルがいくらか必要になるからです。 それは間違いです。多くの人が考えていることとは裏腹に、ネットワーク運用チームのドメイン知識は、大規模な高品質applicationsを提供するために非常に重要だからです。 サポート可能で保守可能なインフラストラクチャを作成するための知識と経験は、導入の自動化モデルへの移行で失われるにはあまりにも重要です。
では、インターフェースはどのように作成すればよいのでしょうか? その一部は、組織全体の自動化戦略に依存します。 applicationスタックの残りの部分の展開方法や使用中のクラウド プラットフォームと一致しないツールを中心に自動化システムを構築しても意味がありません。 組織の展開ツールについて学習する計画を立ててください。まだ決まっていない場合は、少なくとも推奨事項を作成できる程度には理解を深めてください。 いくつかのコアな自動化概念を学び、インフラストラクチャの API 機能を調査することも、重要な基礎作業です。
完全な自動化はまだ将来のプロジェクトであるとしても、今できることは、最も一般的な展開や操作の標準化されたテンプレートを作成し、アクティビティの 80% に取り組むことです。 パラメータが何であるか、デプロイメントごとに何が変化する可能性があるか、何を固定しておく必要があるかを検討します。 たとえば、SSL 暗号スイートのようなものは通常は固定されており標準的ですが、使用される SSL 証明書は変化することがよくあります。 これらのテンプレートを構築すると、自動化実装の構成要素が作成され始めます。 コンポーネントの自動化を可能にするベンダー ツールや、コンポーネントを自動化ツールに統合するソフトウェア ライブラリがある場合は、評価版を入手してテストすることも良いスタートになります。
自動デプロイメントに加えて、容量計画やワークロード管理とともに、インフラストラクチャの自動ライフサイクル管理の計画も開始する必要があるかもしれません。 これらすべては、自動化においては少なくとも考慮する必要があります。
したがって、プライベート クラウドと自動化の取り組みを始めたばかりの場合でも、成功を確実にするために今すぐ実行できる手順はたくさんあります。 私たちのほとんどにとって、自動化はもうすぐやってきます。今こそ準備を整えるべき時です。