独自のアプローチを採用した結果、それに縛られ身動きできなくなっている企業は少なくない。マイクロサービスを再利用するには、全ての外部インタフェースが必ずオープン標準に従う必要がある。

　オープン標準はデファクトスタンダードだ。大半のIT担当者は厳格な規格を採用している。ここでいう厳格な規格とは、人々が集まって議論し、IEEE（米国電気電子学会）標準・IETF（インターネット技術特別調査委員会）標準・ISO（国際標準化機構）標準として発行されたものを指す。誰も採用していない規格では意味がない。

　独自のアプローチは、運用全体に影響を与えることなく的確に役割を果たすため、注意を払いながら利用する限りは役に立つ。ただし独自のアプローチの利用はマイクロサービス内だけに限定する必要がある。マイクロサービスが外部環境と連携する場合はできる限り標準化されたものを利用すべきだ。戦略的な理由から、外部インタフェース内で独自の専用ソフトウェアを利用する場合は、マイクロサービスコード内やバックアップ用のドキュメントに必ずその理由を明確に記載する。

3.疎結合

　企業でサービス指向型アーキテクチャがうまく機能しなかった理由は、ハードコーディングしたモノリスをハードコーディングした連結済みのサービスに置き換えたためだ。機能しなくなったリンクを新しいリンクに置き換えなければならなくなるため、必要に応じてサービスを別のサービスに置き換えるのが困難になる。最新のマイクロサービスでは、XML（Extensible Markup Language）などの手段を利用してサービスを自由に呼び出し、オープンな方法で応答を取得できるようになっている。

4.移植性

　マイクロサービスはプログラムに移植性があり、必要なリンクを内包できることから、ハイブリッドクラウド環境に適する。例えば普遍的な用途には安価なパブリッククラウドを最大限に活用し、頻繁に使用する機能は手近な場所に戻してパフォーマンスを向上させたいと考えたとする。その場合、複合アプリケーションのうちパブリッククラウドに設置する部分は、このワークフローを理解した上でマイクロサービス内の変化に順応できるようにしなければならない。共有されるコンポーネントが多くなると、マイクロサービスの課題も多くなる。そのため、全体のアーキテクチャは移植性を視野に入れて設計すべきだ。

5.機能の規則書

　開発者はめったに機能を変更しない。機能の変更には追加開発が必要になると考えるためだ。マイクロサービスの考え方として、プログラムは必要な場合にのみ記述し、開発費用に見合うようにできる限り再利用するという大前提がある。従って開発者には、利用可能なマイクロサービス、各マイクロサービスの機能、マイクロサービスの利用条件を把握するため、十分な情報を提供する規則書が必要になる。管理者にとっては、開発者がマイクロサービスを利用する方法を監視し、最適な利用を促すことも必要になる。

6.フィードバック

　その本来の形態から、マイクロサービスは1回限りの利用に理想的だ。しかし次に利用する開発者が不足を感じる可能性がある。元のマイクロサービスを入れ替えるのではなく変更できるように、開発者のニーズを理解し、それに従って行動することが重要だ。

7.使用状況の監視

　マイクロサービスの課題は雪だるま式に急増する。管理者は環境全体でのマイクロサービスの使用状況を継続的に監視しなければならない。あまり利用されていないマイクロサービスにフラグを付け、そのサービスがまだ必要かどうか、別のマイクロサービスを利用できるかどうかを担当開発者に確認する必要がある。利用されていないマイクロサービスは停止して、利用可能なライセンスを探すようにする。

8.更新とパッチ

　マイクロサービスが完璧だという考えに決して陥ってはいけない。全てのマイクロサービスが更新とパッチを受け取るようにしなければならない。その後、DevOps（運用開発）やオーケストレーションシステムに統合する。

9.リソースの伸縮性

　共有される回数が多いマイクロサービスは、特定のサイズに合わせて記述ないしプロビジョニングすると適切に機能しない。十分なリソースをリアルタイムにプロビジョニングし、マイクロサービスの要件を満たすようにする。