QCon London 2015でPhil Calcado氏は，SoundCloudがモノシリックからマイクロサービスアーキテクチャへの移行から学んだ教訓を公開した。その中で氏は，マイクロサービスプラットフォームを構築する上で中心となる要件として，迅速なプロビジョニング能力の開発，基本的なモニタリング，素早いアプリケーションデプロイメントの３つを挙げた。
SoundCloudでコアエンジニアリングディレクタを務めるCalcado氏は，まず最初に，2011年から現在までの同社の"急成長"期について詳しく説明した。その期間に，同社のプラットフォームの月間利用者数は，300万からおよそ3億にまで増加したのだという。SoundCloudは，オンラインのオーディオリポジトリとしては最大手である。毎分アップロードされる11時間分のオーディオデータを，モバイルやデスクトップなど，さまざまなデバイス上で利用できる。SoundCloudは当初，モノシリックなRuby on Railsアプリケーションとして開発されていたが，2011年になってマイクロサービスアーキテクチャの導入を決定した。
この数年間，Martin Fowler氏の“MicroservicePrerequisites”を始めとして，マイクロサービスに関する記事がいくつも発表されている。Calcado氏はこの記事を読んでとても不安になったが，なぜそうなのか，最初はよく分からなかったという。2011年にSoundCloudは，マイクロサービスアーキテクチャを実装するプラットフォームの導入を決定した。その時点で同社は，多数のマイクロサービスが新たに開発されることで，特に運用の観点から管理不能になるという“マイクロサービス爆発”を意識していた。
SoundCloudのアプリケーションプラットフォームは“クラウドネイティブ”で誕生し，当初はそのワークロードの大部分がAmazonのAWSプラットフォーム上で動作していたという。オーディオデータとそのフォーマット変換はすべてAWS内で管理されていたが，SoundCloudのアプリケーション自体は，アムステルダムにあるいくつかのプライベートデータセンタを使って稼働していた。2010年から2011年の時点において，一般公開されたアプリケーション展開プラットフォームとして最もポピュラーなのはHerokuだったので，同社のマイクロサービス計画でも，これを設計上のインスピレーションとして使用した。PaaSベースのアプリケーション構築にはHerokuの"12factor.net"のガイドラインにある概念を採用し，デプロイメント機構としてLXCを，プラットフォームコーディネーションのためにDoozerを導入している。
Calcado氏によれば，当初のSoundCloudのアーキテクチャは，当時の同社のプラットフォームで利用可能なものとしては最良だったが，いくつか問題があった。その最たるものが，彼らのデータセンタ内に“口うるさい隣人”が生まれたことだ。原因は，SoundCloudのLXCの利用に対して(cgroupがないなど)リソース制限がなかったことと，単純なスケジュールポリシを実装していたことにあった。
これと同じ頃，SoundCloudでは，新たなプラットフォームの開発作業を行っていた。オープンソースのコミュニティでも，MesosやDocker，Kubernetesなど，同じようなソリューションが開発されていた。これらのプロダクトのいくつかは，TwitterやAirBnB，Googleといった企業のバックアップを受けていたため，ソフトウェアの開発は急ピッチで進行した。SoundCloudでも当初は，これらの公開プロダクトを利用して自社プラットフォームを更新しようとしていたが，そのようなマイグレーションを実行に移す前に，まずは自らの現在のソリューションを単純化する(そして，業界の動向がコンテナベースのソリューションに定まるのを待つ)ことにした。
モニタリングに関して，Calcado氏は，2011年から2012年までという期間が，テレメトリツールにとってあまりよい時期ではなかったと考えている。SoundCloudは最初，StatsDやGraphite，Nagios，Pagerdutyを活用することにしていた。ソリューションとしては現実的だったが，このツールチェーンでは，Graphiteが最も弱点となるコンポーネントだった。提供されているクエリ言語に制限がある上に動作が遅く，しかもディスクスペースを大量に消費したからだ。
大規模なシステム開発を他で経験した後に，同社に参加したSoundCloudチームのメンバたちも，メトリクスのプッシュモデルに納得できていなかった。これが最終的に，同社に独自の管理システムであるPrometheusの開発と，そのオープンソースリリースを決心させる理由になった。Prometheusでは，メトリクスの収集にプルモデルを採用している。収集したデータはIcingaに送信された後，Pagerdutyで監視と警告が行われる。
Calcado氏はマイクロサービスアーキテクチャに関して，モノシリックなアプリケーションよりも問題の特定が困難になる可能性を指摘している。そこから彼らが学んだ最も重要なことが，監視ダッシュボードの標準化の必要性だ。SoudCloudの現在のアーキテクチャでは，アプリケーションのダッシュボード設定を，関連するコードリポジトリ内のJSONファイルで指定するようになっている。これによってサービスを管理するチームは，それぞれ監視に必要なダッシュボードを実装することが可能になる。
監視データへのアクセスやアプリケーションのシャットダウン手段の提供，あるいは下流への影響を遮断するサーキットブレーカ機能を提供するためには，アプリケーションの運用機能を標準化された方法で公開する必要がある。twitter-serverなどのアプリケーションプラットフォームでは，この種の機能をHTTPインターフェース経由で公開する例が提供されている。運用機能の標準化アプローチに加えて，Calcado氏はさらに，実運用レベルのインシデントの解決手順に，管理チームまでのエスカレーションポリシを含めておく必要がある，と指摘している。これにより，実運用中のオンコール作業防止のための作業を優先するようなマネジメントが促進される。
初期のトピックとして氏が挙げた３つの最後となるのは，マイクロサービスの継続的デリバリを実運用するためには，ビルドパイプラインの構築が不可欠である，という点だ。ビルドとデプロイメントのプロセスも，サービス全体で標準化する必要がある。SoundCloudのサービスはすべてがLXC上で稼働しているのではないが，コンテナを使用することにより，開発用のラップトップ上で"ミニSoundCloud"の構築が可能になるとともに，マイクロサービスプラットフォーム内で依存サービスを開発する上でのメリットもある。
講演のまとめとして氏は，プレゼンテーションの始めに提示した疑問 - なぜマイクロサービスの前提条件に関するMartin Fowler氏の記事を読んで不安になったのか - に答を出した。
その記事を読んで初めて，私たちが大変な失敗をしてしまったことに気付きました。迅速なプロビジョニング，基本的なモニタリング，素早いアプリケーションデプロイメントといった問題に，自分たち自身でシステムを構築しなくても対処できる，シンプルでインクリメンタルな方法があるのです。
しかしCalcado氏は，Adrian Cockcroft氏と最近交わした会話によって安心を得ることができた。Cockcroft氏は，Netflixがサービスベースのアーキテクチャを導入していた時期に，同社のクラウドアーキテクトを務めた人物だ。最初の開発で完全なシステムを完成できなかったことを嘆くSoundCloudのチームに対するCockcroft氏の返答を，氏は次のように表現している。
えっ？Netflixが最初から，うまくいったと思っているのですか？[...] 問題を回避する方法が分かるまでに，何もかも壊してしまいましたよ。うまくいったことだけを発表したのです。
Calcado氏は結論として，SoundCloudのマイクロサービスプラットフォーム実装の結果からは，得るものが多かったと述べている。特筆すべきなのは，大規模システムでの運用障害を判断する上で不可欠なツールであるPrometheus監視システムを開発したこと，12factor.netのアプリケーションガイドラインなど，マイクロサービスアプリケーション開発の("ルールではなく")ガイドラインの必要性，さらには，TwitterのアプリケーションプラットフォームであるFinagleが提供するような，強固な基盤の上に構築することの必要性だ。
“No Free Lunch, Indeed: Three Years of Micro-services at SoundCloud”と題されたPhil Caldado氏の講演のスライド資料は，QCon London 2015スケジュールのWebページにある。