クラウドスタートアップのApceraが11月14日，新たなWebサイトをローンチして，同社製品であるContinuumの詳細を公開した。
Continuumは同社創業者のDerek Collison氏が開発に関与したオープンソースPaaSである，PivotalのCloud Foundryに対抗する製品だ。Pivotalが商用版Pivotal CFの最新リリースで，VMwareによる既存のエンタープライズインフラストラクチャとの統合を実現したのに対して，Apceraはより総合的なポリシーベースのアプローチを中心とする。製品を紹介するブログ記事 “Why we’re here” にCollison氏は，次のように書いている：
競合他社に先んじるエンタープライズITのためには，システムのポリシを中心として，複数のデリバリモデル(IaaS, PaaS, SaaS)をうまく組み合わせ，ネットワーク通信の意味的認識を実現する必要があります。今日のPaaSは，開発者の負担を低減するという目的の枠内であるという意味から，いまだクラウドコンピューティングモデルの第1世代にあると言えます。PaaSに欠けているのは，ガバナンスやポリシ，コンプライアンス，認証と識別，セキュリティ，監査性などといった，クリティカルな企業ニーズへの対応能力です。PaaSを利用している人たちを見るに付け，その限界を感じずにはいられません。単独ですべてのデリバリモデルを要求通りに実行可能で，開発(Dev)と運用(Ops)の両方を促進できるような，完全な企業レベルのプラットフォームはこれまで存在しませんでした。それが実現できるかどうかさえ，これまで明らかではなかったのです。
メッセージングに "高性能なNATSサーバ"のgnatsdを使用するなど，Continuumはいくつかオープンソースのコンポーネントを使用している。そうでありながらApceraは，製品をオープンソースとして世に出す方法を選択しなかった。Collison氏はこの製品のより多くの部分をオープンソースとする約束をする一方で，Continumが完全なオープンソースでない理由を次のように説明している：
エコシステムは微妙なバランスの上に構築されています。Google内部からVMwareへと移った私の以前の開発では，この目標達成のためのさまざまなツールがありました。そこで賭け金(table stakes)となるのは，多くの場合，ツールやソフトウェア，プラットフォームなどのオープンソース化です。これによって発展は推進されるでしょうが，それ自体がエコシステムへの関与性を解決し，長く求められる存在にするかといえば，同意はできません。例えばシステムがオープンソースではあるが，プログラミングや拡張，構成変更といった作業がまったく不可能なよう，故意に構築されていたとしましよう。恐らくはエコシステムの誰か他のメンバが，そのプラットフォームを別方向に進めようとするでしょう。ここに暗黙的なフォークの問題が発生します。あなたの所持するバージョンは，リーダたちのコードから乖離し始めます。メインブランチにマージする場合のコストは高まる一方です。これは今日の市場において，オープンソース化をおもなエコシステム構築の手段としている，多くのIaaSやPaaSソリューションに共通して見られる問題です。
ApceraがContinuumでデモしている機能の中には，Dockerによる軽量仮想化(Lightweight Virtulaization)アプローチに極めて近いものもあった。Collison氏は現在進行中の開発内容についても説明してくれた：
Continuumでは，私たちが見るものはすべてジョブ，すなわちプラットフォームによる実行，管理，監視と，ユーザによる更新，レポート，制御が可能なワークロードなのです。OSか，既存アプリか，Webか，あるいは最新のフレームワークを使用したモバイルアプリかといった違いは，私たちにもプラットフォームにも影響しません。&nbsdp;上で述べた目標の大部分を達成するためには，これらのものすべてに独立性が必要となります。そのに関しては，私たちApceraでは常にアイソレーションコンテキスト(Isolation Contexts)を観点とする会話をしています。アイソレーションコンテキストは常に分離され，隔離され，自立しています。それを達成には多くの方法があるはずです。ハイパーバイザ上の完全な仮想化，LinuxコンテナやSolaris Zonesのような軽量プリミティブ，さらにはBromiumなどの企業によって認知度を得た，ハードウェアCPUによて直接駆動されるマイクロタスク仮想化などが選択肢となります。最初のバージョンはLinuxコンテナの下でプリミティブを使って実装しました。他にもさまざまな方法があるでしょう。複合構成やハイブリッドは普通ですし，ひとつのサイズではすべてに対応できません。定義には自立性(automous)が挙げられていないかも知れませんが，これは私たちにとって非常に重要です。ここで言う自立性とは，システム内のすべてのジョブがポリシによって許可および定義された端点を通じてのみコミュニケーションを行う，という意味です。このポリシはネットワークレイヤへの物理的アクセスから，アドレッシング，検出，さらには上述した通信プロトコルの意味的認知までもカバーします。これもまた極めて強力なパターンのひとつであって，アプリケーションSDNと表現する人もいます。この問題に正面から取り組んだのは，私たちが初めてでしょう。さらに，現代的なプラットフォームとしては当然ですが，ユーザに対してすべて透過的です。何かを変更，移動，再始動した場合には，区別されていない重労働のすべてをCotinuumが引き受けます。さらにシステム内で発生するすべての状態遷移を記録する監査ログも提供されています。ポリシをアーキテクチャの中心に組み込んだことで，ユーザに対する可視性，洞察性，コンプライアンスを第1日から提供することができます。
ApceraはGoプログラム言語の積極的なアーリーアダプタでもあり，プラットフォーム全体で幅広く使用している。高度なコンカレントアプリケーションに適したGoのメリットを活かすべく，当面はCloud Foundryが同社のルータやログシステム，ヘルスマネージャ，CLIなどのコンポーネントの移行を行う。