Adrian Cockcroft氏はDevopsdays Amsterdam 2015の基調講演で，CIOの主な目標 – ITとビジネスの整合，製品の迅速な開発，セキュリティ侵害の回避 – は，DevOpsプラクティスの適用とコンテナ化されたマイクロサービスの継続的デリバリによって達成可能である，と論じた。しかしマイクロサービスは，管理面での新たな課題を提起する。その課題をいくつか解決する策として，Cockcroft氏が提案するのはシミュレーションだ。
一般的なプログラミング言語を使った小規模なチーム，あるいは高い効率と低レイテンシが重要な場合には，モノシリックなアプリケーションが適している。しかし，継続的デリバリのコンテキストにおける，不変かつコンテナ化されたマイクロサービスの展開は，この優位性を大きく揺るがすものだ。 この構成には拡張性があり，短期間で開発可能な上に，成長著しいさまざまなプラットフォーム環境をサポートしている，とCockroft氏は主張する。
一方で，マイクロサービスによって現れたソフトウェアの細分化は，管理上の問題を提起する。何百にも及ぶサービス間の流れを視覚化して，障害解析とテストを行わなければならない監視ツールは，これによって大きな課題に直面することになる。継続的にデプロイされて，これまでになく短命なホスト上で動作する，これらすべてのサービスにはどう対処すればよいのか？数年前までは，数週間プロビジョンした後に何年も動作するような，ベアメタルサーバの導入が一般的だった。現在のコンテナは数秒でデプロイされ，数分ないし数時間動作する。AWS Lambdaに至ってはミリ秒単位で応答し，動作時間はわずか数秒だ。
ソリューションとしてシミュレーションを加えるべきだと考えるCockcroft氏は，spigoを開発した。現在では，simianviz – SIMulate Interactive Actor Network Visualization – と呼ばれている。Simianvizの主な目標は，次のものだ。
- 大規模なテスト用マイクロサービス構成／アーキテクチャの生成
- ストレス監視ツール表示機能
Simianvizは，シンプルなデスクトップ上でシミュレーションを行う。アーキテクチャのモデリングにはJSONの記述を使用する。
{
"arch": "netflixoss",
"description":"A very simple Netflix service. See http://netflix.github.io/ to decode the package names",
"version": "arch-0.0",
"victim": "homepage",
"services": [
{ "name": "cassSubscriber", "package": "priamCassandra", "count": 6, "regions": 1, "dependencies": ["cassSubscriber", "eureka"]},
{ "name": "evcacheSubscriber","package": "store", "count": 3, "regions": 1, "dependencies": []},
{ "name": "subscriber", "package": "staash", "count": 6, "regions": 1, "dependencies": ["cassSubscriber", "evcacheSubscriber"]},
{ "name": "login", "package": "karyon", "count": 18, "regions": 1, "dependencies": ["subscriber"]},
{ "name": "homepage", "package": "karyon", "count": 24, "regions": 1, "dependencies": ["subscriber"]},
{ "name": "wwwproxy", "package": "zuul", "count": 6, "regions": 1, "dependencies": ["login", "homepage"]},
{ "name": "www-elb", "package": "elb", "count": 0, "regions": 1, "dependencies": ["wwwproxy"]},
{ "name": "www", "package": "denominator", "count": 0, "regions": 0, "dependencies": ["www-elb"]}
]
}アーキテクチャのシミュレーション実行が完了すれば，その結果を視覚化することができる。DNS，ロードバランサ，Webサーバ，MySQLとmemcachedを含む，標準的なLAMPスタックアーキテクチャでの例を示す。
製品管理プロセス
Cockcroft氏は，CIOが目標とする“ITとビジネスの整合，製品の迅速な開発，セキュリティ侵害の回避”をサポートするための，プロダクト管理についてもアドバイスしている。
プロセスこそが問題を防止する方法であるという仮定は，アジャイルの世界においても，いまだ一般的に信じられている。Cockcroft氏は，このような“瘡蓋”プロセスには注意が必要だという。特定の問題を回避するための積み重ねであるが故に，過去によい結果を得られなかったものをすべて否定しているからだ。ルールが多過ぎると，そのすべてに従うことすらできなくなる。ちなみに，Netflixのメインルールは，“会社にとって最高の利益となることを実行せよ”だ。
CIOの目標をサポートするための最高の選択肢は，ルールをすべて廃止して，“ビジネス”と“製品”と“IT”をすべて一緒にすることだ，とCockcroft氏は示唆する。例えばNetflixにはCIOという役職はなく，チーフ・プロダクト・オフィサのみだ。
Cockcroft氏は，IT関連を２つのタイプのチームにまとめるよう提案する。 “プラットフォーム”チームは，プラットフォーム/インフラストラクチャ自動化のためのAPIを提供する。そのメンバにはシステムやネットワーク，SAN管理のスキルが必要だ。“プロダクト”チームは，マイクロサービスアーキテクチャを使って製品を開発する。 “プロダクト”チームに必要なのは，製品管理からUX, Dev, QA, DBまでの幅広いスキルである。Cockcroft氏は，“安全でないアプリケーションは，ファイアウォールの背後でも安全ではない”と主張して，安全性に重点を置いている。開発者は例えば，セキュリティ要件のテストにGauntltなどのツールを使って，頑強なソフトウェアを構築する必要がある。
一般的な意見と同じくCockvroft氏も，オンコール対応は製品を開発した人が行うべきだという意見を持っている (“開発した人が実行する”)。ただし責任はそこに留まらず，階層全体(管理者以上)がバックアップとして行動すべきだ。ソフトウェアの信頼性を保証するためには，これが重要な前提となる。