過去二十年の大半において、インフラは動きの遅い土台であり、アプリケーションチームはおおむねそれを前提として扱うことができました。サーバーの調達には数週間を要し、需要に先んじて容量が確保され、ネットワークは専門チームが維持する固定的なトポロジーでした。ビジネスの変化の速度は、この体制が成り立つほどに緩やかでした。それはもはや成り立ちません。組織は今や、製品の変更を毎週リリースし、季節的なピークに向けてサービスを十倍に拡張し、現地のデータ所在地規則を満たす地域的な拠点を備えて新市場に参入することを期待します。これらの期待は、最終的にはすべてインフラ層に降りかかります。

同時に、環境は真の意味で多様なものになりました。規模を持つ企業でありながら単一の環境で稼働しているところは、ほとんど存在しません。パブリッククラウドがあり、それは買収や意図的な戦略を通じて複数のプロバイダーにまたがることが通常です。メインフレーム、専用アプライアンス、あるいはデータの重力といった制約によって残り続けたプライベート環境があり、それは消え去ってはいません。拠点や工場、デバイスからなる拡大するエッジがあります。興味深いアーキテクチャ上の問いは、もはやこれらの環境のいずれか一つの内部にあるのではなく、その継ぎ目のあいだにあります。ワークロードをどう配置するか、アイデンティティとネットワークの信頼を境界をまたいでどう成立させるか、そして分断を越えて一貫した運用モデルをどう維持するか、といった問いです。

これを単に重要というにとどまらず、喫緊のものとしているのは二つの力です。第一はコストです。クラウド支出は、テクノロジー予算のなかで最も大きく、最も理解されていない項目の一つになりました。節約として売り込まれた弾力性は、経済性の責任を誰も負わないとき、しばしば漏れへと転じます。第二は規制と、レジリエンスへの期待です。欧州の金融分野におけるDORAのようなフレームワークは、運用上のレジリエンスとサードパーティ集中リスクを、現実的な帰結を伴う取締役会レベルの義務へと変えました。いずれの力も、その性質はアーキテクチャ的なものです。どちらも、より優れた製品を購入することで解決するものではありません。それらは、テクノロジー基盤をどのように構築し、配置し、運用するかについて意図的な標準を持つことによって解決されます。それこそがまさに、この分野の任務です。

インフラアーキテクチャについて考えるうえで有用なのは、それを製品のカタログとしてではなく、それぞれが固有の保証を持つ複数のプレーンからなるスタックとして捉える方法です。最下層には基盤があります。物理的および仮想的なロケーション、クラウドのリージョンとアベイラビリティゾーン、オンプレミスのデータセンター、そしてそれらを結ぶ接続性です。その上にはコンピュート、ストレージ、ネットワークからなるリソースプレーンがあり、これはますますハードウェアではなく抽象として表現されるようになっています。さらにその上にはプラットフォームプレーンがあり、そこではそれらのリソースがランタイムへと組み立てられます。コンテナオーケストレーション、マネージドデータサービス、メッセージングと統合のファブリックです。ビジネスが関心を寄せるアプリケーションとサービスは、その上で稼働し、自らで組み立てる必要のない保証を消費します。

中核となる原理は、各プレーンがその上のプレーンに対して小さく安定した契約を提示し、その下にあるメカニズムを隠蔽すべきだということです。アプリケーションチームは、どのストレージ技術がそれを満たすかを知ることなく、明示された復旧目標を備えた、耐久性があり暗号化されバックアップされたデータストアを要求できるべきです。これこそが基盤を置換可能にするものです。契約が明示的であれば、実装は連鎖的な手戻りを引き起こすことなく変更できます。契約が暗黙的であれば、その下でなされたあらゆる選択が上へと漏れ出し、環境は硬直化します。

