编辑导语:中台在这几年频繁出现在我们的视野里,与他相关的SaaS、微服务也随之出现,这三个产品有什么相同和不同之处?本文来谈谈与中台相关的两个高频概念。
不知道大家有没有注意到,现在我们一谈起中台,经常会伴随着中台会听到这两个词:微服务、SaaS。
但是这两个东西到底有什么区别?这三个产品是否相等呢?
现在几乎是在很多的文章里都有人提出过这样都说法:
那么到底中台与他们有什么关系呢?
今天我为大家带来了我个人的理解: 中台既不等于SaaS也不等于微服务 ,我认为这三者是一个完全不同的东西。
SaaS在我看来其实是一个服务于需求方的一个成熟的软件的产品,通常SaaS会为用户提供了一个运算逻辑服务以及加一个操作终端,事实上就是为外部用户提供了一个标准的解决方案。
但是这里第一个对于中台来说不同的点是:实际上很多时候中台是我们在企业内部的一套管理调度工具,相当于中台是在管理企业内部的一个生产资源,我们可以抽象理解为各个产线上的一些生产机器的一个资源管理,所以它的重心在于管理与调度内部的资源,并不一定会拥有一个可视化终端。
第二个点:中台更多时候是为前台业务线提供半成品服务,而非像SaaS提供完整的解决方案。
但是这不意味着两者没有关系了,其实还是有一定关系的,我认为SaaS其实是中台发展的下一阶段演化产物。
现阶段绝大多数这些做SaaS的企业,通常都是直接根据市场的需求去定义了一款SaaS的软件。
那么事实上我觉得企业有了中台之后,其实每个企业到最后,在他自己内部把他自己的业务模式跑通了之后,并且将核心服务提取归属到了中台后,在经过一段时间的打磨后把中台理顺了,那么再往下发展,其实这个中台就可以抽象出一款SaaS,去服务于整个行业和与自己类似的小企业。
例如在一家电商公司中,在一开始的时候可能这家公司只是专注于某个业务,比如说是专注于化妆品垂直销售的电商平台,一开始他的系统与业务流程都是只服务于化妆品业务销售。
而当企业业务进行发展并多了之后,企业开始进行业务多元化,然后企业内部就有了不同的业务线,比如说开始涉及ToB的业务,此时企业内部就开始发现似乎有很多东西可以复用;那这个时候便开始慢慢去搭建一个中台,然后在中台基础上我去把很多的东西去抽象出来,抽象出来的开始交由中台去和各业务线对接,将这种模式完成跑通。
当然此时中台需要采用标准的:Summary-Details分离设计。
再往后公司开始发现有一些行业的通用问题,而我们内部产出的解决方案,或者抽象出这个东西,不仅仅是我们企业内部能用,其实行业中很多小企业都可以用这个方案,特别是比我们弱的这些产业中的长尾企业,他们都可以用我们这一套抽象出这个东西。
因此我们就完全可以在中台基础上再去进行一个抽象,然后变成一个SaaS对外输出这个能力。于是中台摇身一变就从企业内部的一个工具变为了SaaS,因此未来很有可能每个企业都可以将自己的中台再做一个拓展,变成可以对外输出的一个SaaS化产品。
抽象逻辑由小到大是这样的三个阶段:
刚才我们谈完了SaaS与中台的关系,接下来我们来谈另一个高频词汇——微服务。
事实上微服务它并不是完整的一个产品,也不可以拿来独立使用,它相当于只是一种技术实现手段,例如我们在代码里头听过很多的架构设计模式。
无论设计模式还是设计框架,那么微服务都属于是一种我们实现技术实践的一种方式,和我们的产品设计是不一样。
也就是说中台事实上是一个系统级的设计方案,或者说是一个新的产品方案,而微服务相当于只是我们的一个实现它的方法。
再举个通俗的例子:比如说我把这个大楼的图纸画好了,这就是我们的中台,但是实现上我可以是使用砖混结构去盖楼,也可以使用别的方式搭建,那砖混结构盖楼方法就是微服务,就是我们的一种实现方式。
而中台由于为了将一个个服务抽离出来作为独立的服务,因此我们就必须使用微服务的实现方式。
在了解清楚了这个概念之后,很多事情我们就能看明白了,比如说为什么在双11的时候,我们去一些电商能看到虽然此时购物车卡顿了无法加购,但是商品都还可以去浏览,原因其实就是因为他用微服务去进行的实现;
在这种大并发情况下就充分发挥了微服务最大的优势,虽然说我的架构服务以及后面订单服务挂掉了,但是我的商品中心这些服务都还正常,因为这几者之间没有强耦合,所以我还可以去进行浏览商品,没有任何问题。
我们可以看一个基于微服务架构的设计:目的有效的拆分应用,实现敏捷开发和部署
所以总结一下这三者关系:
对中台及高阶产品技能业务建模感兴趣的朋友,可以看我的新书《中台产品经理宝典》,相信会给你带来不少启发!