点赞
评论
收藏
分享
举报
为什么每个公司都需要平台运营(Platform Ops)
发表于2021-09-02 14:10

浏览 629

如今,“平台运营(Platform Ops)”的势头似乎越来越盛。你可能会问,“我们已经有了 DevOps、NetOps、SecOps、DevSecOps,甚至是 FinOps!何苦再要一种‘Ops’?”实际上,与其他“运营”不同的是,平台运营更多地是充当粘合剂的角色,将所有不同的部门和用例整合在一起,以满足科技企业构建现代分布式和云原生应用的需求。换句话说,我们认为平台运营相当重要。


什么是平台运营?

所谓“平台”不同的工程团队使用的一套技术,他们用这个平台来实现各种依赖于算力的功能。Web 应用团队依赖 Web 服务器、中间件(如 Node.js®)、前端和负载均衡器。营销技术团队依赖 Adobe Creative Cloud 和 Salesforce 等 SaaS 产品。网络运营团队则依赖 Kubernetes、应用交付控制器和虚拟网络解决方案(Kubernetes 也提供了许多此类功能)。在云计算和云原生应用的时代,所有团队都依赖某个既能提供核心计算、存储和网络功能,又能提供应用构建和交付工具的平台。

平台运营团队的职责是打造、维护、连接和保护为 DevOps 团队提供完成工作所需一切的平台。随着越来越多的科技公司迁移到云端,平台运营也与核心功能的实施(例如全公司的网络和安全性)关联日益紧密。


为什么需要平台运营?

在过去的十年里,应用环境发生了翻天覆地的变化。单体应用经过一系列重构,演变成由 API 连接的多个服务。分布式应用可能不仅包括多服务,而且还横跨在多个云环境中。开发人员把控着技术堆栈,可以自由选择他们认为合适的工具。一些企业的 IT 首席技术官和副总裁发现,他们的数十个 DevOps 团队使用成百上千种不同的工具和解决方案来处理计算、数据、消息队列、可观测性、安全性和网络。这一现象在应用层(第 7 层)表现尤为突出。例如,一家大型移动应用公司曾表示,由于应用团队使用了多种互不兼容或者无法统一到单一平台的不同工具和解决方案,他们需要运行多个 Kubernetes 集群和不同类型的服务网格。


过多选择的副作用

面对让企业不堪重负的技术工具激增问题,平台运营解决方案无疑带来了希望。平台运营团队需要企业内所有 IT 和应用用户的配合,从而了解他们的期望和需求,并将他们的请求缩减到少数几个选择。平台运营的核心是在选择和混乱之间取得平衡,让企业在保持强大的安全性、治理和可靠性的同时“向左迁移”。

可以肯定的是,一些公司仍然允许应用或 DevOps 团队自主选择工具,这些工具不一定必须在平台运营团队的支持范围内。Netflix 以“自选、自管”的模式而闻名,除了内部打造的技术工具外,团队还可以选择其他解决方案。但前提是这些团队要自己负责自己的工具,而不能寄望于平台运营、IT 或其他 DevOps 团队的帮助。

需要注意的是,平台运营与 IT 整合不同。IT 整合往往是自上而下的,很多工作都集中在上层机构,平台运营则是自下而上的,更多的是以咨询性质为主。平台运营团队必须成为选定平台的布道者和老师,确保使用该平台的所有用户都了解为什么要做出这样的选择,以及如何最大程度地从平台中获益

平台运营团队成员通常来自应用开发和 DevOps,因此他们比任何人都更了解这些团队的需求和期望。此外,无论是为了内部工具的开发还是为了进行配置和管理,平台运营团队通常还是会写代码最终他们使用的平台就是他们构建的平台。这与 IT 团队的情况大不相同——他们只负责确定要使用的解决方案,不在自己的工作过程中自用。

对于那些努力想要适应令人迷茫的新型云环境、云原生应用、分布式基础架构和“左移”的应用开发和安全性的公司来说,平台运营团队提供了一个信息和评估的重要来源。它可以帮助首席技术官乃至首席财务官、采购和审计团队了解需求和成本。从这个角度来说,平台运营就像是一个中立的经纪人,为信息共享和系统化知识的获取提供了重要渠道。


结论:平台运营IT 战略成败的影响越来越大

事实上,选择和控制之间的关系一直很紧张。但今天,企业必须要为开发人员创造发挥才能的沃土。过度的限制会让开发人员产生挫败感,迫使他们另谋高就;而过多的选择会造成“各自为政”的分布式技术环境,一堆工具互不兼容、配置和结构混杂无序。久而久之,这种环境将变得既难以管理、又缺乏安全。平台运营团队对这些问题的权衡决定了企业能否成功驾驭数字化转型、为以云原生和广泛分布式为特点的未来做好准备,并在“左移”和传统之间取得完美平衡。



已修改于2023-03-08 02:21
本作品系原创
创作不易,留下一份鼓励
NGINX官方账号

暂无个人介绍

关注



写下您的评论
发表评论
全部评论(0)

按点赞数排序

按时间排序

关于作者
NGINX官方账号
这家伙很懒还未留下介绍~
228
文章
21
问答
198
粉丝
相关文章
继续软件架构系列之行业应用篇,相信很多人用NGINX,也很多人用NGINX架构不同的能力,接下来,通过一张行业应用图,分析一下NGINX分层的含义及架构分层的必要性,上图先:   这张图咋一看会发现,好多NGINX呀,没错!这是某行业顶级的业务系统架构图,也是业内市场占有率第一的原版授权,从最外围的用户交互(好比我们使用手机app应用界面)-第1层,到数据中心内网的接入(好比app背后的数据中心或云上部署)-第2层,再到应用负载的第3层(好比应用部署前面的SLB或接口机),进而到前端应用的能力封装和开放-第4层,再到能力中心调度池-第5层,最后到数据存储的第6层。每一层的角色扮演都很明确和清晰,以第2层的NGINX来说,核心功能就是扮演大颗粒度的流量调度和高可靠,因此和传统的LB功能非常接近;以第3层的NGINX来说,核心功能就是扮演业务细颗粒度的流量精分和能力画像,因此和高性能的七层LB高级功能非常接近。因此,每层之间通过分层和解耦的方式,让能力封装更加专注,让精分模型更加贴近应用,某种层面上也把NGINX不同纬度的强项拆解到不同的应用场景中进行发
点赞 2
浏览 1.7k
感谢IgorSysoev,NGINX的作者。RomanArutyunyan,nginx-rtmp-module的作者。贡献者,详情见AUTHORS。功能nginx-rtmp-module提供的所有功能。nginx-http-flv-module的其他功能与nginx-rtmp-module的对比:功能nginx-http-flv-modulenginx-rtmp-module备注HTTP-FLV(播放)√x支持HTTPS-FLV和chunked回复GOP缓存√x虚拟主机√x省略listen配置√见备注配置中必须有一个listen纯音频支持√见备注wait_video或wait_key开启后无法工作reuseport支持√x定时打印访问记录√xJSON风格的stat√xstat中包含录制详情√x兼容性NGINX的版本应该大于或者等于1.2.6,与其他版本的兼容性未知。支持的系统Linux(推荐)/FreeBSD/MacOS/Windows(受限)。支持的播放器VLC (RTMP&HTTP-FLV)/OBS (RTMP&HTTP-FLV)/JWPlaye
点赞 2
浏览 5.8k
upstream-fair模块upstream-fair是比内建的负载均衡更加智能的负载均衡模块,一般google关键词nginx-upstream-fair可以找到相关资源和文章,这里不详述了。它采
点赞 0
浏览 389