思考-支持更激进的产品迭代和多产品矩阵探索

悄风阵雨
113 阅读7分钟

现状思考

  • 行业现状：

    • 随着需求迭代的进行，大型软件复杂度不断提升
    • 历史包袱越来越重，出现烟囱现象 or 数据孤岛（手Q，京东，宝洁）

  • 头条现状

    • 不属于传统软件，处于平台软件初期
    • 目前大部分架构设计/下沉复用，基于归纳法，而非演绎法

架构演变

  • 软件从面向用户，面向开发者/中小企业，面向产业
  • 传统软件(卖产品)-手Q，平台软件(卖服务)-微信，制定标准(卖标准)-苹果手机

传统软件：无法根据实时的用户数据做出反应、无法根据市场动态的复杂性快速做出决策并执行，完全处于刻舟求剑的状态中

以古代印刷术的更新迭代作为参照，我们看下现代软件架构的演变进程：

Iaas:

2010年-2013年，号称第一次技术革命，标志是laaS

IaaS不是一般人能干的活，但他们的存在又会影响到很多人，因为这是基础设施（Infrastructure）。

距今天刚好10年前的2011年，当时的李彦宏和马化腾被问到对于“云计算”的看法时，李彦宏表示，“云计算这个东西不客气一点讲它是新瓶装旧酒，没有新东西”。马化腾认为，“云计算，确实有想象空间，但还太早了”。马云是个异类，他不认同，他觉得云计算最后会是一种分享，数据将会成为最大的生产资料，会成为像水、像电、像石油一样的公共资源。所以阿里云当时对于云计算是每年10个亿地投入，最终打造了中国唯一（目前）自研的云操作系统——飞天。能扛住了双11的瞬时流量，也能为12306提供技术支持。因为阿里云对社会的巨大贡献，项目的牵头人王坚当选了中国工程院院士。如今阿里云的市场份额为亚太第一、全球第三，排在前面的分别是亚马逊和微软。

IaaS的本意也是Infrastructure-as-a-service，基础设置服务。因此，没有自己种树的印刷厂（技术厂商）就会去木材商（如阿里云、Google、亚马逊等IaaS大厂）买一块木板（IaaS）进行雕刻、印刷。

Saas

2014年-2018年，第二次技术革命，标志是****SaaS

木板有了，印刷厂每印一本书，就会用木板先雕刻一个版，这些雕刻出来的版（雕版）就是SaaS。书商（企业）需要买书，就会直接找到印刷厂直接订购雕版并印刷，而后把书卖给消费者。 如你所见，基于雕版是提前刻好的——SaaS的优缺点都来源于此，优点是刻出来的每一本书都一样，够稳定，还能重复利用；但缺点是一旦雕版上刻错字，这块板就废了，完全无法挽救。 案例: A客户根据业务需要跟SaaS技术厂商提出需求，在几轮沟通和提价切磋之后，技术团队在需求提出后的一个月，终于开始写代码。吭哧吭哧写了半个月之后，A客户突然说：我们的业务现在有了改动，能不能删掉某一块功能？程序员们蚌住了，然后说：不行。不是不想改，是没法改！ 码字尚且要照顾前后语气通顺与否，一字码即一功能的代码又怎么能轻易删改。实在要删掉也可以，麻烦给钱，对的，删码也要给钱，因为那是另外的工作量，而非轻按“Backspace”——雕版上哪怕刻错一个笔画，整个板就废了.

SaaS的缺点：太标准，开发慢， 仍然有多烟囱现象

Paas/中台

2018年-2021年，第三次技术革命，标志是****中台

正常的流程是买木板、雕刻、印刷、出版、卖书；但现在是：印刷、出版、卖书。书商，也即企业本身并不具备雕刻的能力，假设哪一天市场不需要这本书了，他只能再去买一块新的雕版印新书。 这也是造成今天烟囱林立的原因之一 —— 大部分人都忽略了IaaS与SaaS之间的过程，导致这部分的能力被SaaS“阉割”了。

中间那份被阉割的能力，也即雕版，现实中的自搭建技术的能力，就是PaaS-活字印刷( 中台 )

有关中台的基本概念已经有了很多介绍，大部分企业对于中台建设已经有了初步想法和规划，无论是解决数据孤岛问题、还是提高快速创新能力，中台都是可选的解决方案，Pass优点：

  • 低代码
  • 能快速定制任何需求，做到快速适应业务方向；
  • 底层天然是打通的

也有一些其他叫法 : APaaS（Application PaaS）或是 BPaaS（Business PaaS）

目标

  • 助力头条成为真正平台化的产品

  • 助力视频业务团队真正中台化

    • 自身稳定，品质可靠
    • 组件or策略 易复用，易扩展
    • 运营成本低

看到的核心矛盾

  • 中台化难度大

  • 中台化BP角色不固定

    • 无固定BP角色

    • 出问题后优先级对不齐

      • 不好意思，确实还有别的要忙，头条主app问题优先，你这个问题我后面再看

应对思路

  • 明显具备共性的模块尽早抽象，不确定共性的模块事后抽象

  • 架构设计时既信任也不信任

    • 不信任什么：对请求，输入，输出不信任，保持自身稳定，品质可靠
    • 信任什么： 不重复造轮子，信息透明
  • 提升中台协同效率：与自身协同、与新业务协同、与视频架构协同
  • 不拒绝打杂：不要眼高手低，脚踏实地解决痛点问题

视频中台不做的3件事

  • 不要理想化，过分强调中台，不过多考虑未来不一定发生的事情

    • 案例1：【订单中心 中台 化】
    • 案例2：【账号中心 中台 化】

  • 不要完全基于抽象复用的视角构建中台

    • 善于多角度：复用，合理性，业务统一管理等综合视角来构建中台

  • 不要人力 "外包" 中台

    • 中台的建设一定要有合理的原因，如果只是为了中台而中台，会让系统的架构混乱，工作效率反而降低。而且很容易产生“人力外包中台”现象，即下游业务团队把中台团队当做乙方来合作，“反正你们要帮我们打理好这些模块，不管是否合理，需求提交给你就必须得高优支持，否则就是不支持业务一线”，这样会让中台产品和中台团队失去该有的气质，形成团队间的敌意和隔阂

参考文档

avatar
文章
阅读
粉丝