Northflank、顧客VPCとmicroVM sandboxを束ねるKubernetes workload platform

2019年、workloadへ視線を戻す

Northflankは2019年に始まり、KubernetesやCI/CDを整えること自体が目的化し、開発者が顧客価値を生むworkloadから遠ざかる問題に向き合った。

Will StewartとFrederik Brixは、公式発表で『Customers don’t pay you to write YAML.』と述べ、インフラ運用ではなくsoftware deliveryへ時間を戻す立場を明確にした。出典

Kubernetesの力を残し、操作を減らす

同社はHerokuのようなself-service体験と、enterpriseが必要とする複雑なworkloadやcustomer cloudを両立させる方向を選んだ。

Gitからのbuildとdeploy、database、job、preview environmentを一つのplatformで扱い、AWS、GCP、Azure、オンプレミスにも展開できるようにした。出典

2024年の資金調達と拡張

2024年11月、NorthflankはBain Capital VenturesとVertex Ventures USを中心にSeries AとSeed合計$22Mを発表した。出典

公式発表では、6超のcloud provider上で数万人のdeveloperが利用し、月間100万超のcontainerをdeployすると説明している。出典

agent時代に広がるworkloadの意味

現在のNorthflankはAI agentのuntrusted codeをmicroVMで隔離するsandbox、GPU workload、永続volumeを含めている。

Frederik BrixがCTOとして共同創業者に名を連ねる体制のまま、単なるdeployment productではなく、production workloadをどこで安全に動かすかというplatformへ範囲を広げたと言える。出典

結び

Northflankの賭けは、Kubernetesを隠すことだけではない。

cloudやVPCをまたいでも同じworkflowを保ち、開発者がworkloadを出荷する時間を増やせるかにある。

Northflankが解くのは、Kubernetesの柔軟性を捨てずに、アプリ、database、job、previewを開発者がself-serviceで動かしたいというplatform teamの痛みだ。

公式はGitからbuild・deployし、preview environment、CI/CD、managed databaseを同一platformで扱えるとしている。出典

参入障壁は単なるcontainer deploy UIではなく、Kubernetes上でCI/CD、preview、stateful workload、sandbox isolation、BYOCを一貫して運用するcontrol planeと運用知識にある。

顧客VPCをまたいだ同一application definitionの運用が定着するほど、置換コストは上がると考えられる。出典

直接的な二面市場のnetwork effectは強くない。

価値は利用者数より、template、GitOps運用、cloudごとのdeployment standardを組織内で再利用できることにある。

したがってnetwork effectよりworkflowの埋め込みと運用標準化が継続性を支える。出典

対象はKubernetesを直接運用する負荷を減らしつつ、Heroku型PaaSでは足りないservice、job、database、AI workloadを扱うsoftware teamとplatform engineering組織である。

特にcustomer VPCやdata residencyを求めるB2B SaaS、AI platform、regulated industryに適合する。出典

第一に、managed cloudだけでなくAWS、GCP、Azureや顧客VPCにも同じ操作面を持ち込むBYOCが、既存のcloud commitmentとcompliance要件に合う。出典

第二に、AI agent向けsandbox、GPU、永続stateまでworkloadの範囲を広げ、point solutionを増やさずに済む設計である。出典

platformの守備範囲が広いぶん、Kubernetes、network、security、costの責任境界を顧客が理解しないまま導入すると、抽象化が新しい運用複雑性になり得る。

BYOCはdata residencyとcontrolを与える一方、既存clusterやcloud accountの前提を揃える必要がある。出典

入口はfree sandboxとusage-based pricingによるdeveloper self-serveで、Git連携、preview environment、managed databaseを使うほど利用範囲を広げるPLG型に見える。

そこからVPC、SSO、audit log、SLAが必要な組織へEnterpriseを提案し、BYOCで既存cloud予算を活かす拡張が合理的だ。出典

主要チャネル: productLedGrowth, developerDocumentation, contentMarketing, enterpriseSales, partnerEcosystem

開発者体験を良くする抽象化は、柔軟性を隠し切ることではなく、必要な時にcustomer VPCやKubernetesへ降りられるescape hatchを設計することだ。

free tierと従量課金で試せても、production移行時のsecurity、network、stateの道筋まで同じproductで示す必要がある。出典

日本で展開するなら、国内リージョンだけを売りにするより、既存AWS・GCP契約を残したまま顧客VPCへdeployできる点を、SaaSベンダーのenterprise案件獲得と結び付けるべきだと考える。

監査ログ、RBAC、data residencyの実装例を日本語で示し、platform team向け導入支援を厚くする余地がある。出典