マイクロサービスをクラウドに展開しようとして，新しいアーキテクチャの理解に苦労している人が多いのは，それがパラダイムシフトだからだ - Daniel Bryant氏は，ロンドンで開催されたMicroservices Conferenceで行ったプレゼンテーションの中で，マイクロサービスをクラウドに配置する作業について，５年間に及ぶ自身の経験をもとに解説した。
OpenCredoのコンサルタントである氏は，クラウドマイクロサービスの設計と実装を支援するために，DHARMA原則に基づいて作成したチェックリストを，オブジェクト指向開発で使用されるSOLID原則と比較して，次のように説明する。
Documented (just enough) - 氏の考える"適切な量の資料"とは，開発を開始する上で必要十分な量の，ライトウェイトなドキュメントだ。開発者のための地図作りであり，コンポーネントの目的などの記述であると同時に，運用上のリスクを強調したり，システムの設計方法を示す文書であることも必要である。
Highly Cohesive and Loosely Coupled - 氏が"凝縮性の高さ"と"疎結合"として考えるのは，コードのみでなく，すべてのレベルにおいて変わることのない，基本的な部分のアーキテクチャに関するものだ。
氏はアーキテクトにとって重要なものを３つ定義する。
- カプセル化 - 単一責務の原則 (SRP/Single Responsibility Principle)，関心の分離，あるいは同種の原則。
- スケーラビリティ - クラウドに移行する一般的理由である。
- 理解力 - 開発期間が重要な意味を持つ市場において，迅速なイノベーションが可能な企業はそれによく対応し，市場競争における自らの優位性を高めることができる。
Automated from Commit to Cloud - 継続的インテグレーションとデプロイ，配信の実践を意味する。重要なのは，開発対象を可能な限り早くクラウド的かつ現実的な環境に対応させて，機能の正常性を確認することだ。気付かないうちにパフォーマンスが徐々に低下して，後になってクリティカルな限界を越えるような事態を避けるためにも，氏は，現実的なデータを使用したパフォーマンステストの実施を強く推奨する。マイクロサービスパイプラインを採用する場合，個々のサービスをデプロイできないのであれば，それらはマイクロサービスではないはずだ，と氏は指摘する。分散型モノリスの開発にならないように十分に注意しなければならない - 実行速度と変更に大きな代償を払うことになるからだ。
Resource Aware - クラウドが根本的に異なるプラットフォームであることを理解する必要がある。クラウドでは，すべてがネットワークの向こうにある。氏の印象深いものとして語るのは，仮想ドライブからのデータ読み込みがラップトップよりも遅いために，パフォーマンスの大幅な低下を招いた，という失敗例だ。
機械的な親和性が重要だ，と氏は指摘する。クラウドの下にある基本構造，仮想化やネットワーキングの原理の最も重要な部分について理解する必要がある。ここでの基本は，機能的に思考および行動すること，開発し提供するものに責任を負うこと，この２つだ。
Monitored Throughly - すべてを徹底的に監視しなければならない。ビジネス的な視点からの評価を含めて，システムで何が起きているかを可視化することは，クラウド的な環境では不可欠である。処理要求の追跡が非常に容易なモノリス型システムに対して，マイクロサービスでは，要求がいくつかのサービスを経由する場合などは，追跡が非常に難しいこともある。このような場合には，要求を追うために相関IDを作ると，非常に役に立つ。
Antifragile - 脆弱(Fragile)の反対は堅牢(Robust)ではなく，非脆弱(Antifragile)である。しかし氏が強調するのは，システムはまず堅牢でなくてはならず，それゆえにシステムが完全にスケールしても失敗するような事態を回避する必要がある，という点だ。
分散コンピューティングの原則は重要である。潜在的な問題は数多いが，その解決策もまた数多い。開発者が既存のソリューションを知らないがために，車輪の再発明をすることがあまりにも多すぎる，というのが氏の見解だ。
Skills Matterがロンドンで開催準備中のMicroservices Conferenceは，この主題による初のカンファレンスである。