×
标签: 暂无标签




“云原生”架构下,IT运维还存在吗?


[color=rgba(0, 0, 0, 0.9)]最近多次被问到:“云原生的逐步完善、DevOps的深度应用,那么NoOps(零运维)的时代是不是真的会来临,作为运维人我们该如何应对这种趋势呢?”。云原生的架构持续浸入到数字化转型应用中后,IT运维是不是真的就没有了呢?这个问题仁者见仁,智者见智。但我个人认为,如果我们能先充分理解“云原生”后,那么再思考“云原生下,是不是真的就是不需要运维”,会更加准确。
[color=rgba(0, 0, 0, 0.9)]
什么是云原生? 云原生(CloudNative)是一个组合词,Cloud+Native。Cloud表示应用程序位于云中,而不是传统的数据中心;Native表示应用程序从设计之初即考虑到云的环境,原生为云而设计,在云上以最佳姿势运行,充分利用和发挥云平台的弹性+分布式优势。云原生的关键特点?Pivotal公司的Matt Stine于2013年首次提出云原生,其定义的云原生4个要点是:微服务+容器+持续交付+DevOps。
微服务:几乎每个云原生的定义都包含微服务,跟微服务相对的是单体应用,微服务有理论基础,那就是康威定律,指导服务怎么切分,是组织架构决定产品形态。微服务架构的好处就是按Function切了之后,服务解耦,内聚更强,变更更易;另一个划分服务的技巧据说是依据DDD来搞。

容器化:Docker是应用最为广泛的容器引擎,容器化为微服务提供实施保障,起到应用隔离作用,K8S是容器编排系统,用于容器管理,容器间的负载均衡,Docker和K8S都采用Go编写。

DevOps:这是个组合词,Dev+Ops,就是开发和运维合体,不像开发和产品,经常兵刃相见,实际上DevOps应该还包括测试,DevOps是一个敏捷思维,是一个沟通文化,也是组织形式,为云原生提供持续交付能力。

持续交付:持续交付是不误时开发,不停机更新,小步快跑,反传统瀑布式开发模型,这要求开发版本和稳定版本并存,其实需要很多流程和工具支撑。
微信图片_20231020132853.png

实际落地中,符合云原生架构的应用程序的特点是:采用开源堆栈(K8S+Docker)进行容器化,基于微服务架构提高灵活性和可维护性,借助敏捷方法、DevOps支持持续迭代和运维自动化,利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
为什么会出现云原生,解决了什么痛点?我们先从云计算说起。在云计算普及之前,一个应用想要发布,就需要企业自己先买几台服务器,并放入IDC机房中。接下来就是装Linux系统,部署应用。我们就假定用Java写了Web应用,怎么部署上去呢?先配置Tomcat服务器,在把编译好的war包上传到服务器,有用FTP的,安全意识高一点的会选SCP,然后配置Nginx、MySQL这些服务,最后一通调试,把应用跑起来,就算齐活。这种物理机配合自搭网络环境、自搭Linux、自配环境的方式,有很多缺点,但最主要的痛点有这么几个:
  • 扩容和维护难。因为是物理机,需要先采购后安装到机房,遇到业务量猛增是来不及扩容的,用术语讲就是计算资源缺乏弹性;
  • 安全性太差。熟悉Linux的运维工程师本来就少,精通SELinux的更是凤毛麟角,而且,系统安全性仅仅是一个方面,应用部署的权限、流程造成的安全漏洞更大;
  • 需求不能快速响应。开发、测试和运维脱节,缺少自动化测试和部署,应用系统的上线部署是大变更,涉及非常多的准备和多轮的测试,直接导致无法快速迭代业务。

解决方案是上云。上云不能解决所有痛点,但部分解决了前两个痛点:
  • 比起物理机,虚拟机的创建、维护、销毁比物理机简单了太多,且随时可以扩容,很大程度上解决了“弹性计算”的问题,至于弹性程度有多大,还得看应用的架构和设计水平;
  • 和绝大多数中小企业相比,云服务商在网络和服务器安全方面要强若干个数量级。只要选择合适的官方镜像,配合防火墙规则,系统级别的安全问题大大减少,可以将重点放到应用本身的安全性上。

那么第三个痛点“不能快速响应业务需求”云计算就不能很好的解决了,要实现持续交付、快速迭代,是需要应用架构、软件开发的方法都需要改变才能实现,这时云原生的“微服务、容器”等特性的优势就体现出来。

