2017 年初，我们基于 DC/OS (mesos + marathon) 开始构建端点自己的 PaaS 平台，核心任务就是解决公司的软件开发和部署交付效率问题，建设公司的研发效能(DevOps)、智能监控运维(APM、Monitoring) 等技术平台。其实 DC/OS 还是很好用的，集大成了一个完整的容器平台，不需要过于关注各个细节模块，比如：网络；其次在多服务的一键编排部署方面也是非常方便的，今天 K8S 主要还是依赖 Helm 来实现。但 DC/OS 存在的最大问题就是用户数还是太少了，出现问题后，需要靠自己探索解决问题。我估计我们团队是国内 DC/OS 运维最专业的团队之一，分母估计不大于 3。

一个让我们团队记忆非常深刻、非常痛的故事：2018 年夏天，一个周六到公司加班，准备保障业务团队的发布，结果公司的整个 DC/OS 的网络挂了，原本的计划是保障完业务的发布就去聚餐吃饭，结果硬生生的折腾了一个通宵。这一夜里，我们尝试了所有网上能找到的方法和建议都没有用，把能做的所有事情都做了，也没法恢复网络；最终还是清理掉整个集群的网络元数据，重建网络才恢复 （摸索出 “清理所有元数据，重建网络” 这个方法就花了很长时间）。

基于 DC/OS 的 PaaS 在 2018 年 4 月完成了第一个正式客户的生产部署之后，又陆陆续续的交付生产了好几个客户。就这样一路磕磕跘跘的走完整个 2018 年，在 2019 年就决定要开始转型到 K8S 了。

在架构设计 PaaS 平台的第一天，就决定要把底层的容器平台 (DC/OS) 给抽象屏蔽掉，所以我们采用了 infrastructure as code 的理念定义了一个 dice.yaml 的规范 (dice 是 PaaS 平台的名字) ，dice.yaml 规范的核心就是“以应用为中心“，“以开发者为中心”去定义、使用基础设施资源等等。“以应用为中心” 其实并不是什么新的概念，Heroku 早已经提出并实践，我们只是把这个概念做得更极致了一些，当然 heroku 的基础架构并不算先进，甚至有点落后。

“以应用为中心，以开发者为中心” 对于端点来说是非常重要的，我们一定要让业务开发的同学只关注业务本身，不用去理解容器是什么？K8S Deployment、Statefulset、Service、 Ingress、Pod 等是什么？更不要关心应用跑在一个什么样的网络上；也不用关注应用的监控接入、监控覆盖、诊断分析这些事情。其实，这对绝大多数据企业都是非常重要的。

“抽象、屏蔽掉底层的容器平台“ 这个设计除了给业务开发降低了极大的门槛，同时也给我们团队自身带来了很大的便利。这便利体现在转型 K8S 的时候，只需要针对性地开发一个 K8S 插件（不是给 K8S 开发插件，是给我们 PaaS 平台开发插件）就完成了。其实，在支持 K8S 之前，我们还和阿里云的 edas 合作，开发了 edas 插件支持将应用部署到 edas 上，On edas 这个模式也陆陆续续的交付了好几个客户。将容器平台插件化后，对接 Openshift, Rancher 等也是一件非常容易的事情，这对很多企业私有云环境是非常友好的。

从我们支持自建 K8S、到支持阿里云容器服务、然后又是 AWS、Azure 等一路支持的客户也越来越多，我们发现在今天的公有云上要从 0 创建一个企业的 IT 环境（测试、生产）还是要做非常多的事情，并且还是需要非常专业的技能知识， 比如：需要涉及 ECS、网络、存储、数据库、SLB、中间件、容器服务、安全等等。在我们的一部分客户中，这一堆从 0 创建云环境的事情都是由我们帮客户完成；所以，我们需要提效，需要将这一堆麻烦的事情给自动化掉，于是就基于 terraform 开发了整个自动化流程。作为一个产品型团队，我们做任何事情都会想着产品化，一开始就将 terraform 自动化的云资源编排流程做到我们的云管平台产品里去了。

越往后走，开发的功能就越来越多了，平台覆盖的范围也越来越大，后续又支持了边缘计算管理、快数据平台、移动开发等等。所有的这些功能的原始诉求都来自于端点的真实场景，比如：pos 应用就是一个边缘场景。

