本文要点
在向云端迁移时，如果使用的是以架构为中心的方法，那么并不会提供用户想象中的优点。
尽可放心使用那些无需自己管理架构的甲方云服务。
在规划故障时，确保考虑了应用故障、服务故障、架构故障和设施故障。
认真考虑所需的服务规模，充分利用云所提供的弹性，一些时候，还需要考虑能节约费用的长效合同。
最近我参与了一个企业IT资产组合向云端的迁移，其中包括了基础架构和应用。我注意到我们过分注重于基础架构方面，而忽视了云端对应用本身的影响。在我看来，应用架构在云时代扮演着更重要的角色。根据自己在云端实施方面的经验，我提出了一些专注于应用程序架构的原则。遵循这些原则，将有助于用户真正地获得云计算的优势。如果你仅依赖于以基础架构为中心的方法，那么迁移到云端将只会是又一次转变，而非转型。
松耦合。云使得我们可以按需扩展和缩小容量。但这只有当我们的系统（或子系统）是无状态时才可以实现。系统（或子系统）应是松耦合的，这样各个部分可以根据各自的负载需求分别进行缩放。
如果应用程序和Web服务器是松耦合的，那么两者均可独立地缩放。要实现这一点，需使用云原生的负载均衡器或队列机制。这允许系统缩放到任意规模，去除了依赖约束。此外，在混合云场景中，队列机制是连接系统的最好选择之一。
单一职责的服务器。这个概念是我从面向对象编程中借鉴而来的。一般来说，我们倾向于将一台服务器用于多个目的。然而，云使得我们可以创建不同规模的服务器，从非常小到非常大。反过来，这使得我们可在指定的服务器上仅部署一个代码库或可执行单元。通过这样的做法，一个应用程序组件的更改就不会影响到其它任何组件。要实现上述模式，请遵循蓝绿部署（Blue-Green Deployment）方法，确保对一个组件的部署不会造成其它组件的停机。
自动部署。云使我们具备了按需提供资源的能力。但是除非我们可以做到无需任何手动干预就在动态配置的基础架构上运行应用程序，我们才能充分利用这种能力。这意味着我们不能交互式登录到服务器去部署应用，应该使用编程的方式去应用配置和设置。换句话说，应禁用主机登录，通过云提供商提供的脚本或API完成所有的配置和设置。
使用本地云服务。许多云实施依然专注于将云主要用作“基础架构即服务”（IaaS）的托管模式。在自治（Self-managed）模式中，定义用于横向和纵向扩展的触发器是我们自身的职责。对于许多原生云服务，云提供商负责底层硬件设施的横向和纵向扩展。云服务提供商负责硬件的配置、构建和设置、复制，以及一些情况下的软件打补丁和集群扩展。云的真正优势所在，只能通过使用原生云服务实现。
例如，使用AWS Lambda、Azure Functions、SQS或类似的原生云（Cloud Native）服务，就可以摆脱对基础架构的定义。将这个工作交给云提供商！使用托管数据库服务，例如AWS RDS，DynamoDB或Azure DocumentDB，避免使用自治的数据库。这种做法存在一个缺点，它会将应用程序绑定到相应的云平台。事实上，如果使用了云互操作（Cloud Interoperability）模型，就无法充分地利用云。这类似于不同的操作系统以自身的方式提供了类似的功能（例如，文件系统访问，网络，编解码器等），每个云提供商都对通用的功能给出了自身独有的建议方法。
将本地存储看做是临时存储。作为扩展或部署实验的组成部分，托管在云虚拟机上的应用可随时丢弃。重要的是，应用不会在虚拟机本地存储任何值。虚拟机的本地存储应被视为临时存储。它会与虚拟机一并丢弃。在传统方法中，应用将配置、日志文件、图像等存储在本地存储中。然而，需要改变这种做法，任何持久信息都应转移到一个持久的服务上，实现数据块或对象的存储。云应用程序应支持蓝绿部署，这只有在当前执行的代码没有绑定到本地存储时才可能实现。
设计应始终针对故障。在云中，我们不知道应用运行所在的位置。硬件会易于出现故障，软件更新和补丁也会易于出错。最好是在架构和设计时，就考虑到对应用故障的处理，而不是去考虑并力图实现稳健性。稳健性是永远也不可能实现的。消除单点故障（SPOF，Single Point Of Failure），逐层构建弹性。这样，即使底层硬件发生故障，应用也可正常运行。