当我和人聊关于使用微服务架构风格时，我感受到许多人的乐观主义。开发人员很享受在更小的单元上工作，期待比单体系统更好的模块化。但是任何架构决策都需要权衡。具体到微服务，对于运维来说有几个重要的影响，他们必须要面对小服务生态，而不是单一定义良好的单体。因此，如果你没有一定的基本能力，你就不应该考虑使用微服务。
快速供应：你应该能够几小时之内启动一台新的服务器。这对于云计算轻而易举，但也应该在没有完备的云服务的情况做到。为了做到快速供应，你需要许多自动化 —— 可能开始没有完全自动化，但在以后做真正的微服务就需要。
基本的监控：在生产环境中，许多松耦合服务相互协作，一定会以难于在测试环境侦测到的方式出错。因此，恰当地构建一个监控体系以便迅速捕获严重的问题是必须的。这里的基线是侦测技术问题（统计错误，服务可用性等）但也值得监控业务问题（如检测订单下降）。假如出现突发问题，你需要确保你可以迅速回滚，因此。。。
快速应用部署：对于许多需要管理的服务，你需要快速部署它们到测试环境和生产环境。通常这涉及到几个小时内就可以执行完毕的部署管道。早期，一些手动交互是可以的，但你要尽快寻求全自动化。
这些功能意味着一个重要的组织转换——开发运维的紧密协作：也就是Devops文化。这种协作确保快速完成（基础架构）供应和（服务）部署。当你的监控显示出了问题，你能够做出快速响应也很重要。具体的说，任何事故管理都需要开发和运维介入修复即时问题和进行根本原因分析以确保修复底层问题。
有了这类设施之后，你就可以开始第一个使用少量微服务的系统了。把它部署到生产环境，并使用它。期望使它保持健康运行并确保devops良好协作。给自己足够的时间做这些，并从中学习，成长，之后再增加服务的数量。
如果你现在没有这些能力，你应该确保先培养它，直到准备好了，就可以把你的微服务部署到生产环境。实际上，对于单体系统你也真正应该需要具备这些能力。虽然他们在软件组织中不是普遍存在，但都是以高的优先级存在。
继续向你的系统中增加更多的服务要求就更高。你需要跟踪跨多个服务的事务和通过完全的采用持续交付实现自动供应和自动化部署。也需要开始切换到产品为中心的团队。你需要组织你的开发环境以便开发人员可以在多个仓库，库，和语言之间进行方便地切换。我的一些联系人觉得这里可能有一个有用的成熟模式能够帮助到那些实现更多的微服务的组织——关于此，在接下来的几年应该会有更多的对话。
