エンタープライズクラウドの現状は、広範な普及とばらつきのある成果によって特徴づけられます。今や規模を持つほぼすべての組織が、一つ以上のハイパースケーラー上で本番ワークロードを稼働させており、多くは方針としてクラウドファーストを宣言しています。はるかに稀なのは、それが置き換えたデータセンターとは異なる振る舞いをするクラウドです。インフラは原理上は伸縮自在でありながら、実際には静的で、一度手作業でプロビジョニングされたまま稼働し、めったに訪れないピークに合わせてサイジングされ、物理サーバーを統制していたのと同じ承認の連鎖を通じて変更されています。請求額は膨らむものの、俊敏性は伴いません。

これが今日重要である理由は、技術的というよりも商業的なものです。クラウド支出はIT予算の中で管理可能な項目のうち大きなものの一つとなり、財務部門が人員数を精査するのと同じように精査し始めるほどの規模に達しています。同時に、初期の移行の波は成熟し、早期に移行した組織は、単純なリフト・アンド・シフトが特有の負債を蓄積することに気づき始めています。すなわち、より安くもより堅牢でもなく、どのように構築されたのかを誰も安全に把握できないためにそれ以上の変更を拒むワークロードです。容易な移行は終わりました。残されているのは、うまく運用するというより困難な作業です。

能力の側面もあります。クラウドはインフラをソフトウェアとして表現できる組織に報い、それができない組織を罰します。なぜならプラットフォームは自動化を通常の経路として想定し、手動のコンソールを予備手段として扱うからです。ポータルをクリックしてプロビジョニングする組織は、スーパーコンピューターを書類棚として使っているのです。運用モデルを内在化した企業と、単に容量を賃借したにすぎない企業との差は広がりつつあり、それはリリース頻度に、インシデント復旧時間に、そして最も目に見える形で月々の請求書に表れます。クラウドを運用モデル、すなわちインフラがどのように要求され統治されるかについての首尾一貫した一連の実践として理解することが、以降のすべての前提条件となります。

運用モデルは、少数の恒久的な問いに答えます。誰がインフラを作成することを許され、どのような境界の内側でそれを行うのか。そのインフラへの変更はどのように提案され、レビューされ、適用されるのか。存在するものの記録は実際にどこに置かれるのか。誰が支払い、そのコストはそれを発生させる人々にどのように可視化されるのか。従来型の基盤では、これらの問いは手続きとハードウェアそのものの希少性によって答えられていました。クラウドでは、それらは明示的に答えられなければなりません。さもなければプラットフォームは、認証情報を持つ誰にでも、即座にかつ有償で、ほとんど何でも作成させてしまうからです。

第一の原理は、インフラは組み立てられるのではなく記述されるということです。システムの望ましい状態、そのネットワーク、そのアイデンティティ、その計算資源、そしてそのポリシーは、リポジトリ内のコードとして表現され、環境はその記述から導出されます。これは、稼働中のシステムが真実の源であり、ドキュメントが遅れて追随する近似であった旧来の関係を逆転させます。記述が権威を持つとき、環境は再現可能で、レビュー可能で、使い捨て可能なものとなります。手作業のプロビジョニングではいかなる代価を払っても提供できない三つの特性です。

第二の原理は、権限はゲートではなくガードレールを通じて委譲されるということです。中央のチームが各要求を承認する代わりに、プラットフォームがポリシーを通じて許容されるものを定義し、チームはその境界の内側で自由に活動します。ガードされた空間の内でのセルフサービスは、人間による承認では決して及ばない形でスケールします。第三の原理は、コストがレイテンシーやエラー率と同等の位置づけを持つ、第一級のエンジニアリング上のシグナルであるということです。なぜならクラウドでは、システムの設計とその運用の価格は、二度表現された同じ一つの意思決定だからです。自らの選択が何をコストとして生むかを見ることができないチームは、別の何かに向けて最適化してしまいます。

