混合云与多云管理进入架构时代！

　　混合云融合了公有云和私有云，是近年来云计算的主要模式和发展方向。我们已经知道私企业主要是面向企业用户，出于安全考虑，企业更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源，在这种情况下混合云被越来越多的采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到了既省钱又安全的目的。

　　随着运维流程变得越来越灵活，IT团队面临着越来越大的复杂度。当应用动态改变时，可以使用敏捷或者持续应用开发。但是当IT资源本身动态变化的时候怎么办呢?

　　多云和混合云是这一新的、动态的IT大格局的一部分——并且带来了新的风险。要解决这里的问题，一些企业使用了基础架构即代码方案。

　　配置管理(CM)在大规模IT基础架构里一直是必需配置。有一些CM工具，来自于云供应商，比如AmazonWebServices或者MicrosoftAzure，或者来自于虚拟化或私有云软件供应商，比如OpenStack或者Vmware。

　　基础架构即代码通过为应用程序创建虚拟托管模型来扩展了CM。这样虚拟的托管模型散布在多个云环境和数据中心平台里。

　　虽然基础架构即代码是CM的一种扩展，它其实是作为DevOps的扩展才开始流行起来。用户无法在还没有搭建好的服务器或者云服务上部署应用程序。因此，DevOps工具和脚本必须包含这些配置任务。这使得DevOps脚本和工具是和配置绑定的;如果从一个云平台改变到另一个平台，用户就必须更改脚本。基础架构即服务提供了一种方式，将应用程序的虚拟世界和底层资源，包括云，隔离开。有更多的托管方案存在，基础架构即代码就会更加有价值。

　　基础架构即代码模型为部署描述创建了中间层;用户将应用程序部署到基础架构即代码所创建的抽象的托管模型里，基础架构即代码随后将其适配到当前使用的任意云，多云或者混合配置环境里。基础架构的变动在应用程序和运维层是不可见的，并且添加新的云供应商仅需要在基础架构即代码里完成其定义即可。

　　但是，基础架构即代码的用户需要注意如下三大重要步骤：

　　1.将基础架构即代码从DevOps中隔离

　　IT团队能够将基础架构即代码部署到定义了配置脚本的任何环境里，并且使得应用程序能够适配几乎所有公有云服务或者数据中心平台。

　　IT团队需要基于哪种基础架构即代码将部署配置，来定义IT资源的抽象模型。基础架构即代码工具和实践变化很大。一些用户为每个应用程序都构建了基础架构即代码，而另外的用户为每种类型的云托管环境，比如基础架构即服务，平台即服务或者Docker，构建通用的模型。

　　总的来说，最好减少创建出的抽象托管模型的数量，因为当添加新的托管选择时，你必须调试每个模型。工具允许的情况下，考虑层级构建模型，这样部署应用组件——或者某个应用的一部分——的基础架构即代码模型，可以在部署整个应用程序的模型里直接引用。

　　2.为使用的所有云或者数据中心环境保护对基础架构即代码的支持

　　一旦你理解了所需模型，要确保它们能够支持计划使用的特定的云供应商和数据中心的配置。几乎所有基础架构即代码工具，比如Chef和Puppet，都让用户为任何环境定义自己的配置规则，但是流行的公有云，私有云和平台方案——比如hypervisor，容器系统和服务器操作系统——都作为基础架构即代码工具集的一部分提供。还可能有社区的支持，其他用户将他们的配置规则贡献出来。从已经能够工作的配置上开始开发，比从头开始构建自己的要更加容易。

　　3.将事件流从基础架构推广到部署工具

　　完成基础架构即代码方案中最微妙，困难和重要的事情是，处理基础架构即代码和其他工具集成的事件流;大多数情况下，这意味着使用DevOps工具。应用程序生命周期运营管理需要根据情况选择合适的软件——这些条件就是基础架构即代码里的事件。这些事件，通过托管资源生成，充当干什么事情的信号。他们通常激活一个自动化流程，比如通过在别的地方托管来替换发生故障的应用程序组件。

　　基础架构即代码事件和流程紧密链接，这也是为什么大多数计划使用混合或者多云部署的企业会研究其DevOps工具对基础架构即代码的支持，而并不使用单独的工具。基础架构即代码和DevOps的集成确保事件触发流程的正确设计和实现。

　　将基础架构即代码集成进DevOps还能够帮助用户避免常识性错误。如果已经有了特定的工具，并且如果基础架构即代码集成进了DevOps的话，使用基础架构即代码计划托管资源就会更为容易。这是因为虚拟化整个部署流程以及基础架构即代码的资源角色会更加容易一些。DevOps工具和包会公布其支持的公有云服务，如果DevOps工具包含基础架构即代码组件，用户就知道该工具能够和列出的公有云一起工作。

　　对于信息控制、可扩展性、突发需求，以及故障转移需求来说。混合和匹配私有云和公有云是一件好事情。我们已经建立了一些云计算模式：私有云，公有云，公众云，以及混合云。根据国家标准和技术研究所的定义，很多企业已经在不同的、更加复杂的方向上适应了这些模式。最近，云计算的发展计划开始围绕整个架构支持方面，围绕混合云，或者是混合、匹配各种云计算模式来展开。

　　顾名思义，混合云，是目标架构中公有云、私有云和/或者公众云的结合。由于安全和控制原因，并非所有的企业信息都能放置在公有云上，这样大部分已经应用云计算的企业将会使用混合云模式。很多将选择同时使用公有云和私有云，有一些也会同时建立公众云。

　　有趣的是，并不是说私有云和公有云各自为政，而是私有云和公有云同时协调工作。下面是一个经典事例：在私有云里实现利用存储、数据库和服务处理，同时，在无须购买额外硬件的情况下，在需求高峰期充分利用公有云来完成数据处理需求。目前，已经有很多企业都朝着这种集中云(cloud-bursting)的架构发展，同时这也是实现利益最大化的关键。

　　因为公有云只会向你使用的资源收费，所以集中云将会变成处理需求高峰的一个非常便宜的方式。比如对一些零售商来说，他们的操作需求会随着假日的到来而剧增，或者是有些业务会有季节性的上扬。

　　同时混合云也为其他目的的弹性需求提供了一个很好的基础，比如，灾难恢复。这意味着私有云把公有云作为灾难转移的平台，并在需要的时候去使用它。这是一个极具成本效应的理念。另一个好的理念是，使用公有云作为一个选择性的平台，同时选择其他的公有云作为灾难转移平台。

　　当然配置方式和这些方式背后的目的是很多。数据显示，大部分使用云计算的企业将会应用几种混合云的类型，这其中的很多简直太复杂了。

　　不管你在IT行业已经待了多久，你都会意识到这些都不新鲜：只不过是把你现有的IT资源重新分布和整合。不过，在云架构的选择上，我们又多了混合云这样一个选项。

　　要更加高效，基础架构即代码必须和DevOps紧密合作，但是同时又保持自己的特性。如果不仔细的话，就会开发出界线模糊的配置和部署实践，并且逐渐侵蚀资源的独立性——这其实是基础架构即代码的最大优势所在。在多云和混合云的部署里，维护敏捷基础架构至关重要，因此这应该成为特定的目标。

　　更多详细内容，尽在课课家教育，我们期待您的咨询！