自动化运维软件的模式变化有哪些

为什么说自动化运维软件更适合采用开源的“集市”模式构建?

新旧两代自动化软件的渊源

传统运维自动化软件以Opsware(后来变成HP Opsware)和bladelogic(后来变成了BMC bladelogic)为代表,畅销书《创业维艰》讲的就是Opsware的经历,属于典型的大教堂模式;新一代运维自动化软件则是以开源软件 Puppet,chef,ansible等为代表,属于典型的集市模式。有趣的是,Puppet创始人Luke, 2007年在bladeLogic干过7个月产品经理。可以说这两类自动化软件之间有很深的渊源,甚至在核心技术实现上都有很多雷同之处。

PUPPET的成长经验

朋友中有几位在Opsware工作过,我自己也曾经在BMC工作过,目前又和Puppet深度合作,对这几家基本上都有一点感官认知。这次美国之行,发现2011年刚开始商业化运作的Puppet,在2015年就能做到$100M(1亿美金)的营收,而且内部人还抱怨说销售做的不好,换了COO至少要翻倍才行,实实在在被惊到了。

如果不是理解错了印式英语,那就是时代真的变了。所以,又看了一遍开源软件圣经《大教堂与集市》,忍不住又要胡言乱语了。

先说为什么吃惊,从传统商业角度来对比集市里长大的Puppet和教堂里的Opsware、bladelogic,简直没法进行下去。比如,Puppet的web界面看起来就不像个正经系统,一点吸引力都没有;功能上,连可编排的流程引擎都没有,这在销售阶段怎么讲啊……除了稳定的agent和开放的抽象定义语言,没法比下去啊,哪儿来的这$100M 的营收啊?

怎么可能,于是带着批判的态度,找些别的数字看看,直到看了:

30000+公司在使用、平均每天增加21个

3800+可复用的自动化管理模块

基本上有点平复,可以思考下去了。

首先,puppet的成长经验,印证了《大教堂与集市》里的诸多观点。puppet既满足开源的5个前提,也符合开源的模式发展特征,不一一列举了,都很贴切。更多的感悟是:结合业务领域的特性,自动化管理软件本身是更适合集市模式的。

首先,自动化事关运行环境安全,架构必须异常稳定,尤其是agent和接口层,直插生产系统,一旦有失,无法想象。

怎么能稳定呢?单靠一个天才灵光一闪,啪啪啪敲几行代码,是很难做到的。必须靠足够多的环境和场景验证,才能逐步成熟,这30000+的客户(包括百分之六十以上的财富500强公司),才带来puppetagent的公信力。靠传统模式,一家一家卖进去,再用起来,想不到结果。(Q:现在还在坚持自己开发agent的逻辑是什么?)

更重要的是,自动化管理对象和场景千差万别,几乎不可穷举,每个管理员遇到的环境和问题可能都不一样,如何满足个性化需求。显然,问题是如何根据环境和功能场景,构建一个持续更新的管理实践库(场景用例,配置模板,动作脚本,固化流程,接口实现等等),既继承了前人和大众通用的经验总结,又满足个性化需求。

答案可能只在集市里,汇聚足够多的合格的用户,来“共创、共建、共享、共赢”。

在工具层面降低扩展成本和使用门槛是前提,让更多的人有生产能力,这是puppet抽象定义语言解决的问题。

不断被建立并成熟起来的管理标准

花精力建立生态是关键,汇总下来广大用户积累的通用经验,去粗取精,去伪存真,把控质量,将可靠的模块毫无保留的连源码一块儿发布出去,供用户选择,并再在这基础之上定制满足个性化需求,当个性化需求再次被汇总,又能积累出新的共性经验,循环往复,不断成熟,所谓的管理标准就这样慢慢产生了。

没有太多积累和技术实力的用户,就可以直接开箱即用的向这些标准积累靠拢,述而不作。这是模块仓库forge解决的问题,这3800+的现成管理模块就是时间的积累。反过来,传统模式采取的运维知识库,靠一个组织独立生产和维护,基本上没法保证更新速度、覆盖范围和质量。

