公有云看上去大同小异，都提供相似的服务并收取相似的费用。但由于每家云计算供应商有不同的发展历史和自己的专长，关注的重点有所不同。对于微软公司来说，该公司非常关注混合云，因为由于数据敏感性或政府监管，很多用户的工作负载一直在自己的内部部署数据中心运行。
这是一个双向的承诺，提供用于快速迁移数据和服务的工具，在内部部署数据中心资源不足时使用云平台处理非敏感、不受监管的数据，并将其Azure管理工具引入用户的数据中心，微软公司在Azure Stack中拥有自己的硬件、使用Azure Stack HCI批准的第三方硬件或其Azur Arc应用程序管理工具。
基于Azure Arc和容器构建
Azure Arc的演变一直是人们关注的焦点。最初是作为通过Azure门户管理内部部署应用程序虚拟基础设施的工具，它增加了对数据服务和Kubernetes容器编排的支持。这是有趣的选项，因为在Azure自己的Kubernetes管理工具的版本上构建是管理Kubernetes环境的一种快速简便的方法，不需要用户深入了解Kubernetes部署和配置。
除了在自己的硬件上托管自己的云原生应用程序之外，Azure Arc的Kubernetes工具还有另外的作用。微软公司一直在重新构建自己的大部分Azure平台服务。虽然这些一直基于微服务以支持快速横向扩展，但它们已经使用微软公司自己的虚拟化技术运行。这种情况正在慢慢改变，将它们从专用的Windows Server实例转移到在容器中运行，并使用自定义Kubernetes扩展和服务来支持容器化代码。
而向容器的转变，以及Kubernetes对Windows和Linux容器的支持，使微软公司能够推广自己的内部Azure托管服务，使用Kubernetes和相关技术来提高扩展性，并使这些容器具有可移植性。人们已经在Azure StackEdge硬件上运行的Azure IoT Hub中看到了一些这种可移植性，因此需要将计算能力放在需要的地方，而不是依赖可能有问题的网络。
下一个合乎逻辑的步骤是使用Arc的Azure Kubernetes作为主机，将可移植应用程序容器迁移到任何一个Azure托管平台。这种方法允许用户在代码所在的位置运行Azure服务，Arc不仅支持内部部署系统，还支持AWS或谷歌云平台上托管的基础设施。如果用户对Azure Function有依赖关系，但希望将其包含在数据中心运行的应用程序中以及Azure和AWS上的多云应用程序中，那么现在不局限于将Azure Function的代码转换为AWS Lambda。
与往常一样，这种方法是一种权衡。用户依赖于Azure Arc，并且需要在其使用的平台上进行管理。但是，用户现在只需开发一次应用程序代码，使不同版本和不同平台之间没有延迟，无需使用通用API，从而降低风险，并提供尽可能多的多云覆盖范围。
设置Azure Arc的应用服务支持
通过Azure Arc运行应用程序服务需要注册的Kubernetes集群。用户可以在任何平台上使用任何正在运行的集群，只要它支持集群API，并且已经在其Kubernetes系统上安装了Azure CLI。务必记住的是，Azure Arc是一种管理在集群上运行的应用程序的方式，而不是集群本身。Arc的功能与管理平台所需的功能之间存在明显的分界线。用户可以将其视为基础设施管理与平台和应用程序管理之间的区别。需要将集群作为基础设施的一部分进行管理，而Arc处理在Kubernetes中运行的平台服务和应用程序。
若要连接集群，可以使用connectk8s Azure CLI扩展，并确保集群可以连接到所需的Azure端点。在连接到Arc之前，可能需要为此配置防火墙。在连接之后，注册Arc提供程序并将其连接到本地区域的Azure资源组。Azure CLI工具下载并运行Helm图表，该图表添加了建立连接所需的证书和ID，为其管理代理部署了一组Pod。
一旦集群由Azure Arc管理，就可以在集群上部署Azure应用程序服务扩展。该服务仍处于试用阶段。接下来需要将应用服务扩展安装到集群，首先设置内部部署环境变量以保存扩展名称、其命名空间和整个环境的名称。然后可以使用Azure CLI将扩展安装到集群。
微软公司提供了一个示例脚本来安装和配置应用服务集群和Pod，添加服务帐户、命名空间和其他关键配置。其安装可能需要一些时间，因此需要耐心等待，然后再配置服务的Arc端。在这里，用户将在创建应用服务环境之前设置Arc使用的自定义位置。一旦它启动并运行，就可以开始创建和部署应用程序。用户可以配置对Kubernetes事件驱动自动缩放(KEDA)以及Kubernetes的默认资源驱动方法的支持。如果正在运行无服务器Azure服务(例如Functions或EventGrid)，那么应该会发现KEDA支持很有用。
在其开发的现阶段，Azure Arc的Azure应用服务支持不适合初学者。它需要现有的Kubernetes环境和从命令行管理Kubernetes和Azure的经验。微软公司可以提供指导，但用户需要自定义脚本以适应其环境，无论是在内部部署设施还是在公有云上运行。
生成代码并将其交付到Azure Arc应用服务
微软公司正在推出一种基于向导的方法，用于从Azure Arc门户将服务部署到连接的集群。这将创建适当的资源并安装适当的扩展。然后，用户可以将其用作部署资源的目标，将它们视为Azure区域旁边的自定义位置。这使用户可以使用现有的Azure开发工具(例如Visual Studio Code)来处理Arc资源。
一旦Azure Arc对Azure应用服务的支持推出正式版本，它将为用户提供与直接使用Azure相同的熟悉的开发和操作体验，将其资源视为Azure服务的替代站点。这意味着确保提前配置它们，赋予Azure管理员新的职责，并要求在DevOps团队中建立新的关系。
由此产生的多云功能利用了Kubernetes的通用API，大多数版本都支持这些API，从边缘到公有云。在内部部署或Azure中开发的代码可以在任何受支持的平台上运行，随时可以部署到数据所在的位置。随着越来越多的Azure服务利用Azure Arc的Kubernetes支持，对多平台服务的多云支持将变得与使用跨云虚拟基础设施一样普遍，并且通过消除基于平台即服务的应用程序的单点故障来提高其可靠性和可用性。