三つの横断的な関心事が、すべてのプレーンを縦に貫いており、後付けするのではなく最初から第一級のものとして扱うに値します。アイデンティティは真の境界です。ワークロード、人、サービスはいずれも、ネットワークトポロジーが意味を持つ前に、検証可能なアイデンティティを必要とします。オブザーバビリティは、自らが構築を見届けていないシステムについて推論することを可能にする性質であり、エージェントとして後付けするのではなく、テレメトリの契約として設計に組み込まれなければなりません。エコノミクスは、コストをそれを生じさせたものに帰属させる規律であり、それによって設計上の判断とその財務的な帰結が同じ人の目に見えるようになります。アイデンティティ、オブザーバビリティ、コストを後回しとして扱うテクノロジー基盤は、書類の上ではレジリエントでも、実際には脆いものになります。

最後に、ここでのすべては、チケットや暗黙知としてではなく、コードと参照パターンとして表現されるべきです。Infrastructure as codeはツールの好みではありません。それは、アーキテクチャをレビューし、バージョン管理し、テストし、再現できるものへと変える仕組みです。文書のなかにしか存在しない標準は、提案にすぎません。チームがインスタンス化する再利用可能なモジュールとしてコード化された標準こそが、アーキテクチャなのです。

いくつかの動きが、テクノロジー基盤の設計のあり方を作り変えつつあります。そこでは、持続的な変化を雑音から切り分けることが重要です。最も明確な持続的変化は、ハイブリッドおよびマルチクラウド環境が、移行の一段階ではなく定常状態として常態化していることです。業界は、すべてが最終的に単一のパブリッククラウドに帰着するという前提を過去のものとしました。ワークロードの配置は、データの重力、レイテンシ、主権、コストによって駆動される明示的な設計判断となり、そのことは、プロバイダーごとに別々の運用モデルを維持するのではなく、共通の運用モデルを通じて複数の環境を扱えるアーキテクチャの価値を高めます。

プラットフォームエンジニアリングは、その複雑さに対する組織としての応答です。あらゆるアプリケーションチームにインフラ層の全域を習得することを求めるのではなく、組織は舗装された道を提示する内部プラットフォームを構築しています。それは、セキュリティ、レジリエンス、コストの標準をすでに満たしたコンピュート、ストレージ、パイプライン、環境を入手するための、意見を持ったセルフサービス型の手段です。うまく行えば、これは先に述べたプレーンの契約が運用として体現されたものになります。まずく行えば、採用されないまま維持だけを要するもう一つの層になります。

主権と規制上のローカリティは、特に欧州において、例外的なケースから設計を駆動する要因へと移りました。データが物理的にどこに存在するか、どの法人がコントロールプレーンを運用するか、そしてワークロードを外国の司法管轄から隔離できるかという問いは、いまやリージョン戦略とプロバイダー選定を形づくる、真のアーキテクチャ上の制約です。これはレジリエンスの課題と交差します。単一プロバイダーへの集中は、組織が推論できなければならず、場合によっては積極的に緩和しなければならないものとして、ますます位置づけられています。

リソースプレーンでは、抽象化が上昇を続けています。サーバーレスとマネージドサービスは、運用上の負担のより多くをプロバイダーへと押しやります。それは魅力的ですが、抽象が漏れて、運用上の労苦をアーキテクチャ上のロックインと引き換えにしたと気づくまでのことです。機械学習と推論ワークロードによって駆動される専用コンピュートへの需要の近年の急増は、その両方を心地よく忘れていたチームに、ハードウェアの多様性と容量計画を再び持ち込みました。このすべてを一貫して流れる筋は、抽象化が根底にある関心事を決して取り除きはしない、ということです。それは責任を移し替えるのであり、優れたアーキテクチャは、その責任がどこに置かれるべきかについて意図的です。

レジリエントで、観測可能で、費用効果の高い基盤は、単一の巧妙な判断の産物ではありません。それは、一貫して適用される少数の原理から立ち現れます。第一の原理は、障害を想定される事態として設計することです。規模が大きくなれば、コンポーネントは絶えず故障します。有用な問いは、いかに障害を防ぐかではなく、いかにその影響範囲を限定するかです。これが意味するのは、明示的な障害ドメイン、それらをまたぐ冗長性、そしてワークロードごとに明示され、想定ではなく実際にテストされる復旧目標です。一度も実施されたことのない復旧計画は、能力ではなく仮説です。

