目录
一、究竟什么是云原生!?公司当下算云原生了吗?
“云原生,全新运维模式,其不亚于核弹一样的威力,自打诞生那一该即震惊了整个行业的运维从业人员。云原生是什么?如何掌握云原生?云原生后,运维将何去何从?等等问题,尤如重棒当头。这一刻,运维感觉到了危机... 本文,我们将围绕如上主题求同存异,分享我的一些思考。 第一作者:花名「兜」,10年+运维从业经验 公司:脱敏后「诺豆」 ”
细想来,突然发现公司全面拥抱K8S
已经2年有余,最近1、3、5年规划也将云原生、Server Less
、Server Mesh
做了更体系长远规划。与此同时,我们也不断反思如下几个问题:
云原生| Tallon
究竟什么是云原生?
不同企业对于云原生有不同的解释,当前在业界具有广泛影响力的云原生计算基金会(Cloud Native Computing Foundation, CNCF
)认为: 云原生是一类技术的统称,通过云原生技术,我们可以构建出更易于弹性扩展的应用程序。
这些应用可以被运行在不同的环境当中,比如说**私有云、公有云、混合云、还有多云的场景。**云原生技术包括:
通过云原生技术构建出来的应用程序,称之为云原生应用,底层基础架构的耦合比较轻,因此易于迁移,它可以充分地利用云所提供的能力,因此云原生应用的开发、部署、管理相对于传统的应用程序更加高效和便捷。
而阿里ACP(阿里云云原生容器工程师)则给出了更为严格的定义:从云中来,从云中云,即应用的完整生命周期都在云上。
金融体制,早期是混合云架构,K8S后,AIC(All In Cloud),使用的技术栈包括但不限:容器、微服务、DevOps。
**如是看,我们公司也算是云原生用户了。**云原生不仅限如上技术,CNCF
官方给出完整的技术图谱!
CNCF云原生技术全景图
乍一看,云原生技术图谱涉及技术繁杂,数百种之多。其实拉远观察后会发现,图谱做了技术分类,核心技术架构分为:
供应指的是为云原生应用准备标准基础环境所涉及的工具。它包含了基础设施的创建、管理、配置流程的自动化,以及容器镜像的扫描、签名和存储等。供应层通过提供设置和实施策略,在应用程序和平台中构建身份验证和授权,以及处理密钥分发等等的工具,也拓展到了安全领域。
供应层包括:
接下来是运行时层。这个词可能会让你感到迷惑。像很多 IT 术语一样,运行时没有严格的定义,且可以根据语境有不同的用法。狭义上讲,运行时是特定机器上准备运行应用程序的沙盒——也就是保障应用程序正常运行所需的最低配置。广义上讲,运行时是运行一个应用程序所需的所有工具。
在 CNCF 云原生全景图中,运行时保障了容器化应用程序组件的运行和通信, 包括:
一旦按照安全和合规性标准(供应层)自动化基础设施供应,并安装了应用程序运行所需的工具(运行时层),工程师就需要弄清楚如何编排和管理应用程序。编排和管理层将所有容器化服务(应用程序组件)作为一个群组管理。这些容器化服务需要相互识别和通信,并需要进行协调。这一层可为云原生应用提供自动化和弹性能力,使云原生应用天然具有可扩展性。
这一层包含:
现在,我们来到了最顶层。应用定义和开发层,顾名思义,聚集了让工程师构建和运行应用程序的工具。上述所有内容都是关于构建可靠、安全的环境,以及提供全部所需的应用程序依赖。
这一层包括:
这里,我们不做赘述,更详尽内容可参考官方文档
作为运维,潜意识的第一收益是成本!但其实不然,如下问题会导致成本无法估算或成本优势延后:
“总结:成本收益不高 ”
运维提效
目前为止,我们真正最大的收益是SLA和隐性效能提升。云原生和微服务简直就是天作之合,微服务向云原生切换几乎可以完全平滑切换。做过云原生才会知道这个事情有多妙。简单总结收益如下:
Wrhite once, Run everywhere!
整个过程几乎可以实现平滑容器化。部分老业务涉及硬代码改造,会有一定难度。Java
是王者,Python
,c++
,go
等诸多技术栈,在公司主流核心业务中均逐步淡化去除。题图
云原生意义重大,不夸张的讲,是迄今为止运维行业功能最强大的"软件", 更是颠覆性运维产品「其实是系统,这里称之为软件方便大家理解」。
但与此同时,也为运维带来了极为夸张的行业属性提升,将运维的职业属性再次提升一个维度,行业聚集度也更高,从原来的纵向多面手转身为横向平面多面手,真正意义不再需要关注IAAS
,不再需要关注PAAS
的阶段也不会太远了。
所以,云原生最重要的意义不是解决了哪些问题,而是带来了哪些问题其实更重要!
我认为,云原生最少解决了下面这些问题:
带来了下面这些问题:
IAAS
从业人员,可以想像到云原生普及后的运维生存环境;云原生庞大的技术架构体系下,模块近300种,同质功能的产品也种类繁多,选型不再是容易的事情「虽然绝大多数的公司几乎不做技术选型」。关于技术选型,我先抛一个亲身履历的经典错误技术选型案例,你也许会觉得不可思议。
早在2017年,我们计划对新业务容器化,在Mesos
,swarm
和k8s
之间做决择。彼时,k8s
已经凭借生态优势,各大主流容器技术厂商均声明兼容k8s, 但我们在做完技术调研后,最终选择了 Mesos
, 后面的结果大家想像的到,不久前我们将Mesos
技术栈剔除运维技术体系。
原因这里不做深究了,这里想表达的是:即使答案就在眼前,我们也有选错的时候。
技术选型的艺术
数据驱动闭环
浅显分享如下几点:
项目需求类型、时间、规模、性质是影响技术选型的首要条件。时间是决定项目质量的不二因素,临时决定做的产品,初期一定问题爆炸多。
以诺豆公司为例,初期为了快速满足SAAS
厂商入驻,我们为每个厂商提供一整套完整隔离的全套服务,每套成本百万级,明显亏本,但后期改造的产品是逻辑隔离。而出现该问题的原因就是临时接到的需求。
再比如hr系统,oa系统,crm系统,多数公司也会选择购买供应商的成熟产品,不会选择自己做。但这也属于技术选型的范畴。
每家公司的技术栈不一样,像bilibili
、ucloud
是以go语言栈为主流,早期的豆瓣、知乎是以python
为流技术语言栈,后期转为go
。游戏公司的主流技术栈是c,c++
。金融企业的主流技术栈是Java
。
拥有显著特色的团队技术栈,技术选型也会有明显的技术亲和性倾向。
除了文化影响,人的影响巨大,前面造成的错误选型其实就是做技术选型的人。
技术因素是构成技术选型的首要因素:
等都是技术选型要考虑的因素。像k8s
,mesos
,swarm
早期竞争阶段,如果趋势不明显,不如卧倒,少动多看。只有大公司才有试错成本。
综上,云原生进行到什么程度才算结束,反倒变成一个简单的问题。诺豆公司接受容器化,也并非是技术驱动演变到容器化的阶段。前期运维为了接触到云原生这类新技术做过多种尝试,但最终都被老板PASS
.而最后推动公司云原生的,也是CTO级别的变动,自上而下的技术演变。
当下我们正在做的1,3,5年规划,期望把多云、多活、Server Mesh、Server Less提到规划议程中,是否审核通过,最终也要看老板的意愿,需要老板在收益和投入,以及公司战略重心之间做评估!而像拍拍贷,则使用是混合云的方式,使用混合云的要因也并非技术驱动,也并非科技创新需要,而是业务早期遗留的巨额硬件资产和云原生之间不能很好的规划成本。
技术人的思维永远是要最新的。但只有摆脱纯技术人思维,才能走出「云原生后,运维将何去何从的困境」..
原生后期,运维未来何去何从,个人观点如下:
上帝掷骰子吗
先说结论,不一定对,但观点明确!运维行业不会消失,但市场容量会逐年缩水。 现在IAAS
运维的命运,就是未来PAAS
运维的命运。
核因如下:
社交、娱乐、电商、游戏、金融、门户等C端日常所需均已被寡头侵蚀瓜分,普通C端客户所能分配的时间再无多余,这也意味着没有潜力可挖。这是各巨头冲击2B服务市场核因。
公有云IAAS
革命了网络、IDC运维的命,公有云PAAS
日趋完善后,靠纯IDC资源流量性质的公司,再无大树可寄生,巨头大包大揽,没有技术核心只有死路一条。同时,PAAS运维的命运未来大概率是IAAS运维的命运一样!
行业逐步成本导向,新岗位要求将重点考核公有云产品使用熟练程度,侧面引导运维技术方向。屁股决定脑袋,市场岗位属性再次强化为非技术引导,而由成本引导。
云原生逐步成为新型公司技术标准,但公有云包装完底层技术复杂实现,甚至ServerLess
方式。运维成长土壤逐年源流失,未来不会存在中级运维,两极分化更加极端。如前文所述,公有云让普通中低级运维外包成为可能。这意味着,廉价外包类低级廉价劳动力不再是开发特权,运维领域也会逐步出现。
如上文所述,云原生即解放了运维,也解放了老板。高并发、高性能、弹性扩缩容不再是行业难题,级别技术门槛被打破,运维行业将再次回到考验工具熟练度、行业深度、架构能力上。
即,云原生对行业是福利,小到个人是把双刃剑。
同步带来冲击的还有SRE
运维。SRE
运维本质是建立标准规范,并产品化落地。解决企业实际运行遇到的困、难、乱点,推进企业高效良性运转。云原生自带的行业解决方案能解决绝大多数规范性问题,公有云配套产品只需简单配置即可完成运维原来可能量变到质变才能完成的工作。
云原生后,服务治理功能还有待完善加强。SRE领域也在被侵蚀。
如游戏、金融、证券、银行等行业物质很强的工种,运维还有较长时间腾挪,但也是最后的死水。
游戏分模块,也逐步支持容器化,甚至全模块支持容器化。
金融、证券、银行等金融核心业务、除部分敏感、核心业务需自建机房,未来最多也只是混合云架构,公有云占大头。
云原生作为有史来最具颠覆性的运维“工具”,即将运维行业向前推进了一大步,又对小人物的从业人员提出了更严苛的从业标准。依旧印证了:历史一直在重演,只有拥抱变化,才能不惧变化的理念,这点在互联网行业就像浓缩的历史,被反复印证!
我协助维护的公众号「奔流Flows」,也会不定期分享自己对行业远景的看法,技术分享。欢迎大家关注