第四の原理は、責任は連合的に分散されるが標準は共通であるということです。アプリケーションチームは自らのワークロードとその支出を所有し、プラットフォーム機能は舗装された経路、ランディングゾーン、そして所有を安全にするガードレールを所有します。これがこのモデルの本質です。デリバリーを窒息させる中央集権化でもなく、乱立を生む無秩序でもなく、多くのチームがその上に構築する少数の強固な規約です。これらの原理を正しく押さえれば、個々の技術は交換可能になります。誤れば、いかなるツールもそれを埋め合わせません。

いくつかの発展が収束し、運用モデルは数年前よりもさらに具体的なものになりました。最も重大なのは、プラットフォームエンジニアリングがそれ自体一つの専門領域として確立したことです。すべてのアプリケーションチームがクラウドのプリミティブを深く隅々まで習得するのではなく、プラットフォームチームが舗装された経路を整備します。それは組織のセキュリティ、ネットワーク、コストの規約を体現した、方針を持ったセルフサービスのテンプレートであり、開発者は準拠した環境を組み立てるのではなく要求します。これは認知的負荷を減らし、さらに重要なことに、良い実践を最も抵抗の少ない経路にします。

ポリシー・アズ・コードは並行して成熟しました。かつては統治文書に書かれていたガードレールは、今ではプロビジョニングのパイプライン内で実行される機械的に強制されるルールとして表現され、ネットワークをパブリックインターネットに開いてしまう変更や、承認されていないリージョンへのデプロイを、それがアカウントに到達する前に拒否します。これは統治を左方へ移し、違反を事後に発見する監査から、変更の時点でそれを防ぐ統制へと変えます。FinOpsも同じ軌跡をたどり、財務が所有する月次の突合作業から、コストの異常が警告され、ショーバックとチャージバックが自動化され、適正化が年次の一掃ではなく運用の日常的な一部となる、継続的なエンジニアリングの実践へと移行しました。

マルチクラウドは、より率直な姿勢に落ち着きました。プロバイダー間を自由に漂うワークロードという野心は、おおむね現実的なパターンに道を譲りました。すなわち、プロバイダーをまたいで運用モデルとツールを標準化しつつ、各ワークロードを最もよく動く場所に配置し、各プラットフォーム固有の強みを活かす代わりにある程度のプロバイダー固有性を受け入れるというものです。これと並行して、インフラのツールも単一の宣言型言語を超えて広がり、オーケストレーター、構成システム、汎用プログラミングがますます組み合わせて使われるようになっています。ごく最近では、AIを活用した運用がツールチェーンに現れ始め、インフラコードの草案作成、ドリフトの要約、適正化の提案を行っていますが、これらは他の変更と同じレビューの規律を要する補助にとどまります。進む方向は一貫しています。運用モデルのより多くがコード化され、強制され、自動化され、個人の裁量に委ねられる部分がより少なくなっているのです。

ランディングゾーンは運用モデルのアーキテクチャ上の表現です。すなわち、ワークロードが配置される、あらかじめ構築され統治された基盤です。それはアカウントまたはサブスクリプションの構造、アイデンティティモデル、ネットワークトポロジー、ロギングと監視の基準、そしてポリシー群を確立し、その上に着地するあらゆるワークロードが、新たに作り直すのではなく既知の良好な姿勢を継承するようにします。ランディングゾーンにおける最も重要な設計上の意思決定はアカウント境界です。なぜならアカウントは、クラウドが提供する最も強力な分離とブラストラジアス（影響範囲）の制御だからです。環境を、そしてしばしば個別のアプリケーションを、それぞれ独自のアカウントに分離することは、設定ミスや侵害された認証情報の到達範囲を、アカウント内のいかなる権限設計も及ばない形で限定します。

Infrastructure as Codeは、ランディングゾーンとワークロードを再現可能にする仕組みです。重要な規律は、単にコードを書くことではなく、それをソフトウェアとして扱うことです。バージョン管理、ピアレビュー、適用前のプランの自動テスト、そして再利用可能なパターンを定義するモジュールと、それらを特定の環境に対して具現化する構成物との明確な分離です。ステート、すなわちコードが実際に何を構築したかの記録は、中央に保管され、同時変更に対してロックされ、データベースと同じくらい慎重に保護されなければなりません。なぜなら破損した、あるいは乖離したステートファイルは、クラウド運用における最も苦痛な復旧シナリオの一つだからです。

