Web AppShut Down

dotCloud

dotCloud は、開発者チームがサーバーを直接管理せずにアプリケーションをデプロイし、ホスティングできる開発者向け PaaS でした。

元のストーリーを見る

プロダクト概要

何だったか

dotCloud は、開発者が managed platform 上で applications を deploy、host、assemble、run できるようにしました。

誰のためか

application developersstartup engineering teamssmall software teams

課題 / 価値

アプリケーションチームの低レベル infrastructure 作業を減らすこと。

中核ワークフロー

  • Web applications を deploy する
  • app components を host する
  • 低レベル server infrastructure の管理を避ける

プロダクト形態

developer PaaScloud hosting platformcommand-line deployment workflow

価格モデル

歴史的には commercial PaaS pricing がありましたが、公開閉鎖ソースには shutdown 時の active pricing や revenue は開示されていません。

何が起きたか

概要

dotCloud PaaS business は Docker から売却され、後に cloudControl insolvency の後で閉鎖されました。

結果

元の hosted PaaS は終了し、Docker がより重要な製品方向になりました。

需要シグナル

公開記録では、Docker が価値ある戦略的焦点になり、元の dotCloud hosted PaaS は売却され、後に cloudControl insolvency の後で閉鎖されました。教訓は技術品質ではなく、事業モデルとの fit です。

集客上の問題

Developer PaaS は混み合い、運用負荷の重い市場でした。この platform は hosted service の継続に顧客が依存するため、customer migration risk も生みました。

タイムライン

  • dotCloud は Docker が会社の焦点になる前から存在していました。
  • dotCloud, Inc. は Docker, Inc. になりました。
  • PaaS business は 2014 年に cloudControl へ売却されました。
  • service shutdown は 2016 年 2 月 29 日に予定されました。

作る前に確認すること

なぜ重要か

developer infrastructure products は uptime、support、migration、pricing、competition の義務を伴い、元の製品仮説を超えて重くなることがあります。

主な確認事項

ホスティング事業と基盤技術を分けて検証してください。顧客が運用済みのプラットフォームに支払うことを証明し、そこから生まれたツールへの称賛だけで判断しないでください。

参考になる場合

  • developer platform、hosting tool、deployment service、infrastructure wrapper を作っている。
  • 最も価値ある資産が、顧客が最初に見る hosted product ではなく internal tool かもしれない。

参考になりにくい場合

  • hosted operations や customer migration risk のない、一人用 developer utility である。

開発前テスト

  • 少数の production users に狭い hosted workflow を売り、support load を追う。
  • primitive を別に release または demo し、platform より強い需要を引くか試す。
  • production workloads を onboarding する前に migration plan を作る。

応用できる学び

  • service business を underlying technology と別に検証する。
  • infrastructure を売る前に support、uptime、migration、shutdown obligations をモデル化する。
  • internal tool が本当の製品になる platform shift を見逃さない。

今作るなら

hosted service と underlying technical primitive を分けて検証してください。paying customers、uptime/support burden、migration liability、そして underlying tool 自体が製品になるべきかを測ってください。