OpsDev将至

DevOps在09年被提出之后,热度一直不减。最近几年,随着容器化、微服务等概念的兴起,DevOps又开始了大规模实践。但是,随着基础设施的增加,软件设计从Ops角度出发,可以更好的规避基础设施变更带来的风险。

从苹果公司开始

开发者、用户、投资者、分析师和竞争对手都渴望在WWDC上学习到苹果公司维持其领导地位的方式。虽然没有令人兴奋的新产品发布,但是贯穿其中很多话题的核心是:用户体验。

和其他手机厂商的发布会不同,苹果公司专注于客户的体验,而不是其产品的功能和特性。当竞争者在吹捧他们新品拥有的高像素相机和处理器核心数量的时候,苹果公司展示iPhone拍摄的优美、富有灵感的照片时,没有提及设备的任何技术细节。

现在,手机已经改变了我们的生活,日常的衣食住行都可以通过手机app来协助完成。但是苹果公司认为智能设备还能使我们的生活更加高效。不同于目前每个app提供独立的功能,苹果公司希望能够将这些服务整合到一起,对于用户来说,他们只需要使用苹果的服务,而无需打开多个app。要实现这样的愿景,产品或者服务都需要有新的设计范式。任何期望通过接入苹果服务以对外提供个性化用户体验的公司,都应该考虑OpsDev而不是DevOps。

进入OpsDev的世界

我们假设一家电器公司制造的智能冰箱,为用户提供以下体验:

当我坐在车里时,智能冰箱通过手机发出提醒:冰箱存货不足,该去买些食品啦。此时,手机自动生成并推荐了三个采购方案。第一个超市不需要绕路,但是没有我喜欢吃的冰淇淋;第二个超市比第一个远10分钟,但是有所有我喜欢吃的所有食物;第三个超市更远,需要多15分钟的路程,但是它除了有所有需要采购的东西,还提供额外优惠券。我点击了其中一个方案,车载导航开始自动规划行车路线,并显示在汽车多媒体系统中。

在不久的将来,很多公司会致力于提供集成的个性化用户体验,因此不同的数据源和服务必须被整合到一起。智能冰箱通过传感器判断冰箱内的存货,超市服务提供其库存和优惠信息,其他还有交通信息、地理位置信息等等。这些数据源由不同的提供商提供,并且保存在不同的数据中心。这些数据的访问,需要特定的授权方式、API和数据处理流程。个性化服务的设计者,必须明确了解每个服务的规约,因为任务信息不能及时正确的获取,都会影响到用户体验。作为零售商,不会希望用户多花了15分钟时间过来,结果却因为需要购买的商品缺货,或者无法使用优惠券而造成损失。

由此可见,个性化软件服务的交付影响了现有的软件设计模式。DevOps克服了传统瀑布流所不能提供的快速交付能力,通过诸如代码审查、编码规范、持续集成等方式解决软件开发遇到的挑战,并且让开发直接参与到了产品上线流程。而OpsDev考虑的方面却不同。由于个性化服务依赖于底层一系列基础设施,一旦我们知道了每个独立的数据源的依赖关系和可用性,首先需要设计出将各个数据源结合在一起的组件。因此,设计者必须从运维的角度来考虑,对每个服务的依赖程度、故障修复、容错等;同时,由于每个服务相对独立由于每个服务相互独立,个性化软件服务的升级频率受其依赖的服务升级频率影响,这也需要从运维的角度考虑向下(向上)兼容。

什么是OpsDev?

OpsDev是在开发行为开始前,就需要了解应用程序依赖的所有组件,并进行建模。此外,对基础设施稳定性的考量、环境建模、安全审计措施都是第一要务。其次,应用程序组件上线后的部署环境需要被建模。再次,将组件部署到生产环境的流程必须尽可能自动化。通过以上步骤,设计和研发团队可以在开发和测试阶段复制应用程序、环境模型和自动化部署流程。这样设计、研发和测试团队可以清楚的知道应用程序在生产环境的约束和参数。在传统的项目模式下,大量时间浪费在完成验证的应用程序部署到生产环境之后才发现的缺陷。

由于部署自动化在设计之初就被考虑到,应用程序可以随时被部署到开发、测试和生产环境。这种方式不仅可以通过自动化流程加快各个环节的部署速度,还可以减少因为手工部署导致的质量问题。部署程序应该可以聚合多个独立开发的模块。每个模块都可以由独立的开发团队进行开发,并且定制适合自己的持续基础、持续交付流程。发布程序需要预先知道每个模块之间的依赖关系,这样可以快速的聚合每个通过持续集成、持续交付的流程的模块,将它们整合之后部署到集成环境或者生产环境。

通过OpsDev方法,发布方式变得更加灵活。整个部署流程被设计的可以插入验证流程。一个典型的持续交付流程可以是:发布程序首先将待发布应用程序部署到集成环境(UAT测试环境、预发布环境)上,然后触发发布前的自动化、手工验证、性能基线验证等一系列验证措施,整个过程通过之后,部署程序再将应用程序发布到生产环境,发布成功之后记录基线信息和本次变更的状态。

总结

对于物联网或者基于用户体验的移动app厂商来说,传统的软件开发流程无法适应它们的产品,因为它们都会对很多SaaS服务有依赖,且应用程序包含很多组件(物联网设备中的app、移动设备中的app、数据中心的后台服务、网页服务等)。像苹果这样鼓励开发者优先思考用户体验,并提供个性化服务的公司,可能会加速思考方式从DevOps向OpsDev的转变。

