写点什么

PaaS,不是银弹

  • 2014-10-21
  • 本文字数:3476 字

    阅读完需:约 11 分钟

概要

首先这篇文章并非攻击 PaaS,也不是否定 PaaS 的价值。相反,笔者是想通过本文对 PaaS 有一个更加明确的界定,它是什么,能处理哪些问题,不能解决哪些问题。这样可以对所有正在探索 PaaS 或准备上 PaaS 的企业,能有一个参考。

本文作为笔者过去十年的工作总结,对 PaaS 的实践和思考。 笔者曾在新浪供职九年时间,参与并负责研发内部动态平台 (私有 PaaS) 的建设并在后来领导了整个 SAE(公有 PaaS) 项目的发展,因为有了动态平台的实践经验,也才有了后来 SAE 的诞生,两者有因果联系。

动态平台 (Dynamic Pool)

这个名词是和静态池相对的。因为新浪在很早就为新闻业务构建了一个静态池(目前仍在沿用)。

起源

动态平台的立项在 2004 年,当时 CTO 李嵩波先生负责新浪技术工作,他对这个项目非常支持。童剑当时是这个项目的带头人。

当时的动态平台解决的问题:

  • 资源共用 避免一个应用一堆机器
  • 开发有规范 不能按照每个开发人员的好恶
  • 统一的运维管理 开发人员不管理机器,只负责代码编写和数据库设计

发展

动态平台的发展初期,得益于公司领导的支持和成本管理的加强。这使得新项目申请设备预算变得困难,进而促进了动态平台的快速发展。

发展过程中遇到的主要难题:

  • 资源争抢冲突问题
  • 故障排查难度大
  • 数据库管理面临挑战
  • 开发和运维的协作配合

这些难题在动态平台不同的发展时期,表现程度也不尽相同。在不同时期,都有相应的流程或技术来解决这些问题。

壮大

2009 年,微博技术负责人决定使用动态平台,这使得动态平台的承载规模在随后几年都呈现了井喷式的高速发展。并使得动态平台的适应能力更强。

动态平台快速发展壮大的根本原因在于公司领导支持和严格的成本管理,削减业务部门 IT 预算。这一点可供想搞私有 IaaS 或私有 PaaS 的企业参考,如果你们的预算很多,那么搞私有云,十有八九是要失败的!很明显,业务部门的 IT 预算足够,是没有能动性去使用私有云的。

如果要问全球业务规模最大的 PaaS 是哪一家,那一定是新浪研发的动态平台!

SAE

2008 年 Google GAE 发布。笔者当时正负责动态平台的日常管理。当时的 GAE 我看到后非常惊艳,开发人员可以自助管理自己的应用,写好代码提交后就直接运行。而当时动态平台还是工单时代,开发人员需要提交应用申请,我们在后台进行手工配置后开通。当时就有一股冲动,想要搞一个类似的产品。这在 2009 年成为现实。2009 年 11 月 SAE 如愿上线,并很快发布了 alpha1、alpha2、beta 等多个版本。随着微博的蓬勃发展,2011 年微博开放平台应用的蓬勃发展,有力地带动了 SAE 的飞速发展,当时的微博投票、粉丝汇、微博数据分析、聊天工具等大量第三方的应用快速地在 SAE 上诞生,并且日访问量都可以轻松过千万。

挑战

SAE 的技术架构,很有多动态平台的影子。其运营维护也得益于过去多年成熟的经验。但外部用户和内部用户的差别,对 SAE 的影响很大,特别是后来 IaaS 和云主机在国内快速发展,SAE 发展速度放缓。

  • 外部业务的差异性大,内部业务相对要整齐
  • 外部客户的协作难度更高 外部客户数量庞大,在服务支持上只能侧重于重要的客户。
  • 敏感应用监管难度高
  • DDoS 攻击每日不绝 这是所有做公有云的人都面临的痛苦
  • 恶意应用多 比如恶意的淘宝客

用户使用 SAE 的理由

毫无疑问,SAE 是国内最早的 PaaS 平台,也是目前国内最成熟、用户规模最大的 PaaS 平台。即使是在目前云计算用户争抢越来越激烈的今天,每天仍然有大量用户注册使用 SAE 平台。之所以有用户愿意使用 SAE,核心的原因:

  • 快速获取 app 运行环境 虽然说用户搭建一套 Lamp 或 Tomcat 环境并不复杂,但如果不是很熟练,看文档去做,几个小时还是需要的。
  • 免运维 这个是最关键和核心的。使用 SAE 后,你完全不需要关心运维了,只要负责写代码,这对很多开发人员来说,很有吸引力。
  • 便宜 SAE 的实现方式,决定了它的密度最高,目前没有其他模式可以相比。这也是为什么使用 SAE 会很便宜的原因。这对很多个人开发者而言很有吸引力。

