本文章发表于:2020-01-16
过去的几年,是云原生技术和理念得到广泛接受的几年。在这个快速发展的领域,预测未来显得尤其困难,但是我们又有着一些坚定的信念,相信以开放创新为支撑的云原生领域会持续重塑软件生命周期,带来不断的价值。
2019,在众多热门技术趋势中,云原生的关注度居高不下,很多开发者都对由此而兴起的一众技术十分追捧,众多企业开始探索云原生架构转型落地。在中国,开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。
在筹备阿里云首届云原生实践峰会的过程中,我们展开了对云原生技术的应用和研究领域的探索,邀请了 17 位云原生技术专家从 Serverless、Service Mesh、Kubernetes、边缘计算、容器实例与容器引擎、云原生基础架构、云原生应用开发 7 个发展方向,回顾 2019 云原生领域进展,描绘云原生技术的新十年。
2020 云原生标志性事件预测
展望 2020,在云原生技术的应用和研究领域,我们预见会有这些标志性事件。
第一,云原生技术关注重心在上移,Serverless 和应用管理重点。
过去的几年我们看到,云原生技术重心围绕容器和容器编排。Docker 和 K8s 的成功几乎成了云原生的代名词。很多人说,Kubernetes is becoming boring,这是对于技术的趋势来说。
云原生关注重心即将上移:
应用的定义和配置、发布和线上的自动化运维,成为开发和运维人员关心的核心内容。阿里巴巴和微软联合推出的 Open Application Model (OAM) 就是这个方向的一个重要项目。
作为云原生技术的延伸,无服务器计算(Serverless)将进一步释放云计算的能力,将安全、可靠、可伸缩等需求由基础设施实现,使用户仅需关注业务逻辑而无需关注具体部署和运行,极大地提高应用开发效率,同时这个方式促进了社会分工协作,云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。相信在 2020 会有更多的创新和落地实践在这个领域涌现。
第二,云原生技术成为云服务商的创新和竞争力的主阵地。
随着以容器为基础的云原生技术被用户广泛接受,可以肯定的预期,容器会很快成为云和用户的基本界面。因此对于云的服务提供商来说,基于容器、微服务、无服务器、服务网格等新型云原生技术的领域,必将是云厂商未来创新和竞争力的主阵地。
虚拟化未来 3 年还会是云上资源增量的主体,但是硬件虚拟化加速的裸金属和安全沙箱容器的组合,正在加速企业的上云和容器化过程。云厂商未来技术竞争力的关键,在云传统的优势包括规模、稳定性、成本发挥到极致的前提下,必将通过云原生技术和产品的持续创新来服务客户来获得客户的认可。云原生产品领域将成为云厂商竞争白热化的必争之地。
第三,云原生从数据中心走向云边端一体化,将无处不在。
云原生技术起源于数据中心内的应用和服务,并在过去几年逐渐扩展到边缘场景甚至端上的计算。相信未来随着 5G/IoT 的快速发展,云边端一体化的云原生技术将深入更多的企业和更丰富场景,将无处不在。
第四,云原生将经历企业落地之痛,云原生上云将成为趋势。
云的技术发展会领先于企业落地的速度。尽管云原生技术已经被广泛接受,其在企业技术栈的落地仍然需要时间,也面临不少挑战。如容器化过程中改变传统虚拟机模式下的运维习惯,企业传统应用分布式微服务化的改造涉及 re-architecturing 等因素。
云原生被企业接受之后,落地的过程需要解决这些挑战。运维管理含有丰富组件并快速演进的云原生的基础设施也对企业 IT 人员的技术技能提出了更高的要求。然而我们相信,云原生技术带来的资源成本降低,研发运维效率提升等巨大价值,会驱动企业迎接这些挑战。
在这个过程中,使用云原生上云,基于容器和服务网格等标准界面和混合云方案,将极大的降低迁云复杂度,使企业可以更快迁移到云上标准服务。通过云原生上云最大化使用云的能力,高效的社会分工,使企业聚焦于自身业务发展,相信将成为企业的共识。
2020 云原生 7 大技术领域趋势
1、Serverless
2019,行业中的各大 Serverless 计算平台的能力有了长足进步,变得更加通用。例如通过预留资源完全消除冷启动对延时的影响,使得延时敏感的在线应用也能够使用 Serverless 方式构建。Serverless 生态不断发展。在应用构建,安全,监控报警等方面涌现了很多开源项目和创业公司,工具链越来越成熟。
用户对 Serverless 的接受度不断增加。除了互联网等迅速拥抱新技术的行业,传统企业用户也开始采用 Serverless 技术。站在新的一个十年, Serverless 领域将发生如下演进:
Serverless 将进一步从偏离线业务进入在线业务。
真正的按请求次数计费和从零到一的响应时间是一个天然的矛盾,以 FaaS 为代表的 Serverless 技术一开始都是从对响应时间不敏感的,事件驱动的偏离线业务入手。但是今天我们已经看到,包括 AWS Lambda Provisioned Capacity 和 Azure Functions Premium plan 在内的产品特性,都在让用户稍微付出一点额外的成本以换取更低的响应时间。这对于在线业务来说,无疑是更适合的。
Serverless 不仅是应用或者函数的能力,也会加速推动基础设施和服务 Serverless 化。
业务代码托管给 Serverless 平台之后,即能享受到自动弹性,按请求计费能能力。但是如果基础设施和相关服务不具备实时的扩缩容能力,那么对于业务整体来说,就不是弹性的。我们已经看到 AWS 围绕 Lambda 对 VPC 网络、数据库连接池等资源做了大量实时弹性优化,相信其他的厂商也会跟进,进而行业整体会加速基础设施和各类云服务的 Serverless 化。
以 Knative 为代表的开源解决方案将得到越来越多的关注。
尽管各个云厂商都在大力推广自己的 Serverless 产品,但是开发者普遍还是会担心被厂商绑定,因此具备一定规模的组织会基于开源方案,如 Knative,搭建自己的 Serverless 平台。而一旦某个开源方案成为主流,云厂商就会主动去兼容开源标准并增大社区投入。
Serverless 开发者工具和框架会进一步繁荣。
IDE,问题诊断,持续集成/发布等配套的工具和服务的用户体验会更加完整。我们将看到更多的成功案例和最佳实践。在前端开发等领域将会出现为 Serverless 而生的应用框架,将工程效率发挥到极致。
Java 持续进击,将成为 Serverless 平台主流语言之一。
Serverless 平台要求应用的镜像足够小以能够快速分发,同时要求应用的启动时间极短。虽然在这些方面,Java 和 NodeJS 和 Python 等语言有差距,但是 Java 社区在不断努力。我们看到 Java 通过 Java 9 Modules 以及 GraalVM Native Image 等技术在不断努力“减肥”,主流框架 Spring 也开始拥抱 GraalVM,而新的框架如 Quarkus 和 Micronaut 也在做新的突破。期待 Java 在 Serverless 领域给人焕然一新的感觉。
解决 FaaS 状态传递的中间层(加速层)研究或产品有望得到突破。
Serverless 在 Function 场景下未来最大的挑战是 function 之间串联需要状态(state)传递、function 处理需要频繁和外部存储交互等带来的时延放大。传统的架构这些都是在一个程序进程内部处理完毕。解决上述挑战需要可计算中间层(加速层),可计算中间层(加速层)是未来学术研究和产品攻坚发展方向之一。
基于 WebAssembly(简称 WASM) 的 FaaS 方案有望出现。
Docker 的创始人之一 Solomon Hykes 曾说,“如果2008年有 WASM 和 WASI,我们当时就没有必要创造 Docker 了”,这句话在一定程度上说明了 WASM 的重要性。虽然当下 WASM 更多作为一种运行在浏览器端的技术被人了解,但是它具备非常优秀的安全隔离能力,极快的启动速度,以及对于超过20种语言的支持,那么为什么不能让它运行在服务端呢?这些技术特性都非常契合 FaaS 的要求。
2、Service Mesh
在 2019 年,Service Mesh 的整体解决方案逐渐显现了寡头垄断的局面。一个解决方案能否得到行业的普遍认可,关键在于其背后的技术团队对分布式应用治理复杂度是否有深刻洞见,以及能否打造一个被所有云厂商都采纳的事实标准。事实标准对于使用 Service Mesh 的客户来说,意味着分布式应用能根据自己的需要在多云和混合云上方便部署。
站在新的一个十年, 2020 年 Service Mesh 领域将有如下变化:
2019 Service Mesh 热度持续上升,落地的问题将在 2020 得到解决。
2019 年,Service Mesh 在部分公司如蚂蚁金服迎来大规模的落地,整个业界的热度在持续上升,大大加大了国内公司对于 Service Mesh 的信心,目前几乎每家稍微大一点的互联网公司都已经开始实践 Service Mesh,包括美团、头条、百度等公司。
当然,在 2019 年业界落地遇到的各种问题,包括 Sidecar 大规模运维的问题等等,以 OpenKruise/kruise 的为代表的 SidecarSet 虽然已经在做一些努力,但是目前仍然存在升级 Pod 过程过于复杂的问题,这些问题有望在 2020 年得到解决。
Istio 将更加成熟,更加适合大规模集群的落地。
2020 年 Istio 作为控制平面的一种技术实现仍将在 Service Mesh 领域扮演核心角色。Istio 获得业界广泛关注的原因,在于背靠 Google 公司的内部工程实践,以及对工程实践的再思考和重新提炼。Istio 在过去一年的重要工作是完善功能和改善稳定性确保小规模生产可用,在 2020 年随着阿里巴巴采用这一技术实现大规模落地将为 Istio 的规模化运用提供真实的场景,这将使得 Istio 在接下来的一年在支持集群规模的能力上大幅提高。
此外,随着探索,Istio 的可运维性和架构的合理性在 2020 年也将迎来积极的变化,其部署和运维的复杂性高等问题将得到解决。Istio 所采纳的 Envoy 开源项目,在新的一年依然保持 Service Mesh 数据平面的事实标准这一领导地位,Istio 和 Envoy 两大开源社区因为紧密协作而更好地推动 Service Mesh 向前演进。
Serivce Mesh on EdgeService 热度持续 Service Mesh & IoT。
2019 年 Serivce Mesh on Edge 的热度在逐渐提升,Edge 本质上要提供更快的响应提升体验。对于 Service Mesh 来说,被从“舒适”的云端下放到 Edge,要解决性能,低资源消耗,安全,高可用等问题,具体 Kernel Bypaasing,Sidecar as Node+WASM,SmartNic 软硬件结合, IoT Identity 结合,secret 保护,低输出成本,非可靠网络环境等,当下看还非常有挑战,这些问题将在 2020 年得到部分解决。
More Than Service Mesh。
Service Mesh 作为解耦应用与基础设施的关键技术,在 2020 年将有更多的产品通过与 Service Mesh 结合去完成 BaaS 化,这除了减少没有必要的重复建设,还使得云产品因为将那些与应用无关的内容剥离出来下沉为基础设施的一部分而加速自身的演进速度,以及给云产品的使用者带去更棒的软件开发和维护体验而加速业务的探索效率和降低探索成本。
我们看到 Envoy 也提供了 MySQL、Redis、MongoDB、DynamoDB 的协议支持,能够支持请求解析、请求级统计、失败统计等通用的可观测性特性。后续 Mesh 将继续发展,成为整个网络层面的一个基础设施,用以管控所有应用层面的出/入口流量。
展望 2020 年,Service Mesh 将会成为解决异构系统通信、混合云架构等方向上的必备组件,在混合云、新老架构的场景下,Service Mesh 和原有基础设施的结合能力将成为 Service Mesh 落地的关键,比如对于 VM 场景的支持,对于传统服务注册中心的支持等等,相信会有更多的公司通过实践而对 Service Mesh 的价值更有体感,通过创造更多的成功客户故事而加速 Service Mesh 的普及。也许,2020 年将成为 Service Mesh 的普及年。
3、Kubernetes
2019 年,在社区头部参与者的持续推进下,“规模”与“性能”终于成为了 Kubernetes 项目的重要关键词,这不仅真正意义上打通了 Kubernetes 在企业生产环境中大规模落地的最后一公里,也让 Kubernetes 第一次成为了 “双11” 等顶级互联网规模化场景中实实在在的技术主角。
站在新的一个十年, 2020 年 Kubernetes 领域将有如下变化:
Kubernetes 将成为用户和云计算新的交互界面。
随着云原生计算的普及,越来越多的应用负载都部署在 Kubernetes 之上,包括数据库、大数据、AI智能和创新应用,Kubernetes 已成为云原生计算的基石。得益于 Kubernetes 的大规模应用管理能力、多云混合云的支持能力,在 2020 年,Kubernetes 会成为用户和云计算新的交互界面。从架构的角度,Kubernetes 成为了 IaaS 层的控制平面,并进一步推动底层 IaaS(计算、存储、网络)的能力优化,来满足容器带来的一二个数量级的高密度和高动态性要求。
Kubernetes 掌控能力成为企业运维团队的核心技能,并和 AIOPS 相互促进发展。
Kubernetes 的大规模使用是否会带来企业运维人员的失业?实际上,随着越来越多的企业 IT 架构,从 on Kubernetes 到 in Kubernetes,大量的 CRD、自定义 Controller 和服务网格的引入,给 Kubernetes 的稳定性和性能优化带来大量的挑战。Kubernetes 的掌握深度逐渐成为企业运维团队技术能力的重要评估标尺,而企业运维人员的技能也会从自动化向数据化和智能化发展。
预测在 2020 年,围绕着 Kubernetes 的 AIOps 会逐渐涌出,来进一步完善 Kubernetes 的成本优化、故障检测和集群优化。
而 Kubernetes 等云原生技术也会让 AIOps 不再雾里看花:
1)得益于 Kubernetes 的良好设计,包括声明式API、不可变架构、优雅的扩展机制,可以促进应用发布和运维的操作归一化(Normalization);
2)结合 GItOps、Tekton、SecOps 等自动化流程的落地,应用的生命周期更加标准化(Standardization);
3)随着 OpenTelemetry、CloudEvents 等项目的推进,应用可观测性领域在日志、监控、Tracing、事件等领域进一步标准化和融合,使得多指标、根因分析的数据集更加丰富,从而提高 AIOPS 的 AI 层面的准确率和覆盖率。
新内核、新硬件助力容器优化 OS 的演进。
容器技术经过了多年的发展,从早期的 Docker、rkt、CRI-O 等,到 containerd、Kata Container、gVisor,已经成为 Kubernetes 运行的重要基石。然而无论是 runc 场景的进一步隔离,还是安全容器场景的进一步性能优化,还需要持续的打磨和增强。
随着新内核技术包括 CGroup V2、namespace、virtiofs 等的逐步成熟,可以进一步增强容器运行时的能力。另一方面,一些新硬件包括 NPU、MoC、NUMA 等的引入,也给容器和 K8s 调度带来了更多的优化空间和场景。得益于这些能力的加成,为容器场景量身定制的容器优化 OS 成为可能,并会快速发展。
容器网络和 Mesh 网络将进一步融合。
Service Mesh 经过多年的市场培育,2020 年将会成为 Service Mesh 技术的普及年。而 Service Mesh 的性能优化也会成为重头戏,一些下沉方案也在选择基于 CNI(容器网络接口)和内核技术进一步优化网络转发性能。
而容器网络自身也在逐渐演进,从面向 ip 到面向 Identity,从单容器网络平面到多网络平面,并进一步优化网络转发性能和零可信安全。在 2020 年,我们相信容器网络和 Mesh 网络将进一步融合,在 Network ServiceMesh、NFV等场景进一步集成。
4、边缘计算
随着 5G 和万物互联时代的到来,联网智能终端设备数量将急剧增加,传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求,将云计算的能力下沉到边缘侧、设备侧,并通过中心进行统一交付、运维、管控,将是云计算的重要发展趋势。
IDC 预计,到 2020 年全球将有超过 500 亿的终端与设备联网,超过 40% 的数据要在网络边缘侧进行分析、处理与存储,这对边缘计算提供了充分的场景和想象空间。
站在新的一个十年,2020 年边缘计算领域将有如下变化:
以 Kubernetes 为基础的云原生技术,经过近几年的高速发展,适用范围、落地场景、技术成熟度等均有了长足发展,其核心价值之一是通过统一的标准实现在任何基础设施上提供和云上一致的功能和体验。将云原生技术和边缘计算相结合,可以快速实现『云-边-端』一体化的应用分发,解决在海量边、端设备上统一完成大规模应用交付、运维、管控的诉求;
在安全方面,云原生技术可以提供容器等更加安全的工作负载运行环境,以及流量控制、网络策略等能力,能够有效提升边缘服务和边缘数据的安全性;
在边缘网络环境下,基于云原生技术的边缘容器能力,能保证弱网、断网的自治性,提供有效的自恢复能力,同时对复杂的网络接入环境有良好的兼容性;
依托云原生领域强大的社区和厂商支持,云原生技术对异构资源的适用性逐步提升,在物联网领域,云原生技术已经能够很好的支持多种 CPU 架构和通信协议,并实现较低的资源占用;
目前已经有不少厂商在进行云原生边缘计算的尝试,并有了部分成功案例,相信在 2020 年随着 5G 的快速铺开,云原生边缘计算的发展将大大提速。
5、容器实例与容器引擎
在 2019 年的最后一个月 AWS 终于发布了 Fargate for EKS 产品,这也宣告了云上 Kubernetes 使用 Serverless 容器实例作为底层运行时资源的产品形态得到了业界更广泛的认可。通过容器实例作为底层运行实体可以让用户专注于构建自身的业务和服务,无需再配置和管理服务器,摆脱基础设施运维的复杂性。同时通过真正的按需付费和实时扩容来降低用户的使用成本。 无论是亚马逊的 Fargate,微软的 ACI 还是阿里云的 ECI,各产品当前在对接 Kubernetes 的具体架构上仍然有分歧,以 Fargate 为代表采用的是透传 Node 信息的方式来提供对 Kubernetes 功能的完整支持;以 ACI/ECI 为代表则采用 virtual kubelet 方式对接 Kubernetes 对容器实例进行管理。
但无论采用何种对接方式,容器实例产品的核心依然需要构建在弹性、成本和 Kubernetes 兼容性上。通过弹性实现用户服务的按需实时扩容,用户无需选择实例和集群容量,不需要为额外的服务器预置而付费;通过实时扩容实现真正的按使用资源付费,降低用户的使用成本;Kubernetes 已经成为容器编排领域的事实标准,对 Kubernetes 功能的兼容性决定着容器实例的适用范围。
站在新的一个十年,相信在 2020 年容器实例产品会在这三个方面继续改进和完善,持续提升弹性能力,降低用户的使用成本,并不断完善与 Kubernetes 的集成。同时也会有更多的云原生应用迁移到 Kubernetes+ 容器实例上,享受云原生的技术红利。
从上述各厂商的同类产品中我们也可以看到此类产品在设计上的共同之处:
一个实例对应一个 Pod
对接 Kubernetes
安全容器作为底层容器引擎
这其中使用安全容器作为底层容器引擎是各家都很重视的底层基础能力。在 2019 年安全容器技术的隔离性越来越被看重,作为一个隔离层,不仅提升云原生平台的安全性,也对可运维性、服务质量和用户数据保护有显著效果。不过,回归初心,用户选择云原生的本质是容器带来的敏捷性,他们可以快速地调度并启动容器,并且可以灵活地使用资源,这方面安全技术尚不能达到传统容器的水平。 不论是 Kata Containers 还是 gVisor,开源安全容器引擎在 2019 年都取得了很多进展,Kata Containers 明确提出了“做面向云原生的虚拟化”作为 2020 年的目标:
在沙箱间共享资源,同时保持沙箱边界仍然清晰。
即时、动态地按需为沙箱提供资源,而不是像分区那样进行固定的资源分配。
主机的用户态工具、VMM、乃至应用的内核联合起来,彼此协同为沙箱中的应用提供服务。
在 2020 年,Kata 代表的虚拟化容器会与传统虚拟化渐行渐远而更加“应用中心”,gVisor 为代表的进程级虚拟化也期待更多为应用的优化。我们相信在 2020 年的时候,我们还不会有一个统一的安全容器技术,但展望 21 世纪 20 年代的头几年,我们期待软硬件的共同发展会让主流的容器引擎都具有更好的隔离性。
6、基础架构演进
基于 Kubernetes 的 Serverless Infras 架构演进一直是各大云厂商和社区关注的焦点。2019 年 12 月 AWS 在拉斯维加斯召开了一年一度 re:Invent 大会上宣布了 EKS on AWS Fargate 产品正式 GA,这个消息在云市场和社区里掀起了不小的波澜。
EKS on Fargate 提供了标准的 Serverless Infra.的用户体验,即用户购买了 EKS 的服务后,不再需要购买额外的 Infra 云资源(如VM,Nitro),就可以使用原生 K8s API 部署自己的应用,并且支持按量计费。
Serverless Infra.架构使得用户无需关注计算、网络、存储等底层基础设施细节,真正让用户回归到面向POD应用资源部署形态上去;同时管控面与数据面的强隔离能力将会是 Serverless Infra.架构的关键,除了对用户屏蔽底层基础设施细节外,Serverless Infra. 需要提供给用户一个安全可信的租户隔离环境
2019 年随着经济体全面上云,底层调度系统全面升级到云原生 Kubernetes + 轻量级容器架构演进,并且大规模部署在神龙裸金属实例上;同时基于 kata-container 的安全容器运行时技术趋于成熟,已经具备大规模铺开的条件。
站在新的一个十年,预计2020 年,将是经济体全面迈向基础设施 Serverless Infra. 的一年,Serverless Infra.架构将会基于神龙+安全容器架构,通过构建软/硬多租户能力,弹性能力和高度的容器自愈能力,为用户提供极致的安全、稳定、隔离性的用户体验。同时底层资源池共享也能有效提升整体资源利用率,并池后资源互通将会有效降低整体机器成本
7、应用开发
展望 2020,我们认为云原生+智能化将成为下一代研发平台最重要的两个特性,它将进一步降低开发者采纳复杂技术的门槛以及通过工具释放生产力。当所有复杂度都卸载到云上以后,我们将回到 10 年前开发单机程序时的高效。
站在新的一个十年, 2020 应用开发领域将发生如下演进:
从 Web-IDE 演进为 Cloud-Native IDE
2019 年是 VS Code 生态继续高歌猛进的一年,得益于其模块化的设计,VS Code 中的几个核心组件Monaco编辑器,插件体系,Language Server Protocol(LSP)等成为了Web-IDE的标准选型。社区也出现了code-server这样基于 VS Code 一行命令拉起 Web-IDE 的方案。
除了 VS Code 之外,Theia 也继续演进,尤其是基于 Theia 的gitpod.io 让人眼前一亮,通过把 gitpod 按钮集成在诸如 GitHub README 页面上,一键实现了从代码到预览的顺滑体验。
另一方面,大厂已有的 Web-IDE 方案也需要回过头来拥抱社区,彻底如 Facebook 完全从自研的Nuclide 转而投向 VS Code,而无论是 Amazon的Cloud9 还是 Google 尚未对外的 Cider,如果要在商业化上更进一步,支持 VS Code 的插件体系想必也是理所当然。
从 Local-IDE 到 Web-IDE 让我想起了当年从 PC 到移动端。虽说时至今日,不少专业工具 PC 端的体验仍然是移动端难以企及的,但移动端的主导地位早已不容置疑。
Web-IDE 具备开箱即用,环境一致可控以及和其它Web服务无缝集成的先天优势。接下来要做的除了继续补齐和 Local-IDE 在端功能的差距外,还可以结合分布式编译构建,集中式代码仓库,海量代码索引分析,云端协同等,提供真正的 Cloud-Native IDE。
工具 -> 平台 -> 标准
GitHub 今年推出了 GitHub Actions,通过它可以在工作流中灵活地集成各种第三方服务。GitLab 也在更早的时候就推出了可定制化的 CI 流水线配置。无论是 GitHub 还是 GitLab,它们都从早期单纯的代码托管工具成长为了一站式 DevOps 平台。
最早以 IntelliJ 工具起家的 JetBrains 不再满足于仅仅打磨 IDE,今年也推出了 Space,力图打造一站式研发团队平台。以项管工具 Jira 起家的 Atlassian,一直是自研收购两架马车并驾齐驱,今年通过收购又在自己研发平台的版图上增加了针对管理者视角的 Jira Align。
后起之秀如 sourcegraph 干脆直接在网站上号称自己是 The new standard developer platform。不管是基于 Dev 工具的右移,抑或是基于 Ops 工具的左移,当年的工具们都或多或少地长成所谓的一站式 DevOps/DevSecOps 平台。
那接下来,在这些平台之上是否能提炼出通用的标准?比如 CI 领域,是否能有一套 CI 流水线定义可以一统CircleCI,GitLab,GitHub Actions 诸如此类?是否也有一套 workflow 标准可以让用户在 AWS Step Functions, Argo, Tekton 之间无缝迁移?
在更高的抽象层面,诸如 Open Appliction Model(OAM) 这样的标准是不是能真正架起从业务架构到基础架构的桥梁。虽然如今的研发平台已然是诸侯割据的局面,但在云原生,标准先行的理念下,我还是会期待有离业务层更接近的云原生标准去串联起整个研发平台。
开发者工具从本地工作到云端协作
当前的开发者工具绝大多数采用的是 lift and shift 的方式从本地平移上云,产品设计针对的还是单人人机交互,移到云端的研发工具还没有很好地利用云端多人实时交互的能力。无论是多人协作(云已经让我们离彼此更近),还是人机协作(云已经让机器变得更强),我期待着出现进一步挖掘云端协作能力的创新点。
更多云原生研发平台涌现
以 Kubernetes、Serverless、Service Mesh、Cloud IDE 为代表的多项云原生技术在过去一年让人印象深刻。我们意外的观察到,以中小互联网公司为代表的技术群体开始快速拥抱这个技术体系,并且通过云原生落地,快速的获得了以往互联网大厂才有的精英软件交付能力,比如复杂的流量治理能力,灰度发布能力,A/B Test 能力,多环境管理能力,基础设施一键拉起,快速扩缩能力等等。
但在企业采纳新技术的同时,也面临着诸多挑战,比如开源软件复杂的搭建过程,黑屏化的交互设计,缺乏研发管理方法,缺乏企业权限管理能力等。因此一大批软件供应商开始基于云原生技术体系开发相关的管理平台,比如 QingCloud,Rancher,阿里云容器服务。作为云上研发协同平台领导者的云效也在积极将 CICD 工具、测试环境管理方法、应用运维理念、DevOps 协同方法论等与云原生技术融合贯通,为企业提供开箱即用的新技术解决方案。
数据和智能的工具时代到来
云原生是一套开放标准的技术体系,核心贡献者就是当今世界的互联网云厂商巨头企业。随着技术的发展和影响力的增强,逐步将企业的私有技术壁垒打破,并且开始采纳云上现成的云原生产品来改造自身的技术体系。技术的收敛带来了统一数据规范的可能,而数据是所有智能化的基石。
我们观察到最近一年 AWS、微软、Facebook、ebay 等厂商都在积极布局智能化工具,从传统的“代码”智能工具逐步扩展到“服务”智能工具。比如最近 AWS 发布的CodeGuru,它是一个用于代码审查自动化和性能优化推荐的机器学习服务。它能找出最影响程序性能的代码行,并让提供修复或改进代码的具体建议。这就是代码大数据和运行时服务大数据结合的智能工具。
2020 如何兑现新技术给业务带去的价值
对于云原生从业者来说,2020 年最大的挑战可能是兑现新技术给业务带去的价值。虽说过去一年对云原生的价值有不同层次、不同视角的解读,但更多还是从技术层面,鲜有各行各业的客户成功案例阐述新技术所带来的直接业务价值。
从市场的角度:仍存在大量的传统行业的企业处于物理机或虚拟机时代,受资产状况的影响他们很难一下子将核心业务搬迁到云原生之上而体会到新技术的巨大价值;另一方面,对于早已进入容器时代的那些企业,他们在软件资产上过去多年持续地投入了大量的资源做建设,从功能层面早已建立起了与云原生等同的软件资产,不会很快从自建转变为云原生。这是市场面对新技术普及之前的正常姿态,行业客户从两端正在被改变,今天大家正逐步对云原生这一概念达成有具象的共识。
站在新的一个十年起点,云原生从业者应当坚定自己对于新技术价值的理解和洞察,沉下心去将云原生的基础能力建设好。同时,需要特别重视以合适的方式和时机去兑现业务价值,通过更多的成功客户故事去加速市场对新技术的接受,让自己的成果更快、更好地被市场认可,创造行业趋势,为云计算的发展做出自己的贡献。
(本文转载自51CTO.com)
本文章发表于:2020-01-16 10:20:05
过去的几年,是云原生技术和理念得到广泛接受的几年。在这个快速发展的领域,预测未来显得尤其困难,但是我们又有着一些坚定的信念,相信以开放创新为支撑的云原生领域会持续重塑软件生命周期,带来不断的价值。
2019,在众多热门技术趋势中,云原生的关注度居高不下,很多开发者都对由此而兴起的一众技术十分追捧,众多企业开始探索云原生架构转型落地。在中国,开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。
在筹备阿里云首届云原生实践峰会的过程中,我们展开了对云原生技术的应用和研究领域的探索,邀请了 17 位云原生技术专家从 Serverless、Service Mesh、Kubernetes、边缘计算、容器实例与容器引擎、云原生基础架构、云原生应用开发 7 个发展方向,回顾 2019 云原生领域进展,描绘云原生技术的新十年。
2020 云原生标志性事件预测
展望 2020,在云原生技术的应用和研究领域,我们预见会有这些标志性事件。
第一,云原生技术关注重心在上移,Serverless 和应用管理重点。
过去的几年我们看到,云原生技术重心围绕容器和容器编排。Docker 和 K8s 的成功几乎成了云原生的代名词。很多人说,Kubernetes is becoming boring,这是对于技术的趋势来说。
云原生关注重心即将上移:
应用的定义和配置、发布和线上的自动化运维,成为开发和运维人员关心的核心内容。阿里巴巴和微软联合推出的 Open Application Model (OAM) 就是这个方向的一个重要项目。
作为云原生技术的延伸,无服务器计算(Serverless)将进一步释放云计算的能力,将安全、可靠、可伸缩等需求由基础设施实现,使用户仅需关注业务逻辑而无需关注具体部署和运行,极大地提高应用开发效率,同时这个方式促进了社会分工协作,云厂商可以进一步通过规模化、集约化实现计算成本大幅优化。相信在 2020 会有更多的创新和落地实践在这个领域涌现。
第二,云原生技术成为云服务商的创新和竞争力的主阵地。
随着以容器为基础的云原生技术被用户广泛接受,可以肯定的预期,容器会很快成为云和用户的基本界面。因此对于云的服务提供商来说,基于容器、微服务、无服务器、服务网格等新型云原生技术的领域,必将是云厂商未来创新和竞争力的主阵地。
虚拟化未来 3 年还会是云上资源增量的主体,但是硬件虚拟化加速的裸金属和安全沙箱容器的组合,正在加速企业的上云和容器化过程。云厂商未来技术竞争力的关键,在云传统的优势包括规模、稳定性、成本发挥到极致的前提下,必将通过云原生技术和产品的持续创新来服务客户来获得客户的认可。云原生产品领域将成为云厂商竞争白热化的必争之地。
第三,云原生从数据中心走向云边端一体化,将无处不在。
云原生技术起源于数据中心内的应用和服务,并在过去几年逐渐扩展到边缘场景甚至端上的计算。相信未来随着 5G/IoT 的快速发展,云边端一体化的云原生技术将深入更多的企业和更丰富场景,将无处不在。
第四,云原生将经历企业落地之痛,云原生上云将成为趋势。
云的技术发展会领先于企业落地的速度。尽管云原生技术已经被广泛接受,其在企业技术栈的落地仍然需要时间,也面临不少挑战。如容器化过程中改变传统虚拟机模式下的运维习惯,企业传统应用分布式微服务化的改造涉及 re-architecturing 等因素。
云原生被企业接受之后,落地的过程需要解决这些挑战。运维管理含有丰富组件并快速演进的云原生的基础设施也对企业 IT 人员的技术技能提出了更高的要求。然而我们相信,云原生技术带来的资源成本降低,研发运维效率提升等巨大价值,会驱动企业迎接这些挑战。
在这个过程中,使用云原生上云,基于容器和服务网格等标准界面和混合云方案,将极大的降低迁云复杂度,使企业可以更快迁移到云上标准服务。通过云原生上云最大化使用云的能力,高效的社会分工,使企业聚焦于自身业务发展,相信将成为企业的共识。
2020 云原生 7 大技术领域趋势
1、Serverless
2019,行业中的各大 Serverless 计算平台的能力有了长足进步,变得更加通用。例如通过预留资源完全消除冷启动对延时的影响,使得延时敏感的在线应用也能够使用 Serverless 方式构建。Serverless 生态不断发展。在应用构建,安全,监控报警等方面涌现了很多开源项目和创业公司,工具链越来越成熟。
用户对 Serverless 的接受度不断增加。除了互联网等迅速拥抱新技术的行业,传统企业用户也开始采用 Serverless 技术。站在新的一个十年, Serverless 领域将发生如下演进:
Serverless 将进一步从偏离线业务进入在线业务。
真正的按请求次数计费和从零到一的响应时间是一个天然的矛盾,以 FaaS 为代表的 Serverless 技术一开始都是从对响应时间不敏感的,事件驱动的偏离线业务入手。但是今天我们已经看到,包括 AWS Lambda Provisioned Capacity 和 Azure Functions Premium plan 在内的产品特性,都在让用户稍微付出一点额外的成本以换取更低的响应时间。这对于在线业务来说,无疑是更适合的。
Serverless 不仅是应用或者函数的能力,也会加速推动基础设施和服务 Serverless 化。
业务代码托管给 Serverless 平台之后,即能享受到自动弹性,按请求计费能能力。但是如果基础设施和相关服务不具备实时的扩缩容能力,那么对于业务整体来说,就不是弹性的。我们已经看到 AWS 围绕 Lambda 对 VPC 网络、数据库连接池等资源做了大量实时弹性优化,相信其他的厂商也会跟进,进而行业整体会加速基础设施和各类云服务的 Serverless 化。
以 Knative 为代表的开源解决方案将得到越来越多的关注。
尽管各个云厂商都在大力推广自己的 Serverless 产品,但是开发者普遍还是会担心被厂商绑定,因此具备一定规模的组织会基于开源方案,如 Knative,搭建自己的 Serverless 平台。而一旦某个开源方案成为主流,云厂商就会主动去兼容开源标准并增大社区投入。
Serverless 开发者工具和框架会进一步繁荣。
IDE,问题诊断,持续集成/发布等配套的工具和服务的用户体验会更加完整。我们将看到更多的成功案例和最佳实践。在前端开发等领域将会出现为 Serverless 而生的应用框架,将工程效率发挥到极致。
Java 持续进击,将成为 Serverless 平台主流语言之一。
Serverless 平台要求应用的镜像足够小以能够快速分发,同时要求应用的启动时间极短。虽然在这些方面,Java 和 NodeJS 和 Python 等语言有差距,但是 Java 社区在不断努力。我们看到 Java 通过 Java 9 Modules 以及 GraalVM Native Image 等技术在不断努力“减肥”,主流框架 Spring 也开始拥抱 GraalVM,而新的框架如 Quarkus 和 Micronaut 也在做新的突破。期待 Java 在 Serverless 领域给人焕然一新的感觉。
解决 FaaS 状态传递的中间层(加速层)研究或产品有望得到突破。
Serverless 在 Function 场景下未来最大的挑战是 function 之间串联需要状态(state)传递、function 处理需要频繁和外部存储交互等带来的时延放大。传统的架构这些都是在一个程序进程内部处理完毕。解决上述挑战需要可计算中间层(加速层),可计算中间层(加速层)是未来学术研究和产品攻坚发展方向之一。
基于 WebAssembly(简称 WASM) 的 FaaS 方案有望出现。
Docker 的创始人之一 Solomon Hykes 曾说,“如果2008年有 WASM 和 WASI,我们当时就没有必要创造 Docker 了”,这句话在一定程度上说明了 WASM 的重要性。虽然当下 WASM 更多作为一种运行在浏览器端的技术被人了解,但是它具备非常优秀的安全隔离能力,极快的启动速度,以及对于超过20种语言的支持,那么为什么不能让它运行在服务端呢?这些技术特性都非常契合 FaaS 的要求。
2、Service Mesh
在 2019 年,Service Mesh 的整体解决方案逐渐显现了寡头垄断的局面。一个解决方案能否得到行业的普遍认可,关键在于其背后的技术团队对分布式应用治理复杂度是否有深刻洞见,以及能否打造一个被所有云厂商都采纳的事实标准。事实标准对于使用 Service Mesh 的客户来说,意味着分布式应用能根据自己的需要在多云和混合云上方便部署。
站在新的一个十年, 2020 年 Service Mesh 领域将有如下变化:
2019 Service Mesh 热度持续上升,落地的问题将在 2020 得到解决。
2019 年,Service Mesh 在部分公司如蚂蚁金服迎来大规模的落地,整个业界的热度在持续上升,大大加大了国内公司对于 Service Mesh 的信心,目前几乎每家稍微大一点的互联网公司都已经开始实践 Service Mesh,包括美团、头条、百度等公司。
当然,在 2019 年业界落地遇到的各种问题,包括 Sidecar 大规模运维的问题等等,以 OpenKruise/kruise 的为代表的 SidecarSet 虽然已经在做一些努力,但是目前仍然存在升级 Pod 过程过于复杂的问题,这些问题有望在 2020 年得到解决。
Istio 将更加成熟,更加适合大规模集群的落地。
2020 年 Istio 作为控制平面的一种技术实现仍将在 Service Mesh 领域扮演核心角色。Istio 获得业界广泛关注的原因,在于背靠 Google 公司的内部工程实践,以及对工程实践的再思考和重新提炼。Istio 在过去一年的重要工作是完善功能和改善稳定性确保小规模生产可用,在 2020 年随着阿里巴巴采用这一技术实现大规模落地将为 Istio 的规模化运用提供真实的场景,这将使得 Istio 在接下来的一年在支持集群规模的能力上大幅提高。
此外,随着探索,Istio 的可运维性和架构的合理性在 2020 年也将迎来积极的变化,其部署和运维的复杂性高等问题将得到解决。Istio 所采纳的 Envoy 开源项目,在新的一年依然保持 Service Mesh 数据平面的事实标准这一领导地位,Istio 和 Envoy 两大开源社区因为紧密协作而更好地推动 Service Mesh 向前演进。
Serivce Mesh on EdgeService 热度持续 Service Mesh & IoT。
2019 年 Serivce Mesh on Edge 的热度在逐渐提升,Edge 本质上要提供更快的响应提升体验。对于 Service Mesh 来说,被从“舒适”的云端下放到 Edge,要解决性能,低资源消耗,安全,高可用等问题,具体 Kernel Bypaasing,Sidecar as Node+WASM,SmartNic 软硬件结合, IoT Identity 结合,secret 保护,低输出成本,非可靠网络环境等,当下看还非常有挑战,这些问题将在 2020 年得到部分解决。
More Than Service Mesh。
Service Mesh 作为解耦应用与基础设施的关键技术,在 2020 年将有更多的产品通过与 Service Mesh 结合去完成 BaaS 化,这除了减少没有必要的重复建设,还使得云产品因为将那些与应用无关的内容剥离出来下沉为基础设施的一部分而加速自身的演进速度,以及给云产品的使用者带去更棒的软件开发和维护体验而加速业务的探索效率和降低探索成本。
我们看到 Envoy 也提供了 MySQL、Redis、MongoDB、DynamoDB 的协议支持,能够支持请求解析、请求级统计、失败统计等通用的可观测性特性。后续 Mesh 将继续发展,成为整个网络层面的一个基础设施,用以管控所有应用层面的出/入口流量。
展望 2020 年,Service Mesh 将会成为解决异构系统通信、混合云架构等方向上的必备组件,在混合云、新老架构的场景下,Service Mesh 和原有基础设施的结合能力将成为 Service Mesh 落地的关键,比如对于 VM 场景的支持,对于传统服务注册中心的支持等等,相信会有更多的公司通过实践而对 Service Mesh 的价值更有体感,通过创造更多的成功客户故事而加速 Service Mesh 的普及。也许,2020 年将成为 Service Mesh 的普及年。
3、Kubernetes
2019 年,在社区头部参与者的持续推进下,“规模”与“性能”终于成为了 Kubernetes 项目的重要关键词,这不仅真正意义上打通了 Kubernetes 在企业生产环境中大规模落地的最后一公里,也让 Kubernetes 第一次成为了 “双11” 等顶级互联网规模化场景中实实在在的技术主角。
站在新的一个十年, 2020 年 Kubernetes 领域将有如下变化:
Kubernetes 将成为用户和云计算新的交互界面。
随着云原生计算的普及,越来越多的应用负载都部署在 Kubernetes 之上,包括数据库、大数据、AI智能和创新应用,Kubernetes 已成为云原生计算的基石。得益于 Kubernetes 的大规模应用管理能力、多云混合云的支持能力,在 2020 年,Kubernetes 会成为用户和云计算新的交互界面。从架构的角度,Kubernetes 成为了 IaaS 层的控制平面,并进一步推动底层 IaaS(计算、存储、网络)的能力优化,来满足容器带来的一二个数量级的高密度和高动态性要求。
Kubernetes 掌控能力成为企业运维团队的核心技能,并和 AIOPS 相互促进发展。
Kubernetes 的大规模使用是否会带来企业运维人员的失业?实际上,随着越来越多的企业 IT 架构,从 on Kubernetes 到 in Kubernetes,大量的 CRD、自定义 Controller 和服务网格的引入,给 Kubernetes 的稳定性和性能优化带来大量的挑战。Kubernetes 的掌握深度逐渐成为企业运维团队技术能力的重要评估标尺,而企业运维人员的技能也会从自动化向数据化和智能化发展。
预测在 2020 年,围绕着 Kubernetes 的 AIOps 会逐渐涌出,来进一步完善 Kubernetes 的成本优化、故障检测和集群优化。
而 Kubernetes 等云原生技术也会让 AIOps 不再雾里看花:
1)得益于 Kubernetes 的良好设计,包括声明式API、不可变架构、优雅的扩展机制,可以促进应用发布和运维的操作归一化(Normalization);
2)结合 GItOps、Tekton、SecOps 等自动化流程的落地,应用的生命周期更加标准化(Standardization);
3)随着 OpenTelemetry、CloudEvents 等项目的推进,应用可观测性领域在日志、监控、Tracing、事件等领域进一步标准化和融合,使得多指标、根因分析的数据集更加丰富,从而提高 AIOPS 的 AI 层面的准确率和覆盖率。
新内核、新硬件助力容器优化 OS 的演进。
容器技术经过了多年的发展,从早期的 Docker、rkt、CRI-O 等,到 containerd、Kata Container、gVisor,已经成为 Kubernetes 运行的重要基石。然而无论是 runc 场景的进一步隔离,还是安全容器场景的进一步性能优化,还需要持续的打磨和增强。
随着新内核技术包括 CGroup V2、namespace、virtiofs 等的逐步成熟,可以进一步增强容器运行时的能力。另一方面,一些新硬件包括 NPU、MoC、NUMA 等的引入,也给容器和 K8s 调度带来了更多的优化空间和场景。得益于这些能力的加成,为容器场景量身定制的容器优化 OS 成为可能,并会快速发展。
容器网络和 Mesh 网络将进一步融合。
Service Mesh 经过多年的市场培育,2020 年将会成为 Service Mesh 技术的普及年。而 Service Mesh 的性能优化也会成为重头戏,一些下沉方案也在选择基于 CNI(容器网络接口)和内核技术进一步优化网络转发性能。
而容器网络自身也在逐渐演进,从面向 ip 到面向 Identity,从单容器网络平面到多网络平面,并进一步优化网络转发性能和零可信安全。在 2020 年,我们相信容器网络和 Mesh 网络将进一步融合,在 Network ServiceMesh、NFV等场景进一步集成。
4、边缘计算
随着 5G 和万物互联时代的到来,联网智能终端设备数量将急剧增加,传统云计算中心集中存储、计算的模式已经无法满足终端设备对于时效、容量、算力的需求,将云计算的能力下沉到边缘侧、设备侧,并通过中心进行统一交付、运维、管控,将是云计算的重要发展趋势。
IDC 预计,到 2020 年全球将有超过 500 亿的终端与设备联网,超过 40% 的数据要在网络边缘侧进行分析、处理与存储,这对边缘计算提供了充分的场景和想象空间。
站在新的一个十年,2020 年边缘计算领域将有如下变化:
以 Kubernetes 为基础的云原生技术,经过近几年的高速发展,适用范围、落地场景、技术成熟度等均有了长足发展,其核心价值之一是通过统一的标准实现在任何基础设施上提供和云上一致的功能和体验。将云原生技术和边缘计算相结合,可以快速实现『云-边-端』一体化的应用分发,解决在海量边、端设备上统一完成大规模应用交付、运维、管控的诉求;
在安全方面,云原生技术可以提供容器等更加安全的工作负载运行环境,以及流量控制、网络策略等能力,能够有效提升边缘服务和边缘数据的安全性;
在边缘网络环境下,基于云原生技术的边缘容器能力,能保证弱网、断网的自治性,提供有效的自恢复能力,同时对复杂的网络接入环境有良好的兼容性;
依托云原生领域强大的社区和厂商支持,云原生技术对异构资源的适用性逐步提升,在物联网领域,云原生技术已经能够很好的支持多种 CPU 架构和通信协议,并实现较低的资源占用;
目前已经有不少厂商在进行云原生边缘计算的尝试,并有了部分成功案例,相信在 2020 年随着 5G 的快速铺开,云原生边缘计算的发展将大大提速。
5、容器实例与容器引擎
在 2019 年的最后一个月 AWS 终于发布了 Fargate for EKS 产品,这也宣告了云上 Kubernetes 使用 Serverless 容器实例作为底层运行时资源的产品形态得到了业界更广泛的认可。通过容器实例作为底层运行实体可以让用户专注于构建自身的业务和服务,无需再配置和管理服务器,摆脱基础设施运维的复杂性。同时通过真正的按需付费和实时扩容来降低用户的使用成本。 无论是亚马逊的 Fargate,微软的 ACI 还是阿里云的 ECI,各产品当前在对接 Kubernetes 的具体架构上仍然有分歧,以 Fargate 为代表采用的是透传 Node 信息的方式来提供对 Kubernetes 功能的完整支持;以 ACI/ECI 为代表则采用 virtual kubelet 方式对接 Kubernetes 对容器实例进行管理。
但无论采用何种对接方式,容器实例产品的核心依然需要构建在弹性、成本和 Kubernetes 兼容性上。通过弹性实现用户服务的按需实时扩容,用户无需选择实例和集群容量,不需要为额外的服务器预置而付费;通过实时扩容实现真正的按使用资源付费,降低用户的使用成本;Kubernetes 已经成为容器编排领域的事实标准,对 Kubernetes 功能的兼容性决定着容器实例的适用范围。
站在新的一个十年,相信在 2020 年容器实例产品会在这三个方面继续改进和完善,持续提升弹性能力,降低用户的使用成本,并不断完善与 Kubernetes 的集成。同时也会有更多的云原生应用迁移到 Kubernetes+ 容器实例上,享受云原生的技术红利。
从上述各厂商的同类产品中我们也可以看到此类产品在设计上的共同之处:
一个实例对应一个 Pod
对接 Kubernetes
安全容器作为底层容器引擎
这其中使用安全容器作为底层容器引擎是各家都很重视的底层基础能力。在 2019 年安全容器技术的隔离性越来越被看重,作为一个隔离层,不仅提升云原生平台的安全性,也对可运维性、服务质量和用户数据保护有显著效果。不过,回归初心,用户选择云原生的本质是容器带来的敏捷性,他们可以快速地调度并启动容器,并且可以灵活地使用资源,这方面安全技术尚不能达到传统容器的水平。 不论是 Kata Containers 还是 gVisor,开源安全容器引擎在 2019 年都取得了很多进展,Kata Containers 明确提出了“做面向云原生的虚拟化”作为 2020 年的目标:
在沙箱间共享资源,同时保持沙箱边界仍然清晰。
即时、动态地按需为沙箱提供资源,而不是像分区那样进行固定的资源分配。
主机的用户态工具、VMM、乃至应用的内核联合起来,彼此协同为沙箱中的应用提供服务。
在 2020 年,Kata 代表的虚拟化容器会与传统虚拟化渐行渐远而更加“应用中心”,gVisor 为代表的进程级虚拟化也期待更多为应用的优化。我们相信在 2020 年的时候,我们还不会有一个统一的安全容器技术,但展望 21 世纪 20 年代的头几年,我们期待软硬件的共同发展会让主流的容器引擎都具有更好的隔离性。
6、基础架构演进
基于 Kubernetes 的 Serverless Infras 架构演进一直是各大云厂商和社区关注的焦点。2019 年 12 月 AWS 在拉斯维加斯召开了一年一度 re:Invent 大会上宣布了 EKS on AWS Fargate 产品正式 GA,这个消息在云市场和社区里掀起了不小的波澜。
EKS on Fargate 提供了标准的 Serverless Infra.的用户体验,即用户购买了 EKS 的服务后,不再需要购买额外的 Infra 云资源(如VM,Nitro),就可以使用原生 K8s API 部署自己的应用,并且支持按量计费。
Serverless Infra.架构使得用户无需关注计算、网络、存储等底层基础设施细节,真正让用户回归到面向POD应用资源部署形态上去;同时管控面与数据面的强隔离能力将会是 Serverless Infra.架构的关键,除了对用户屏蔽底层基础设施细节外,Serverless Infra. 需要提供给用户一个安全可信的租户隔离环境
2019 年随着经济体全面上云,底层调度系统全面升级到云原生 Kubernetes + 轻量级容器架构演进,并且大规模部署在神龙裸金属实例上;同时基于 kata-container 的安全容器运行时技术趋于成熟,已经具备大规模铺开的条件。
站在新的一个十年,预计2020 年,将是经济体全面迈向基础设施 Serverless Infra. 的一年,Serverless Infra.架构将会基于神龙+安全容器架构,通过构建软/硬多租户能力,弹性能力和高度的容器自愈能力,为用户提供极致的安全、稳定、隔离性的用户体验。同时底层资源池共享也能有效提升整体资源利用率,并池后资源互通将会有效降低整体机器成本
7、应用开发
展望 2020,我们认为云原生+智能化将成为下一代研发平台最重要的两个特性,它将进一步降低开发者采纳复杂技术的门槛以及通过工具释放生产力。当所有复杂度都卸载到云上以后,我们将回到 10 年前开发单机程序时的高效。
站在新的一个十年, 2020 应用开发领域将发生如下演进:
从 Web-IDE 演进为 Cloud-Native IDE
2019 年是 VS Code 生态继续高歌猛进的一年,得益于其模块化的设计,VS Code 中的几个核心组件Monaco编辑器,插件体系,Language Server Protocol(LSP)等成为了Web-IDE的标准选型。社区也出现了code-server这样基于 VS Code 一行命令拉起 Web-IDE 的方案。
除了 VS Code 之外,Theia 也继续演进,尤其是基于 Theia 的gitpod.io 让人眼前一亮,通过把 gitpod 按钮集成在诸如 GitHub README 页面上,一键实现了从代码到预览的顺滑体验。
另一方面,大厂已有的 Web-IDE 方案也需要回过头来拥抱社区,彻底如 Facebook 完全从自研的Nuclide 转而投向 VS Code,而无论是 Amazon的Cloud9 还是 Google 尚未对外的 Cider,如果要在商业化上更进一步,支持 VS Code 的插件体系想必也是理所当然。
从 Local-IDE 到 Web-IDE 让我想起了当年从 PC 到移动端。虽说时至今日,不少专业工具 PC 端的体验仍然是移动端难以企及的,但移动端的主导地位早已不容置疑。
Web-IDE 具备开箱即用,环境一致可控以及和其它Web服务无缝集成的先天优势。接下来要做的除了继续补齐和 Local-IDE 在端功能的差距外,还可以结合分布式编译构建,集中式代码仓库,海量代码索引分析,云端协同等,提供真正的 Cloud-Native IDE。
工具 -> 平台 -> 标准
GitHub 今年推出了 GitHub Actions,通过它可以在工作流中灵活地集成各种第三方服务。GitLab 也在更早的时候就推出了可定制化的 CI 流水线配置。无论是 GitHub 还是 GitLab,它们都从早期单纯的代码托管工具成长为了一站式 DevOps 平台。
最早以 IntelliJ 工具起家的 JetBrains 不再满足于仅仅打磨 IDE,今年也推出了 Space,力图打造一站式研发团队平台。以项管工具 Jira 起家的 Atlassian,一直是自研收购两架马车并驾齐驱,今年通过收购又在自己研发平台的版图上增加了针对管理者视角的 Jira Align。
后起之秀如 sourcegraph 干脆直接在网站上号称自己是 The new standard developer platform。不管是基于 Dev 工具的右移,抑或是基于 Ops 工具的左移,当年的工具们都或多或少地长成所谓的一站式 DevOps/DevSecOps 平台。
那接下来,在这些平台之上是否能提炼出通用的标准?比如 CI 领域,是否能有一套 CI 流水线定义可以一统CircleCI,GitLab,GitHub Actions 诸如此类?是否也有一套 workflow 标准可以让用户在 AWS Step Functions, Argo, Tekton 之间无缝迁移?
在更高的抽象层面,诸如 Open Appliction Model(OAM) 这样的标准是不是能真正架起从业务架构到基础架构的桥梁。虽然如今的研发平台已然是诸侯割据的局面,但在云原生,标准先行的理念下,我还是会期待有离业务层更接近的云原生标准去串联起整个研发平台。
开发者工具从本地工作到云端协作
当前的开发者工具绝大多数采用的是 lift and shift 的方式从本地平移上云,产品设计针对的还是单人人机交互,移到云端的研发工具还没有很好地利用云端多人实时交互的能力。无论是多人协作(云已经让我们离彼此更近),还是人机协作(云已经让机器变得更强),我期待着出现进一步挖掘云端协作能力的创新点。
更多云原生研发平台涌现
以 Kubernetes、Serverless、Service Mesh、Cloud IDE 为代表的多项云原生技术在过去一年让人印象深刻。我们意外的观察到,以中小互联网公司为代表的技术群体开始快速拥抱这个技术体系,并且通过云原生落地,快速的获得了以往互联网大厂才有的精英软件交付能力,比如复杂的流量治理能力,灰度发布能力,A/B Test 能力,多环境管理能力,基础设施一键拉起,快速扩缩能力等等。
但在企业采纳新技术的同时,也面临着诸多挑战,比如开源软件复杂的搭建过程,黑屏化的交互设计,缺乏研发管理方法,缺乏企业权限管理能力等。因此一大批软件供应商开始基于云原生技术体系开发相关的管理平台,比如 QingCloud,Rancher,阿里云容器服务。作为云上研发协同平台领导者的云效也在积极将 CICD 工具、测试环境管理方法、应用运维理念、DevOps 协同方法论等与云原生技术融合贯通,为企业提供开箱即用的新技术解决方案。
数据和智能的工具时代到来
云原生是一套开放标准的技术体系,核心贡献者就是当今世界的互联网云厂商巨头企业。随着技术的发展和影响力的增强,逐步将企业的私有技术壁垒打破,并且开始采纳云上现成的云原生产品来改造自身的技术体系。技术的收敛带来了统一数据规范的可能,而数据是所有智能化的基石。
我们观察到最近一年 AWS、微软、Facebook、ebay 等厂商都在积极布局智能化工具,从传统的“代码”智能工具逐步扩展到“服务”智能工具。比如最近 AWS 发布的CodeGuru,它是一个用于代码审查自动化和性能优化推荐的机器学习服务。它能找出最影响程序性能的代码行,并让提供修复或改进代码的具体建议。这就是代码大数据和运行时服务大数据结合的智能工具。
2020 如何兑现新技术给业务带去的价值
对于云原生从业者来说,2020 年最大的挑战可能是兑现新技术给业务带去的价值。虽说过去一年对云原生的价值有不同层次、不同视角的解读,但更多还是从技术层面,鲜有各行各业的客户成功案例阐述新技术所带来的直接业务价值。
从市场的角度:仍存在大量的传统行业的企业处于物理机或虚拟机时代,受资产状况的影响他们很难一下子将核心业务搬迁到云原生之上而体会到新技术的巨大价值;另一方面,对于早已进入容器时代的那些企业,他们在软件资产上过去多年持续地投入了大量的资源做建设,从功能层面早已建立起了与云原生等同的软件资产,不会很快从自建转变为云原生。这是市场面对新技术普及之前的正常姿态,行业客户从两端正在被改变,今天大家正逐步对云原生这一概念达成有具象的共识。
站在新的一个十年起点,云原生从业者应当坚定自己对于新技术价值的理解和洞察,沉下心去将云原生的基础能力建设好。同时,需要特别重视以合适的方式和时机去兑现业务价值,通过更多的成功客户故事去加速市场对新技术的接受,让自己的成果更快、更好地被市场认可,创造行业趋势,为云计算的发展做出自己的贡献。
(本文转载自51CTO.com)
热门资讯
快速打开国外网站的方法大汇总
如今,互联网已经成为人们获取信息、进行交流的重要平台之一。然而,由于各国的政治、文化等方面的差异,某些国外网站在中国是无法直接访问的。这对于需要接触国际信息的人来说,可能会带来不便。那么你知道如何访问国外网站,访问国外网站的几种方法?接下来就让我们一起来详细了解下吧! 访问国外网站的几种方法 使用加速器:加速器是一种将数据包压缩和加密传输的技术,可以提高网站访问速度。用户可以选择使用付费或免费的加速器服务商,安装加速器客户端,连接到加速器服务器即可。 修改DNS设置:有时候无法访问国外网站是由于DNS解析的问题,用户可以尝试修改DNS设置,使用公共DNS服务器或者自己搭建DNS服务器,以提高访问速度。 使用CDN:CDN是一种分布式缓存技术,可以将网站内容缓存在离用户最近的服务器上,从而提高网站访问速度。用户可以选择使用CDN服务商,将网站内容缓存在CDN服务器上。 使用镜像站点:镜像站点是指将国外网站的内容复制到国内服务器上,从而实现快速访问的目的。用户可以通过搜索引擎或者其他渠道寻找到镜像站点,并使用镜像站点访问国外网站。 使用VPN:VPN是一种虚拟私人网络技术,可以通过加密通道连接到国外服务器,从而实现访问国外网站的目的。用户可以选择使用付费或免费的VPN服务商,安装VPN客户端,连接到VPN服务器即可。 以上就是关于如何访问国外网站,访问国外网站的几种方法的全部内容,访问国外网站有多种方法,每种方法都有其适用的场景。如果您仅需要偶尔访问国外网站,那么使用VPN、代理服务器、DNS服务等工具都是可行的选择。但如果您需要经常访问国外网站,建议您选择付费的VPN服务,以获得更好的使用体验和更高的安全性。
2023-03-24
错误代码502,网页无法打开?教你如何解决!
在使用互联网的过程中,我们时常会遇到各种错误代码,其中502错误代码是最为常见的一种。502 Bad Gateway错误表示,网关或代理服务无法将请求发送到上游服务器。那么,错误代码502是什么意思?错误代码502怎么解决?接下来小编将为您一一解答。 一、什么是错误代码502 502 Bad Gateway错误是指代理或网关从上一个服务器接收到的响应无效或不完整。通常,这种情况发生在文件太大或处理速度太慢的高流量网站上。例如,当您访问一个具有高流量的网站时,您的请求将被发送到它的代理服务器。如果代理服务器在尝试访问网站时无法从上游服务器获取完整的响应,则会生成502错误代码。 502错误代码通常是由代理服务器、网关或负载均衡器等设备导致的,而不是由您的计算机或网络连接引起的。这意味着您只能为自己的网络连接做些有限的调整,但无法修复网关响应错误。 二、错误代码502的可能原因 1、上游服务器返回的响应无效或不完整 当请求通过代理服务器到达上游服务器时,服务器有时会出现响应故障。这可能是因为服务器正在忙于处理请求,或者因为出现其他问题造成了响应不完整。如果代理服务器无法从上游服务器获取完整的响应,则表现为502错误代码。 2、代理服务器或网关故障 当请求到达代理服务器或网关时,如果设备发生故障或未正确配置,则会导致出现502错误。如果代理服务器或网关未得到正确配置,将无法正常地从上游服务器获取响应。 3、网络连接问题 本地计算机与服务器之间的网络连接是错误代码502的常见原因之一。如果您的互联网连接出现问题或受到网络中断的干扰,则可能导致您的请求无法成功连接到代理服务器或网关,这会导致错误代码502的出现。 三、如何解决错误代码502 1、刷新页面 首先尝试刷新网页。因为502错误代码可能是由临时问题引起的,例如超载的服务器或墙壁上的阻止。因此,刷新页面可能会解决问题。 2、检查网络连接 检查您的网络连接是否正常。您可以尝试与其他网站进行通信,以确定问题是否出现在本地网络连接中。如果您的其他网站可以工作,但一个特定的网站不起作用,那么很可能是这个网站出现了502错误。 3、清除浏览器缓存 清除浏览器缓存还可能有助于解决502错误。浏览器的缓存可能是旧数据的源,这可能会使代理服务器或网关出现错误。 4、暂时使用其他网络连接 尝试切换到其他网络连接,例如在使用Wi-Fi时尝试使用移动数据。通过使用其他网络连接,您可以确定是否存在网络连接问题。 5、联系网站管理员 如果以上方法都尝试过了,但仍然出现502错误代码,并且您确信问题不是出在您的本地网络连接中,则可能需要联系网站管理员寻求帮助。他们可以告诉您更多关于错误代码502的信息,并提供解决方法。 在互联网时代,我们经常会遇到502错误代码。这意味着请求未能正确连接到上游服务器,通常是由代理服务器、网关或网络连接问题引起的。为了解决这个问题,我们可以尝试刷新网页、检查网络连接、清除浏览器缓存、暂时使用其他网络连接或联系网站管理员。希望本文能帮助您了解并解决错误代码502问题。
2023-04-20
一分钟带你了解网页升级访问原因
相信大家肯定在日常浏览网页访问的时候会遇到页面紧急升级就是页面打不开的这种情况,其实就是暂时访问不了该网站的,很多小伙伴们搞不清楚网页升级访问是什么意思,也不知道网页升级访问原因?其实这种情况很常见,很多网站当前的性能以及功能不能满足用户访问需求的时候,网站就会进行升级来满足访问者。那么为什么需要升级页面?具体跟小编一起来详细了解下吧! 网页升级访问是什么意思? 所谓的网页升级访问,就是用户们正在访问的网页正在进行升级,暂时不可能进行访问等操作,一般来说互联网的网页使用过程中会出现各种问题的,网页建设者们会通过升级访问提升网页的流畅度,让大家后续访问过程中更加顺畅。 网页升级访问升级原因 1、 每个网站的站长都是希望把自己的网站做大做强的,当网站的流量高了以后网站的后台服务器可能无法接纳大量的网友访问,这时候就需要升级网站了,升级以接纳更多的网友访问网站。 2、 网站营运一段时间后,由于网络技术的发展以及网络服务器环境的改变,原网页可能出现兼容性、功能与用户体验上的缺陷,为了更长远的发展就需要升级访问页面了。 3、 现在的网络发展很快,网站的设计与服务器安全的水平可能还停留在比较老的水平,页面的升级就能完善这些方面的缺陷。 为什么需要升级页面: 1、 升级页面对于网站优化:网站进行META标记优化,W3C标准优化,搜索引擎优化等合理优化操作,使网站在页面的布局、结构与内容方面都对用户与搜索引擎更加的友好,提升用户体验与搜索引擎对网站的认可。 2、 对于网站的安全与维护:页面安全方面的升级能有效的防止黑客入侵,造成网站破坏,数据损坏,商业机密泄露,客户资料丢失等损失;页面升级对于内容更新调整,网页X信息清理,网络速度提升等网站维护操作;定期检查企业网络和计算机工作状态,降低系统故障率;网站系统遭遇突发严重故障而导致网络系统崩溃后,在最短的时间内进行恢复;在重要的文件资料、数据被误删或遭病毒感染、黑客破坏后,通过技术手段尽力抢救,争取恢复。 以上就是关于页面升级访问的原因以及解决方法全部内容,其实很多网站都是需要升级优化的,为了的就是可以满足各种用户的需求,也是提升网站用户体验的一种方法,当然很多网站想要留住更多用户就需要对网站不断进行页面访问升级,这样才能有利于网站的发展,特别是当服务器无法接纳新用户访问的时候,更需要及时进行页面访问升级,希望本文可以帮助到大家。
2023-03-16
AWS永久免费服务器:你需要知道的一切
互联网技术的发展,促使云计算得以兴起并快速发展。云计算提供了无与伦比的服务和方便性,却也带来了高昂的费用。现在,你可以获得一些AWS永久免费服务器,使你能够在开发和测试新的应用程序时节省不少成本。本文将告诉你AWS永久免费服务器有哪些,以及如何充分利用它的免费资源。 AWS永久免费服务器提供哪些服务? AWS(Amazon Web Services)是亚马逊提供的一种基于云平台的服务。AWS永久免费计划提供高端计算、存储和数据库服务。下面列出了十种免费使用的AWS服务: 1. Amazon Elastic Compute Cloud (EC2):EC2是AWS的核心计算服务。免费计划提供750个小时的EC2实例。 2. Amazon S3:在AWS上创建和管理存储桶,对于不超过5GB的数据存储和处理是免费的。 3. AWS Lambda:以事件驱动的方式在云中运行代码,免费计划提供每月100万个AWS Lambda请求和每月400,000 GB秒的计算。 4. Amazon DynamoDB:AWS的高性能NoSQL数据存储,免费计划提供每月25个WCU和25个RCU。 5. Amazon Glacier:用于非常少访问数据的低成本归档存储服务,在AWS中,小于3GB的数据存储是免费的。 6. Amazon CloudFront:AWS的全球内容分发网络(CDN),免费计划为每个月50GB的数据传输提供免费流量。 7. Amazon Machine Learning:一种基于云的机器学习服务,在免费计划中提供每月10,000个批处理预测。 8. Amazon RDS:AWS的关系型数据库服务,免费计划实例持续使用750小时,每月获得20GB的备份存储和10万条I/O请求数。 9. Amazon SES:简单邮件服务,用于发送和接收电子邮件,AWS SES在免费计划中提供每月62,000封电子邮件发送。 10. Amazon CloudWatch:AWS的监控服务,AWS CloudWatch在免费计划中提供1个月内每个AWS账户$0.10的按需监控。 如何使用AWS永久免费服务器 AWS提供的免费计划通常是给新用户或者想要尝试AWS零成本的用户来使用。以EC2为例,我们将简单介绍该服务的使用。 1. 注册AWS账户:在AWS官网注册一个账户并使用AWS Free Tier即可开始使用免费计划。 2. 创建EC2实例:在控制台中,选择EC2,选择运行模板(AMI),选择实例类型,并分配安全组。分配完毕后,新EC2实例将被创建。 3. 登录EC2实例:使用Amazon EC2 SSH键对或Windows密码来登录EC2实例。使用AWS管理控制台中的实例状态检查每个实例的状态。 4. 配置安全组:安全组包含一个或多个入站规则和出站规则,限制EC2实例的流量。您可以根据需要配置安全组。 5. 使用EC2实例:EC2实例已经处于活跃状态,您可以连接到实例并使用它们。对于Windows实例,可以通过远程桌面连接到实例。 AWS永久免费服务器提供的服务使得开发人员更加容易入门云计算。当然,AWS Free Tier不是所有人都适用的,如果你需要更多的资源和服务,需要考虑更高级别的付费服务,但是对于学习和开发初期,使用永久免费服务是一件很明智的事情。
2023-04-08
全新的页面访问界面升级,让你的网页变得更精彩!
相信大家在访问网站的时候时常会遇到页面访问界面升级,暂时不可能进行访问操作,可能遇到这种情况很多小伙伴们都不知道怎么版,其实互联网网页在正常使用过程中是不会出现这种问题的。那么如果遇到页面访问界面升级怎么办?页面访问界面升级通知怎么设置?接下来就跟小编一起来详细了解下吧! 页面访问界面升级怎么办 所谓的网页升级访问页面,就是用户们正在访问的网页正在进行升级,暂时不可能进行访问等操作,一般来说互联网的网页使用过程中会出现各种问题的,网页建设者们会通过升级访问提升网页的流畅度,让大家后续访问过程中更加顺畅。这样上网就不会太卡了。 页面访问界面升级通知怎么设置出现页面访问升级通知中,可以首先打开这个永久访问页面,然后点击升级按钮,点击升级以后,网络就会自动的升级的,如果手机不会自动升级的话,就点击手动升级,大概等五分钟之后它就会自动的升级了。重复多次,通过以上方式就可以打开需要访问的页面。 页面访问升级出错? 有几个情况会导致这个现象出现: 1.你的网速过慢,网页代码没有完全下载就运行了,导致不完整,当然就错误了。请刷新。 2.网页设计错误,导致部分代码不能执行。请下载最新的遨游浏览器。 3.你的浏览器不兼容导致部分代码不能执行。请下载最新的遨游浏览器。 4.你的IE浏览器缓存出错,请右键点击桌面IE浏览器,选择属性,在常规页面里,点击删除文件这个按钮,选择全部删除,并且点击删除cookies按钮。 5.网站服务器访问量太大,导致服务器超负载,部分代码没有完全下载就提示浏览器完毕,导致错误。 你可以多刷新,或者换一个网速比较好的时候访问(前提是这个网站是个大网站,不会出现问题2) 6.qq空间目前在升级5.0版本,会出现一点小问题..请不用担心,到10月份更新完毕后,所有问题都会解决的。 以上就是遇到页面访问界面升级怎么办的全部内容,其实当网站停止访问的话,不一定及时网站问题,也有可能只是网站正在升级,升级也是为了更好的保证用户访问以及使用体验。当然也是为了安全性能,服务器软件功能会随着版本的更新而提升。当现有的网站功能不能满足访问需求的时候也会及时升级提升体验。
2023-03-02
网页打不开,原因竟然是这些!解决方法你get了吗?
相信很多小伙伴们都知道,现在的生活离不开互联网,几乎每个人都需要上网,但是我们上网时经常遇到打不开网页的情况。那么网页打不开是什么原因?又该如何解决呢?今天就让快快云小编带大家一起来详细了解网页打不开的解决办法吧! 一、网页打不开的原因 网页打不开的原因有很多,下面列举一些可能的情况: 1. 网络连接问题 如果网络连接不稳定或者没有连接到网络,就会导致网页无法加载。如网络断开、网络不稳定等。 2. DNS解析问题 DNS解析是将域名转换为IP地址的过程,如果DNS解析出现问题,就会导致网页无法加载。如DNS服务器故障、DNS缓存问题等。 3. 浏览器问题 浏览器可能存在一些缓存问题、插件问题或者设置问题,导致网页无法加载。如浏览器缓存问题、插件冲突、代理设置等。 4. 网站问题 有些网站可能存在服务器故障、维护或者访问限制等问题,导致网页无法加载。 二、网页打不开的解决方法 针对以上可能的原因,下面介绍一些解决方法: 1. 网络连接问题 检查网络连接是否正常,如无线网络是否连接、有线网络是否插好等。如果网络连接不稳定或者没有连接到网络,可以尝试重新连接或者重启路由器。 2. DNS解析问题 可以清除DNS缓存,让浏览器重新获取DNS信息。在Windows系统下,可在命令提示符中输入“ipconfig /flushdns”命令清除DNS缓存。如果DNS服务器故障,可以更改DNS服务器地址。 3. 浏览器问题 可以尝试清除浏览器缓存、禁用浏览器插件、重置浏览器设置等。如果使用代理服务器,可以检查代理服务器设置是否正确。 4. 网站问题 可以尝试访问其他网站,检查是否存在网络问题。如果其他网站可以正常打开,说明问题可能出在网站本身,可以等待网站恢复正常或者联系网站管理员。 其实网页打不开的原因有很多,常见的包括网络连接问题、DNS解析问题、浏览器问题和网站问题等。针对不同的原因,可以采取不同的解决方法。在平时使用互联网时,我们应该保持网络连接的稳定性,及时清理浏览器缓存,避免使用过多的插件等,以保证网页的正常访问。
2023-05-01