本文转自d1net(转载)

时间: 2024-10-04 00:12:50

OpsDev将至的相关文章

OpsDev的时代来了!

本文讲的是OpsDev的时代来了![编者的话]OpsDev指的是在进行开发之前必须理解和模型化应用程序不同组件的依赖. 最近在旧金山举办的WWDC(苹果全球开发者大会)大会上,开发者.终端用户.投资者.分析师以及竞争者全都渴望知道苹果公司(Apple)是如何保持其在手机市场领导地位以及市场份额.大会并没有发布什么令人兴奋的产品,而实际上苹果公司的股票价格有所下降.然而在不同的会议上多次提到了一个共同的主题:用户体验. 苹果公司不断地调整所有的产品和App,从而让一个拥有多款苹果产品的用户从一个产

Docker技术这些应用场景,你知道吗?

场景一:节省项目环境部署时间 1.单项目打包 每次部署项目到测试.生产等环境,都要部署一大堆依赖的软件.工具,而且部署期间出现问题几率很大,不经意就花费了很长时间. Docker主要理念就是环境打包部署,可在任意Docker Engine运行.前期我们只需要将每个项目环境打包到镜像,push到镜像仓库,当有需要部署这个项目时,直接pull镜像启动容器,这个项目就可以访问了!一次构建多次部署,一劳永逸. 2.整套项目打包 公司有一项这样的业务:有一个产品可以整套部署到客户那里,以往都是派一名实施工

福利来喽!个人分享课安排(免费)

感谢广大博友这么多年对我博文的认可!由于工作繁忙.备课等情况,近期发布的博文也少了. 近期也一直想做技术分享课方面的事,所以现在在业余时间与群友分享运维相关的技术,希望把自己多年的运维经验传授给他人,这样才能发挥技术的最大价值,同时也能提高自己的讲师功底,为以后更好的发展铺垫! 每周六日都有技术直播分享课,都是免费的! 腾讯课堂地址:http://opsdev.ke.qq.com(请报名,会及时收到上课提醒) 51CTO学院地址:http://edu.51cto.com/lecturer/787

从临危授命到扭转乾坤,天天拍车运维架构演进及实践

从临危授命到扭转乾坤,天天拍车运维架构演进及实践 李强 2017-04-24 11:52:24 本文根据李强老师在[4月8日DBAplus社群上海数据库技术沙龙]现场演讲内容整理而成.点击文末链接还能下载PPT哦~   讲师介绍  李强 天天拍车运维总监   网名:撒加,先后在AdMaster.饿了么担任运维经理,现任天天拍车运维总监,主要负责天天拍车运维架构的管理.持续优化以及运维团队的建设.培养. 9年以上运维及管理经验.作为国内最早一批思科网络模拟器的推广者.虚拟化先锋论坛的创始人,一直致

探讨下DevOPS

技术界一直就是新名词不断的风格,DevOPS这个词话说出来也挺长时间了,一直以来对这个不算太明白,以为就是指OPS应该不仅仅做OPS的工作,而是应该同时承担起开发自己OPS工作的系统,注意指的是系统,而不是脚本,因为很多的OPS操作是一个流程式的多步骤组成,并且多集群,多系统的交互,这个时候用脚本去实现是会比较难的,而且还要处理诸多的异常等,系统是一个工程性的东西,不仅仅是功能的实现,还要考虑很多异常.稳定性等的问题,但最近的一些思考,让自己对DevOPS有了更多的看法. OPS去承担起开发自己

基于 ThinkJS + React 的通用博客系统 Firekylin

A Simple & Fast Node Blogging Platform Base On ThinkJS 2.0 & ReactJS & ES2015+. 安装 普通用户安装参见 普通安装,如需对 Firekylin 进行开发,可参考 仓库版安装 如何使用 添加和管理文章 添加和管理页面 添加和管理推送 调整网站外观 系统设置 常见问题 如果您在使用过程中遇到问题,请查看 问题解答 中的解答,或者在 GitHub 及 Gitter 上提问. 用户列表 奇舞团博客 / opsde

OpsDev--软件设计从Ops角度出发以规避风险

DevOps在09年被提出之后,热度一直不减.最近几年,随着容器化.微服务等概念的兴起,DevOps又开始了大规模实践.但是,随着基础设施的增加,软件设计从Ops角度出发,可以更好的规避基础设施变更带来的风险. 从苹果公司开始 开发者.用户.投资者.分析师和竞争对手都渴望在WWDC上学习到苹果公司维持其领导地位的方式.虽然没有令人兴奋的新产品发布,但是贯穿其中很多话题的核心是:用户体验. 和其他手机厂商的发布会不同,苹果公司专注于客户的体验,而不是其产品的功能和特性.当竞争者在吹捧他们新品拥有的

高级运维工程师的打怪升级之路

运维工程师在前期是一个很苦逼的工作,在这期间可能干着修电脑.掐网线.搬机器的活,显得没地位!时间也很碎片化,各种零碎的琐事围绕着你,很难体现个人价值,渐渐的对行业很迷茫,觉得没什么发展前途. 这些枯燥无味工作的确会使人匮乏,从技术层面讲这些其实都是基本功,对后期的运维工作会无形中带来一定的帮助,因为我也是这么过来的,能深刻体会到.所以在这个时期一定要保持积极向上的心态,持续的学习.在未来的某一天,相信会回报给你的! 好了,进入正题,根据我多年的运维工作经验,给大家分享下高级运维工程师学习路线.