在DevOps产品的设计和研发中，我曾犯过的6个错误

正文

请到「今天看啥」查看全文

5. 规范约束。 处理一些管理过程规范外，在开发规范上，定义了子系统之间的边界规范，以API和SPI的模式来实现，每个小团队与上下游团队共同制定和review接口设计，具体如下：

上面的配图是一些草图，不太严谨，我之前在另一个群分享过我们平台的总体设计，大家若对材料有兴趣，可联系我，也可从我们的公众号上获取。

从大面上粗看貌似没什么问题，但大家或许心里已经有疑问了，比如说：

1. 数据模型在哪儿？DevOps平台本身讲究工具链的整合，对于扩展性，尤其是数据库的扩展性设计要求非常高（大家有时间可看看Team Foundation Service、Rational Team Concert这些平台的扩展性设计，非常不错）

2. DevOps平台本身采用微服务架构，同时支撑微服务在上面运行，难免会陷入一个鸡生蛋、蛋生鸡的问题，如何解决？

3. 开发架构上只是定义了一些子系统边界，对于DevOps平台具体的依赖产品或框架是怎么制定标准的？

4. 团队分工采用了两维设计，一些两维度冲突的地方是怎么解决的？

5. ……

是的，这些都是问题，也正是这些问题以及我的经验不足，让我犯了标题中提到的6个错误：

错误1：概念耦合。最典型的就是没有将DevOps、CaaS、MicroService拆分开来看。

这是现在业界的一个普遍现象，大家会看到，很多人把微服务，Docker，DevOps都放在一起谈。比如下面这些大会分享上的截图：

当然不是说这些作者本身概念混了，而是说现在的很多讲法，容易造成读者的误解。

事实上，这三者是独立的三个领域概念，DevOps的本质是：

而微服务是一种架构风格，难点在于开发规范与运维支撑。而容器呢，可以这么说，微服务架构给容器技术的风靡加了一把火：

所以，这三者完全是可以分开建设的，DevOps平台更应该关心多工具链及应用整合，异构环境的统一管理，流程的驱动支撑。

第一个错误给我的启示是：概念模型需要从领域着手，多领域需严格分开，当然，这也符合时下DDD倡导的设计模式。

请到「今天看啥」查看全文