传统企业IT系统迁移上云-构建公有云PaaS+SaaS平台

今天谈下对传统企业IT系统迁移上云的进一步思考。

在我前面谈云原生的很多文章里面都谈到一个核心观点，即公有云服务商本身一个关键变化就从IaaS层资源能力提供到PaaS层服务能力提供，整个抽象层次在不断上移。

但是传统企业IT应用相对于单纯的互联网应用来说偏重，而且各个业务应用之间的耦合性很强，事务一致性要求也高，如何迁移上云并没有想象的容易。

在我谈私有云PaaS平台的文章里面就谈到了，私有云的PaaS平台实际增加了数据库，技术+业务服务能力，集成能力，基础主数据能力，技术框架等诸多的内容。而对于常规的公有云PaaS平台则仅仅提供中间件资源池，各类技术服务能力。

这也是我今天准备再写一篇文章讨论的原因。我不准备系统的写PaaS平台或SaaS平台的构建，而仅仅是将一些关键思考点进行整理和记录。

从技术服务平台到SaaS生态

传统IT应用迁移上云，可以看到当前的公有云PaaS技术服务已经可以提供完整的数据库，消息中间件，应用引擎，缓存，通知，任务调度，日志等各种能力。但是对于企业IT应用常用的两个关键能力仍然欠缺。即常说的4A+流程引擎的能力。

也就是企业构建自己的云原生应用，这两个能力还是自己在云端私有化构建的。

我一直在思考大的工作流厂商，是否可以构建一套在公有云平台的支撑多租户的公共流程平台服务能力，这个完全是可行的。比如类似当前钉钉的开源生态，本身也有一些小型的流程引擎服务可以提供，但是还无法应对复杂的企业应用流程建模需求。

4A在这里作为一个统称，也可以理解为组织引擎，实际包括了组织，人员，用户，权限管理等各类信息。这些信息基本是构建任何一个业务系统或微服务模块都需要的基础共性主数据信息，必须得集中化构建并进行服务能力开放。这个4A服务能力也完全可以作为标准的公共服务能力，以第三方开发商来开发并进行服务能力提供。

我在早期谈SaaS应用的时候就一直在思考一个问题，比如有CRM，HR，OA等多个SaaS应用服务，但是各个SaaS都是自己构建自己的组织，流程基础数据，导致各个SaaS之间不能做到互联互通。即企业用了多个SaaS应用服务，但是最终发现端到端的协同没法做。

而谁在解决这个问题？

还是回到钉钉这个应用，钉钉看起来是一个提供一个互联网版本的轻量OA系统，但是实际是构建一个SaaS生态，这个生态的核心就是类似组织引擎，流程引擎这些基础技术服务能力是统一构建并提供服务的。你在钉钉上面开发第三方应用，那么这些应用可以使用这些底层共享数据和服务能力，同时各个第三方应用之间很容易打通。

从这个层面来说，钉钉构建生态的思路是成立的。

也就是说你面向中小企业开发各种SaaS应用，当你没有融入一个生态系统的时候，这个应用本身就是一个信息孤岛，无法互联互通，那么最终命运就是被准备淘汰。面对服务于中小企业的SaaS应用开发商来说实际可选的路线并不多，要么就是自己也去构建一个小生态，要么就是融入一个大生态。

企业IT应用全面上云

当前可以看到，类似用友，金蝶等大的传统ERP服务商都在大力地推广自己的云服务，而且从营收来看云服务的收入占比也在不断扩张。原来是企业内部建设和实施一套ERP系统，而现在是希望企业用户之间使用云端的ERP服务，而且告诉你以后所有的扩展应用最好也都放在云端，不要再按传统私有云方式进行构建。

在早期我们讨论内部IT全部SaaS化或迁移上云的时候，更多考虑的是云安全方面的话题，而今天重点谈下安全性以外的一些考虑。

首先对于传统IT应用，有些还是使用的分布式CS架构模式，即PC端的桌面应用，采用这种架构的原因重点是PC端往往在批量数据录入方面有巨大的优势，而BS端网页无法具备。如果转为网页版本实际代理的是处理效率下降。

其次就是当所有应用迁移到云端的的时候，即使互联网带宽再好，当存在大数据量传送或大量的数据库操作，事务处理的时候，互联网应用性能下降明显。简单来说你在内部局域网百兆带宽下一个查询可能1S就能出结果并返回，但是转化为互联网SaaS应用后可能就要10S甚至更久，这本身也带来性能体验上的下降。

再次，当谈一个IT应用的时候，实际数据来源有两个方面，一个是传统的人工录入或导入，一个是自动化的数据采集。在当前智能制造和工业互联网下垂直线条下的应用，比如MES，CIM等诸多业务系统，会大量存在自动化的数据采集。

当IT应用迁移到互联网后，这些自动化采集和处理一定带来是性能和体验下降。即使我们在整个IT应用架构规划下，会在企业端保留少量的边缘计算和边缘服务器能力，但是仍然无法达到全部构建在IT应用全部构建在企业内部时候的高效性。

能力开放和扩展开发定制

