概要
首先这篇文章并非攻击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，还是后来的CloudFoundry、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 ...
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：PaaS，不是银弹
本文网址：http://www.toberp.com/html/consultation/10839717012.html
相关文章