使用云原生后对应用系统开发的带来哪些变化?1.本地部署的传统应用往往采用c/c++、企业级java编写,而云原生应用则需要用以网络为中心的go、node.js等新兴语言编写,但并不是说Java不能用,只是说GO语言对云原生适配更好。2.本地部署的传统应用可能需要停机更新,而云原生应用应该始终是最新的,需要支持频繁变更,持续交付,蓝绿部署。3.本地部署的传统应用无法动态扩展,往往需要冗余资源以抵抗流量高峰,而云原生应用利用云的弹性自动伸缩,通过共享降本增效。4.本地部署的传统应用对网络资源,比如ip、端口等有依赖,甚至是硬编码,而云原生应用对网络和存储都没有这种限制。5.本地部署的传统应用通常人肉部署手工运维,而云原生应用这一切都是自动化的。6.本地部署的传统应用通常依赖系统环境,而云原生应用不会硬连接到任何系统环境,而是依赖抽象的基础架构,从而获得良好移植性。7.本地部署的传统应用有些是单体(巨石)应用,或者强依赖,而基于微服务架构的云原生应用,纵向划分服务,模块化更合理。

所以,云原生应用后貌似所有现在面临的运维棘手问题都不存在了?目前云原生使用情况怎么样? 之前看过一个针对国内中大规模企业调查报告显示“60%以上的用户已在生产环境中应用容器技术,1000节点规模的容器集群能够满足近8成用户的生产需求”。作为容器最主要的应用场景,8成用户已经使用或计划使用微服务。同时,Serverless技术显著升温,近3成用户已在生产环境中应用,但用户在Serverless化部署的过程中仍面临诸多挑战。”Gartner更是预测“到2025年,95%数字化运维将通过云原生平台进行支撑”。  这个数据和我目前接触到的客户的应用情况差不多,无论是ToB还是ToC,无论是标准化产品还是定制化产品,都在大踏步的进行云原生的改进,最重要的理由就是:“能快速迭代,持续交付”。

使用云原生后对IT运维带来哪些变化?云原生运维要解决几个关键问题:1.标准化:标准化可以促进开发团队与运维团队的沟通和协同,标准化也有助于生态分工,推动更多自动化工具的出现。2.自动化:只有自动化运维,才能支撑互联网规模的挑战,才能持续支撑业务的快速迭代与稳定性。3.数智化:数据化、AI 增强的自动化运维成为未来发展的必然趋势

上述的几个问题对于运维人的变化是:
  • 工作思路的变化
原来以标准化的工作过程来协同人高效完成工作,转变为通过标准化的过程来实现自动化;
  • 传统以故障为核心的维护,转变为以快速交付为核心;
传统以知识积累来提升团队能力,转变为通过开发自动化处理模型来训练AI来完成运维能力提升;
  • 技术栈的更新,运维开发工程师将是未来的主要运维团队
微服务、多云环境、IaaS下,无论是应用系统还是基础设施都被切分为足够小的业务服务,以实现持续交付和迭代,这样传统的人工运维的方式已经无法管理如此多的对象,运维工程师必须要能够在原有维护对象专有技能的基础上,无论是软件运维、服务器运维、操作系统运维还是网络运维,都必须要执行自动化运维,而业务的差别也就无法使得运维工具标准化。因此,运维工程师必须要有一定的开发能力。而对于流程也是,传统的业务都是由人工来协同完成的,而云原下,各个板块的工作都是对应自动化工具完成。这样运维流程经理在具有原有流程能力的基础上,必须要有能力去编排不同的自动化组件以实现从资源准备、软件部署、自动化业务验证(测试)的一系列工作。也许,运维的工作不会消失,但云原生下运维工程师不具备编程、开发能力将寸步难行。
  • 运维工具生态的重新洗牌,低代码开发平台将成为主流
传统的运维工具,无论是监控还是运维流程,都是通过标准化的产品以保障业务的稳定,确保快速响应为核心,云原生背景下,故障、性能都会被自愈处理,而业务的差异也就使得自愈处理的过程不能统一,必须要通过二次开发来完成,那么运维工具的二次开发能力将决定工具是否能落地。

写在最后
数字化转时代已经来临,扫码加入我们吧,全新思维方式学习ITIL4,数字化转型时代必须掌握的新技能。








上一篇:画了多年的流程图,你真的画规范了吗?
下一篇:数字化转型,是数字化+转型,还是?
slbenben

写了 1673 篇文章,拥有财富 10325,被 10 人关注

B Color Link Quote Code Smilies

成为第一个吐槽的人

手机版|小黑屋|最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部