前回のQCon Londonで，英国Government Digital Service(GDS)のテクニカルアーキテクトを務めるMichael Brunton-Spall氏は，マイクロサービスの運用に成功するためにDevOpsがいかに重要性であるか，自身の見解を説明した。その中で氏は，マイクロサービスを識別するための重要な要素を特定した上で，最初のマイクロサービスを開発するための方法と，マイクロサービスのエコシステムを管理するために必要なツールとプラクティスについて述べている。
マイクロサービスは小型で自身のデータを有し，データベース統合の類いを必要としないものでなければならない。データはすべて公開インターフェースを通じて共有され，"ダムパイプ/スマートエンドポイント"アプローチに従う必要がある。各マイクロサービスには，唯一の所有者として，コードとランタイムを所有するチームが存在しなければならない。Brunton-Spall氏はJeff Sussna氏の意見を認めて，次のように述べている。
マイクロサービスは新たなアーキテクチャモデルであると同時に，新しい組織モデルの表現でもあるのです。
新しい組織モデルはまた，開発者と運用担当者の役割を変えることにもなる。開発者がマイクロサービスのライフサイクル全体の所有権を有する一方で，運用担当者はコンサルタントの役割をより強くする。
マイクロサービスを始める際にBrunton-Spall氏が推奨するのは，小さな部分から着手する，ということだ。最初はただひとつのマイクロサービスから始めて，適切なサポートツールやプラクティスが利用できていることを確認する必要がある。氏が推奨するのは，インフラストラクチャの自動化，デプロイメントの自動化，ログアグリゲーション，運用や統合の容易な監視ツール，警告に関する適切なプラクティスといった，DevOpsコミュニティで議論されたツールやプラクティスである。
複数のマイクロサービスへの移行には，多くの課題が伴う。それらは主に，トラブルシュートでの複雑性の増大に関するものだ。Brunton-Spall氏は次のように言う。
マイクロサービスでの失敗は，モノリスシステムの場合よりも甚大なものになります。
マイクロサービス間の複雑なインタラクションを完全に把握するためには，高度な診断ツールや監視ツールが必要だ。QCon Londonのマイクロサービスに関する講演でも，いずれも監視の重要性が強調されていた。Brunton-Spall氏は，簡単な監視(サービスは動作しているか？)と，より深い監視(サービスの依存関係は機能しているか？)を区別する。後者の方が包括的ではあるが，ユーザの多いマイクロサービスに障害が発生した場合，警告が連鎖的に発生して，問題の根本原因の把握が難しくなる可能性がある。
マイクロサービスの耐障害設計とともに注目されることが多いのは，一貫性のある管理インターフェースの提供だ。例えば，マイクロサービスのサーキットブレーカを起動する，汎用的な方法を用意する必要がある。TwitterServerは，このアプローチの好例だ。
デプロイが適切に監査されているのであれば，開発者にはポケットベルとデプロイ用にキーを与えるとよいだろう。ポケットベルが開発者に，自身の誤りに対する痛みを感じさせることで，繰り返し発生する問題への迅速な対応を促してくれる。しかしこれでは，成熟したサポートプロセスとして十分ではない。例えば開発者がうんざりして転職してしまったらどうするのか，とBrunton-Spall氏は問う。あるいはチームが解散してしまったら？ サポートとトリアージの最前線は，それでも存在し続けなくてはならない。このような状況に対する移譲ルールを定義するには，サポートの成熟度モデルを使用する必要がある。例えば，“作業の移管時には，M週間でN回の障害発生と，整備された行動手引きが必須である”といったものだ。
シンプルなソリューションは，優れたマイクロサービス運用プラクティスを可能にする。Brunton-Spall氏は，GDSに参加する前に自身が働いていたThe Guardianの事例を引き合いに出している。そこでの初期サーバのプロビジョニングイメージは，Ubuntuイメージをベースとして構成されたもので，そのプロビジョニングは，パッケージの"apt-get"とwgetによるJARファイルのダウンロード，そして実行という，わずか数行のbashスクリプトで構成されていた。