另一方面,当生态圈足够大时,成为事实的标准,汇聚的就不止是用户的力量了,周边组织,像设备提供商,系统提供商,软件提供商,资源提供商,服务提供商,都会选择从生产和设计阶段一开始就遵从这个标准,不用自己费心费力去发明私有框架了。可以在社区里看到很多顶级厂商主动适配,我们国内的H记大厂就将在新的设备里内置puppet代理(即将发布)。

最后,还有一点颇为精妙的个人体会。也挺符合古书里的陈述,是关于对用户的筛选,如何取得足够多的“合格用户”。传统商用软件因为其销售使命,会尽量满足用户喜好,尽量不让用户努力,除了核心组件,各种辅助功能都做到产品化,甚至有时候对销售来说,辅助功能比核心功能还重要。达成效果是,用户觉得反正又不用做什么,又能买到一堆功能,不管是不是真要用,买了吧。而puppet这种开源软件,是只关注核心刚需的,周边配套一塌糊涂,我有时候觉得它是故意的,这样选择了puppet的用户,必须要自己研究怎么使用,没有刚需推动,也没人搞这个。所以,也反向淘汰了一批不那么合格的用户。这也符合互联网思维中“少即是多”的理念(臆想的谋略)。

有了这些刚性资本,还谈什么商业模式,企业版解决方案加企业版软件,技术支持,顾问服务,培训认证……满眼都是模式。越说越多,好像没法说完,所以干脆不说了,$100M的事儿,个人基本被说服了。

所以忍不住分享出来,自动化软件的平台特性十分明确,开源的集市模式已经在改变游戏规则。自动化运维的未来已来,与诸君共勉!

作者:杨超

来源:51CTO

时间: 2024-10-09 08:08:51

自动化运维软件的模式变化有哪些的相关文章

博云PaaS:容器应用老司机 自动化运维践行者

近日,向来保持低调的PaaS市场有了新消息--企业级PaaS云平台解决方案提供商BoCloud博云,刚刚宣布完成近亿元人民币的B轮融资.一直以来,由于巨头入局,IaaS/SaaS市场炙手可热,此次博云融资成功,一定程度上提振了PaaS市场信心. 里程碑:容器与混合云管理平台 博云成立于2012年,一直专注于PaaS层云计算市场.5年来,容器技术在PaaS层的应用以及BoCloud混合云管理平台的推出,对博云来说可谓是里程碑式的事件,在业界也引起了较大反响. 2014年之前,博云的主要产品是虚拟化

Linux集群和自动化运维

