云原生实践思考：先上云还是云原生？
InfoQ编辑赵钰莹
讲述：初明明大小：3.82M时长：04:09
目前，企业纷纷追捧云原生技术，在实践云原生之前，有一个问题不得不思考：先上云还是云原生？最近，InfoQ 就此问题采访了灵雀云 CTO 陈恺，他基于灵雀云所接触到的客户案例对“企业先上云再做云原生改造，还是直接进行云原生改造”这个问题做了详细分析和解答，具体内容如下。
整个云原生领域的创新仍在持续，这种创新开始转移到技术栈的上层。这些技术当中，沉淀出一个核心的云原生技术栈：底层是 Kubernetes，解决部署管理的问题；中间是 ServiceMesh，解决应用层面、网络连接相关的问题；往上是 Serverless，它把整个运行时都做了虚拟化、抽象。
在云原生时代，很多企业希望借助此技术实现数字化转型，其最核心的是应用，最后承载企业价值的就是应用和软件。但是光有软件是不够的，光有软件不见得转型成功，也不见得有什么竞争力，关键在于软件是如何设计、开发并交付的，能不能很快将价值传递出去，这是想通过软件做的事情。
在这一点上，云原生是可以发挥作用的，因为云原生讲的就是如何最大化利用其交付模式，并发挥云计算的所有生产力，使得一系列应用从设计到开发、交付，再到管理的思维方式，将最佳实践和技术结合在一起，让应用最快传递价值。
目前，传统企业对此的接受程度还是挺高的，灵雀云对于头部客户的覆盖非常好，因为大部分 CIO 也都很明白自己的痛点，最终需要软件交付的能力。
随着技术不断地深入，很多传统企业都有大量的复杂传统应用，开发模式依旧没有改变，这时就要考虑如何对传统应用进行改造，兼顾两种类型的应用，即敏态和稳态应用。随着时间的演进，企业愿意把这些应用全面云原生化。此时，企业需要识别哪些应用适合进行云原生改造，哪些不适合，对于适合的应用，也需要考虑改造步骤，如何循序渐进对技术进行选择。
总结来看，云原生应用架构要在企业 IT 环境落地，必须务实，需要遵循以下四个原则。
第一，并不是所有应用都需要做微服务的拆分，做微服务化，多种粒度的服务同时并存，是很正常的事情，甚至可以反过来考虑这件事情。默认的、缺省的应该从比较大的粒度开始，当真正有业务层面敏捷性需求时，再按照变更的边界和优先级去逐步做微服务的拆分。
第二，当有敏捷性需求，一定要意识到微服务化之后会带来运维的复杂度。所以做了微服务化一定要拥抱云原生，将微服务应用迁移到 Kubernetes 平台上，甚至在 Kubernetes 平台上应该用 Service Mesh 对它做微服务治理。
第三，API 在整个架构中起到非常重要的作用。一个应用即便不做微服务拆分、不改动技术架构，也可以做一些服务化的适配，把关键能力通过 API 暴露出来。通过 API 来实现内部集成和对外能力开放。
第四，需要做 API 治理。 API 治理一般通过 API 网关来实现，但可能不会只有一个 API 网关，可能有多个层级的 API 网关。一般来说，越往上，API 网关的职能越偏向运营，越往下，API 网关的职能越偏向技术。
在具体实践中，关于先上云再做云原生改造，还是直接进行云原生改造，灵雀云接触到的大部分客户基本以私有部署为主，会先从云原生改造开始，上不了公有云的客户也可以很好地使用容器等云原生方面的能力。所有客户上公有云，这会是一条长期且漫长的道路。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论