目录

    1. 工作场景

    本人所在的小组,20+人的规模,兼具PaaS和SaaS开发的职责。 开发PaaS的人员PaaSer,主要负责PaaS平台的开发和维护,目标是对SaaS开发提供需要的API和文档。 开发SaaS的人员SaaSer,主要负责开发基于上述PaaS平台的Web应用,目标是交付给用户SaaS应用。

    关联他们的是,开发者中心、开发框架、Restful风格的API接口、API GateWay。

    • 开发者中心,提供SaaS应用的创建、部署、管理、日志查询、权限配置、入门指南、开发文档等入口。
    • 开发框架,采用的是Django框架,主要对开发、测试、正式三个运行环境进行适配,针对某些常见的漏洞,增强安全性,还集成了一些常用的装饰器和组件模块。
    • Restful API,这部分是扩展SaaS功能重要部分。企业总线主要是由此接入,提供给SaaS使用,组件提供的功能也算在其中。
    • API Gateway, 基于微服务的架构,服务与服务间的通信,需要网关去控制接入策略。这些API,包括敏感权限的API、非原生系统提供的API、某些需要对外服务的SaaS提供的API。最后,API Gateway还可以记录调用Log,统计调用次数。

    2. 工作方式

    现有的工作方式是,PaaSer负责维护平台的基础功能,同时也负责新功能的开发,比如登录、平台组件等。登录是给每个用户下发票据,有效期内通用于PaaS平台。组件通过API对SaaS提供服务,比如短信、邮件、文件存取等。

    PaaS提供的服务,针对的是SaaS的应用开发人员。清晰的API调用逻辑、简洁易懂的说明文档,是平台云服务商成功的关键。PaaSer会提供大量的文档,指导SaaSer对平台功能的使用。

    实际上PaaS的API功能,常常不能满足SaaS的需求。比如,需要发送验证码。这时,会使用到PaaS提供的发送短信组件的功能,但是,仍需要SaaS做一层封装才能够满足开发需求。比如,需要对业务权限进行管理。这时,会用到PaaS提供的接口,但是依然无法直接满足开发需求。

    久之,SaaS开发人员就会经常拷贝之前自己写过的代码,一部分是对PaaS功能的封装,一部分是业务通用而PaaS平台没提供的功能。这里并不是在指责PaaS平台的开发人员,没有去集成这些功能。我认为,这是缺乏一种功能筛选的机制。这种机制应该能从SaaS功能项中筛选出PaaS平台应该提供的功能。对于整个团队来说,虽然最终交付给用户的是SaaS应用,但是随着开发需求的增长,SaaS开发会被转移出去,沉淀下来的技术和经验应该被固化到PaaS。还有一点就是不能忘记做PaaS的初衷: 降低开发门槛,让SaaS敏捷

    我思考的是,怎样去构建这种筛选机制?

    3. 如何构建有效的正向机制

    正向是哪个向?请看下图。 IaaS、PaaS、SaaS存在一定依赖关系。先有IaaS,然后PaaS,最后SaaS。现在IaaS和SaaS都有比较成功的案例,亚马逊和Salesforce。

    这是一个动态的圈。当IaaS服务商,能提供成熟的主机服务之后,就会考虑向PaaS突破。而这里的突破点,就是PaaS中最常用用到的功能项。比如,亚马逊提供的存储服务。直接从PaaS入手,不提供IaaS的服务商,成功的非常少,包括GAE、SAE、XAE等都没有取得很大成功,平台依耐性高、迁移成本大,Salesforce是个成功的案例。而Salesforce是从SaaS的CRM入手的。SaaS的圈子扩张很容易理解,随着越来越多的需求接入,SaaS会越来越大。

    PaaS是一个很好的方向。PaaS能黏住用户,具备自动化生产SaaS的潜力。而IaaS提供商门槛低,需要足够的用户群和巨大的基础设施投入。而BaaS之类的服务,可靠性得不到保障,也无法监控,会是PaaS的有力补充。

    PaaSer的职能是,输出各种API和文档,而SaaSer的职能是实现具体的功能,交付用户。工作职能的不同,从一定程度隔离了PaaSer和SaaSer。从技术人员成长的角度思考,SaaSer在不断完成PM的KPI,做业务需求的压力下,意识到最终技术会被沉淀到PaaS,会觉得非常的不安。而PaaSer也在绞尽脑汁的思考怎样提供更好、更多的平台功能,但是思路的来源也限于其他云服务平台、内部调研。

    没有数据,就不能算是现代科学,精细化的运营开发更需要数据支撑。所以,我想到的是要去记录功能项和使用频次。团队使用的Django框架中,一个Project,是由若干个App组成,很好的对功能项进行了划分。

    定义一个SaaS功能项:一个能独立运行、可集成的小项目。第一是要能独立运行起来,第二是可集成,具有独立的标识。所以,需要这几方面的工作:

    • 需要一个注册SaaS功能项与发号系统。 - 部署Django App注册系统
    • 统计使用频次,不用每次使用都远程刷新一次,采用公平的策略即可。 - 统计策略
    • 统一的Django App风格。- Django App创建模板
    • 建立Django App的评星和留言系统,便于及时反馈,筛选优质Djang App。- 评价系统。

    4. 机会

    • SaaSer的工作成果可以得到非常快的沉淀。共享的SaaS功能项可以集成更大的SaaS功能项,交付给用户的SaaS应用只是其中的一个集成环节。
    • SaaSer可以分工合作。每个SaaSer实现自己的功能项,然后集成即可。
    • PaaSer有了平台功能目标。根据统计的SaaS功能项,基于平台优化实现,然后与SaaS功能项竞争,可以激励PaaSer。

    5. 风险

    • 有些功能项与场景耦合太紧密,影响功能项的独立性,仍然需要修改后才能使用。比如,发送验证码,又需要记录个人信息表的外键。
    • 一个项目下,可能会有很多的功能项。考验开发者的项目组织能力。
    • 功能项的学习成本VS自己开发。粒度不好把握。