PaaS 解密

定义

维基百科的解释: In this model, the consumer creates the software using tools and/or libraries from the provider. The consumer also controls software deployment and configuration settings. The provider provides the networks, servers, storage, and other services that are required to host the consumer’s application

上面的定义,应该是对多家 PaaS 供应商的产品的一个总结。包括 GAE、Heroku、CloudFoundry、OpenShift、SAE 等。翻译为中文的意思就是:使用者只要提交应用代码,其余所有事由 PaaS 供应商搞定。

这是多么美好的愿景!我想这也是所有开发者的梦想,只关心代码,其他的都不用管,服务还都能运行得很好,99.99% 的可用性,不用担心半夜出故障还得爬起来,不用担心数据库忘记了备份导致数据丢失,不用担心访问量突然倍增,服务抗不住,不用担心网络故障来回切换服务。世界变得好有秩序。

上面描述的愿景,令人十分向往。如果真的有这样的 PaaS 存在,如果 GAE 真的做到了这些,为何云计算的领导者是 AWS,不是 GAE?

我不禁怀疑,这样的万能的包治百病的 PaaS 真的存在吗?不论是作为先行者的 GAE、Heroku、SAE,还是后来的 CloudFoudry、OpenShift,还是现在的基于 Docker 的 Flynn、Deis。

如果让我现在给一个 PaaS 的定义,我会这样写:PaaS是一套开发、运维的规范和流程,可以通过一些辅助工具将规范、流程沉淀下来。但同时业务和技术总是处于不断变化的时代。流程和规范也需要适应变化。没有一套流程规范能让你用一辈子,也没有什么工具可以帮助你一劳永逸地解决所有问题。新浪动态平台已经有不到 10 年的历史,一直都处于不断的演进、变化、调整中,之所以需要不断演进变化,因为技术在变化、业务在变化、组织在变化,不要期待不变,那是不可能也是做不到的。

PaaS 解决什么问题

要谈 PaaS 能够解决哪些问题,取决于 PaaS 提供哪些能力,一般而言,目前的 PaaS 提供:

  • 代码部署能力
  • 代码运行时环境,如 Java、PHP、Ruby 等
  • 各种应用运行所需的服务 典型的是数据库

从上面的功能看,PaaS 主要解决的问题是应用的部署以及执行。

PaaS 不能解决什么

  • PaaS 不能做到全自动、无故障的运维管理
  • PaaS 也不能代替你实施开发和运维流程的梳理,而这个我认为对企业才是最核心的,是一个开发和运维观念的变化,光有工具是不行的。
  • PaaS 需要的运营维护工具,仍然是需要你自己开发或者购买的。PaaS 无法提供全套的管理工具。
  • PaaS 提供的服务仍然是有限的。比如你需要 LBS 服务,或者消息推送服务,可能某个 PaaS 提供,但另外的就没有。没有全能厂商可以提供所有服务,如果他提供了,也一定是个花架子。

看到上面几点,大家是不是觉得 PaaS 没什么用?其实不是,PaaS 只是个工具,你需要首先变革你的理念,或者你不使用 CloudFoundry 这么复杂的系统,但如果你已经将你的开发和运维流程规范做得很到位,那么确实是不需要 PaaS 的,或者你在实施你的流程时,就已经自觉或不自觉地使用了某些工具,你可以非常快速地部署软件、实施监控、有条理地进行备份,那么你确实无需再去引入一个 PaaS 平台了。

PaaS 最终应该是解决方案,适应客户需求的解决方案,而且是需要随着业务需求的变化可以不断演变。而不是客户削足适履去适应 PaaS 这个工具。那样的话,PaaS 之路必定是多灾多难。

NiceScale

离开老东家新浪后,当时我立志做一个灵活性很强的 PaaS,可以支持任意的软件栈,能够帮用户管理维护好他的所有软件栈。这个项目设定的目标比 CloudFoundry 要大,当然我们在 PaaS 运营上的经验足够。但是 Docker 发展如火如荼后,一个通用的 PaaS 意义还有多大?而且要解决 PaaS 的运管方面的需求,其复杂度也很高。但最关键还是,用户真的需要这么复杂的工具吗?

