云原生的发展速度日新月异，但要用好并不容易。开发者在开始使用云原生或者迁移到云原生架构的时候，往往会面临一些困难：首先，云原生对软件产品有约束，比如容器化、12元等等，所以要把一个遗留系统适配到云上原生系统，必然需要进行一些改造，甚至可能涉及到开发模式的改变。对于团队来说，过渡过程可能具有挑战性。其次，K8s的复杂性足以让很多开发者望而却步，只有把握好它，才能充分发挥云原生的优势，否则可能导致系统难以维护，甚至会因为以下原因导致故障错误的配置。让开发者的技术水平接近K8s的开发速度，需要持续的投入。这些额外的投入也背离了让开发以业务为中心的初衷。第三，虽然开源社区为云原生贡献了丰富的能力组件，但是对于线上业务，尤其是企业级服务，开源组件的性能、可靠性、可维护性是否经得起考验，如何维护？团队是否有能力充分理解这些开源组件也是技术选型前必须考虑的一个因素。总之，了解云原生和K8s只是一个开始。开发者应该着眼于在业务上实现云原生，充分发挥云原生的价值，选择一条合理的“原生”路径。阿里巴巴在使用云原生方面起步较早，在将云原生技术应用于具有大规模、高可靠、分布式特征的系统方面有着丰富的经验。EDAS作为阿里云aPaaS的旗舰产品，由阿里云原生团队出品。早期也提供了容器和K8s的支持能力。随着近期EDAS3.0的重磅发布，云原生融入了EDAS的功能核心，致力于帮助企业实现云原生落地，基于云原生平台构建更强的应用管理能力，释放技术红利，服务于广大开发者。下面通过一些实例带大家一窥EDAS如何帮助开发者进入云原生时代，玩转云原生。不能否认“纯”云原生。EDAS是阿里云平台上的商业产品，而云原生主要是开源社区提倡的。两人显然来自两个截然不同的阵营。所以“纯粹”是骗人的？事实上，商业化和开源并不矛盾。相反，他们总是在很多领域互补。这个话题不是本文的重点。如果抛开“出生”的因素不谈，我们理解的“纯”指的是：在原有的系统下，对资源进行组合抽象，抽象出来的资源并没有脱离原有的系统。不侵入、限制、破坏现有云原生资源的使用协议。得益于K8s的开放性，EDAS的实现原理并不复杂，用户只需要在K8s中配置资源（应用），通过声明式配置将其置于想要的状态，EDAS可以感知变化，自动维护和调整状态，使其最终与用户预期一致，从而实现controlapplications为此，这一切不需要修改K8s的版本，只需要安装EDAS提供的扩展即可。下面从两个方面具体介绍EDAS的方法以及由此带来的优势。云原生应用定义前文提到，EDAS将应用抽象为资源。在这个过程中，应用定义的设计至关重要。在声明性规则下，应用定义需要能够涵盖软件生命周期过程中各个主体的配置、状态和关系的描述，并保证良好的可读性。因此，必须从大量的应用、复杂的场景和长期维护的经验中总结出来，只有这样才能保证定义不脱离实际，能够高效推导到其他应用中。EDAS并没有重新发明轮子，而是选择了开放标准“开放应用模型（OAM）”作为应用定义，并选择与之共建的方式来丰富标准的内容。可以说，EDAS是OAM在阿里云上的一种实现。对于开发者来说，EDAS使用OAM有两大好处：OAM消除了厂商平台对开发者的绑定。虽然不同平台支持的运维特性和底层实现方式相同，但只要厂商遵循标准，相同的应用配置就可以在不同平台之间迁移。因此，在EDAS上产生的应用可以迁移到同样符合OAM规范的其他平台，同样适用于其他平台迁移EDAS的场景。OAM隐藏了具体的底层工作负载类型，通过更高的抽象层次避免了直接操作底层K8s的复杂性，提供独立的ApplicationConfiguration资源，通过在Components上配置Traits（运维特性）来强加不同的操作。维护能力，Component和Trait的设计更好的分离了开发和运维团队的关注点，使得应用生命周期中的配置和协作变得更加容易。由于ApplicationConfiguration也是K8s自定义资源（CR），开发者可以直接使用kubectl工具对其进行增删改查。EDAS遵循K8s终态设计原则，最终将应用调整到预期状态。操作一个应用程序和操作一个常规的Deployment资源没有区别，并且可以很容易地与其他CI/CD工具或GitOps工作流集成。
