云原生应用程序和数据需要确保安全

将数据作为云原生应用程序的一部分进行管理非常困难。对于许多企业而言，当前冠状病毒疫情带来的压力加剧了他们在软件开发方面所面临的挑战。数字化转型已从一种增长战略变成了一种生存之道。在线商务几乎在一夜之间得到爆炸式增长，达到了只有在假日期间才会出现的水平。

这将是一个推动更多变革的推动力，因为企业或者致力采用新技术，或者努力在竞争中保持领先。基于云原生IT的新方法将会有所帮助。

更敏捷、更多数据……更多问题?

为了采取必要的措施，开发人员正在研究如何利用云原生方法。但是，这不仅仅是将现有应用程序迁移到云平台上并添加更多基础设施那样简单。它需要围绕软件容器构建的新架构和采用的业务流程工具如何在从构建到生产的自动化应用程序中发挥作用，如何在容器之间有效地使用API​​，然后如何通过应用程序基础设施的动态更改来处理数据。

Kubernetes现在是基于这种方法来编排容器和管理应用程序的一种首选方法。 Kubernetes可以处理设置应用程序工作负载，确保其继续运行，并应对规模挑战。但是，尽管Kubernetes可以编排应用程序，但它不能解决数据管理问题。应用程序创建的所有信息仍然需要管理。

传统上，要想成功地使用像Apache Cassandra这样的数据库，用户必须从操作系统开始理解整个软件堆栈。他们还必须确保其一致性并遵循严格的操作和部署手册。这种方法不仅需要深入了解数据库的工作原理，还需要随着时间的推移进行一些人工干预以处理扩展。

使数据与应用程序一样易于编排

与Kubernetes一起管理云原生应用程序数据需要一些计划。一种方法是使每个服务的数据库实例位于Kubernetes集群之外。这使企业的数据基础设施脱离了控制平台，并为那些现在必须管理两个环境的用户创建了额外的工作。而这种情况并不理想。

更好的方法是从物理角度将数据与应用程序组件一起分布，但需要在同一控制平台内。这确保了每个应用程序服务都可以有效地读写数据，企业可以将这些数据和应用程序作为一个整体进行管理。更重要的是，这种方法应该能够像任何软件容器映像一样在多个云服务或云平台上进行扩展。

为了与诸如Apache Cassandra之类的数据库一起运行Kubernetes，企业将需要在Kubernetes集群中使用Cassandra Operator。这使Cassandra节点可以作为服务在现有Kubernetes集群内部运行。运营商在Kubernetes和更复杂的流程(例如Cassandra)之间提供了接口，以允许对其进行一起管理。启动和停止Cassandra集群，对其进行扩展和处理故障都通过Kubernetes Operator以Cassandra理解的方式进行处理。

更好地参与Kubernetes环境意味着需要深入了解集群状态。实际上，这意味着以前属于数据库内部的某些操作(例如自动重试或建立Gossip链接以跟踪内部集群状态)被提升到API层。然后，Kubernetes可以基于整个集群的健康状况做出决策，以便可以采取任何行动，例如如果需要更多节点，则可以启动这些元素以自动弥补。通过可用指标可以观察到所有这些情况。

围绕数据思考状态

通常情况，Kubernetes中的容器实例是无状态的——根据需要创建它们，然后将其删除，而不是随时间存储。存储需求被认为是短暂的。但是数据管理是不同的。对于像Cassandra这样的数据库，节点将需要持久化数据，因此必须被视为有状态服务。因此，必须使用PersistentVolumes和StatefulSets来添加这些对象，以确保在任何重新启动事件之间将数据卷连接到相同的运行节点。

这种基于Kubernetes的自动化的使用可以使开发人员和操作人员的工作更加轻松。可以使现有服务更高效、更轻松地进行升级，同时可以添加新服务来满足客户需求。除了一起运行Kubernetes和数据库外，还可以考虑它们如何为内部开发人员提供数据库即服务或DBaaS功能。

对于尚未熟悉设置和运行Kubernetes或不想花费太多时间的团队来说，将这些技术结合使用的数据库即服务(DBaaS)选项可以从云平台中按需提供。数据库即服务(DBaaS)可以消除一些管理开销，并使企业更容易专注于如何处理数据，而不是人工管理数据库实例。

支持企业业务的数据处理方法

对于希望更快地实施并交付客户所需的企业而言，迁移到云原生应用程序和数据至关重要。从开发人员的角度来看，将“全局”方法与保持系统运行所需的方法联系起来可能是一项挑战，特别是在扩展数据库需要工作人员具有一定经验的情况下。先前的流程和组织孤岛可能是阻碍这些变化的主要问题，因此需要消除转变为数据驱动的业务所面临的障碍。