第二の原理は、インフラは不変かつ再現可能であるべきだということです。サーバーとクラスターは、バージョン管理された定義から構築され、その場でパッチを当てるのではなく置き換えられるべきであり、それによって稼働中の環境が常に、検査可能な記述に対応するようにします。構成のドリフト、すなわちデプロイされていると思っているものと実際にデプロイされているものとの緩やかな乖離は、本番障害の不釣り合いに大きな割合の源であり、不変性はその構造的な治療法です。

第三の原理は、契約によるオブザーバビリティです。あらゆるサービスは、一貫した識別子で相関づけられた、定義済みの一連のシグナル、メトリクス、ログ、トレースを発信すべきであり、それによって事後に、慌てて計装することなく問いに答えられるようにします。目標は、予期していなかった振る舞いについて推論できることであり、これは既知の一定条件の集合を監視することよりも強い性質です。

第四は、最小権限とアイデンティティ中心の信頼です。分散した環境において、ネットワーク上の位置は信頼の弱い根拠です。アクセスは、境界がすでに越えられていることを前提としたセグメンテーションとともに、検証済みのワークロードとユーザーのアイデンティティに従うべきです。第五は、コストを意識した設計です。そこでは財務的な影響が、月次の驚きではなくアーキテクチャ上の判断の可視な属性となり、その選択を行うチームが帰結を目にできるほど明確に帰属されます。これらの原理をあわせると、最良の意味で退屈な基盤、すなわち予測可能で、検査可能で、ストレス下でも意外性のない基盤が好まれます。狙いは最大の高度化ではありません。それは、レジリエンス、オブザーバビリティ、経済性の目標を満たす、よく理解された最小限のパターンの集合を、例外なく適用することです。なぜなら、例外こそが次のインシデントが始まる場所だからです。

インフラアーキテクチャは、それとわかる仕方で失敗します。それらに名前を与えることが、最初の防御です。偶発的な複雑性が最も一般的です。環境は、それぞれがローカルには正当化されるプロバイダー、ツール、一回限りのパターンを積み重ね、ついには誰一人としてトポロジーを頭のなかに保持できなくなり、あらゆる変更が未知のリスクを伴うようになります。原因はたいてい、強制された参照集合の不在であり、そのため各チームが同じ問題を別々に解決してしまいます。治療法は、意図的に小さく保たれたパターンの標準ライブラリと、複雑さに見合わない追加を断る規律です。

再設計を伴わないリフト・アンド・シフトは、クラウドプログラムを失望に変える失敗です。ワークロードは固定容量の前提を保ったまま、そのまま弾力的な環境へと移され、組織はクラウドの便益なしにクラウドの価格設定を引き継ぎます。コストは上昇し、レジリエンスは改善せず、そして移行は失敗と判じられますが、実際に失敗したのは、アーキテクチャを設計しないという判断でした。

後付けとしてのオブザーバビリティは、そうでなくなるまでは静かな環境を生み出します。テレメトリはインシデントのたびに事後的に追加され、カバレッジは不均一で、シグナルは相関せず、そのため診断は、どこに死体が埋まっているかをたまたま知る少数の人々に依存します。そのようなシステムについてなされるレジリエンスの主張は、検証不能です。

静かなロックインは、離れようとして初めて可視化される失敗です。撤退コストを正直に見積もることなくプロバイダーの独自サービスを深く採用することは、正当な選択です。ただし、それが選択であった場合に限ります。集中リスク、価格支配力、規制上のエクスポージャーが、判断によってではなく既定として積み上がるとき、それは失敗になります。

コストのエントロピーは、誰も経済的に責任を負わない環境の、着実な漏れです。遊休リソース、過大なインスタンス、忘れ去られた環境、帰属されていない支出が積み上がるのは、スケールアップする弾力性が、スケールダウンするようには配線されていることがまれであり、そして誰も自らが生み出した請求を実感しないからです。最後に、一度もテストされたことのない、文書化されたフェイルオーバーによるレジリエンスの演劇は、まさに疑いを持つべきところで組織に自信を与えます。これらの失敗モードはいずれも、運用上のものではなくアーキテクチャ上のものです。それらは、欠陥のある構造のなかでより懸命に働くことによって修正されるものではありません。それらは構造によって防がれるものであり、いったん存在してしまえば、省略された標準を意図的に再導入することによってのみ取り除かれます。

