混合云架构的7个规则
混合云架构的7个规则
JP Morgenthal 的这篇文章来自 DZone 的云开发指南 - 2015年版（Guide to Cloud Development - 2015 Edition.）。欲了解更多信息，包括行业专家的深度文章，PaaS，iPaaS，IaaS和MBaaS的最佳解决方案，请点击以下链接下载免费的指南。
研究公司IDC预测，到2016年，超过65％的企业IT将致力于混合云技术。 IDC并不是唯一一家预测混合云计算企业采用率将会升高的企业，Gartner Group也预测，到2017年，50％的企业将部署混合云，DZone的2015年云开发调查显示，目前有50％的受众使用混合云技术。
混合云架构经常被描述为“私有云和公共云共享资源”。但事实上，许多混合架构只是利用公共云资源与私有托管应用程序相结合。例如，企业可能会从公共云上的多个外部源捕获，聚合和分析数据，然后将这些结果传递给在私有托管环境中运行的应用程序。或者一个企业可能会将其公共网络存在于公共云中，但将该应用程序的数据保存在私有托管环境中。
这种公私合作会带来潜在的复杂性。本文将介绍采用混合云架构时要考虑的七条规则。
规则1：您正在扩大您的业务范围
部署混合云体系结构时要牢记的最重要的事情之一是，您正在扩大您的业务范围。虽然这看起来很明显，但它可能会对IT运营和开发组织产生真正的影响。考虑以下问题：
- 哪个团队负责在公共云中运行的组件？
- 您的IT运营团队是否准备好管理另一个平台？
- 您当前的监控和操作工具是否可以与公共云提供商一起使用？
- 这个架构对服务台的调用有什么影响？
- 公有云和数据中心之间的网络中断应急预案是什么？
正如您所看到的，混合架构可能会要求您聘请具有适当技能的人员在所选公共云平台上运行。同样，如果当前工具不支持所选的云平台，则可能需要购买新的监控工具。一些组织可能会选择使用“NoOps”方式。（在这种方式下，开发团队负责在公共云上运行的应用程序组件 - 这是一种消除IT运营负担的方法，但却导致需要定义新的操作业务流程。）
这里关键的一点是，由于按需计算的性质，决定采用混合式可能看起来很简单，但不应该对业务掉以轻心。
规则2：不要与YouTube和Facebook分享您的网络
确保您与您的网络运营团队合作，确定混合应用程序周围的网络要求。有时候唯一的协作就是开发人员要求向公共互联网开放一个端口，以便私人托管的应用程序可以接收来自公共云应用程序的请求。
如果网络运营不知道是否需要与公有云建立连接以保证服务质量，那么您的应用程序流量可能会与在Facebook上观看猫视频的同事共享带宽。您的网络运营团队需要成为部署您的混合云应用的团队的一个组成部分，以便他们可以专注于适当的连接和流量整形。
规则3：避免反向数据引力
简单地说，“数据引力”就是过程应该迁移到给定数据相对质量的数据的理论。也就是说，当您考虑以TB或PB为单位运行数据时，流程相当轻便。但是，混合云体系结构有时会遭受“反向数据引力”的困扰，因为使用混合云意味着在私有托管环境中保留（某些）数据。也就是说，托管在公有云中的进程从私有方绘制数据。这是一个限制风险的架构选择，但在某个时刻，业务需要确定什么是可接受的数据量，在达到收益递减点之前可以移动。进一步影响反向数据重力是通过服务提取数据或直接连接到私有数据源的选择。后者很可能会导致更多的数据传输。
此外，由于您现在拥有在公共云上运行的应用程序组件，因此公共云和私有云上都会生成数据。具体来说，日志是通过公共云上的活动生成的 - 这意味着要对新数据进行管理和分析。
规则4：信任只能到此为止
这也被称为明知故问（ Captain Obvious）规则。但事实是，有时企业为了简单而做出的选择很差。例如，一些企业实际上已经在私有云上存储了私钥，从而能够连接到私有托管环境。这为私人环境带来了重大的风险。如果需要密钥，则应将其加密存储在第三方存储库中，并在需要时由进程提取，并在不再需要时进行删除。这种关注的分离显着增加了攻击面。
以下是一些其他的最佳实践建议：
- 限制可以与数据中心建立安全连接的端点数目
- 限制在公共云中的互联网服务器（Internet-enabled servers）的访问
- 从公共云上离开安全区域的流量应该通过网络地址
请注意，NAT服务器通过限制访问公有云上的专用网络区域来提供更高程度的安全性。但是这也是一个流量瓶颈和单点故障，因此可能需要高可用性和负载平衡解决方案来获得必要的性能。
规则5：应用程序重新设计可以提供更好的性能
如果我们将传统的三层（three-tier）Web应用程序视为混合架构的良好模型，那么在公共方面拥有Web界面而在私有方面拥有应用程序服务器和数据库是一种自然的倾向。但是，这种架构可能无法为应用程序提供最佳的经济性或性能。
有时重新设计应用程序以更好地利用公有云服务，同时仍然提供混合云架构的好处是有利的。如FIG.1所示：从左向右移动，我们可以看到应用程序的各个部分开始转移到公有云。第一个过渡说明应用程序服务器的拆分，以便某些服务可以在Web服务器上本地运行，而其他服务器则在数据库本地运行，如果存在计算功能和数据管理功能的划分，则这是一个很好的折中。
最右边的例子表示将所有数据移动到公共端，但也许使用缓存技术或NoSQL数据库来临时存储数据，以便计算功能可以更有效地响应。这些修改具有减少延迟的效果，对用户交互更加敏感，并且限制了需要传回私人端的数据量。
规则6：不要把公共云看作另一个数据中心
回归到我们所知道的未知或未知的领域是人类的天性。对于运营人员来说，即使他们在云平台上进行了培训，他们也将对自己在过去几年的职业生涯中的运作方式非常熟悉。这意味着过度配置，云计算意味着订购比您真正需要的更多的虚拟机和存储服务。也可能意味着他们选择部署和管理所有软件组件，而不是使用公共云提供商提供的服务，例如关系数据库和队列服务。
公共云的价值不仅仅是资源的可用性。公共云也让你获得这些具有良好的经济价值的资源。利用折扣政策等优惠政策是一种更好的选择，而不是按需购买。使用提供高可用性和故障转移选项的工具和服务可以比手动构建这些功能更有效，成本更低。由于私人托管环境中不存在这些选项，所以操作往往被迫进入双重状态，需要不同的方法来管理资源。对于许多人来说，这种双重性可能令人不安和困惑。
规则7：测试，测试然后再测试
测试您的混合云架构需要了解构建分布式应用程序的常见问题。网络变得如此可靠，有时我们认为我们的数据包会到达目的地。但是，虽然网络一样可靠，由于硬件故障或流量增加，仍然会发生传输错误。关键是在面对这些故障时为您的应用程序开发适当的弹性。
应用程序开发人员花费了数年的时间来处理数据中心内的可靠性问题，这可以依靠光纤连接和高速连接。当我们转向混合架构时，我们经常通过较慢的连接进行通信，并与其他应用程序共享带宽。因此，我们需要一些额外的测试来确定我们的应用程序将如何响应。
以下是我们为混合应用推荐的其他测试列表：
- 网络故障测试
- 增加了延迟测试
- VM服务器故障测试
- 无效的消息测试（针对服务）
- 授权测试
- 认证测试
结论
正如我想说的：“混合云架构很容易...直到他们不容易。” 管理企业规模，强大的混合云部署涉及到许多隐藏的复杂性。在数据中心内以孤立方式运行的应用程序的方法和跨越地理边界的普通广域网络的方法不能期望行为相同，也不能以相同的方式操作。遵循这七条规则提出的建议，我希望，将帮助您交付有弹性的混合应用程序。