4 年走来，让我们自己最欣慰的事情，并不是做了多少产品功能，而是从 18 年中开始，我们就坚持一个月发布一个版本，并且还坚持给所有客户升级到最新版本，从来没有出现过代码分叉维护，包括前面提到从 DC/OS 转到 K8S 的大迁移、大升级。这是我个人心里觉得做得很牛的一件事情。时至今日，我们的平台已经管理了上百个 K8S 集群的应用，我们的目标之一就是 “成为管理最大规模的 K8S 应用的平台”。

2021年初（春节前），我们在思考 2021 年规划的时候，才开始意识到自己做了很多的事情，开发了一个很强大的产品，我们在产品开发这条路上走得很扎实、很专注，完全忽略了分享给更多的人、回馈社区、建设影响力等重要的事情。

所以，在今年春节后，我们团队就全力投入将整个平台完全开源。做开源这件事情，我们想得非常清楚，要做就是全部开源，不留所谓的高级功能（私货），不留内部代码分支，整个团队的日常迭代开发全部转移到 GitHub 上执行。我们希望做一个长期主义者，用 3、5年、更长的时间持续建设一个足够好的开源社区。

在全球，我们可以找到非常多的优秀开源项目，但大多数开源项目都是以工具属性为主，比如：前端 js 库、开发框架、基础服务器软件等，直接开源产品（甚至堪称商品）的项目却不多，我个人认为开源产品逐渐会成为这个领域的新趋势，社会肯定是向着更高效、低成本的方向去演进，基础工具或技术将会是真正的基础设施 ，对大多数人来说都不用过于关注；面向用户群，解决大多数用户的直接问题（第一问题）才是社会价值的最大化。直接开源产品也给我们带了新的麻烦，我们希望、也乐于大家免费使用开源的产品，但肯定不希望某一个公司或组织直接将我们的开源产品进行二次销售（含服务），所以我们只能先选择采用 AGPLv3 协议进行开源。采用 AGPLv3 的出发点不是为了限制个人、企业自己内部使用，仅仅是防止软件或服务再销售。

4 年了，我们的 PaaS 平台一直叫 Dice，已经做到了 4.0 版本，我们非常纠结在开源社区的第一个版本是 4.0 还是 1.0，如果是 4.0 对社区来说看上去会非常的奇怪。今天我们为了和公司所有的产品命名保持一致，所以改名成 Erda。Erda 是《基地》小说中地球的别名。Terminus (端点)、Erda、Trantor、Gaia 等都是源自于这部小说，都是星球名称。刚好完成了改名，新名字新起点，所以开源社区从 1.0 开始版本发布，也就很自然了。

Erda 开源项目有一个小小的愿景：“能够在 Erda 平台上构建任何类型的应用，持续提升应用研发效能；能够将应用部署、分发到任何云、任何地方；能以应用为中心持续完成应用的监控、诊断、治理”。

四年风雨，终归要历遍山河。

最后，欢迎大家关注端点开源项目 ，一起探讨、交流，共建开源社区。

企业背景：

端点刚于2021年3月完成超过四亿人民币的A轮融资，红杉资本领投，老股东阿里云、耀途资本跟投。

端点Terminus成立于2012年，是国内领先的新商业软件提供商，为全球规模型行业客户提供全链路服务，帮助企业实现新商业数字化转型。公司总部设在杭州，在南京、广州、青岛、上海、北京均设有分部，是国家高新技术企业、国际级软件名城项目、阿里云新零售核心伙伴。

端点自主研发的企业数字化生态Terminus，包含企业数字化平台（Erda）、软件生产系统（Trantor）、企业智能业务平台（Gaia）、软件设计体系（NUSI）、智能集成平台（Mule），高效重构、管理企业核心业务链，实现分布式敏态开发部署。基于生态的数字化能力，端点新商业智慧解决方案覆盖采购、管理到销售、营销大供应链业务体系，具备端到端的业务交付能力，并为客户提供一站式的实施和运维服务。

端点科技定位于新商业软件提供商，服务规模型企业，为行业客户提供核心业务系统软件，帮助企业实现数字化转型。目前研发产品有：企业级 PaaS平台Erda、软件生产系统Trantor、快数据平台、供应链采购平台、电商平台、 全渠道运营平台、会员营销平台、TMS、WMS、POS等。

截至目前，端点已服务过埃克森美孚、中国海油、山东能源、光明乳业、新华书店、首创奥特莱斯、宝胜体育、万科、龙湖、中海地产、中南置地、世茂集团等近百家规模型客户，覆盖零售、地产、能源、制造、金融等国内外500强企业。在海外市场，端点的业务范围覆盖欧洲、东南亚、拉美等国家。