プロビジョニングは環境を記述し、オーケストレーションは時間をかけて多数の環境にわたる変更を調整します。オーケストレーションを安全にする設計原理はイミュータビリティです。稼働中のリソースをその場で変更するのではなく、記述から新しいバージョンを構築して古いものを置き換え、あらゆる環境が、文書化されない編集の蓄積ではなく、コードからの新鮮な導出物となるようにします。これは構成ドリフト、すなわちコードが述べていることと実際に動いているものとの間の緩やかな乖離を排除します。それは再現性を静かに殺すものです。パイプラインは、すべての環境に対して同じレビュー済み・自動化された経路を通じて変更を適用し、本番環境は別個の手作業によってではなく、ステージングを通じて同一の変更を昇格させることによって到達されます。これらすべてを貫く原理は、人間が意図を表現し、機械がそれを実現すべきだということです。手作業のプロビジョニングが招く即興を排し、一貫して、繰り返し可能な形で。

失敗のパターンは組織や業界を越えて見分けがつくものであり、そのほとんどはデータセンターの習慣を、それを罰する環境に持ち込んだことに帰着します。

負債をそのまま持ち越すリフト・アンド・シフト。仮想マシンを、どう構築されどうサイジングされているかを再考することなくそのまま移動させることは、既存のあらゆる問題を移設し、そこに新たな問題を加えます。すなわち、以前は埋没費用だった遊休容量に対する従量課金の請求です。ワークロードは今やより高価であり、能力は少しも増しておらず、何もコードとして表現されなかったために、以前と変わらず不透明なままです。スノーフレーク環境と構成ドリフト。インフラがコンソールで手作業により変更されると、環境は静かに乖離し、ステージングは本番に似なくなり、インシデントは再現不能になります。なぜなら、それが発生した正確な状態を誰も再構成できないからです。

設計されるのではなく発見されるコスト。支出が月次の請求書でのみ精査されるとき、組織は常に数週間前になされた意思決定に反応しています。タグの付いていないリソースは帰属を不可能にし、放置されたボリュームや遊休インスタンスが蓄積し、対応は継続的な規律ではなく周期的な緊急の間引きになります。ゲートによる統治。弱いガードレールを重い手作業の承認で補うことは、デリバリーを、チームがそれを迂回するほどまでに遅らせ、統制された経路の外にシャドーインフラをプロビジョニングさせ、まさにゲートが防ごうとしていた乱立を生み出します。過剰な権限を持つアイデンティティ。利便性のために付与された広範で恒常的な認証情報は、単一の侵害をIT基盤全体のインシデントに変えます。最小権限は実装が面倒ですが、省略すると高くつきます。

運用モデルなきツール。Infrastructure as Codeを技術として採用しながら、組織の意思決定権、所有権、標準を変えないままにしておくと、誤ったプロセスをより速く自動化するコードが生まれます。ツールは必要ですが、決して十分ではありません。これらのほとんどの根底にあるのは、単一の誤りです。すなわち、クラウドをインフラの運用のあり方の変化ではなく、容量の調達として扱うことです。苦労する組織は、才能や予算が不足していることはめったにありません。首尾一貫したモデルが不足しているのであり、プラットフォームは、与えられたモデルを、あるいはモデルの不在を、忠実に増幅するのです。

Nashuaは移行ではなく運用モデルから始めます。なぜなら、モデルが定まる前にワークロードを移動させることは、既存の無秩序を移設するだけだからです。最初のエンゲージメントは、IT基盤が実際にどう動いているかの評価です。どのワークロードが存在し、それらがどう結合され、いくらのコストがかかり、今日どのように変更され、真の制約がどこにあるのか。これは、何を近代化すべきか、何を穏当な労力でリプラットフォームできるか、何が本当に単純な移行に値するか、そして何を移動させるのではなく廃止すべきかについての率直な地図を生み出します。目指すのは、すべてを移動させよという一律の指示ではなく、証拠に根ざしたポートフォリオの意思決定です。