Linux/Unix技术丛书 Linux集群和自动化运维 余洪春 著 图书在版编目(CIP)数据 Linux集群和自动化运维/余洪春著. -北京:机械工业出版社,2016.8 (Linux/Unix技术丛书) ISBN 978-7-111-54438-8 I. L- II.余- III. Linux操作系统 IV. TP316.89 中国版本图书馆CIP数据核字(2016)第176055号 Linux集群和自动化运维 出版发行:机械工业出版社(北京市西城区百万庄大街22号 邮政编码:100037

一名运维创业者的思考:云计算时代的自动化运维走向

关于题目"云计算时代的自动化运维",用通俗的话讲,就是应用的自动化部署. 第一个关键词是自动化,自动化代表高效率.低成本;第二个关键词是应用部署.即,不涉及讲物理基础设施的运维(如机房基建.能源.消防.安保.布线等等). 假设一个企业要做一个电商网站,典型的运维流程是这样: 1. 购买硬件设备:服务器.交换机.可能还有路由器.负载均衡器.防火墙,不一一穷举了. 2. 在服务器上安装操作系统 3. 在服务器上安装配置基础环境(数据库.Web服务器.搜索引擎等) 4. 在服务器上安装配置应

《Puppet权威指南》——1.2 自动化运维工具箱

1.2 自动化运维工具箱 1.2.1 Cfengine Cfengine是一个借助C语言开发的.功能强大的自动化UNIX管理工具,最早出现于1993年.通过Cfengine可以轻而易举地管理客户端上的设备.Cfengine不仅运行成本低.效率高.功能强大,而且使用范围广.Cfengine可以管理各种环境下的设备,从一台到上千台服务器的集群均适用.如果运维工程师想同时修改2000台服务器的root密码,通过Cfengine可以轻松地在几分钟内实现.Cfengine还包含以下主要的功能: 检查和配置

数据中心新的自动化运维技术

自从数据中心引入了云计算.虚拟化等大咖技术,立刻变了模样,这些技术大幅提升了数据中心的运行效率,给数据中心带来了诸多好处.不过,任何事情都有两面性,我们在享受新技术带来的益处时,也给数据中心运维的管理带来了不便,需要管理对象的数量.规模及复杂度均呈现指数级增长,传统人工干预.保姆式管理监控与故障处理的方式肯定无法满足要求了.比如对于公有云及大型私有云,服务器数量往往可以达到数万到数十万.百万规模,各类系统云服务及租户的业务应用负载数量,也达到了数以百万乃至千万级的程度,这样全靠人工维护不现实,必

自动化运维之 Puppet 实战

 随着IT行业的迅猛发展,传统的运维方式靠大量人力比较吃力,近几年自动化运维管理快速的发展,得到了很多IT运维人员的青睐,一个完整的自动化运维包括系统安装.配置管理.服务监控三个方面.那今天咱们大家一起来学习一下Puppet实际运维中的案例.仅供参考,欢迎大家提更多的意见! 一.应用背景 某公司新到500台服务器,需要安装Linux系统,并部署上线以及后期的管理配置.对于系统安装,这个时候肯定得采用批量安装的,常见批量安装方式有大家熟知的Kickstart和Cobbler,具体配置方法,网上也有

细说自动化运维的前世今生

作者介绍 朱祥磊,山东移动BOSS系统架构师,负责业务支撑系统架构规划和建设.获国家级创新奖1项.通信行业级科技进步奖2项.移动集团级业务服务创新奖3项,申请发明专利13项.   系统规模的不断发展以及应用软件架构的发展,推动着自动化运维的演进.因此在说自动化运维之前,需要先说说应用软件架构的发展简史.回顾过去,应用软件架构先后经过了单块架构.多层架构.服务化架构.分布式.微服务架构等:   单块架构    应用软件发展早期,系统规模一般很小,特点是应用功能集中.代码和数据中心化,表现为一个软件

自动化运维工具ansible的使用详细教程_服务器其它

一.ansible简介 1.ansible ansible是新出现的自动化运维工具,基于Python研发.糅合了众多老牌运维工具的优点实现了批量操作系统配置.批量程序的部署.批量运行命令等功能.仅需在管理工作站上安装ansible程序配置被管控主机的IP信息,被管控的主机无客户端.ansible应用程序存在于epel(第三方社区)源,依赖于很多python组件.主要包括: (1).连接插件connection plugins:负责和被监控端实现通信: (2).host inventory:指定操

架构设计 - 自动化运维之架构设计六要点

运维自动化是我们所渴望获得的,但是我们在一味强调自动化能力时,却忽略了影响自动化落地的一个关键因素.那便是跟运维朝夕相处,让人又爱又恨的业务架构. 因为业务架构是决定运维效率和质量的关键因素之一,所以我想跟大家一起聊一下怎么样的架构设计是对运维友好的.结合这些年在腾讯遇到的业务架构和做运维规划时对业务非功能规范的思考,我们可以把面向运维的架构设计分成六大设计要点. 要点一:架构独立 任何架构的产生都是为了满足特定的业务诉求,如果我们在满足业务要求的同时,能够兼顾运维对架构管理的非功能性要求.那么