Infrastructure as Code と Platform as Code とは何ですか?読めば明らかになる

Infrastructure as Code (IaC) を使用すると、インフラストラクチャのコンピューティング、ストレージ、およびネットワークの要件の宣言的な記述を記述し、その宣言を実行できます。これは Platform as Code (PaC) とどう違うのでしょうか?

あらゆるアプリケーションのテクノロジー スタックは、ベアメタル インスタンス、仮想マシン、ネットワーク、ファイアウォール、セキュリティなどを含む基盤レイヤーの 3 つのレイヤーに分かれています。オペレーティングシステム、ランタイム環境、開発ツールなどを備えたプラットフォーム層。そしてもちろん、アプリケーション コードとデータを含むアプリケーション層もあります。一般的な技術運用チームは、コードのデプロイに加えて、インフラストラクチャ層とプラットフォーム層のデプロイ、監視、管理タスクも担当します。

クラウド コンピューティングの登場により、まず基本レイヤーを抽象化できるようになりました。 Infrastructure as a Service (IaaS) モデルを使用すると、IT/Ops チームはクラウドを通じて簡単にクラウド インフラストラクチャを即座にプロビジョニングできます。 AWS、Microsoft Azure、Google GCE、Alibaba Cloud などはすべて、AWS EC2 などの幅広い IaaS サービスを提供しています。その上にプラットフォーム・アズ・ア・サービス (PaaS) モデルがあります。インフラプロバイダーは、クラウドオペレーティングシステム、開発ツール、データベース管理など、クラウド上のプラットフォーム層を提供します。例えば、皆さんがよくご存知のAWS Beanstalk、Azure CDN、Google App EngineなどのPaaSサービスも非常に人気があります。

実際には、運用チームも PaaS プラットフォームを独自に構築し、選択した機能のサブセットを、既存のインフラストラクチャと互換性のあるものやカスタム ワークフローを持つものに統合します。コンテナ化またはマイクロサービスパラダイムを使用する場合、これは面倒で扱いにくいものになる可能性があります。

マイクロサービス ベースのアプリケーションを構築するには、スケール、一貫性、再現性、共有性、監査可能性が求められるため、運用チームはインフラストラクチャ層とプラットフォーム層を処理するための新しいアプローチを検討する必要があります。こうした懸念に応えて、Infrastructure as Code (IaC) と Platform as Code (PaC) の概念が登場しました。

インフラストラクチャ・アズ・コード

Infrastructure as Code は、物理的なハードウェア構成やその他のツールではなく、ソフトウェアを通じてインフラストラクチャを管理および構成します。 IaC を使用すると、インフラストラクチャのコンピューティング、ストレージ、ネットワークの要件に関する宣言型の命令を記述して実行できます。その後、自動化エンジン (AWS Cloud Formation や Terraform などのツール) が、抽象化された IaaS API を通じて宣言/コードをキャプチャして構成します。

その結果、配信パイプラインの自然な一部として、または特定のイベントに応じて自動的に拡張されて、インフラストラクチャのプロビジョニング速度が大幅に向上します。開発、QA、ステージング、本番などの複数の環境を使用する場合、同じコード ベースでインフラストラクチャを起動すると一貫性が確保され、誤った構成やダウンタイムなどのリスクが軽減されるため、多くの時間と潜在的な問題を節約できます。変更管理も非常に重要になり、はるかに簡単になります。コードを記述してインフラストラクチャを更新し、完全なバージョン管理を行うことができます。

これは、クラウド上のコンテナ化されたアプリケーションに特に影響を及ぼします。

• コンテナ化とマイクロサービスでは、以前の開発パラダイムのように少数の大きなインスタンスを起動するのではなく、数百の小さなアプリケーションを起動します。この規模では、開発プロセスにタイムラグが生じ、俊敏性に重大な影響を及ぼします。
• マルチクラウド展開では、一貫した顧客エクスペリエンスを提供するには、数百/数千のアプリケーションにわたる繰り返し性が重要です。
• クラウド コンピューティングの支払いメカニズムは、需要に応じてインフラストラクチャを慎重に動的に拡大および縮小しますが、この規模では手動で管理することはほぼ不可能です。

インフラストラクチャをコードとして使用することで、クラウドネイティブ アプリケーションは、一貫性があり、信頼性が高く、バージョン管理された大規模なインフラストラクチャを実現できます。ただし、IaC だけでは最適なアプリケーション ライフサイクル管理エクスペリエンスは提供されません。プラットフォームは、運用チームによって構成および管理される必要があります。 IaC は、基本レイヤー API のラッパーとして抽象化を提供することで実装されるため、開発者は抽象化ごとに新しい CLI を提供する必要があります。

スムーズな開発者エクスペリエンスを実現するには、IaC だけでは不十分です。プラットフォームをコードとして必要としています。

プラットフォーム・アズ・コード

Platform as Code (PaC) は、プラットフォーム レイヤーを抽象化したものです。 PaC を使用すると、オペレーティング システムやアプリケーションの開発と運用に必要なその他のツールを含むプラットフォーム層に関する宣言的な記述をコードに記述して実行できます。

基本的に、PaC を使用すると、開発者は独自のプラットフォームを定義できます。つまり、アプリケーションにカスタマイズされた実行環境を提供します。アプリケーションの数に関係なく、アプリケーションごとに異なる環境になる可能性があります。 Kubernetes をプラットフォームとして選択する場合は、アプリケーション コードを記述するのと同じように、プラットフォーム要素の YAML 宣言を記述できます。

IaC とは異なり、PaC は k8s API のラッパーを作成するのではなく、抽象化を通じて Kubernetes API の拡張として実装されます。その結果、PaC 抽象化はファーストクラスのエンティティになり、開発者は kubectl と YAML を使用して宣言型の指示を提供できるようになります。

自動化によって節約される時間とエネルギーは明らかです。ただし、Kubernetes 上の PaC の真の価値は、開発者が K8s クラスター用にカスタム プラットフォーム スタックを作成する場合でも、繰り返し可能かつ制御可能であることです。これにより、アプリケーションの開発と運用の整合性が確保されます。 YAML ファイル、管理者マニフェストなどのすべてのプラットフォーム要素は共有可能です。 Kubernetes Operators を使用すると、マルチクラウド環境全体で一貫したデプロイメントも可能になります。

プラットフォーム・アズ・コード・パラダイムにより、エンタープライズ・アプリケーションの大規模で効率的、一貫性があり、繰り返し可能な配信が可能になりました。共通言語を通じてコラボレーションすることで、開発 (Dev) と運用 (Ops) の連携を強化します。最も重要なことは、次世代の開発ライフサイクル ツールへの道を開くことです。反復的な開発、最適化されたワークフロー、軽量のクライアント ツール、本番環境に対応した CI/CD パイプライン、アプリケーション中心のデプロイメント自動化を提供します。