一个传统企业的IT应用，基本还是围绕ERP核心系统展开，如果ERP系统以及使用SaaS版本的ERP云服务。那么需要考虑的就是后续围绕ERP的定制开发方面的问题。在ERP上云后，后续扩展需求如何定制开发？定制开发后的应用如何快速的部署和交付到云服务平台。

比如你用的金蝶云ERP服务，当企业有扩展性需求的时候，能否定制开发一个类似财务分析的小应用，并将这应用部署到阿里云上面去。

要做到这点，核心就变成了云ERP服务本身应该提供足够的API接口能力开放，类似当前主流的电商平台都提供有Open API能力开放平台一样，将电商平台的能力以API接口方式进行暴露并提供给外部使用，你完全可以基于电商平台提供的能力开放一个方便你自己管理的进销存外挂。

对于ERP云服务同样需要考虑将核心能力开放为API接口服务。

能力开放实际包括两个方面的场景。

第一就是我拥有数据，提供开发的查询API接口服务给外部使用，你在需要的时候进行查询。在这种场景下我们实际推荐数据不落地，即需要的时候直接调用接口实时查询，以保证数据的实时性和一致性。

第二就是在外部存在外挂，需要导入数据给我，比如在ERP外部你单独开发了一个采购平台，进行采购请购，框架协议等操作，形成采购订单后再导入到ERP。那么这个时候云服务需要提供导入类的API接口服务。

在这里和传统电商OpenAPI平台一个最大区别就是第二种导入类API接口，一般OpenAPI平台并不推荐提供导入类API接口，但是在企业IT应用集成下存在何种场景。ERP云服务对应的OpenAPI平台是否足够成熟，将直接影响到企业应用全面迁移上云和后续定制开发的难度。

当然在企业应用建设到一定阶段后，自然涉及到从OLTP类应用走向OLAP类应用，你所有应用都构建在云端的时候，就需要在云端构建数据中台或数据仓库，分析类应用，那么传统谈到的大数据平台，BI分析工具也需要在云端，以服务化方式提供。

类似阿里云当前已经提供了云上数据仓库，数据湖的解决方案，重点就是进一步满足企业业务全面上云后的OLAP分析类需求。

低代码开发平台的演进思路

对于低代码开发平台，我前面写过多篇文章对于一些基础内容和应用场景进行说明。其中一些主要观点先总结如下：

• 低代码开发平台不是万能的。
• 低代码开发对人员技能有要求，特别是建模能力。
• 要将低代码开发和无代码开发两类分开。
• 低代码平台可以和DevOps融为一体。

当前低代码平台服务商，一般都是为应用开发和SaaS化运营是融合在一起的。即你在互联网上的低代码开发平台设计和开发一个应用，完成后可以自动部署和托管到公有云环境，实现向公有云环境的持续交付。

低代码开发本身也是一种技术服务能力，因此低代码开发商应该和公有云服务商之间进行解耦。即低代码开发完成的应用或微服务，通过DevOps过程支撑，能够持续部署或交付到类似阿里，华为等不同的公有云平台。既可以交付二进制部署包或镜像，也可以交付最终的源代码，低代码开发商不应该对用户进行深度绑定。

今天谈低代码开发，实际上我想谈什么呢？

即如果将低代码开发单纯地看做一个技术开发平台，那么其应用场景相当有局限性，更多的是企业一些小功能，小需求的快速开发和满足。比如我想做一个薪酬发放管理，做一个员工日志填报，一个OA办公类的日常流程管理等。但是这些小应用本身又是信息孤岛，无法和其它应用打通。或者说脱离一个大的应用生态或平台往往很难独立长周期运行和运维。

简单来说就是更多的应该是类似前面谈的金蝶，用友做ERP云服务厂商，或者类似阿里，华为做云原生服务平台的厂商，更加容易将低代码开发平台做成功。

对于ERP云服务厂商，低代码开发可以看做是做ERP外围小应用，外挂的一个快速方式，当ERP存在的时候代表底层的业务和数据模型基本是稳固的，那么基于这个模型你做上层的独立外挂应用才有基础支撑。即低代码开发应该是围绕核心应用外围定制开发的一个延展工具而已。这类低代码开发平台一定需要有完整的数据建模，流程建模，表单建模，规则建模，报表建模等能力。

对于公有云服务商，当前主推的低代码开发方式是类似Serverless无服务器架构，其核心思想是希望沉淀和稳定BaaS层能力，然后开发商可以快速地构建FaaS层能力，并实现对BaaS层服务能力的组合和编排。因此公有云服务商的低代码开发更类似于SOA分层架构和可复用的思路进行构建。不是没有代码，而是将代码变成足够小的代码片段或脚本，并完全去掉各种繁重的开发技术框架。这类低代码开发核心是第共性技术服务沉淀，其二是提供灵活的服务组装和编排能力。

最后，给大家分享一下早些年干的一些数字化saas商用产品，现在全部开源了，想研究和学习的小伙伴可以在gitee上搜索weiit-saas。 weiit-saas是一款Java开源项目，属于weiit团队自研产品，意在通过技术封装，让企业无需代码开发，帮助企业一键生成小程序、公众号，让企业拥有独立品牌的自营商城。产品竞争对手《有赞》、《微盟》。