クラウドは強力である。数分でサーバーを用意でき、データベース、キュー、ストレージ、CDN、監視、認証、機械学習基盤まで揃っている。新しい事業を始めるとき、これほど頼れる選択肢はない。
一方で、クラウドを使い込むほど、アプリケーションの作り方と運用の仕方は特定ベンダの前提に引き寄せられていく。最初は便利だったサービスの組み合わせが、数年後には移行しづらい制約になる。事業が成長し、顧客ごとの専用環境、オンプレミス対応、複数クラウド対応、規制産業向けのデータ配置、買収後のシステム統合が必要になったとき、その制約は表面化する。
AppThrustで作りたいのは、クラウドを否定する世界ではない。クラウドを使いこなしながら、アプリケーションの運用モデルを特定ベンダに閉じ込めない世界である。
ベンダロックはAPIだけの問題ではない
ベンダロックというと、特定クラウドのマネージドデータベースを使っている、特定のキューやストレージに依存している、という話になりやすい。もちろん、それもロックインの一部である。しかし本質はもう少し広い。
本当に移しづらくなるのは、アプリケーションの運用そのものだ。
どのようにデプロイするのか。リリース前に何を確認するのか。環境変数やシークレットをどこで管理するのか。証明書をどう発行し、ドメインをどう紐づけるのか。ログ、メトリクス、監査証跡をどこで見るのか。障害時に誰が何を判断するのか。バックアップとリストアはどの単位で行うのか。権限と承認の境界はどこにあるのか。
これらが特定クラウドのコンソール、特定サービスの設定画面、属人的な手順書、個別に作られたCI/CD、環境ごとの例外処理に散らばると、単に技術を差し替えるだけでは移行できなくなる。コードよりも、運用のほうがロックインされる。
だからAppThrustでは、アプリケーションを中心に考える。ユーザーが扱う言葉は、クラウドサービス名ではなく、Application、Component、Database、Cache、Release、Publish といったアプリケーション運用上の概念である。実行基盤としてKubernetesや各クラウドのAPIを使うとしても、アプリケーションチームが毎回そこに直接向き合う必要はない。
同じ運用モデルを持つことの価値
AppThrustの重要な価値は、クラウドでもオンプレミスでも、できるだけ同じ運用モデルでアプリケーションを扱えるようにすることにある。
新規事業であれば、クラウド上に素早く環境を作り、アプリケーションを公開する。エンタープライズ向けであれば、顧客専用の環境やオンプレミス環境に同じ考え方で展開する。規制産業であれば、データの配置やネットワーク境界に合わせて実行場所を選ぶ。それでも、アプリケーションを作り、リリースし、公開し、状態を確認し、問題があれば復旧する、という開発チームの体験は大きく変えない。
これは単なる抽象化ではない。抽象化しすぎると、実行基盤の現実を隠してしまう。クラウド、ネットワーク、ストレージ、証明書、権限、監査、障害は現実に存在する。AppThrustが目指すのは、それらをなかったことにすることではない。プラットフォームチームが制御すべきものとして扱い、アプリケーションチームにはアプリケーションの意図として見せることである。
アプリケーションチームは、どのクラスタにどのマニフェストを適用するかではなく、どのアプリケーションをどの環境にリリースするかを考える。プラットフォームチームは、その裏側で配置、ポリシー、接続、証明書、監査、ロールバック、実行基盤の健全性を扱う。この分担ができると、開発速度と統制は対立しにくくなる。
クラウドを選べる状態を保つ
ベンダロックフリーとは、どのベンダも使わないという意味ではない。むしろ、必要な場面では積極的に使う。クラウドのマネージドサービスは強力であり、事業の初期速度を大きく上げる。
重要なのは、クラウドを選べる状態を保つことだ。
初期はAWSで始める。ある顧客には専用環境を提供する。別の顧客にはオンプレミスに近い形で提供する。ある領域ではクラウドのマネージドデータベースを使い、別の領域ではKubernetes上のデータベースオペレータを使う。将来、コスト、規制、可用性、組織戦略の理由で実行場所を変える必要が出たとき、アプリケーションの運用モデルを作り直さずに済む。
この状態を作るには、最初から運用上の境界を設計しておく必要がある。アプリケーションの意図、実行場所、接続、公開、リリース、監査、証跡、復旧を、環境ごとの手作業ではなく、プロダクトのモデルとして扱う必要がある。
AppThrustはそのためのアプリケーション基盤である。Kubernetesを使うのは、実行基盤の共通言語として強力だからだ。しかし、AppThrustの目的はKubernetesをそのまま見せることではない。Kubernetesの上に、アプリケーション運用のための言葉とワークフローを作ることにある。
プラットフォームは手順書ではなくプロダクトである
多くの組織では、プラットフォームチームが運用手順を用意する。デプロイ手順、ログ確認手順、スケール手順、シークレット更新手順、障害時の確認手順、バックアップ手順。最初はそれでよい。しかし手順書が増え続けると、開発者はどれを実行すべきか迷い、プラットフォームチームは問い合わせ対応に追われる。
AppThrustでは、繰り返される運用を手順書ではなくプロダクトのワークフローとして扱いたい。リリースする、公開する、DBへ接続する、ログを見る、スケールする、バックアップを確認する。そうした操作が、アプリケーションやコンポーネントの文脈から自然に実行できる状態を目指す。
これは開発者を楽にするためだけではない。プラットフォームチームにとっても重要である。操作がプロダクトのワークフローになれば、入力を検証できる。権限を確認できる。監査ログを残せる。リスクの高い変更には承認を挟める。実行結果を状態として返せる。属人的な運用を減らし、組織として同じ品質でアプリケーションを届けられる。
AI時代には、共通の運用モデルがさらに重要になる
AIによって、コードを書く速度は上がる。テストの生成、リファクタリング、ログ解析、ドキュメント更新、設定変更の提案も速くなる。これ自体は大きな変化であり、開発の前提は確実に変わる。
しかし、コードを書く速度が上がるほど、リリースと運用の境界は重要になる。AIが生成した変更を、どの環境に、どの権限で、どの証跡を残して、どの承認を経て適用するのか。その判断を曖昧にしたまま自動化だけを進めると、速く壊れるシステムになる。
AIに必要なのは、無制限の権限ではない。変更を提案し、検証し、差分とリスクを示し、必要なところで人間の承認を得て、安全な経路で適用するための運用モデルである。
AppThrustが目指す世界では、AIエージェントもアプリケーションの言葉で作業する。クラウドごとのコンソール操作や環境ごとの手順を覚えるのではなく、アプリケーションの変更、リリース、公開、接続、状態確認というモデルの中で動く。これにより、AIによる開発自動化は、単なるコード生成から、アプリケーションを安全に届けるためのワークフローへ進む。
自由度を失わずに速く作る
AppThrustで実現したいのは、自由度を失わずに速く作ることである。
クラウドを使えば速い。しかし、使い方を間違えると、事業の選択肢を狭める。すべてを抽象化すれば自由になるように見えるが、現実の運用責任を隠すだけでは、いずれ破綻する。必要なのは、クラウドの力を使いながら、アプリケーションの運用モデルを自分たちのものとして持つことだ。
アプリケーションチームは速く届ける。プラットフォームチームは安全な境界を作る。経営や事業側は、クラウド、オンプレミス、専用環境、複数クラウドといった選択肢を後からでも持てる。この三つを同時に成り立たせるための基盤が必要である。
AppThrustは、そのために作っている。
クラウドに閉じ込められない。Kubernetesの複雑さを開発者に押し付けない。手順書ではなく、プロダクトとして運用を扱う。AI時代の開発速度を、安全なリリースと運用につなげる。
それが、AppThrustで作りたい世界である。