将Windows应用提升并转移到容器中
微软自己在Microsoft 365上的经验表明，即使你有大量的代码需要转移，向云原生迁移也是可能的。
有一句老话经常被在微软平台上构建的开发人员分享。"你怎么能知道一个微软的产品是否已经准备好了？当微软把它用于其旗舰应用或服务之一时"。
这意味着，当奥尔良分布式应用框架为《光环》的大部分内容提供支持时，是开始使用它的时候了；当流体框架进入Teams时，是使用它的时候了，还有其他的。最新获得批准的服务是Azure Kubernetes服务上的Windows容器。微软在过去一年多的时间里一直致力于将微软365平台的大部分内容转移到AKS上，目的是在COVID-19大流行病推动的工作模式快速变化的情况下使其更具可扩展性和灵活性。
将微软365迁移到云原生和AKS上
将微软365这样规模的服务转移到容器上是一个复杂的过程；从Office Online单租户系统转移到多租户虚拟化架构已经很困难了，尤其是在结合转移到CI/CD（持续集成和持续交付）时。第一次转变使许多架构上的改进到位，这些改进对转向容器是必要的。首先是将状态从应用虚拟机转移到我们现在所知的微软图谱。然而，很多服务都是定制的，特别是管理可用性和支持构成租户的机器和服务之间的网络。
这种方法导致了一致性的缺失。应用程序的构建必须以特定的平台为目标。因此，它建立了架构上的低效率，因为不同的服务器类型需要承载不同的虚拟机，增加了托管微软365服务的数据中心的复杂性和成本。这增加了运行服务的成本。负载不能轻易地在服务器之间移动，以确保最佳利用率，这降低了超大规模的成本优势。
在Kubernetes上构建需要重新思考曾经的单体服务，并重构它们作为可扩展的微服务工作。然而，由于他们可以使用Windows容器，该团队并没有失去任何他们已经在使用的东西。AKS容器主机可以用适当的.NET工具和服务来配置，可以访问Windows APIs。虽然这些主机功能是在容器之间共享的，但容器隔离确保它们可以被安全地访问。
同时，与虚拟机相比，容器实例的尺寸较小，确保在相同数量的物理主机上可以运行更多的应用程序，降低总体成本，并允许更有效地使用Azure硬件。微软的内部会计系统意味着集团需要对云计算的使用进行预算，因此任何节省的资金都可以投资到服务的其他地方。
微软365迁移到云原生架构还有其他好处。所有开发人员共享相同的API表面，这简化了测试和变更管理，并允许团队使用CI/CD作为应用运营模式的一部分，使平台运营与代码分开，管理服务使用的AKS功能。应用程序首先被构建和部署到测试集群中，然后在转移到生产之前为内部用户和外部内部人员提供早期环。
如何将你自己的代码容器化
如果微软可以将其代码转移到容器和AKS，那么你如何才能做到这一点呢？显然，大部分的变化必须是组织性的。你需要一个成熟的devops实践，它已经分成了三个部分，有专门的基础设施、平台和应用团队。然后你需要提升和转移这些代码，进行必要的改变以支持在容器环境中工作。单一的应用程序不太可能在基于容器的环境中运行良好，特别是像AKS这样的环境，你的大部分平台操作都是自动化的，在飞行中扩展，并使用平台级服务网格来管理声明性网络和安全。
值得一提的是，微软的Windows容器团队最近根据其与微软365等客户的合作经验发布了文档。这为你提供了一组指针，以便在将应用程序从Windows Server环境--即使是虚拟化的环境--转移到容器时考虑。与容器一起工作并不像与服务器一起工作，即使我们确实可以访问熟悉的API和库。
留意容器封锁者
大部分的阻止者名单是常识性的。容器不适合交互式应用，也没有GUI支持。主机操作系统是Windows Server Core的一个版本，所以代码需要被设计成适用于它，例如，只支持静默安装或不允许RDP访问。在没有用户界面的情况下，代码需要备用的管理API，例如，提供端点供Windows管理中心使用。
同样地，你应该确保代码永远不会在容器内存储数据。这包括设置。容器需要被视为无状态的、短暂的项目，根据容器协调平台（如Kubernetes）的要求进行创建和销毁。如果你的目标是AKS，可以考虑使用Azure存储实例，如Azure Files或Blob来保存容器的状态和数据。这样一来，如果处理支付流程的容器发生故障，替代的容器就可以在用户不知情的情况下接过会话状态并继续使用。同样地，如果需求需要额外的容器，它们可以在准备好后立即接收应用程序的状态和设置。
还有其他的限制。你的代码需要在Windows Server 2016或更新版本上运行，所以旧的应用程序可能需要一些兼容性工作。.NET框架的旧版本也是如此。虽然微软提供了支持版本的容器镜像，但你最好确保代码在更多的最新版本下运行，这些版本是为了支持微服务架构而设计的，占地面积更小，允许更多的容器在同一主机上运行。重要的是要避免对活动目录角色的任何依赖，或者对任何Windows服务器基础设施功能的依赖。你的容器是为你的应用程序服务的，没有别的。
尽可能利用云服务的优势
如果你打算转移到AKS或Azure容器实例，甚至Azure容器应用程序，那么值得考虑的是，你可以在你的应用程序中使用其他Azure服务。如果你对数据库或其他应用程序有依赖性，你很可能会发现使用Azure等价物比设置一个虚拟服务器来托管应用程序更容易。另外，云优化的版本和供应商支持的版本可能在Azure市场上。同样，如果你可能使用活动目录进行访问控制，可以考虑使用Azure活动目录API，因为这些API与短暂的容器兼容。
微软的容器化文档为那些在容器中不被支持的企业内部服务提供了合适的替代品。切换到它们可能需要时间，并需要额外的开发工作，这对传统的应用程序可能是一个问题。在某些情况下，尽管你可能想转向云原生和容器，但事实可能证明这是不经济的或太复杂。
容器化是构建新的云原生应用程序的有用技术，将容器视为CI/CD管道的终点，并使用Kubernetes来协调和扩展构成应用程序的服务。微软自己的经验表明，从虚拟基础设施转向云原生是可能的，它的文档提供了关于如何进行必要改变的指针。这并不容易，但正如微软365所证明的那样，其好处是非常值得付出必要的工程努力的。
