用于生成过程的 Azure 技术
在本单元中，你将了解创新过程与行业中的一些技术之间的关系，这些技术可帮助你将新功能构建到应用程序中。
DevOps
开始构建阶段来验证创新假设后，应尽可能简化所需的开发周期、集成周期和部署周期。 这个阶段就是 DevOps 的用武之地。 可以将 DevOps 定义为“快速可靠地分发软件功能的流程和工具”。以下是有关此定义的详细信息：
流程和工具：作为整体的创新过程，DevOps 基于鼓励改变的文化模式。 Azure 和 GitHub 围绕 DevOps 提供了很好的工具，但仅仅购买许可证是不够的。 流程和组织文化需要不断发展，以适应变化和创新。
快速交付软件功能：DevOps 流程和工具采用快速失败的概念。 构建 MVP 或原型，以快速验证正在开发的功能是否朝着正确的方向发展是 DevOps 概念的核心。
可靠地交付软件功能：反对更改的组织通常会将快速更改与停机联系起来。 但是，DevOps 承诺的内容完全相反：较快的更改速率和高可靠性。 可以通过在开发周期的早期阶段集成测试（称为“向左移动”的过程）来实现这种可靠性。
如果在时间上将功能的开发视为从左到右的一条线， 则旧的开发过程将在开发周期结束时，在这条线的“右”端 执行用户验证和质量控制。 DevOps 建议在这条时间线的“左”端尽可能早地进行测试和验证。
DevOps 体现了正常创新文化的相同核心概念。 采用其方法是实现敏捷创新周期的关键。
微服务体系结构
模块化是一种众所周知的技术，用于在构建复杂系统时降低复杂性。 如果系统是很多不能彼此分离的多个部分（通常称为“单体架构”）的复杂交互，则紧密的组件相互依赖性会使系统改进变得困难。 每次更改都需要通过系统的其余部分进行验证，从而使测试过程复杂化。
如果系统是模块化的，则可以将其分成较小的子系统，这些子系统通过定义完善的接口彼此交互。 在其中一个子系统中引入更改会更容易，因为只要该子系统与其他模块的接口保持不变，整个系统就会继续工作。
微服务体系结构是利用模块化的应用程序模式。 应用程序细分为单独的小组件，这些组件可以彼此独立地进行开发，甚至可能使用不同的编程语言。 每个组件（或微服务）都可以独立运行。 可以根据需要缩放它，可以将其作为单个单元进行故障排除，可以独立于其他微服务对其进行修改。
组织经常询问的问题是，如果应用程序是单体的，那么应该怎么做？ 组织应该在引入创新之前将应用程序重新设计为微服务体系结构，还是可以并行运行创新过程和重新设计过程？ 这个问题没有单一的答案。 答案取决于所考虑的应用程序的复杂性和业务相关性。
研究在电子商务平台中引入创新时，Tailwind Traders 面临着此问题。 该公司决定启动一个项目，以将电子商务应用程序重新设计为微服务体系结构，因为该应用程序的业务重要性证明了这一努力的合理性。 没有模块化的应用程序会严重削弱 Tailwind Traders 对不断变化的在线市场趋势做出反应的能力。
但是，Tailwind Traders 决定同时解决其平台的一些主要缺口。 因为等待应用程序重新设计项目完成，意味着将大量市场份额拱手相让给目前正在扰乱电子商务市场的新的初创企业。
两个项目将在创新的业务价值指导下相互作用。 重新设计工作将重点关注最重要的应用程序领域，这些领域最迫切需要进行修改以改进客户体验。
容器
容器化技术不是微服务体系结构所独有的，但这两个概念可以结合在一起。 容器是封装应用程序代码及其依赖项的一种方法，因此可以在任何平台中轻松地部署它们。
传统的应用程序部署要求组织首先安装软件，例如应用程序运行时、编程库或外部组件。 这种方法通常会导致出现“它在我的计算机上正常运行”这一问题：很难跨开发、测试、暂存和生产复制相同的环境。 安装应用程序依赖项的方式上的微小差异，可能会导致应用程序在进行测试时正常运行，但在部署到生产环境时失败。
容器会更改游戏规则。 因为应用程序依赖项会与自动部署单元（称为容器映像）中的应用程序代码一同进行打包。 无论应用程序容器部署在开发人员的笔记本电脑上，还是部署在具有数百个节点的生产群集中，依赖项处理都是完全相同的。 容器的工作方式完全相同，因此应用程序测试更可靠且可信。
自 Docker 于 2013 年以开放源代码方式发布代码以来，容器已经取得了长久的发展。 容器现在支持 Linux 和 Windows，以及不同的 CPU 体系结构。 Azure 中提供了许多产品/服务来帮助运行基于容器的工作负载。 在本单元中，你将了解其中一些产品/服务。
Kubernetes 和 Red Hat OpenShift
容器运行时是一种技术，该技术在计算机上启动容器，但生产环境中需要更多逻辑。 如果需要更多的性能，谁负责部署更多的容器？ 如果容器出现问题，谁负责重启容器？ 如果有多台计算机可用，谁决定哪台计算机应该启动哪个容器？ 这些任务和其他任务是容器业务流程平台的责任。
Kubernetes 的第一个版本于 2015 年发布，它很快便成为了容器业务流程的标准。 Kubernetes 群集由多个工作器节点组成。 每个工作器节点都有一个容器运行时，因此它可以运行容器，其中 Kubernetes 控制平面可计划容器化应用程序的部署。 此控制平面通常在一组核心节点中运行。 它负责使应用程序正常运行、纵向扩展或纵向缩减应用程序并执行任何所需的更新。
Kubernetes 受欢迎的主要原因之一是容器提供的硬件独立性。 由于可以将基于容器的应用程序可靠地部署到任何容器运行时，因此，你可以在使用各种虚拟机监控程序的云中运行 Kubernetes。 部署的应用程序的行为应该类似（假设基础硬件资源也相似）。 许多组织已采用 Kubernetes 作为抽象层，从而在本地和公有云中实现一致的应用程序部署过程。
在 Azure 中运行 Kubernetes 非常简单。 Azure Kubernetes 服务易于部署，并且经济高效，因为只会向客户收取工作器节点的费用。 包含核心组件的控制平面的费用和运营由 Microsoft 负责。 Microsoft 会修补和更新工作器节点的操作系统，进一步降低管理 Kubernetes 群集以运行 Linux 和 Windows 容器的操作复杂性。
OpenShift 是一个基于 Kubernetes 的应用程序部署平台，由 Red Hat 开发和提供支持。 它包含许多其他功能。 一些组织之所以选择在 OpenShift 上运行其应用程序，是因为 Red Hat 提供的这些额外的功能和支持。 在 Azure 上运行 OpenShift 也非常简单。 Azure Red Hat OpenShift 包含一个 OpenShift 群集，Microsoft 管理它的许多方面，包括群集的整个生命周期。
Azure 应用服务
Azure 应用服务是一个平台，组织可在其中运行基于 Web 的工作负载，而无需管理任何业务流程协调程序或基础操作系统。 唯一的要求是通过多种可用的部署方法之一将应用程序代码上传到服务。 Azure 会执行其余操作：横向缩减和横向扩展应用程序、修补和维护底层虚拟机等，而无需经历 Kubernetes 的学习曲线。
Azure 应用服务支持基于容器的工作负载，因此你可以上传容器映像，而不是应用程序代码。 它还支持 Linux 和 Windows 工作负载，以及许多不同的应用程序运行时。
此外，Azure 应用服务支持不同的定价模型，包括名为 Azure Functions 的无服务器选项。 在 Azure Functions 中，只会按应用程序的使用情况收费， 而没有任何固定成本。
无服务器模型对于创新来说非常有意义，因为通过这种模型，即使市场不接受所部署的新的微服务，也不会产生高昂的每月费用。 此模型是快速失败策略的另一个示例，其中创新并不一定意味着高昂的费用。
Azure 应用服务还提供支持面向 DevOps 的部署的功能，例如 Web 应用槽。 槽是临时区域，你可以在其中部署新功能，而不会影响生产环境。 从创新的角度来看，槽非常理想，因为你可以将挑选的一小部分客户重定向到新版本的应用程序。 然后，可以验证创新假设是否正确。 最终，若要将新代码推广到生产环境，你可以“交换”槽，以便使过渡环境成为生产版本。
总结
在本单元中，你了解了可为创新提供支持的技术：
- DevOps 流程和工具可以让你的开发和运营团队迅速、可靠地提供新功能。
- 可以将应用程序重新设计到微服务中，以允许单独对其组件进行创新，而不影响其他内容。
- 容器可跨多个平台和环境实现可靠的应用程序部署。
- Kubernetes 是一个与云无关的业务流程平台，用于运行容器化应用程序。
- Azure 应用服务可以运行基于 Web 的工作负载，并且产生的管理开销最小。 它提供多种功能，例如无服务器或应用程序槽，旨在加速创新周期。
Tailwind Traders 决定开始将其电子商务应用程序重新设计为微服务体系结构。 该公司将从“单体架构”分离的第一个应用程序子系统是支付服务，因为你已将其标识为关键领域，在这个领域中，竞争对手能够为客户提供更高的价值。
在支付子系统之后，更多的应用程序组件将转换为独立微服务。 微服务可以通过 REST API 进行通信。 每个微服务的应用程序代码都将进行容器化，并且开发和运营组织将采用 DevOps 最佳做法。
由于 Tailwind Traders 不希望依赖于任何特定的公有云，因此决定在内部积累 Kubernetes 专业知识，并在 Azure Kubernetes 服务群集上部署应用程序。 如果需要开发新的微服务，该公司选择考虑使用 Azure Functions 作为 MVP 部署的平台，以降低开发成本。
后续应该查阅的内容
云采用框架文章《通过数字发明提升采用率》和《云采用框架中的 Kubernetes》中对本文的许多概念进行了进一步的解读。