企业是否应部署软件定义的数据中心？_公众号

软件定义的数据中心标志着数据中心基础设施和自动化架构的下一演变。但是，我们并不建议所有IT企业都部署SDDC.企业的领导者们务必先要了解业务价值、最佳用例和相应的风险。

当前的企业正面临着需更快地响应并规模化扩展以满足业务需求，并同时支持混合云解决方案、分析、数字化业务、物联网、移动化和边缘计算的新应用程序架构的挑战。

应用程序编程接口（API）正在成为数字化数据中心的“粘合剂”，但仍然需要一款跨所有这些API的协调引擎来协调，并最终提供业务服务所需的技术能力。

基础架构供应商们正在积极向其平台添加API，但这些API不是标准的，也不是跨供应商开源的，哪怕是来自同一家供应商。

除了需要在内部实施大量部署工作外，软件定义的数据中心的（SDDC）实施还涉及到新的IT技能和企业文化转变。

企业领导们应关注于基础设施的灵活敏捷性：

通过确定企业的业务模式和IT项目、以及使这些成果成为可能的技术要求，进而从SDDC中获得最大价值。

根据业务成果确定SDDC业务案例的优先级顺序，如产品上市时间、降低运营成本和加快变更速度（敏捷性）。

以一个小的，焦点型用例开始您的SDDC计划，从中学习，然后逐步扩展。

减轻SDDC项目的最大风险，如技术不成熟和供应商锁定，同时意识到所有软件和自动化都会产生一定程度的锁定。

如果您不是某技术的早期采用者，并且对于工程和编程方面缺乏深入的专业知识，则不要构建完整的SDDC架构；而应选择在其成熟时再部署特定的软件定义组件。

战略规划假设

到2022年，编程技能将成为50%的I&O职位角色的主要招聘标准，这在今天仅为20%.

到2023年，SDDC的规划能力将被全球85%的大型企业视为重要要求，远远高于今天25%的比例。

软件定义的数据中心是公共云基础设施即服务（IaaS）产品的基础，如Amazon Web Services（AWS）和Microsoft Azure.软件定义的方法可以通过自助服务目录或API来选择自动化和策略执行活动，并通过策略和分析以编程的方式实施。私有云服务今天很少部署一款完整的SDDC（除非是基于OpenStack）；然而，随着SDDC产品的成熟，他们将越来越多地这样做。

SDDC正在成为实现与数字化业务相关的业务敏捷性和加快产品上市的关键。通过软件定义的组件实现协调基础架构，如IoT，DevOps和云服务所需的基础架构，实现了通过使用API和策略推动更高端的端到端自动化、移动性和集成整合。

SDDC尚不成熟

挑战的关键在于：完整的、跨多个领域（例如计算，网络，存储，安全等）的SDDC仍然处于不成熟状态，不适用于广泛的内部实施（用于访问内部数据中心和基础设施）。因此，只有具有先进的I&O工程和架构技能的有远见的企业或具有非常孤立的用例的公司，将在短期（1 - 2年）内部署SDDC.其他对SDDC带来的灵活性感兴趣的企业将会寻求公共云提供商或者在场外管理的私有云来实现这一优势，而无需全面设计和部署SDDC.

然而，I&O领导者不能简单地采购一款能够提供业务灵活性和价值的现成的SDDC产品。相反，他们必须部署、整合和规划多个部分，而这些部分可能来自多家公共云IaaS提供商以及内部部署的厂商，如软件定义的存储（SDS）、软件定义的网络（SDN）、软件定义的计算（SDC）、软件定义的安全（SDSec）和软件定义的设施。

I&O技能更新和企业文化转变

除了需要大量的部署工作外，SDDC的内部实施还涉及新的IT技能和企业文化转型。例如，将网络，存储和计算资源分配给特定工作负载将需要IT人员为该分配进行逻辑编程或设置策略，而不是依靠电子表格和系统管理工具支持的主要手动流程集。此外，随着自助服务基础设施的出现，I&O领导者在直接通过使用API和服务目录来满足这些需求方面面临越来越多的挑战。这需要I&O预先为应用程序开发人员的消费进行设计和建立，而这正是大多数I&O企业所缺乏的技能。即使企业决定更全面地部署公共云IaaS，I&O也必须推动策略和自动化，例如，确保遵守弹性策略、备份策略和监控策略，同时保持开发人员尽可能高效。 I&O还必须通过具有安全性和应用程序和企业架构的通道来建立对公共云和公司所有基础架构（包括IoT传感器）的访问和集成整合的恰当功能。

随着云计算、DevOps和数字化技术的发展，许多I&O企业已经发展到更自动的SDDC业务流程功能。然而，由于缺乏技能，传统应用程序面临的挑战以及维持当前环境的要求使新功能变得越来越重要，使得这方面的进展往往缓慢。另外一个问题是，很少有SDDC产品将其功能完全扩展到公有云中；这种支持才刚刚开始。还有一个问题是缺乏真正的由产品供应商支持的行业标准API，这将SDDC的部署限制为大型供应商专有的。

对于I&O领导者来说，往往对这方面的变化存在恐惧，其也是非常真实的风险。SDDC的部署必须在不仅仅专注于速度的商业文化的背景下进行，而且也必须是精于提供业务价值和实现业务战略的企业文化。仅专注于潜在的技术能力，而没有与业务驱动力的紧密联系的IT文化将不是实施SDDC的好选择。

了解软件定义的数据中心

