云原生的候选应用
考虑组织需要构建的应用。 然后，查看项目组合中的现有应用。 其中有多少保证云原生体系结构？ 它们全部？ 也许有一些？
如果应用成本/好处分析，可能有些会得不偿失。 成为云原生的成本将远超过应用程序的业务价值。
哪种类型的应用程序可能是云原生的候选项？
需要不断改进业务功能的策略企业系统
需要高发布速度的应用程序（具有高置信度）
一个系统，其中各个功能的发布无需完全重新部署整个系统
由具有不同技术堆栈专业知识的团队开发的应用程序
具有必须独立缩放的组件的应用程序
影响较小的小型业务线应用程序可能适合使用云 PaaS 环境中托管的简单的整体式体系结构。
然后存在旧系统。 虽然我们都想生成新应用程序，但我们经常负责对旧的业务关键型工作负载进行现代化改造。
对旧应用进行现代化改造
免费的 Microsoft 电子书使用 Azure 云和 Windows 容器对现有 .NET 应用程序进行现代化改造提供关于将本地工作负载迁移到云的指导。 图 1-10 显示，对旧应用程序进行现代化改造没有单一的通用策略。
图 1-10。 迁移旧工作负载的策略
非关键型的整体式应用可能会受益于快速的直接迁移。 在这里，本地工作负载会重新托管到基于云的 VM，没有更改。 此方法使用 IaaS（基础结构即服务）模型。 Azure 包括多种工具，（例如 Azure Migrate、Azure Site Recovery 和 Azure Database Migration Service）以帮助简化迁移。 虽然此策略可以节省一些成本，但此类应用程序通常并非设计为解锁和利用云计算的优势。
旧的业务关键型应用通常受益于增强的云优化迁移。 此方法包括启用关键云服务的部署优化 - 无需更改应用程序的核心体系结构。 例如，可以容器化应用程序，将其部署到容器业务流程协调程序，如本书稍后讨论的 Azure Kubernetes 服务。 在云中后，应用程序可以使用云支持服务，例如数据库、消息队列、监视和分布式缓存。
最后，提供策略企业功能的整体式应用可能最受益于云原生方法（这是本书的主题）。 此方法提供敏捷性和速度。 但代价是重新构建平台、重新构造和重写代码。 随着时间的推移，旧应用程序可以分解为微服务、容器化，并最终重新平台化为云原生体系结构。
如果你和你的团队认为云原生方法合适，那么你需要向组织针对决策进行合理解释。 云原生方法将解决哪些业务问题？ 它如何与业务需求保持一致？
更自信地快速发布功能？
精细的可伸缩性 - 更高效地使用资源？
改进了系统复原能力？
改进了系统性能？
更高的操作可见性？
混合开发平台和数据存储，以提供最适合作业的工具？
面向未来的应用程序投资？
正确的迁移策略取决于组织优先事项和你针对的系统。 对于许多人来说，性价比最高的方式是云优化整体式应用程序或向 N 层应用添加粗粒度服务。 在这些情况下，仍可以充分利用云 PaaS 功能，如 Azure 应用服务提供的功能。
总结
在本章中，我们介绍了云原生计算。 我们提供了一个定义以及驱动云原生应用程序的关键功能。 我们了解了可能为这种投资和投入提供依据的应用程序类型。
在介绍后，我们现在深入探讨云原生。
