目前，一些大型企业都在AWS的基础之上部署微服务架构。这一举措能够为企业带来什么样的好处呢？

微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

对于大型应用程序来说，增加更多的用户则意味着提供更大型的弹性计算云（EC2）实例规模，即便只是其中的一些功能扩大了规模亦是如此。其最终结果就是企业用户只需为支持超过微服务的那部分需求的EC2实例支付费用。一些大型企业（如Netflix和Nike等）都在亚马逊Web服务（AWS）的基础之上部署了一个微服务架构，从而提高灵活性和以较低的价格来实现应用程序的扩展。Netflix横跨其30个工程团队设计部署了500多个微服务。

在容器和代码之间进行选择

微服务架构是把应用程序作为独立可部署服务组合的一个设计方法。虽然对于这一概念还没有确切的定义，但是这些架构往往是围绕业务能力、自动化部署以及去中心化管理来组织设计的。
很多企业都正在使用容器技术，例如基于亚马逊EC2容器技术的Docker，就让在EC2实例的托管集群上运行应用程序成为可能。这样做就降低了对安装、运行和扩展集群管理基础设施的要求，而这正是部署单个微服务组件所需要的。但是并不需要为实施微服务而设计容器。

诸如AWS Lamba这样的新服务让部署一个微服务架构且无需容器或虚拟机成为了可能。Lambda运行代码响应事件和管理计算资源，从而让建立响应事件或流量的微服务集合变得更为简便。开发人员可以在Lambda上在诸如网站点击这类毫秒级事件内启动新服务；计费增量以100毫秒计。

简化至微服务架构的转移

企业的架构师们有大量的最佳实践可以遵循以便最好地实现至微服务的转移，具体包括正确选择存储设施、重新思考传统IT竖井式系统、创建微服务组件之间的边界，等等。
为每一个服务选择最佳数据存储。微服务架构的优点之一就是单个微服务都是松散耦合的。这样就能够让开发人员选择最适合某一特定微服务的开发语言和数据存储，而不是对所有的组件都使用一个数据库。

使用微服务团队取代“竖井”。对于一个微服务架构，软件开发团队必须保持密切协作和可扩展的态势。Conway的Law表示，一个软件系统的接口结构往往反映了开发这一软件系统的组织的体系结构。为了切换至微服务架构，企业需要组织员工成为有组织的生产团队并使用开发运营方法。

传统软件团队的组织架构条块分割，形成了泾渭分明的开发、质保以及生产小组。“你需要一个小型团队来负责它的微服务——从概念形成、概要设计、详细编码、组织测试到实际部署——然后（据推测）就是解bug和升级更新，一家应用程序交付平台供应商Nginx的产品负责人Owen Garret说。
像对待网络应用程序一样看待微服务。必须在微服务组件之间建立强边界。像对待网络应用程序一样看待微服务意味着独立开发团队不需要对不同微服务的内部工作原理有一个透彻的理解。反之，微服务需要一个可执行相关功能的API。

“你不需要透露你的微服务的任何内部信息，”Garrett补充道。“另一个微服务的开发团队完全不需要了解微服务的表达方式或者内部数据是如何对其进行请求的。”只要相关API与其他微服务的关系不被打破，那么这个方法就可以让开发人员按需求修改微服务。

使用声明合同。程序使用服务合同的声明特性，而不是执行如何使用其它服务的程序。使用一个抽象方法来运行需求是更简便的；一组解释性的步骤将让程序变得更为静态。这意味着开发人员可以通过策略实施应用程序并向基础设施发送指令。

例如，开发人员可以不对EC2语义进行编码，他们可以使用策略把数据移至AWS产品。可以把声明纳入到容纳微服务的容器中，或者把声明嵌入到被用于与AWS产品进行通讯的Lamba代码中。
使用OODA循环。因为不同的团队会开发不同的微服务，所以企业必须确保软件开发团队都有着一个共同的工作目标。这样，使用Netflix的Observe、Orient、Decide、Act（OODA）循环将会有很大帮助。

在一个OODA循环中，观察（Observe）涉及检查代码库的当前状态以寻求进行创新的机会；定向（Orient）表示分析指标以了解已观察到的现象；决定（Decide）则是制定和执行项目计划的过程；而行动（act）是测试解决方案并将其投入生产的过程。