我重读 Unix 经典著作,思考前辈们是如何处理这样复杂的工程的。我们承认,服务运行的管理确实非常复杂,但是如果使用了复杂的工具去管理,那么也只能带来更高的复杂度。解决复杂的问题,只有简单,任何复杂的事情,都是可以分解为简单。

从简单入手,于是有了新的 NiceScale。但 NiceScale 的目标没有变,降低用户使用云计算的复杂度一直是我们的追求,是我们矢志不渝的目标!

这个新的产品,前期只解决一个小问题,帮助你非常容易地管理多个服务器。通过批量在多个机器上执行脚本,并将行为记录下来。功能虽少,但是相信你使用过后,会体验到它的强大与方便。

原来服务器管理也可以不再枯燥,变得有趣、很酷!

初心未变,但我们选择了另外一条路,简单的路。

Keep it simple, stupid …

本文作者: @IT 人 ,曾负责新浪研发私有 PaaS(动态平台) 和公有 PaaS(SAE)。混合云管理平台 NiceScale.com 创始人。

2014-10-21 12:582593

评论

发布
暂无评论
发现更多内容

存储新图谱:DNA存储的边界与天地

脑极体

eBPF 完美搭档:连接云原生网络的 Cilium

火山引擎边缘云

边缘计算 ebpf 云原生网络 cllium

Pulsar 职位广场 | 腾讯、华为云、虾皮、众安保险、StreamNative 等多个热招岗位

Apache Pulsar

开源 架构 云原生 招聘 Apache Pulsar

好用不卡,这些插件和配置让你的 Webstorm 更牛逼!

前端下午茶

前端 工具 webstorm

开源| 直播推拉流2.0升级了什么

anyRTC开发者

开源 音视频 屏幕共享 视频直播 美颜滤镜

[Python]介绍

謓泽

Python 2月月更

Nginx跨域解决配置示例

nginx 跨域

用简单例子带你了解联合索引查询原理及生效规则

华为云开发者联盟

sql 索引 查询 联合索引

学生管理系统的架构设计

凌波微步

「架构实战营」

如何打造一个能自动回复的钉钉机器人

老表

Python 机器人 Linxu 跟老表学云服务器

关于MVVM和MVC,面试看这篇就够了

山河已无恙

mvc 全栈 MVVM 2月月更

『The ShardingSphere Global Echo』Vol.4

SphereEx

数据库 开源 中间件 ShardingSphere SphereEx

学生管理系统的架构文档

卡西毛豆静爸

「架构实战营」

Python 中的数组哪去了?

宇宙之一粟

Python 数组 2月月更

基于CC2530设计的智能风扇

DS小龙哥

2月月更 智能风扇

CSS实现阮大佬博文的阅读进度功能

战场小包

CSS css3 前端 2月月更

初级工程师建议收藏|企业级APIs安全实践指南

领创集团AdvanceGroup

鲲鹏DevKit & BoostKit直播解密:如何“做开发者的开发者”

科技热闻

OpenHarmony移植案例与原理:如何适配服务启动引导部件bootstrap_lite

华为云开发者联盟

OpenHarmony 移植 bootstrap_lite startup 系统服务

FIddler+Proxifer工具对windows PC客户端进行抓包

喀拉峻

黑客 网络安全

UMEM:友盟统计自定义事件多应用一键同步 & 批处理工具

SamgeApp

Docker Vue 友盟助手 友盟自定义事件批处理 友盟统计

凡泰极客成为W3C成员并加入MiniApps工作组,将积极参与小程序快应用技术标准化进程

FinClip

小程序

云原生时代,如何保证容器镜像安全?

极狐GitLab

DevSecOps 镜像安全 极狐GitLab

数据库读写分离如何保证主从一致性?

蜜糖的代码注释

MySQL 数据库 2月月更

面试突击25:sleep和wait有什么区别?

王磊

java面试

大厂偏爱的Agent技术究竟是个啥

捉虫大师

架构 agent

[Python]第一章(建议收藏)

謓泽

Python 2月月更

VIPKID基于Karmada的容器PaaS平台落地实践

华为云原生团队

开源 Kubernetes k8s多集群管理 混合云 分布式云

工作想法小计(2):2/14 - 2/18

非晓为骁

个人成长

盘一盘常见的6种索引失效情况

华为云开发者联盟

MySQL 索引 字符串 查询 索引失效

十年所学,梦想终至,不负时光 | 《云端架构》新书首推发布,来自极度努力的吕校长

博文视点Broadview

PaaS,不是银弹_服务革新_王利俊_InfoQ精选文章