云原生基础架构由应用程序来维护，而云原生应用则由基础架构来维护，两者密不可分。这就要求基础架构和应用程序设计必须是简单的。如果一个应用程序比较复杂，则应该采用微服务模式，将复杂功能拆分为细微的服务，然后通过集成这些细微服务来组装成一个应用系统。但由微服务构成的如此复杂的系统，势必无法通过人工管理，应该采用自动化管理，这也是云原生应用的一个基本特征。
一、何时采用云原生
云原生架构是一个阶段性产物，是否采用云原生要看各自场景的需求以及是否具有使用云原生的基础条件。在选择上云原生之前，需要先了解∶
（1）企业的现有基础架构是否敏捷所谓敏捷是指可以通过API来自动分配、销毁资源，现有laaS层是不是API可控制的。当应用不再关注底层系统的情况时，就可以尝试云原生架构。
（2）企业的开发团队、部署团队、运维团队是否独立?技能是否相通?如果采用云原生架构，将打破这种独立运作的组织架构，由传统纵向分割团队改为横向分割团队，每个小组可以自己负责纵向的所有事宜，从而更好地协作。
（3）企业的业务是否需要更快地迭代，是慢步速应用还是快步速应用?采用云原生架构的应用，就是为了快速响应业务变化，并快速部署应用，只有业务变化快的业务才能充分发挥云原生架构的作用。
（4）企业是否有云原生应用? 是否有满足十二要素的应用? 是否有微服务等应用? 适合云原生架构的应用必须职能单一、与系统无绑定，能够动态扩展实例数量。这就要求能够以无人值守的方式扩展应用实例，也要求状态持久化的存储服务独立于应用所在的服务器。符合十二要素是最好的实践。
实际上，对于一个非互联网企业或者高校、*机关来讲，能够部分采用云原生架构，能够部分借鉴云原生应用的理念，也是一种改进的成果，为转向云原生架构做准备工作。
二、实现云原生模式
在传统单体应用中，企业所用开发语言是单一的，云原生应用并不限定语言，它只对诸如弹性、服务发现、配置、日志记录、健康检查和度量检查等模式有要求。针对两种不同情况，目前常用的做法主要有两类。
（1） 单一语言情况下，可以通过导入标准库的形式在程序代码中声明云原生特征。
（2）多语言情况下，则可以通过伴生模式来解决。该模式将实现各种功能的微服务应用通过容器化部属捆绑在一起。在云原生架构下，应用的生命周期也是由软件来进行控制的，普通用户无须关心应用的生命周期。应用程序的集成、测试和部署应该是自动化、自助式的，按照 DevOps 文化来进行。