中台反思:技术中台的未来
![中台反思:技术中台的未来](https://static001.geekbang.org/infoq/7a/7adadecda53770fc6f683d1799d2df88.png)
中台系列文章见:http://www.idealworld.group/archive/?tag=%E4%BC%81%E4%B8%9A%E4%B8%AD%E5%8F%B0
中台自被提出以来不断的有反对的声音,比如传播较广的这两篇文章 《阿里彻底拆中台了!》[https://mp.weixin.qq.com/s/DJn-CLLfG_5nMCKKXSclIg] , 《ERP 已死,“中台”已凉,“低代码”称王!》[https://mp.weixin.qq.com/s/NlFRrylozbqyLk1xCORe-w]
那么中台真的是明日黄花了吗?其实不尽然。从发展的眼光看中台也在逐步地自我完善。笔者之前的文章 《中台反思:技术中台设计架构》[http://www.idealworld.group/2021/04/23/reflections-of-middle-platform-technical-architecture/] 提到了中台的演进,也提到了低代码置于中台的作用。本文我们就此进一步展开讨论。
首先我们要明白为什么很多人说中台不适合“颠覆式创新”,那是因为当前的中台多以“服务”的形式露出,完成一个业务能力需要有前台应用参与,也就是中台没有端到端的业务实现能力。所以中台的演进一定是将“去前台”视为重要的能力,通过中台即可构建完整的业务能力。
![](https://static001.geekbang.org/infoq/c0/c00759fbb6667376fd98c5871347bfdd.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
这时我们一定会想到低代码,低代码是什么?
![](https://static001.geekbang.org/infoq/d8/d890579b2be0bba58f473a25466f1659.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
如上图所示,低代码想解决就是简化业务实现的流程进而提升效率。市场上也有很多的低代码产品(如下图,《Gartner Magic Quadrant for Enterprise Low-Code Application Platforms》节选):
![](https://static001.geekbang.org/infoq/0a/0a10335e6442bbbf1b32a27a71fcd98f.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
我们可以大概将这些产品分成三大类:
全能型:如 OutSystems,这些产品可以用于构建复杂的系统,但上手很难
![](https://static001.geekbang.org/infoq/ec/ec92f731bc687e66668981a15bd86f1e.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
简洁型:如轻流,这些产品上手简单,体验友好,产品及业务人员都可以轻松使用,但是场景比较受限,只能构建简单的应用
![](https://static001.geekbang.org/infoq/5e/5ed15e5df22e1c5beefb568ca941c7df.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
均衡型:比如一些产业互联网厂商开发的产品,这些产品支持二次开发,产品及业务人员构建大部分的功能,开发人员可以构建余下的功能,但几乎都需要离线开发
这些产品都有不同的适用场景,并且目前看低代码这个方向的发展势头也很强劲。但是我们也注意到近期 ThoughtWorks 中国区 CTO 徐昊的观点《“行业毒瘤”低代码》[https://mp.weixin.qq.com/s/nux9xJko6N1tLTK23-ZbzA] 。从笔者的经验看非常赞同,用“虚火过旺”形容不为过。 目前低码平台最大的问题是改变了编程模型,导致开发与可视化构建存在断层,进而导致高不成低不就。
怎么理解?开发人员有对项目开发的经验范式,这是他们熟悉的,但低代码由产品或业务人员完成了大部分能力的构建,给到开发人员补充实现时却是各种 DSL,或是使用自定义的 XML 让开发扩展能力,或是注入了一堆用于界面可视化的 Schema/元数据到代码中,导致开发人员有很高的学习成本,并且很难去集成已有的能力。
那么怎么看待低代码吗?笔者认为其有不可比拟的优势,但在技术中台叠加低代码能力时我们需要把握以下几个原则:
BaaS 建设:低代码能力不是从 0 构建的,是中台的第四个能力象限,必定基于之前能力之上构建
我们要先有完善的公共能力,比如用户权限、用户触达、任务调度、规则决策等,后者为低代码提供了基础服务。同时很重要的一点是低代码能力要先实现 BaaS 能力,提供诸如对数据库、缓存、对象存储、MQ、日志、事务等原子化的服务。
![](https://static001.geekbang.org/infoq/fa/fac6174cac72dc242f2bedfdb558c094.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
也就是说我们可以基于中台的能力使用纯大前端技术(比如 Node、RN)完成复杂应用的构建。
DevOps 建设:支持一站式在线应用构建、测试、发布、反馈能力
实现 BaaS 能力建设后,我们也需要考虑 DevOps 流程的建设,能实现从需求到开发再到测试、发布、部署、监控等应用研发全流程的构建。
开发者优先:使用主流编程模型,支持在线编码、支持可视化与编码混合构建
有了 BaaS 及 DevOps 能力后我们还需要明确开发者优先策略,这是比较反主流的。笔者认为要先给开发者提供友好的体验,让开发者使用熟悉的编程模型,0 学习成本的情况下基于我们这个低代码平台可以开发完整的复杂应用。然后我们再要考虑的是在这一前提下逐步加入可视化、拖拉拽的能力,实现界面、模型、规则、服务、逻辑等方面的编排。
![](https://static001.geekbang.org/infoq/89/8939c81aad40fb43b545a6fc29b458e7.jpeg?x-oss-process=image/resize,p_80/auto-orient,1)
所以如上图所示,一个比较完善的技术中台大体的架构应该是这样的。它实现了我们中台能力支撑的四个象限。重点是实现了 DevOps 流程支持应用全流程构建,实现了原子、基础等公共服务支持纯大前端代码开发完整的应用的能力,实现应用构建平台建立应用管理、开发编排、持续发布等核心能力。
最后我们还要考虑的是推广成本的问题,目前来看各个中台产品的部署使用成本很高,比如某知名的技术中台仅验证环境就需要至少 500c100g。如果我们的目标是产品化不是平台化,那么必须使用创新的技术去实现服务伸缩、一键部署、代码安全等非功能需求。
本文只是抛砖引玉,泛泛地讲了一些原则,具体到实现还有很多有意思的点,如有兴趣欢迎进一步沟通、探讨。
关注我的公众号:
版权声明: 本文为 InfoQ 作者【孤岛旭日】的原创文章。
原文链接:【http://xie.infoq.cn/article/d55589ffe27cdfe7e8e50bfaf】。文章转载请联系作者。
评论 (2 条评论)