对于许多组织来说，一个日益增长的趋势是DevOps团队支持业务目标和战略。在这种软件开发重点的转变中，开发团队在差异化服务产品甚至颠覆、最终改变行业方面发挥着关键作用。
因此，应用程序架构师不太关心封装在单体应用程序中的大规模工作流。今天的问题通常围绕着DevOps团队必须做些什么来实现所需的敏捷级别(通过大规模使用云原生平台有节奏地部署软件)——这在不久前是闻所未闻的。
得益于敏捷实践和全新的云原生基础设施，开发团队可以每天部署代码几次，而不是每几个月(甚至更长时间)部署一次。
云本原生应用程序开发的好处
与使用传统的、单体的应用程序开发实践所开发的应用程序不同，云原生应用程序由于其多功能性，可以更小、更灵活，并且容易与其他应用程序和服务集成。许多开发人员还可以开发属于更广泛生态系统的应用程序或服务。
目标是使部署持续的快速和健壮。最终的测试是，这些敏捷部署是否能够在规模上满足最终用户的需求，并且比竞争产品更好。在无状态容器环境中快速一致地部署数据和网络时，可能会出现无法预见的问题，因此，组织必须优先考虑在云原生世界中高效地管理和扩展数据和网络。
管理容器中的持久存储
笔者经常发现，组织在进行云原生迁移时面临的一个主要障碍是如何在暂态的容器环境中管理有状态应用程序的数据。
在为云原生架构开发和部署软件时，开发人员必须始终了解他们创建和分发的代码将如何在组织的运维中进行交互。容器和微服务为开发人员提供了难以置信的部署通用性。由于底层架构的无状态性，它们可以立即扩展和减少代码部署。然而，当涉及到数据放置时，维护数据持久性、稳定性和安全性可能会带来挑战，特别是当应用程序架构师使用可能存在于多个位置的代码和微服务时。
在最初使用容器的新兴DevOps环境中，一个简单的策略可能是为其CI/CD管道、Git存储库或应用程序附加一个网络文件系统(NFS)。尽管如此，正如我们将在下面看到的，数据可移植性、弹性和动态供应/取消供应可能会变得繁琐和不合标准。使用不可共享且具有潜在故障点和数据安全威胁的专有云存储基础设施，可能会出现类似问题。
简言之，在云原生之旅开始之前，拥有一个持久存储层可以避免麻烦和回溯。
持久存储应该如何工作
解决无状态环境中应用程序开发和部署的持久存储难题的一种方法是采用与容器平台集成的存储层。
当开发人员使用Kubernetes编排器使他们更容易为项目创建资源时，理想情况下持久存储层应该由动态存储平台组成。开发人员应该有信心，存储层也会符合应用程序部署的数据安全性和弹性要求。
通过一个可行的软件定义的存储平台，开发团队可以动态地定义和调整项目的数据需求，而不是使用NFS挂载手动完成此过程。而且，他们不需要依赖存储管理员来提供存储，他们可以根据需要更改存储配置。
同样，对于以块协议(如SQL或NoSQL数据库)存储数据的应用程序，一些组织可能倾向于采用服务提供商的专有解决方案。但是，这样会限制跨不同的多云或区域提供存储可用性的能力，并且会将开发人员锁定到单个提供商的解决方案中。
开源软件定义的存储允许跨许多不同类型的基础设施(包括裸机、虚拟机以及公有云和私有云环境)进行持久和可移植的存储。数据联合可以跨混合和多云环境进行，因此开发人员可以根据需要放置敏感数据，并集成来自各种多云部署的应用程序和微服务。
对于人工智能(AI)和机器学习(ML)等大规模分析应用程序，数据科学家通常必须管理来自多个位置和设备的大量数据增量。另一个例子是来自边缘设备和物联网资源。必须在整个数据生命周期中无缝地提供从设备边缘到远程staging，再到核心系统的数据聚合和分发。通常，不同类型的事件需要不同的存储协议，从对象到块再到文件。持久存储层功能必须可用，以处理这些非常动态和多样化的存储需求。
最终，开发团队必须能够依靠一个标准化的平台，通过一个单独的API，在经常是多样的、要求很高的环境(包括多云、裸机和虚拟机)中自动化存储管理。当开发人员需要根据需要缩减或重新部署时，存储层还应提供显著的故障转移优势。它还需要非常灵活，因此，开发人员可以通过提供几乎零延迟来定义他们需要什么。
云原生持久存储提供了这些功能，并为DevOps团队带来了显著的灵活性和可移植性。它可以为云原生环境中的软件部署提供灵活性，同时使开发人员能够自由地管理自己的存储需求。