Googleが“Large-scale cluster management at Google with Borg“と題した論文を発表して，これまでほとんど語られなかった技術の詳細を明らかにした。
Borgはクラスタマネージャである。数万台のサーバから構成されるクラスタ群上で動作し，数千というアプリケーションから送信される数十万のジョブを，さまざまなサービスに代わって受け入れ，それらのスケジュール，開始，停止，再起動を行う。Borgの目的は，開発者に代わってリソース管理作業を実行することにより，彼ら自身の作業に集中できるようにすること，データセンタの枠を越えてリソース使用効率を最大化すること，この２つである。次の図は，Borgのメインアーキテクトを表している。
このアーキテクチャの構成要素は次のとおりである。
- セル -ユニットとして扱われるマシンの集合。 セルには通常10,000台程のサーバが含まれるが，必要ならばそれより多くても構わない。セルを構成するサーバは，CPUやメモリ，ディスク容量などの面で不均一である。
- クラスタ – 一般的にはひとつの大きなセルで構成されるが，テスト用など，特定の目的を持った小さなセルをいくつか含む場合もある。クラスタは常にデータセンタの建物内に限定され，クラスタ中のすべてのマシンが高性能ネットワークで接続されている。これに対してサイトは，複数の建物やクラスタで構成される場合もある。
- ジョブ – セル境界の中で実行されるアクティビティ。 CPUやOS，公開IPなどの要件が添付される場合もある。ジョブ同士での通信や，ユーザあるいは監視ジョブがRPCを通じてジョブにコマンドを送ることができる。
- タスク -ジョブは同じ実行ファイルから実行される，1つないし複数のタスクで構成される。 これらタスクは通常，仮想化のコストを回避するため，仮想環境ではなくハードウェア上で直接実行される。タスクは静的リンクされたプログラムとして提供される。これにより，実行時の動的リンク実施を回避する。
- Alloc – ひとつ以上のタスクのために確保された，マシンリソースのセット。Allocはタスクが動作する別のマシンに，タスクとともに移動させることができる。Allocセットは，ジョブのために複数のマシンに分散して確保されたリソースを表す。
- Borglet - 各マシン上で動作するエージェント。
- Borgmaster – セルレベルで動作し，すべてのBorgletの状態データを保持するコントローラプロセス。実行キューへのジョブの追加を行う。Borgmasterとそのデータは5回複製され，データがPaxosストアに永続化されるとともに，Borgmasterのひとつがリーダになる。
- Scheduler – キューを監視し，個々のマシンで利用可能なリソースを考慮した上で，ジョブをスケジュールする。
Borgシステムでユーザが投入するジョブは，一つ以上のタスクで構成される。それぞれのタスクは同じバイナリコードを共有し，複数のマシンで構成されたBorgの実行単位であるセル上で動作する。これらセルの上でBorgは，2種類のアクティビティを組み合わせる。ひとつはGMailやGDocs，BigTableなどのように，長期にわたって動作するが，低レイテンシ - マイクロ秒から数百ミリ秒 - の応答が必要なサービスであり，もうひとつは，即時応答は不要で長時間，時には数日間動作するバッチジョブである。最初のタイプのジョブはProdジョブ(プロダクションジョブ)と呼ばれ，非プロダクションジョブと考えられているバッチジョブよりも高い優先度を与えられる。ProdジョブはセルのCPUリソースの70%を受け取り，総CPUの～60%を消費する。また， メモリの55%を割り当てられ，その～85%を消費する。異なるタイプのジョブをセルに混在させるのは，リソースを可能な限り有効利用し，Googleのデータセンタ全体のコストを低減するためだと，Googleの研究者であるJohn Wilkes氏は述べている。
論文によると，セルのいくつかは10Kタスク/分の到着率を有し，Borgmasterは10～14のCPUと50GBのRAMを使用することができる。Borgmasterの稼働率は99.99%に達する。ただしBordermasterあるいはBorgletがダウンしても，タスクは動作を続けることができる。50%のマシンでは9以上のタスクを実行し，いくつかのマシンでは25タスクと4,000スレッドが管理されている。タスクの起動待ち時間は平均で25秒だが，その内の20秒はパッケージのインストールに要するもので，待ち時間の大半はディスクアクセスに起因する。
中心的なセキュリティ機構として採用されているのは，Linuxのchroot jailと，タスクのデバッグを行う時に使用する，Borglet経由のsshである。GAEあるいはGCE上で動作する外部ソフトウェアに対しては，KVMプロセスでBorgタスクとして動作するホステッドVMを使用する。
Googleにはもうひとつ，Omegaというクラスタマネージャがある。これについても，簡単に説明されている。
Omageは，大まかに言うとBorgmasterから永続化ストアと共有リンクを取り除いたものとほぼ等価な，特殊な"バーティカル"を複数，並列的にサポートします。Omegaのスケジューラは楽観的同時制御機構を使用して，中央の永続化ストアにある，必要なセル状態と確認したセル状態の共有表現を操作します。永続化ストアとBorgletとは，独立したリンクコンポーネントを使用して双方向に同期されます。Omegaのアーキテクチャは，アプリケーション固有のRPCインターフェースや状態マシン，スケジュールポリシ(例えば，長時間動作するサーバ，さまざまなフレームワークによるバッチジョブ，クラスタストレージシステムなどインフラストラクチャサービス，Google Cloud Platformの仮想マシン)を持った，固有のワークロードを複数サポートするように設計されています。その一方でBorgは，“ワンサイズですべてに合う”RPCインターフェースや状態マシンのセマンティクス，スケジュールポリシなども備えています。これらはいずれも，多くの異質なワークロードをサポートする必要性から，時間を掛けて大規模かつ複雑に成長してきたもので，拡張性が問題になったことはありません。
10年間のシステム運用でGoogleが学んだ教訓のいくつかが，Kubernetesの設計に適用されている。具体的には，同一サービスに属するジョブに対するオーケストレーション機能，マシン毎に複数のIPアドレスの割り当て，シンプルなジョブ構成機構の利用，Allocと同等なPodの利用，ロードバランシング，デバッグデータをユーザに提供する深いイントロスペクションといったものだ。Borgで開発を行っていた技術者の多くは，現在はKubernetesに移行している。