プライベート クラウドには異なる考え方が必要

クラウドは何も変えません。 クラウドはすべてを変えます。 プライベート クラウドは、どちらも実行しません。

はい、禅についてはこれで十分です。 実のところ、どのような種類のプライベート クラウドで実行されるapplicationsでも、セキュリティ、負荷分散、高可用性、最適化など、従来ネットワークが提供してきた重要なapplication配信サービスが必要です。 マイクロサービスやコンテナプラットフォームなどの新しいアーキテクチャでも、applicationsの稼働を維持するために使い慣れた方法が使用されます。 最新の言語や開発手法も、アクセス制御や Webapplicationファイアウォールなどのセキュリティ ツールでバックアップする必要があります。 このままでは何も変わりません。

それで、何ですか?

ほとんどの組織にとって、プライベート クラウドによって変わるのは、展開する内容ではなく、展開方法、そしてさらに重要なことに、展開の速さです。 プライベート クラウドの実装が成功すると、セルフサービス IT が提供され、社内顧客が自動化とインフラストラクチャ アズ コードを使用して、非常に動的で運用効率の高いapplication環境を作成できるようになります。 新しいサービスやapplicationsがより効率的に開発され提供されるにつれて、コードやインフラストラクチャの変更の頻度は加速します。 「価値実現までの時間」を短縮する要因の多くは文化的および組織的なものです。しかし、インフラストラクチャが障害になってはなりません。 リクエストから実装まで、人的遅延が発生する時間はありません。 インフラストラクチャがボトルネックにならない場合、自動化ツールが IT サービス提供の大部分を制御することになります。  

変更が手動で要求、確認、実装されるチケットベースの従来の組織から移行する場合、この移行によって日常業務が大きく変わります。 IT は、実装重視からフレームワークの設計とエンドツーエンドのサービス自動化へと移行します。 application開発者やapplication運用 (「DevOps」と言ってもいいでしょうか) が、スタックの残りの部分と同じ方法でネットワークおよびapplication配信サービスをプロビジョニングできるようにする方法を考えることは、プライベート クラウド プラットフォームを展開する上で中心となる必要があります。 同僚からフレーズを盗む: IT 運用は、ボタンを押す人からボタンを作成する人へと移行する必要があります。

哲学的なレベルでは（結局のところ、この記事はそこから始まりました）、根本的に変わるのは、IT 運用がインフラストラクチャを制御する方法です。 考えてみてください。インフラストラクチャに変更を加えるためのチケット システムと運用チームが存在した理由の 1 つは、ドメインの専門家だけが変更を加えることで、エラーや誤った構成を防ぐためでした。 IT 運用担当者はすべてのボタンにアクセスでき、要求された変更を実行するためにどのボタンを押せばよいかを把握しており、その過程で他のものが壊れないようにすることも期待できました。 今では誰もが自分でボタンを押したり、ソフトウェアにそれを実行させたりしたいと考えています。 操作によって作成される論理ボタンは、安全に押せるようにする必要があります。 ここで、オペレーションが制御を及ぼします。 要求者が何を望んでいるかだけを知り、それをどのように行うかは知らなくてもよいテンプレート化された自動化システムを作成し、選択肢を安全でサポート可能な構成に限定することで、IT 部門は顧客に自由を与えながらインフラストラクチャの制御を維持できます。

こうした変化は技術的にも文化的にも困難を伴うかもしれませんが、その結果得られる生産性と俊敏性の向上は、そこに至るまでの困難を正当化するほど大きなものです。