Nashuaは、テクノロジー基盤を、まずアーキテクチャの問題として、次いでテクノロジー選定の問題として捉えます。エンゲージメントは、現状の環境の正直な評価から始まります。実際に何がどこで稼働しているか、ワークロードがクラウド、ハイブリッド、オンプレミスの環境にわたってどう配置されているか、レジリエンスとオブザーバビリティのギャップがどこにあるか、そしてコストが何に付随しているか、という評価です。これは、組織が信じていたよりもたいてい多様な、共有された像を生み出し、それは信頼に足るあらゆる目標設計にとって不可欠な基礎となります。私たちは、出発点が理解される前に到達点を規定したいという誘惑に抗います。

そこから私たちは組織とともに、目標とする参照アーキテクチャを定義します。すなわち、環境全体にわたって用いられる、コンピュート、ストレージ、ネットワーク、アイデンティティ、オブザーバビリティ、コストのための、小さな標準パターンの集合を、スライド資料ではなくコードと再利用可能なモジュールとして表現します。意図するのは置換可能性と一貫性です。チームは、基盤を作り直すことなく、舗装された道を通じて準拠したレジリエントな環境を入手できるべきであり、そしてアーキテクチャは、連鎖的な手戻りなしにプロバイダーやプラットフォームの変更を吸収できるべきです。プラットフォームエンジニアリングの能力が正当化される場合には、標準を最小抵抗の道とするセルフサービス層の設計と立ち上げを支援します。

私たちは、レジリエンス、オブザーバビリティ、エコノミクスを、意図ではなくエンジニアリングの成果物として扱います。それが意味するのは、ワークロードごとに定義されテストされる復旧目標、環境を診断可能にするテレメトリの契約、検証済みのアイデンティティに基づいて構築されるセグメンテーション、そして判断とその財務的な帰結が並んで可視化されるように配線されたコスト帰属です。全体を通じて、私たちは組織自身のエンジニアを迂回するのではなく、彼らとともに働きます。なぜなら、テクノロジー基盤は、それを運用する人々が理解し信じる標準と同じだけしか堅牢ではないからです。私たちの役割は、組織が自力で拡張し守れるアーキテクチャを、それを維持可能にする参照パターンと論拠とともに残すことです。それらは、エンゲージメントが終わったずっと後まで、その基盤を保守可能なものにします。

Nashuaがもたらす違いは、アーキテクチャの厳密さと運用上の現実との組み合わせです。多くの組織は、この文章にある原理を言葉にすることができます。しかし、環境全体、すなわちクラウド、ハイブリッド、オンプレミスを単一の一貫した設計として保持しながら、それを現実のものにするコンピュート、ストレージ、ネットワーク、プラットフォームの選択について具体的であり続けられる組織は、より少数です。取締役会レベルのレジリエンスと主権の義務から、あるチームが火曜日にインスタンス化する参照モジュールに至るまでの、その一貫性こそが、テクノロジー基盤が複利的に価値を積み上げるか、静かにリスクを蓄積するかの分かれ目です。

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

これがもたらすのは、変化とストレスのもとで予測可能に振る舞うテクノロジー基盤です。障害が設計によって限定されるがゆえにレジリエントであり、診断可能性が後付けではなく組み込まれているがゆえに観測可能であり、そして経済性が月次の清算ではなくあらゆる判断の属性であるがゆえに費用効果が高いのです。同じく重要なことに、それは組織が所有する基盤であり、組織自身の人々が理解し守ることのできるパターンとして表現されています。Nashuaの狙いは、自らを不可欠な存在にすることではありません。それは、偶発的ではなく意図的なテクノロジー基盤と、環境、規制、ワークロードが変化を続けるなかでもそれをそのように保ち続けられる、組織内部のアーキテクチャの実践を残すことです。