刘杨
对于许多企业而言,使用多个公有云不可避免,大多数大型企业都在使用多云,将所有开发、数据和影子IT等工作引导到单个公共云需要很高的管理水平。全球企业和大型企业确定使用多云的原因有以下几个。
IT领导者十分了解建立安全且强大的云基础架构的复杂性,当组合多个云时,这些复杂性会成倍增加,企业应该努力避免一次处理所有问题。
由于跨多个云的操作很复杂,建议IT团队尽可能利用其主要云提供商,而不是在第二家提供商那里寻找新的或更好的功能。在公共云中没有一种万能的方案,而且只有40 %~ 60 %的需求可以通过一个提供商找到。
一些IT领导者分享了关于多云如何发展以及如何应对初始复杂性的务实观点,大数据顾问Travis Campbell就多云的使用提供了以下见解:做多云的公司,实际上每个业务线都将其视为单一云,这不是一个特例。例如,财务可能在云X上有应用程序,而工程正在部署到云Y,并且工作和数据没有交叉,它是没有问题的多云。
因此,对于已经为不同目的独立运营多个云的企业而言,下一步将是跨这些云的应用程序集成、数据集成或服务编排。这就是那些难题的开始,最好缓慢而谨慎地进行。
其他IT领导者也表达了类似的看法,许多人指出,如今支持多云并不容易,IT领导者应该在认可多云架构之前确定强大的业务原理。
Edgevana的首席执行官兼创始人Mark Thiele概述了从多云架构中寻求的许多战略优势:“当多云为我的客户提供一个或多个显著的价格价值、上市速度、独特的技术能力、推动更好的价值、创新和性能改进时,我会着手使用多云。”
Palo Alto Strategy Group的执行技术专家Mike D. Kail对此表示赞同:“考虑使用多云的主要原因是,当云服务提供商提供的服务远远优于其最初部署中使用的服务时,用于人工智能和机器学习的TensorFlow就是一个例子。”
下面提供了一些操作指导:
许多企业会选择一个平台作为主要关注点,而其他平台则根据业务利益来满足特定的需求和解决方案。IT领导者必须从战略、支持和流程的角度定義如何处理多云。当引入其他平台时,会有一个框架和结构来提供其方法的一致性。不要因为“云蔓延”而让它成为现实,因为这总是会导致灾难。
HPE金融服务首席技术专家Chris Ibbitson表示,企业在公有云和私有云中寻求敏捷性。“无论是与公有云提供商合作,还是在混合云模式中,利用私有云功能或多个公有云提供商的组合,都专注于交付变更的敏捷性和速度。虽然大多数企业已经采用了某种形式的混合云,但现在的重点正在转向多云。”
因此,IT部门可能会引入第二家云服务提供商来支持特定的业务或技术需求。在这些情况下,IT领导者应该定义每个云将服务于哪些业务和用例,以及每个云将提供哪些服务和技术。
当然,还有一些额外的原因:
大型企业试图避免依赖单一的云服务提供商,特别是当他们希望就特定企业的服务水平和定价进行协商;
数据主权与合规性通常需要将数据存储在居住国,对加密和数据安全的具体要求,甚至是对云服务提供商的具体要求;
寻求并购的企业通常针对多个云服务提供商和支持模型,以简化支持结构;
IT需要特定的技术能力,尤其是在大规模部署时,部署到一个云服务提供商可能比部署到另一个云服务提供商更具有战略业务优势;
当IT选择自行管理在公共云上运行的商业购买应用程序时,它已经采用了不同于公共云的开发标准。特定于行业和其他小众的应用程序可以在单个云服务提供商上提供结构和支持模型;
混合和多云架构也提供了技术优势,特别是在边缘计算、安全应用程序和实时分析方面。
虽然企业可能有一些理由来支持多云架构,但IT领导者仍然强烈建议执行财务分析并审查云运营模式。
企业最好想明白这些问题:收益是否会大于部署和运营多云架构的复杂性?是否存在短期和长期的财务影响?
Nutanix财务副总裁Steven Kaplan对此表示赞同。他建议:“与任何重要的IT决策一样,必须进行全面的财务分析,不仅要选择最具战略意义的最佳解决方案,还要为下一步提供理由和财务基准。”
如果有正当理由,IT部门必须考虑将其服务模型和专业知识从单一云扩展到多云。Featherston指出,云计算更多的是关于人、流程和文化,而不是关于技术。“企业应该尝试在其组织中经历这些巨大的转变,首先为一个平台奠定基础,并提供在其他平台上发展的框架。”他说:“基本上,先弄好一朵云,然后再向外延伸。”
建议从基础设施即代码工具开始。它们支持某种形式的基础设施自动化和配置,虽然他们没有解决云治理的整个范围,但拥有可编程和版本控制的基础设施很重要。
稳健的devsecops实践,尤其是围绕用于部署应用程序的CI/CD、用于供应和配置基础设施的基础设施即代码以及包括AIops在内的监控功能,对于实施和支持多云架构都至关重要。
但并不是所有的devops技术或devops实践都可以,因为有些技术更适合多云战略。一种方法是避开云服务提供商的专有工具,例如AWS CloudFormation、Azure资源管理器或谷歌云部署管理器,即使有些提供多云支持。企业IT团队还应将其devops文化从以部署频率为重点扩展到包含部署敏捷性。
基础设施即代码应该是减轻配置漂移的筹码,从一开始就需要对安全进行架构设计,诸如Terraform之类的工具肯定会有所帮助,可以跨越多云的安全解决方案也至关重要。
多位IT领导者推荐Terraform用于多云架构,因为它是一种声明式、无代理、无主配置工具。一种推荐的架构将Terraform与Packer、Docker和Kubernetes配对,以支持配置、服务器模板和编排。
但是,选择支持多云的工具并不意味着实施支持多云。 Featherston推荐Terraform,但带有免责声明。“我的一个警告是确保客户理解,它是一种在多个平台上使用的通用语言,但构建AWS的代码并不能构建Azure,”他解释道:“这样做的好处是团队可以使用一种通用语言进行编码,但代价是并非所有平台功能都可用。”
除了基础架构即代码之外,建议使用以下工具、实践和治理来满足多云需求:
应用程序和单个虚拟机的自动化和编排;
安全性,包括身份管理和数据保护/加密;
政策治理和合规性,包括审计和SLA指标;
基础架构(即计算实例、存储、网络)和应用程序的性能监控;
通过资源优化和计费估算进行成本管理。
尽管当今采用多个公共云存在诸多复杂性,但IT领导者的共识是,大多数企业将支持多云架构,甚至跨云集成应用程序。我们可以借鉴历史,举几个例子,企业必须支持Linux和Windows、.NET和Java,以及Oracle和Microsoft SQL数据库。
预计将在未来3~5年内看到多云的演变,默认情况下,更多的工作负载被设计并从底层云提供商中抽象出来。重点将放在不同云提供商可以启用的高级功能上,例如人工智能、机器学习和分析。
多云架构维护起来既困难又昂贵。企业需要对单一云提供商保持战略性,对多云业务保持战术性,并不惜一切代价避免在基础设施层为相同的工作负载执行多云。
一次构建,随处运行是我们都在努力达成的目标,成功使用多云仍有希望。