そこからNashuaは、ランディングゾーンを恒久的な基盤として設計し構築します。アカウント構造、アイデンティティモデル、ネットワークトポロジー、ロギングとポリシーの基準を、最初からコードとして表現し、基盤そのものが再現可能でレビュー可能となるようにします。ガードレールはプロビジョニングのパイプライン内で実行されるポリシーとして実装され、統治が事後に監査されるのではなく、変更の時点で自動的に強制されるようにします。次にワークロードは舗装された経路、すなわち組織のセキュリティとコストの規約を備えたセルフサービスのテンプレートの上に載せられ、チームがあらゆるプリミティブを習得する必要なく準拠したインフラをプロビジョニングできるようにします。

コストの規律は、後から加えるのではなく最初から組み込まれます。タグ付け標準、ショーバック、異常アラート、そして日常的な適正化がプラットフォームの一部として確立され、支出がそれを発生させるチームに可視化され、初日からエンジニアリング上のシグナルとして扱われるようにします。全体を通じてNashuaは、依存を生み出すのではなく能力を移転させるよう努めます。コード、規約、運用のランブックはクライアントのものであり、Nashuaのエンジニアは社内チームと並んで働き、運用モデルが組織が所有し拡張できるものになるようにします。クライアントがNashuaに継続的にプラットフォームを運用してほしいと望む場合、それは引き渡すのと同じ透明で、コード化され、統治されたモデルの内側で行われ、マネージド運用と自己運用が、異なる人員配置のもとでの同じ規律となるようにします。

Nashuaがもたらす違いは、クラウドを単なる設置場所として扱うことを拒む姿勢です。多くのプロバイダーが移行を実行できますが、運用モデルがまず定まっていること、ワークロードが到着する前にガードレールがコード化されていること、そしてコストが発見されるのではなく設計されていることを、あくまで求めるプロバイダーははるかに少ないのです。Nashuaの実務者たちは、最初のランディングゾーンから、ドリフト、乱立、コスト圧力が通常表面化する厄介な二年目、三年目まで、十分な数の基盤をそのライフサイクル全体を通じて運用してきたため、それらの年月を最初から見据えて設計します。その長期的な視点こそが、価値を複利的に積み上げるクラウドを、それが置き換えるはずだった高価なデータセンターへと静かに堕していくクラウドから隔てるものです。

実務上の当然の帰結もあり、それは作業が前提としてよいことを変えます。エンゲージメントがまだ存在しない能力を必要とするとき、それは調達サイクルやベンダーのロードマップを待つ必要はありません。enterprise platformは、エージェンティック・エンジニアリングを通じて、ほぼあらゆる機能をペースを保って受け入れられるように構築されています。必要なものを平易な言葉で記述して素早く生成しますが、常に確固たるアーキテクチャ原則の内側で、厳格な品質保証のもとで行われるため、速度が首尾一貫性、セキュリティ、統制を犠牲にすることは決してありません。その効果は単に便利であるというより戦略的です。それは自製か購入かの境界線を動かし、選択肢を安価に保ち、戦略が棚にたまたまあったものに屈するのではなく、アーキテクチャが戦略に従うことを可能にします。

エンゲージメントの後にクライアントが手にするのは依存ではなく能力です。すなわち、自ら読めるコードとして表現されているために理解できるランディングゾーン、自らの標準を強制するガードレール、エスカレーションなしにチームが使えるプロビジョニングの経路、そしてあらゆる選択を、それを統べる通貨で可視化するコストモデルです。Nashuaは自らの成功を、組織がNashuaなしに意図をもって運用できるかどうか、そしてIT基盤が、あらゆる近道を露呈させる成長のもとでも首尾一貫性を保つかどうかによって測ります。意図をもってクラウドで運用すること、すなわち意図をコードで表現し、組織が選んだ境界の内側で機械によって実現することが、この規律のすべてです。それはNashuaが構築の基準とするものであり、Nashuaが違いを生み出すために関与するものです。