微服务架构可能不适合所有企业
微服务架构可能并不适合于所有企业。对于那些IT资源有限的小公司来说，微服务并不可行。对于那些遗留系统运行尚可的公司来说，可能不值得尝试将他们的系统分解为多个微服务。它甚至可能不适合于DevOps文化。
这个观点来自于Stripe工程师Susan Fowler，她同时也是“生产就绪的微服务”的作者，前Uber公司微服务团队的一名工程师。最近Fowler与InfoQ的Thomas Betts进行交谈，提出微服务项目的最佳候选者是那些遇到了可扩展性问题的公司。微服务可以帮助管理应用，在这些应用中“可扩展性方面的局限可导致服务器性能和稳定性的问题，无法在这个应用上进行任何工作，开发者速度显然也受到了影响”。
（巧合的是，另外一位Fowler——Martin Fowler早在2014年为微服务奠定了基础，包括对微服务进行定义：“微服务架构是一种把单一应用作为一套小型服务进行开发的方法，每个微服务都运行着它自己的进程，与轻量级机制——通常是HTTP资源API——进行通信”。）
对于很多组织机构来说，要想实现一个运行良好的微服务架构也许并不困难。“大多数系统并不是以考虑微服务架构而设计的，”Susan Fowler这样表示。因此，很多微服务最终被设计成了独立于孤岛环境，或者孤岛环境中的孤岛。
据Fowler的观察，微服务也不一定能与DevOps环境很好地融合。特别是在大型数据中心内，开发工作和运营工作显然是分离的。然而在微服务架构中，“会有数十个、数百个甚至数千个微服务，因此，许多微服务开发团队，以及这些团队中既是开发者又是运营工程师的工作人员可能从组织架构上来说都是没有意义的。”
但是，微服务架构也需要很好地适应所在的组织机构。在另外一篇博客文章中，Fowler主张采取一种四层方法：
硬件层：配置管理工具、数据据、服务器、主机层日志记录和监控、操作系统、资源隔离、资源抽象。
通信层：DNS端点、负载均衡、通讯、网络、远程过程调用、服务发现、服务注册。
应用层：部署管道、开发环境、微服务层日志记录和监控、自助服务式内部开发工具、测试、包、构建和发布工具。