SDDC是一种协调IT基础设施和设备的架构方法，可提供诸如加快产品上市，增加自动化（如持续集成/持续部署[CI / CD]）和提高员工生产力等业务价值。如图1所示，SDDC实现了物理基础架构的抽象化，降低了通过虚拟化层访问物理基础架构功能的复杂性。虚拟层允许通过另一组API来访问物理层，这些API掩盖了下面的物理层（例如，允许访问存储，而不必准确地知道您正在访问哪些存储）。然后可以通过API或通过业务流程层直接访问虚拟层，从而通过其API在许多基础设施组件上实现可编程性。在业务流程层，可以为基于规则的业务流程启用策略（例如，在需求峰值时添加更多的基础架构）。

SDDC的目标是通过基于策略的流程自动化来提高基础架构的灵活性和速度，从而提供比传统的、更加手动的流程和脚本更大的业务价值。这包括基础设施选择，安全性，配置和持续的生命周期管理和优化。因此，通过减少管理需求并实现自动化的可重用性，可以节省运营成本。今天，许多运营成本节省可归因于个别的SDDC技术，如SDS、SDN或SDC.

在提供更大的业务价值的同时，SDDC能够将支持专有硬件的软件服务迁移到更高级别的软件服务层，通过分布式环境驱动配置，自动化和部署的策略，以及实现资本支出成本节约的潜力，其中包含商品化硬件的资源池。此外，SDDC可以扩展到传统硬件投资，从而通过抽象和可编程层增加其使用寿命。

了解SDDC的属性和分类

软件定义组件的主要属性和SDDC的标准如下：

● 抽象 - 从物理实施中获取资源，从而将资源与消费者分离。抽象可在配置和重新使用实例化的基础设施元素的逻辑模型时定义，从而实现标准化。

● 仪表化 - 用于监控、发布和智能分析基础设施（物理和虚拟）。

● 可编程 - 不仅可以实现自动配置服务，还可以通过记录的API（通常为RESTful API）实现所有IT流程。

● 自动化 - 使用API，借助脚本和其他自动化工具对暴露的元素进行接线，以删除“人为中间件”。

● 政策管理 - 通过预先建立的政策实现分散式基础架构的集中配置和重新配置，以满足业务需求。

● 协调 - 超越基于脚本的自动化功能，可实现跨计算，网络，存储，设施和安全性资源领域的任务自动化，并与策略管理联系起来进行强化和优化。

上述功能的结合将促进基础设施的优化和基础设施应用程序使用的创新。示例包括为SLA选择正确的基础架构，并动态优化基础架构以提高资产利用率。这些功能可以独立获取或作为一组功能的一部分来获取，例如在云管理平台（CMP）中。

图2显示了SDDC的更广泛的分类法以及“软件定义的任何东西”（SDx），Gartner用其来描述软件定义的任何东西，包括应用程序和基础设施的总称。SDDC是软件定义基础设施（SDI）的组成部分，SDI建立在SDDC之上，并扩展到SDDC，包括软件定义的设备和软件定义的机器，这将是IoT的关键组件。

SDDC被分解为多个组件 - 计算、存储、网络和设施 - 利用软件定义服务的应用程序，通过技术服务API请求基础架构服务。安全和管理是涵盖应用程序、应用程序服务和基础设施的跨域服务，也是API可访问的。每个组件都可以通过自己的业务流程层进行访问和管理，该层提供了一组API和策略功能，希望将一个业务流程引擎放在一起。逻辑蓝图或策略模板的目录可以实现特定基础架构配置（例如OpenStack Compute [Nova]中的“风格”）的可重用性，或者使用OpenStack Heat生成基础架构模板，例如用于低延迟的工作负载特定的存储配置文件和每秒高输入/输出操作，具有某些SLA保证）。公共云IaaS中的策略模板示例包括AWS CloudFormation模板和Microsoft Azure资源管理器模板。

当业务案例变得有价值时，建立SDDC

SDDC的业务价值在于通过更快的配置速度，简化IT管理流程，并通过更快的软件配置和更改速度实现成本控制，从而加快所有软件（包括数字化产品和服务）的上市时间。在建立内部SDDC之前，I&O领导者应根据这三个价值主张确定SDDC的投资回报率。

内部设计的SDDC（而不是基于云的SDDC）允许抽象、业务流程和可编程的内部部署（或基于托管）的基础设施。例如，这将允许开发人员通过业务流程层提供和扩展基础结构，而不需要I&O人员的手工配置步骤。内部设计的SDDC还将使I&O人员能够可编程性，例如，为资源池增加新的容量，或动态优化资源池以实现最大的资产利用。

对于IT企业来说，制定云战略至关重要，确定内部可编程基础设施的可访问性将是必要的。例如，对于具有重要私有云基础设施的企业来说，开发人员可能需要访问，尽管通过使用平台即服务（PaaS）层可以进一步抽象该访问。通过PaaS，I&O团队可以通过PaaS层向基础架构启用策略，但开发人员不需要直接访问IaaS层。对于大量使用公共云IaaS的企业，大多数开发人员的访问将直接通过公共云提供商的API和协调层进行。然而，公共和本地网络与安全的整合可能会有一些要求，因此需要内部SDDC，但是比IaaS全面的私有云的规模要小。

表1提供了一个衡量内部设计的SDDC部署的潜在投资回报率和收益的框架，首先应该根据内部组成部分所需的可编程程度来考量。 I&O领导者应该注意，SDDC的投资回报率将大大提高开发人员的可访问性和可编程性，从而加快产品上市速度。作为一个副带效应，I&O人员成本将被简化和减少，因为预先打包可重复的IaaS功能为开发人员释放了I&O人员的手动操作。这些成本节省将长期存在，因为大多数基于软件定义的应用程序将是新的，从而使传统应用程序和基础架构继续得到支持（主要是以手工方式，直到应用程序合理化和现代化）。内部设计的SDDC还可以降低资本支出，因为基础设施资源得到更好利用，商品化基础设施可以替代更昂贵的专有硬件。

表1、SDDC的价值和投资回报率

微信图片_20170808162740