＃1：組織のスキルと受け入れ体制
マイクロサービスのコンテナという取り組みを開始する前に、組織内のすべての人々がその旨を承諾し、自らの心構えを持つ必要がある。Badani氏は「文化の変革を推し進めるITリーダーは、幹部らと、より小さなグループ内におけるエバンジェリストの双方からの支持を得る必要がある」と述べるとともに、「最も容易な道は何もしないことだ」という判断に陥ってしまいがちになる点を警告している。今日のような、目まぐるしく移り変わる、極めて競争の激しい経済環境では、コンテナやマイクロサービスがもたらすスピードとアジリティが必要となる。Badani氏は良い面として、「業務に大きな変化をもたらすために、Facebook並みのリソースやスキルは必要ない。小規模グループで試験的に手を付けるのだ。そして、軌道に乗り、自信がついてきたら、技術面と人材面で拡張していけばよい。チームメンバーに対して、社外の人たちとやり取りし、技術や文化の難題について語り合うよう奨励してほしい」と述べている。
＃2：プラットフォーム
プラットフォームの選択は、コンテナやマイクロサービスへの取り組みにおける鍵となる。Badani氏は「プラットフォームによって、マネジメントやガバナンス、セキュリティの懸念に取り組むことになる」と述べ、「いろいろと試せるオープンソースのコンテナツールはたくさんあるものの、エンタープライズグレードのコンテナプラットフォームにはたいていの場合、『Kubernetes』によるオーケストレーションや、セキュリティ、ネットワーク、マネジメント、ビルドの自動化、継続的インテグレーションと継続的デプロイメントを含む、多くのオープンソースプロジェクトによる機能がすぐに使用できるかたちで含まれている」と述べている。
＃3：容量とライフサイクルマネジメント
Wilczek氏は「コンテナやマイクロサービスはいずれも容易に置き換えられるため、そのライフスパンは比較的短いものとなっている」と述べ、それが数日単位になる場合もしばしばだとしたうえで、「ライフスパンの短さと密度の高さにより、監視が必要な対象の数はかつてないほど多くなる」と述べている。また、コンテナは多くのメモリを必要とする。同氏によると、ここでの難問は「自らの運用環境をアタッチすることで、イメージはすぐに数百メガバイトに達する」点だという。同氏は、継続的なライフサイクル管理プラクティスとして、「共有リソースを解放し、容量から来る制限を回避するために特に、古いイメージの退役」を推奨している。割り当てメモリを解放するための、コンテナの迅速な退役を実現するうえで、包括的なライフサイクル管理に向けた取り組みが必要となる。
＃4：ネットワーク層
Wilczek氏は、ネットワークが（そして仮想化されたネットワーク層であったとしても）、マイクロサービスとコンテナ化されたアーキテクチャにおけるパフォーマンスのボトルネックになる可能性を述べたうえで、「パフォーマンスやロードバランシング、シームレスなやり取りという観点からの密接な監視」が必要だと警告している。
