再谈云原生和企业上云(200215)

在1月9日的文章中，我谈到云原生，当时就提到。

微服务架构+容器化+DevOps 将成为后续企业信息化转型的主流趋势。

实际上我们看到围绕云原生有一个重点就是企业的信息化规划和建设全面上云，所有细项工作的开展你可以看到完全是围绕这个目标展开的。即我们上云的概念变化了。

从单纯的购买云主机和存储服务 =》 规划，设计，开发完全面向云环境而生的应用和服务。

你要做到这点对企业的考验很大，即使是对已有一定的信息化基础积累的企业，这不仅仅是单纯的技术问题，也包括了业务的问题，组织和团队文化的问题。同时也不可能是简单的抛弃已有IT资产全部重新建设，而是涉及到如何兼容遗留系统，准备完成向云环境的转变和迁移。

传统企业的IT架构转型是企业走向数字化和对外服务化的关键一步。

网上看到由于本次疫情，由于湖北零件供应商无法及时供货，现代韩国的工厂停产。在当前的全球协同和企业生态链下，企业绝对不可能孤立的存在，而是需要和上下游供应链高度协同，一方面你需要上游的供应商提供服务能力，同时你又可以开放你自己的核心服务能力为下游服务。数字化转型里面有一个关键重点我的理解就是：

需要将企业已有的业务资产转变为一种IT服务能力，并对外开放和上下游自动化高速协同。

因此IT架构转型，信息化建设本身是对企业已有的业务资产赋能，让其进一步产生价值，无协同无价值，藏在深闺无人知也无价值。一定要打包传统企业边界，形成真正的无边界才能够产生价值。

我一直在整理和思考，我们当前究竟能够为企业提供哪些核心产品和服务，简单来说，就是协助企业传统IT架构转型，构建灵活高效的能力中台并全面上云，提示企业IT运维治理能力，提升企业IT对业务敏捷响应能力。 所有事情都会围绕这个目标而展开。

初步展开来说，将为企业提供如下服务并形成完整的解决服务，覆盖咨询规划到实施落地。

1. 中台和微服务架构咨询和规划设计

1.1 当前企业IT遗留资产分析和评估

1.2 当前IT对企业核心业务和端到端流程支撑和响应能力评估

1.3 企业中台整体规划和架构设计

1.4 中台微服务模块识别和拆分，API能力识别和定义

1.5 企业IT架构转型和全面上云演进路线和实施

2. 微服务开发框架和运行环境

2.1 微服务开发框架提供，包括限流，熔断，注册中心各组件封装提供

2.2 微服务组件拆分和设计规范

2.3 微服务API接口服务开发和设计规范，测试规范

2.4 技术中台能力提供（4A，流程服务，消息，缓存等）

3.DevOps过程管理和支撑平台

3.1 敏捷开发管理和过程规范，工具提供

3.2 Devops过程模型和企业实施路线策略

3.3 持续集成和交付，容器化PaaS平台，和公有云无缝对接

3.4 自动化运维，自动化监控

3.5 API网关集成和能力开放平台

基于这个思路，仍然还是围绕云原生提供的微服务，DevOps，容器化展开。当然对于ServiceMesh和Serverless等个人感觉前期没有必要，更多还是基于API网关的架构思路来实现中台各微服务模块的构建，接口服务能力集成和API能力对外开放。同时实现和公有云平台的完整对接，真正实现持续交付和多点部署能力。

上面这些事情要做到实际上不容易，但是以上列的内容实际都在我们公司和团队做了完整的实践，能够提供一整套可落地的咨询规划和实践方法，不仅仅是规划，更加重要的是真正可以落地，这个才是我们的优势。同时大企业也不要一味的迷信大公司和品牌，对于类似我们公司当前产品线来说，完全有能力做好上面这些事情。