博客列表

• 软件工程的第一性原理
• 聊聊平台工程
• 没有使用IaC的DevOps系统都是耍流氓
• SmartMeetup(S01E05) - 10分钟搭建开源免费的私有CloudIDE服务
• HashiCrop和Forrester为企业云战略提供的4条建议
• SmartMeetup(S01E04) - 仅有50Mb的小工具搞定大厂才能玩的CloudIDE
• 市值200亿美金的Slack：远程开发如何提高开发效率
• 开放原子开源峰会 - SmartIDE正式开源并发布v1.0版本
• 埃隆马斯克五步工作法
• 【开源云原生大会】现场演示：k8s套娃开发调试dapr应用
• 为什么Dapr是比SpringCloud和Istio更优雅的微服务框架？
• README.exe

软件工程的第一性原理

一直都想写这样一篇文章来聊一聊我对软件工程的看法，粗略算来我从事软件工程这件事情已经将近18个年头。很多人并不理解软件工程和软件开发的区别，用一个简单的类比来说明一下：如果说软件开发人员是淘金者，那么从事软件工程的人员就是卖牛仔裤的。是的，软件工程就是为软件开发人员提供最好的方法，工具和实践的学科。要做好软件工程这件事情首先要做的就是要理解到底什么是软件开发，也就是说软件工程的从业者必须对自己所服务的对象有正确理解，才能摸清其中的规律，从而为软件开发人员提供符合自然规律的方法，工具和实践 — 这个所谓的规律就是我今天想跟大家聊的内容：软件工程的第一性原理。

第一性原理这个词被埃隆马斯克带火了，其基本含义就是事物的根本性规律，马斯克经常说自己对物理学很痴迷就是因为物理其实研究的就是世间万物的根本性规律，从这个规律出发所做出的判断和决策就是符合规律的，也是一定可以实现的。相反，如果做不符合规律的事情，那么结果被各种困境缠绕，无法脱身。所谓的适者生存，就是这样一个简单的道理。

但是，规律的做法不一定就是简单方便的做法，事实上一般的情况恰恰相反，符合自然规律的做法往往都更加困难，违背基本的人性。举个简单例子，我们都知道要获得健康的身体就要坚持规律的作息，持续的锻炼身体并且科学的饮食；而实际的情况是我们总有理由去熬夜，总会在计划好的锻炼时间偷懒，高糖高碳水的冰淇淋和蛋糕也永远比蔬菜沙拉更加吸引我们，这就是人性。

软件第一性原理第一定律：软件是虚拟的

软件是一个虚拟物品，这就是软件工程的第一性原理，认识到这一点你才能真正理解精益敏捷、理解DevOps和持续交付，理解研发效能，理解平台工程，理解任何为了软件而存在的方法，工具和实践。 等等，软件是一个虚拟物品，这不是废话吗？是的，只有符合自然规律的描述才能被称之为废话，因为这个第一性原理本来就不神秘，本来就在你的身边。这就好像牛顿的力学定律一样，说出来你也会觉得是废话，但是真的要把它解释清楚，那么你就成为牛顿了。是的，你和牛顿的距离就是一句废话。

地下室的故事

话说一家知名的房地产大厂有一位具备500年房地产从业经验的设计师，他设计大楼的经验年头甚至都比大楼存在的时间要长那么几十年，唯一的问题是这些设计师是个盲人。有一次这位设计师来到一座将要竣工的大楼面前，这座楼有50多层，已经进入到内装修阶段了。设计师在仔细检查了大楼的各项设施之后提出了自己专业的意见，这个大楼需要增加2层地下室。

你一定可以想象在场的项目经理，施工方和工人们惊吓的目光，感觉自己遇到了一个疯子。不过，类似的场景其实只是各个软件/互联网大厂的日常而已吧，这样的疯子每天都见，早就习惯了。

疯子错了吗？

当然没有，他只是发现了一个“底层”问题，但是并没有意识到这是个“底层”问题，因为他根本看不到这栋大楼。这就是软件，一个虚拟的大楼。

作为程序员，大家都懂软件的分层，数据/逻辑/界面这是基本的三层架构；实际中的软件往往比这要复杂的多。但是如果你尝试去给普通人解释，这将是一件非常有挑战的工作，恐怕要从Hello World讲起。

因为软件本身是一件虚拟物品，普通人很难通过常识判断软件的复杂性以及内部关系，造成严重的信息不对称，这是软件工程领域各种问题的原罪。

软件第一性原理第二定律：软件只能被制造一次

复制一款软件和复制一辆汽车的成本是完全不同的，这也是基于第一定律延续。复制一辆汽车需要从新投入原材料，人工和各种生产资料，但是复制一款软件只需要Ctrl-C加Ctrl-V就够了。软件开发团队所做的事情严格来说不是生产制造软件，而是在设计软件，因为生产制造是指重复产出同样的产品，而软件开发团队每次产出的都是不一样的产品。

瀑布模式就是个错误

设计是一项创造性活动，创造性活动的目标是无法被预先定义的，其最大的风险是创造了无用的产品，如果方向错了，所有的努力都只会加速死亡。既然生死未知，计划的意义何在，你在计划更好的生，还是计划更快的死？现实中的表现是软件经常延期，工作量估算不准确，开发过程经常遇到不可见问题，轻则延期重则推翻重做。这也是瀑布式开发模式为什么从根本上就是错的，瀑布式开发的一个基本假设就是目标是确定的。

既然瀑布本身就是错误，为什么仍然有那么多组织和团队仍然在使用这种模式呢？其实在本文一开始已经解释了原因，这就是蔬菜沙拉和奶油蛋糕的区别。瀑布模式虽然不符合软件工程的基本规律，但是它更加符合懒惰和规避变化的人性特点，因此大家会不自觉的选择奶油蛋糕。如果再考虑组织中僵化的流程，官僚的氛围以及各种利益的驱使因素，那么瀑布这种更加容易管理，更省心轻松的方式自然会受到欢迎，至于产出的软件是否有用，是否浪费了资源，开发人员是否痛苦不堪，这些都不重要。当然，前提是这个组织本身不依赖软件生存，对于一个数字化的组织或者强烈依赖软件运作的组织而言，产出无用的软件这一点就已经足够驱动他们选择蔬菜沙拉了。事实上，那些选择了奶油蛋糕的早就死于高血脂引起的心血管疾病和脑梗了。

敏捷只是个标签

倡导迭代式的敏捷开发模式为什么现在被大多数开发团队认可，原因就是敏捷从根本上承认了软件开发目标的不确定性，而不像瀑布模式那样非要去定义一个无法被定义的东西。精益思想里面的核心Build-Measure-Learn强调的也是在目标不确定的前提下，怎样通过不断的检视来识别问题，调整方向，最终达到目标。DevOps的三步工作法 1）建立流和系统化思维 2）建立反馈 3）建立持续实验和学习的文化，看上去是不是也异曲同工？这些方法和实践都诞生于软件工程领域，现在已经在很多非软件行业使用，其思想根基都是以上所述的软件第一性原理，都是为了应对客观规律而被总结出来，又在实际工作中被验证的方法。

软件工程的基本工作思路 - 粒度和解耦

软件这件事情，现在变得越来越重要。现在火热的所谓数字化，研发效能，平台工程，其根本都是在寻找最大化软件价值的方法而已，只不过关注的层面有所不同。数字化更加关注用户侧和业务价值，研发效能更加关注开发过程，而平台工程则强调用一个内部开发者平台（Internal Developer Platform, IDP）来承载具体的方法和实践。 1993年，被称为是互联网点火人的马克安德森（Marc Andreessen ）开发出了Mosaic浏览器，后来加入网景（Netscape）公司，开创了互联网时代。可以说，软件这件事情只有到了互联网出现以后才真正开始进入普通人的生活。2011年，马克安德森提出了 软件正在吞噬世界（software is eating the world） 的说法，同一年的1月21日腾讯推出了一款为智能终端提供的即时通讯软件，叫做微信。

随着软件规模的不断扩大，早期几个人就可以搞定的软件现在需要几百上千人协同完成，软件开发过程本身的问题也被放大，变成了影响组织生存发展的大问题。 从研发效能的层面，从软件第一性原理出发，我们需要确保在目标不确定，方法不确定，系统越来越复杂的前提下帮助企业取得成功，其基本思路只有2个：就是粒度和解耦。面对不确定目标最简单的应对方式就是将复杂问题简单化，对问题进行拆解，然后逐个攻克。 但是在拆解的过程中会带来一个副作用就是拆解后的单个问题确实简单了，但是问题的数量增加引起问题之间的依赖的副作用。因此我们需要解耦，采用各种管理和技术手段，让拆解后的问题可以被独立解决，而不是依赖其他问题。有关粒度和解耦的话题，请参考我的另外一篇文章 DevOps实施落地的2大法宝——粒度&解耦

解耦是一个非常难的话题，在软件工程领域，对这个问题的解决方式就是 基础设施即代码 （Infrastructure as Code, IaC）,IaC本身看上去是一个纯粹的工程方法/工具，实际其背后隐含了一个重要逻辑，就是如果要降低AB系统耦合，就要从他们依赖中提取共性，然后由第三方C来解决这个问题，如下图：

如果想详细了解IaC的概念以及落地方法，请参考我的另外一篇博客 没有使用IaC的DevOps系统都是耍流氓 。

软件工程随着软件在我们生活中变得日益重要而开始引起了越来越多人的关注，这个行业也非常善于创造概念，因此你会听到各种新鲜的词汇，包括在本文中提到的敏捷，精益，DevOps，平台工程，研发效能等等。但只要做的还是软件，就无法背离软件工程第一性原理的2条定律，记住粒度和解耦，落实IaC的工作方法，就一定能找到适合自己的模式，应对好自己的问题，在自己的领域中取得成就。

最后还想说一句话：这些方法都会帮助你登上高峰，但一定不是别人的那座。

本周二晚 SmartIDE Meetup 继续 本期话题：谁说CloudIDE就只能用浏览器访问，Hybrid模式远程工作区想用什么就用什么 B站直播预约通道已经开启，现在预约就有机会获得 价值3500元的JetBrains全系列激活码一个和SmartIDET恤2件

聊聊平台工程

最近InfoQ上的一篇文章火了 DevOps 已死，平台工程才是未来，事实证明标题党确实对营销很有效，但这也确实只是一篇营销文章而已，文章内容其实和标题大相径庭。这个标题极具误导性，文中作者的核心观点：开发者不想跟基础设施打交道，企业在发展过程中又需要控制自己的基础设施。只有平台工程，能将这两个相互矛盾的命题统一起来。 看上去非常有道理，但是在我仔细研究了原文之后发现其核心观点本身其实不攻自破，就连作者自己的文章之中也在不停的引用各种DevOps中已经存在的实践和方法，同时承认这些方法实践的有效性。

平台工程的来源和定义

作为IT行业研究的权威机构，Gatner在2022年8月发布的 Hype Cycle for Emerging Tech （技术趋势发展曲线）中提到了这个词汇：平台工程 Platform Engineering，从其所处的曲线位置大家可以判断这是一个将在2-5年内快速流行的技术。

平台工程社区的发起人 Luca Galante 在 platformengineering.org 对平台工程的描述（定义）是这样的：

平台工程是一门设计和构建工具链与工作流的学科。这些工具链和工作流可以为云原生时代的软件工程组织提供自助服务功能。平台工程师提供集成化产品，通常称为“内部开发平台（Internal Developer Platform - IDP）”，可以涵盖应用程序整个生命周期的所有操作需求。

这里面的关键词有2个：自助服务和内部开发平台。 平台工程的目标其实是为企业构建一个协助开发者完成软件交付过程中与核心业务逻辑开发无关的支撑类操作的平台。从这个角度来看，我相信大家一定感觉非常的不陌生。

实际上，在我从事软件工程 / 敏捷 / 精益 / DevOps 咨询服务将近20年的过程中，我所服务的所有开发团队都在构建这样一个平台。

DevOps真的死了吗？

对于这个问题，一句中国的古诗可以描述得非常贴切：

春蚕到死丝方尽，蜡炬成灰泪始干

如果企业没有在软件工程上下真功夫，没有敏捷和精益的方法指导，没有实施DevOps实践的经验积累，平台工程也只能是空中楼阁。实际的情况是，很多企业在不停的寻找所谓“创新”而忽略了基本功的锤炼。真正企业需要的研发系统，一定不仅仅是DevOps工具就能覆盖的，但没有DevOps也一定是不能覆盖的。

我记得曾经在上海拜访过某国有大型银行的研发中心，交流的主题是高大上的企业研发效能平台，当时参与交流的几位关键领导之外还有1位负责项目发布上线的工程师，在领导们介绍了他们当前的各种实践之后的感觉这是一个相当成熟的DevOps团队，流水线仪表盘都做的很到位，度量数据丰富扎实，MTTR看上去走势良好 …… 但是场面在这位工程师回答了我一个问题之后急转直下，我的问题是：你所负责的系统，如果你不来上班，其他人可以正常发布吗？答案是：不能。后来我觉得，跟领导交流还是要纯粹一点，让懂技术的人参与进来肯定会带歪主题。

这其实是大多数企业在落地DevOps研发效能时候的通病，光鲜亮丽的仪表盘背后其实是人力发电的空调系统。 其实DevOps的各种所谓文化，理论，实践都基于一个最基本的逻辑，就是基础设施即代码IaC。对于IaC的理解我们不能仅仅停留在字面意义上，其真正推动的其实是一个共享，协作，抽取共性的工作模式。有关IaC的详细分析，可以参考我的另外一篇博客：没有使用IaC的DevOps系统都是耍流氓。

很多企业还没有做好最基本的配置管理，分支管理，开发环境管理就开始要搞什么灰度发布，微服务架构。其实一个DevOps系统完全可以简单到一个 shell 脚本，当然也可以复杂到需要200人的团队去维护。关键是要 回到问题的本质，软件研发只是手段，不是目的，做出来的软件是给用户用的，不是拿来跑流水线做自动化测试出指标看度量数据的 。如果一个工具平台，不能让开发者获得自由，反而增加了各个角色之间的耦合，那么这种平台还不如没有。在那些被PMO吹上了天的DevOps平台过级认证的背后，我看到的是这些企业内部开发人员的怨声载道，本来可以简简单单，清清爽爽的开发，测试上线，现在变成了一堆高大上的平台，系统里面繁琐得找不到 “下一步” 按钮的流程。

DevOps可以死，在它燃烧掉所有的价值能量之后，在企业真正吸收了这些知识和实践之后，这时候真正可以锤炼抽取出对开发者有用的这样一个平台的话，那么也是死得其所。

一定要警惕专家

埃隆马斯克曾经在一次采访中说过：对于任何的需求都要谨慎，特别是那些来自所谓专家的建议，因为你可能因为他们的身份而停止了自己大脑的运转。 看看下面这几位专家的建议，我只能说：你们长的这么帅，我只能相信你们了。

Tammer Saleh: 从单体开始，逐步抽取出你的微服务

Stefan Tilkov：如果你的目标是微服务架构，那么就不要从单体开始

Simon Brown: 如果你做不出一个单体应用，你觉得你能搞定微服务吗？

开发不想做运维

回到作者的核心观点：开发者不想做运维工作！谁说DevOps就是让开发做运维工作了？谁又说持续改进就要让用户使用不稳定产品了？DevOps底层所需要的IaC的本质就是要创建一种机制，让开发和运维一起构建一个工具或者系统，双方都把公用能力贡献出来，简化双方的工作，即不是运维为开发服务，也不是开发要学习运维。

到了具体个体案例的时候，企业在实施DevOps过程中会受到领导者和实施者自己组织现状的种种制约，才会出现各种变形。问题根源不在方法，在于人。这就好像给你一把手枪，你可以用来主持正义也可以用来杀人越货，难道这是手枪的问题？

最后还是我常说的那句话：没有不适合DevOps的组织，只有不想做出改变的人！

参考资料

• https://platformengineering.org/blog/what-is-platform-engineering
• https://www.liatrio.com/blog/what-is-platform-engineering-the-concept-behind-the-term
• https://www.gartner.com/en/articles/what-is-platform-engineering
• https://web.devopstopologies.com/
• https://teamtopologies.com/

没有使用IaC的DevOps系统都是耍流氓

作为现代软件工程的基础实践，基础设施即代码（Infrastructure as Code, IaC）是云原生、容器、微服务以及DevOps背后的底层逻辑。应该说，以上所有这些技术或者实践都是以基础设施即代码为基本模式的一种或者多种方法的集合。基础设施即代码并不是一种特定的技术，而是一种解决问题的思路。本文将从基础设施即代码的含义，原则和落地方法三个层面来帮助你理解为什么没有使用IaC的DevOps系统都是耍流氓。

什么是IaC

基础设施即代码的目标是解决一个古老的问题：如何能够安全、稳定、快捷、高效得完成软件交付过程。注意这里的交付并不仅仅指将可部署的软件部署到最终的运行环境，而是更宽泛的概念上的交付，也就是将软件从一个看不见摸不到的想法或者创意，转变成用户可以操作并使用的一个系统。这个过程涉及软件创意的捕捉、设计、计划、开发、测试、部署和发布的全过程，也包括软件发布之后收集用户反馈重复启动以上过程的迭代。这个迭代在软件的整个生命周期里面会一直重复下去，直到这个软件不再有人使用，寿终正寝。

软件生命周期中的这个持续的迭代过程构成DevOps反馈环路的概念，在这个反馈环路的左右两端分别是Dev和Ops，而代码和基础设施正是Dev和Ops最重要的工件（Artifact），Dev维护代码，Ops维护基础设施。传统意义上，代码和基础设施是有明确的界限的，一般来说：代码特指应用代码，而基础设施则是除了应用以外（或者以下）的所有“基础”组件。

在云计算技术出现以前，硬件被普遍认为是一旦创建就无法改变的，就好像你购买一台电脑，如果希望更换其中的CPU，内部，磁盘以及网卡，那么都必须重新购买相应的组件并重新组装。云计算将计算资源（电脑）解耦成了可以随意组合的计算、存储和网络三种资源类型，允许用户根据需要自助的进行组合。其底层实现机制是将硬件软件化，比如：对象存储技术和软件定义网络（SDN）就是云计算的基础技术。硬件被软件化之后的结果就是我们可以通过配置来变更硬件的能力。这其实就是基础设施即代码的最基础的含义。

但是对于用户而言，其实并不关心所使用的软件到底运行在什么硬件，什么云上面。比如：对于用户的社交需求来说，微信就是社交需求的基础设施；对于需要编写文档的用户来说，WORD就是他的基础设施。相对于硬件，这其实是基础设施的另外一个极端含义，也就是：任何支撑用户完成某种操作的支撑能力，都可以成为用户这一类别操作的基础设施。

从这个极端含义的角度来说，以上环境堆栈中的任何一层都可能成为上层的基础设施。为了能够为上层提供类似云计算的自助化能力，都需要提供可配置性。为了满足这种可配置性的需要，IT行业里面就出现了容器化技术、Kubernetes、Terraform、Azure Resource Manager等等基础设施即代码的实现方式。其实这些技术解决的都是一个问题，也就是系统的可配置性问题。

IaC的实现原则

实现可配置性能力的方法很多，传统运维的做法其实很简单，就是通过脚本来自动化这个配置过程，让原本繁琐的配置过程自动化起来。

自动化脚本的方式虽然能够在一定程度上解决可配置问题，但是当系统变更频繁程度到达一定量级的时候，维护自动化脚本的工作量将会抵消自动化脚本所带来的效率提升，这个时候运维团队会发现采用人工处理的方式甚至比编写和维护自动化脚本更加高效。因此，在当今软件迭代速度越来越快的背景下，自动化脚本逐渐无法满足团队应对快速变化的市场的需要。我们需要一种能够能够允许团队轻松适应快速变化的环境维护方式，基础设施即代码（Infrastructure as Code, IaC）就是在这样的背景下诞生的。实际上，说诞生并不准确，IaC其实是工程师们在遇到问题之后持续改进的结果。

当维护自动化脚本的方式无法适应快速变化的市场需要的时候，如何让开发和运维团队解耦就变成了解决这个问题的核心。在上图左侧的工作模式中，问题的核心是开发和运维团队之间基于“请求-响应”的工作模式，这种工作模式让开发和运维团队相互依赖，无法独立的按照自己的节奏工作。为了解决这个问题，IaC借用了大规模软件架构设计中的分层原则，让那些需要被共享的能力变成通用组件，并在开发和运维之间共享这些组件，从而让本来互相依赖的两个团队变成依赖另外一个第三方组件。如下图：

为了能够通过第三方组件协同工作，IaC方式需要遵循几项关键原则

• 声明式（Declarative）：为能够让所有编排能力独立于开发和运维团队，任何一个团队都不应该将能力的具体操作保留在自己的团队中，采用声明式配置可以确保这一点，因为配置中只有声明没有具体逻辑，就意味着原来的依赖双方都必须将公用能力贡献出去，否则上图中的C就无法生效。

• 幂等性（Idempotence）：进一步来说，声明式配置必须能够在任何时候确保环境编排的结果，也意味着通用组件C中对于环境的操作必须能够在任何状态下执行并且获得一致的最终结果。换句话说，无论目标环境处于初始状态，中间状态，最终状态还是错误的状态，当加载声明式配置以后，都会变成我们需要的理想状态（Desired State）。

IaC的落地方法

从本质上来说，IaC是一种做事情的方法，实现IaC的方法和工具只要遵循以上原则，都可以帮助团队落地这种方法。在实际工作过程中，我们需要一些基本条件才能够实现IaC：

文化支撑

落地IaC将改变团队（特别是开发和运维团队）的工作模式和协作方式，双方的工作边界和职责都会发生变化。传统模式下，开发和运维团队通过流程进行协作，双方在需要对方配合的时候发起一个流程（发出请求），等待对方按照要求完成操作（给出响应）之后继续这个流程直到目标达成。而IaC则要求双方通过共享能力进行协作，双方需要持续发现协作中阻碍对方独立工作的问题点，一起将解决这些问题的能力贡献给另外一个双方共享的组件（一般是一个工具），在日常工作中不再依赖流程驱动对方，而是使用这个共享的组件（工具）完成工作。IaC的工作模式要求两个团队都接受不确定性思维方式，出现问题的时候要共同解决问题而不是界定和追究责任。如果团队中的文化不允许这种不确定思维方式的存在，IaC将无法落地。

共享工具

具备以上文化支撑的团队，需要共同构建一个双方都认可的工具，将双方都需要的环境编排能力全部封装到这个工具中。这个工具的核心目标有两个：

• 解耦：让双方在日常工作中不再依赖对方，可以按照自己的节奏和工作模式自由的使用，同时确保双方关注的标准，规则和策略都可以被正常落实并可以被监督。

• 可定制可演进：这个工具存在的目的就是为了能够适应不停变化市场需要，一个静态的工具是无法做到这一点的，只有那些具备了高度可定制性和扩展性的工具才有可能具备这样的能力。因此在设计和实现这个工具过程中做到功能粒度的控制就变得至关重要，如果所有的功能都按照日常业务流程设计，不考虑通用性，最终的结果就是任何的工作流程变更都会造成工具的变更，这样的工具也就失去了通用组件的存在价值。

IaC无处不在

实际上，云原生，微服务，容器化和DevOps都是在从各个不同的层面践行IaC。云原生强调利用云的基本特性赋能团队，其实就是利用上述云计算的底层技术为团队提供实现IaC的基础条件。微服务则是通过组件化的思维让多个团队可以独立自主的工作，不再受到其他团队的影响从而最大化团队工作效率。容器是在云计算技术的基础上，为操作系统以及其上层的环境堆栈提供IaC能力，包括Docker和Kubernetes为代表的主要容器工具都是基于声明式配置和幂等性原则设计的。

DevOps在这里又是什么呢？DevOps是以上所有这些概念，方法和实践的综合，实际上DevOps的范畴比这个还要宽泛。开头的那张图上你应该可以看到，从广度上来说，围绕Dev和Ops构成的这个无限环其实涵盖了软件交付过程的所有环节，从深度上来说，DevOps又可以涵盖文化理念、管理方法、商业创新、敏捷和精益、项目管理、团队管理、技术管理和工具实现的全部层次。以至于越来越多的人将越来越多的内容放在DevOps这顶帽子下面，出现了诸如：AIOps, GitOps, TestOps, DevSecOps, BizDevOps等很多扩展概念。

其实，我们不必纠结这个概念本身，因为来自于社区自发总结的DevOps本来就没有一个集中的知识产权所有者，也就没有人能够给予它一个明确的释义。这本身其实也是一件好事，因为就如同以上对IaC的分析解释一样，DevOps的存在也是在帮助我们持续改进的，如果它本身变成一个静态的方法集或者工具包，又如何能够适应当前不断多变的商业环境和市场需要呢？从这个角度来说，所有那些希望将DevOps进行标准化的所谓认证，体系和方案其实都是一种带有误导性的行为。

很多的企业在引入容器技术，微服务，云原生以及DevOps的过程中仍然在延续原有部门结构和工作流程，并且试图将这些新技术新方法融入到现有的流程中，而不是探索新技术新方法带来的全新可能性。我在过去十多年帮助企业实施落地DevOps的过程中遇到了太多类似的组织，其中最明显的表征就是你会发现那些推动DevOps实施落地的部门不停的界定责任，造锅甩锅，那么他们一定是在用DevOps耍流氓。以上我所描述的IaC的工作思路对这些人来说从来都不重要，他们不在乎问题出现以后的根源分析和改进措施，相反如果根源分析的结果让锅到了自己头上，那么宁可不分析；如果改进措施的结果是需要自己将一部分职能贡献出去，那更加不能做。最后的结果就是那个“共享工具” 里面埋藏了各种补丁，硬编码流程以及技术债务，可想而知这样的工具又如何能够承载不确定性，如何能够帮助其他部门提高效率，更不要提为组织提升总体效能了。对了，这个埋藏了大量定时炸弹的工具就是你们热衷的那个“一体化研发平台/DevOps平台”。

SmartMeetup(S01E05) - 10分钟搭建开源免费的私有CloudIDE服务

S01E04 - CLI使用详解 回顾

• Meetup 时间：2022.9.21 晚20:30 （临时调整在周三）
• 主持人：徐磊
• 观察员：衣明志，烟台易云网络创始人/资深.NET开发者/前微软最有价值专家MVP

在上周的Meetup上，我们邀请到了来自烟台易云网络创始人衣明志作为观察员参与我们的活动。我们对SmartIDE的核心模块CLI进行完整的介绍，为大家展示了以下场景：

• SmartIDE CLI 安装和基本操作
• 使用 start 指令在本地，远程主机和k8s集群上启动远程工作区
• 使用 host 指令将Linux主机注册为开发环境
• 使用 list/start/stop/remove 指令管理远程工作区生命周期
• 使用 new 指令从预制的开发环境模板启动新开发环境
• 使用 init 指令对现有代码库进行初始化，自动完成 IDE配置文件 的生成和适配
• 第三方系统集成：在 gitlab-ci 中集成smartide cli实现云原生IDE调度能力 下面是S01E04的视频回放，大家可以关注我们的B站频道

S01E05 - 搭建开源免费的私有CloudIDE环境

• Meetup 时间：2022.9.27 周二晚20:30
• 主持人：徐磊
• 观察员：周文洋，LEANSOFT研发总监/资深DevOps顾问/前微软最有价值专家MVP

本周二的 Meetup 我们邀请到来自 LEANSOFT的研发总监周文洋作为我们的观察员，周文洋曾经参与多家大型企业的DevOps实施咨询，也是《专业SCRUM - 基于Azure DevOps的敏捷实践》的主要译者，他的客户包括博时基金、浦发银行、华为等多家大型企业。

这次的 Meetup 我们将围绕 SmartIDE Server 这个产品组件展开，SmartIDE Server 是面向团队和企业的云原生容器化远程工作区管理平台，可以为开发团队提供统一的开发测试资源管理，基于浏览器的开发环境访问以及团队协作能力。SmartIDE Server 的 团队基础版 功能是开源而且免费的，任何人都可以按照本手册所提供的方式完成部署并免费使用，没有使用期限限制，没有用户数限制，也没有资源数量限制。

下图展示了 SmartIDE Server 的部署架构

下图展示了一个 SmartIDE Server 的云端工作区，同时支持使用多种方式进行连接

• VSCode WebIDE 浏览器接入
• JetBrains Gateway 远程接入
• 命令行终端直接接入

我们将现场完成以下场景的演示：

• 使用一台云端虚机完成 SmartIDE Server 的一键搭建过程
• 将Linux主机和Kubernetes集群注册到 SmartIDE Server
• 通过模版启动预置的开发环境
• 使用代码库URL启动项目开发
• 在Kubernetes工作区中嵌套运行 Docker 和 Kubernetes 进行云原生开发
• 在iPad上使用云端工作区

直播抽奖

一等奖：价值3500元的JetBrains全系列IDE激活码一个

二等奖：SmartIDE文化衫两件

立即扫码预约直播

HashiCrop和Forrester为企业云战略提供的4条建议

本文是译文，原文地址 https://www.hashicorp.com/blog/hashicorp-state-of-cloud-strategy-survey-2022-multi-cloud-is-working

有关 HashiCrop

HashiCorp是由Mitchell Hashimoto和Armon Dadgar联合创办，总部位于美国旧金山，致力于为企业提供服务，通过数据中心管理技术研发，让开发者通过工具构建完整的开发环境，提高开发效率。HashiCorp提供了大量的DevOps 基础设施自动化工具，集开发、运营和安全性于一体，可以帮助开发者编写和部署应用程序，加速应用程序分发，助力企业提升开发效率，包括：Vagrant、Packer 、 Terraform 、Serf 、Consul , Vault 和 Nomad 等。

2016年9月，HashiCorp 获得2400万美元的 B 轮融资，由GGV Capital 领投，Mayfield 、 True Ventures 和新投资方 Redpoint 参投。截至目前2016，该公司共融资3400万美元。2021年12月9日，美国云开源软件公司HashiCorp登陆纳斯达克，市值153亿美元，是迄今为止今年全球市值最高的开源IPO。

HashiCrop和Forrester通过调研得出的结论：90%的企业通过多云策略和专业的云平台团队取得成功；但安全、员工技能和费用管理仍然是非常大的挑战。– 《2022企业云策略现状调研报告》

第二份《企业云策略现状调研报告》已经发布，非常清晰的显示了以下结论：

• 更多的企业正在采用多云策略
• 组建专业的云平台团队对于企业的云策略取得成功至关重要

这些结论延续了我们2021年的首次调研的结论，今年的调研结果更加清晰的显示了多云战略，云安全性以及缺少专业技能正在影响着企业利用云计算的能力。2022年报告中的新发现是，专业的云平台团队正在组织中扮演越来越重要的角色，以及很多组织正在云平台的使用上浪费大量金钱。

我们在2022年的调研报告中引入了Forrester咨询作为调研机构，我们调查了超过1000个千人以上的大型组织的决策者和关键角色，这些被调研对象覆盖了全球的不同行业的组织。今年的报告 全文可以通过以下网址获取：

• https://www.hashicorp.com/state-of-the-cloud

您也可以扫码关注DevOps公众号，并输入：云策略报告2022，即可获取PDF版本的报告全文。

以下数据展示了本次报告中的关键结论，5个关键数据

• 90%的受访者认为多云战略可行
• 86%的受访者依赖云平台团队执行多云战略
• 94%的受访者认云资源使用中存在浪费
• 89%的受访者认为安全是决定云战略成功的关键因素
• 员工的云技能缺失是企业执行多云战略的最重要的障碍

云平台团队对执行多云战略非常有帮助

报告显示，81%的受访者正在使用多个云平台，或者计划在未来一年中采用这种策略。但这并不是真正的中带你。更重要的是，在这些采用了多云策略的组织中，90%的受访者认为这种多云战略已经对他们实现商业目标有所帮助。虽然我们的调研方法有所变化，但是相比于2021年的结果仍然是一个巨大的跃升，因为在2021年这个比例仅为53%。

多云战略之所以能够取得成功，与专业化云团队的增加很有关系，一般来说这些团队被称为 云平台团队 或者 云技术中心。受访对象中10家中有9家都有类似的职能存在，而在那些没有设置类似 职能的组织中，仅有四分之一在使用云而且他们并不认可云的价值。

这背后的原因应该是由于云团队为组织提供了很多关键能力。云团队的主要职能就包括：让云服务变得标准化，构建和共享最佳实践以及实现云安全/合规的集中管理。超过四分之三的受访对象依赖云团队完成被调研的全部15项职能。这些职能包含了非常多的关键能力，比如：构建云管能力和运维策略，开发和推广云最佳实践，构建云解决方案以及云运维操作。

安全、技能和费用管理仍然是重要挑战

当然，多云策略仍然充满挑战。90%的受访对象对于云安全非常担忧，并将安全列为第一优先级，甚至超过了可用性指标。下面一项关注点是员工的云技能短板，41%的受访者认为这是阻碍他们实现多云战略的关键障碍。正是因为云技能人才的紧缺，才使得 云平台团队 变得更加重要，因为这样企业可以最大化具备云技能的工程师的作用。

另外一个同等重要的挑战就是费用，仅有6%的受访对象认为他们的费用管理已经没有可提升的空间。剩下94%的受访者都被各种浪费所困扰，包括66%来自资源空转/无人使用，59%来自超规格部署以及47%来自员工技能缺失。从乐观的角度来看，仅有24%的受访对象在云费用上超支，因此至少大多数组织在云资源预算控制上做的还不错。

来自Forrester的关键建议

2022年的调研报告是HashiCrop和Forrester一同完成的，调研范围扩展到了HashiCrop的客户之外，并且提供了更加中立的分析和建议。你可以通过我们的报告官网下载完整版报告，以下列出了Forrester给予企业的一些关键建议。

• 为你的业务量身定制多云战略 - 多云战略有多种形式，Forrester建议企业管理者根据自己企业的情况考量哪种战略更加适合，并想清楚选择原因。
• 引入自动化对于减少浪费和提升效率非常重要 - 来自Forrester的建议：“引入自动化工具对于企业提升云资源利用率以及优化ROI（投入如产出比）非常有效。自动化不仅仅能够有效减少浪费，还能从整体上降本增效。”
• 充分利用自动化的安全工具来支撑多云战略 - Forrester 建议组织 “充分利用自动化工具不仅仅可以节省运维团队的时间，还能帮助解决非常复杂的IT问题，优化云资源成本，监测并消除安全隐患。”
• 构建全功能的云平台团队 - Forrester认为 “云平台团队可以帮助组织更好的推动多云战略的安全、管控、规范和框架、内部培训、云技能认证在整个企业的落地实施。” 同时也要意识到企业文化对于构建一个成功的云平台团队非常重要。

Meetup预告

本周二晚8点30分，SmartMeetup S01E05精彩继续，本期主题：搭建私有CloudIDE服务，扫码预约直播，千万别错过

现场还有抽奖

• 一等奖，价值3500元的JetBrains全系列激活码
• 二等奖，SmartIDE文化衫

SmartMeetup(S01E04) - 仅有50Mb的小工具搞定大厂才能玩的CloudIDE

Smart Meetup已经在上周二（2022.9.13）重新启动，后续我们将在每周二晚8点30分和大家见面。Smart Meetup得目标是持续为大家输出云原生IDE相关得最佳实践，并不局限于介绍SmartIDE自己的特性和功能，而是希望能够从软件工程的角度为开发者提供帮助。以下是我们当前规划的一些方向，希望各位小伙伴多提意见和建议：

• SmartIDE 特性介绍 - 按照我们的发版周期，每隔2周都会发布新版本给社区，我们会通过这个Meetup为大家介绍这些新特性，帮助大家尽快的将新功能用起来。
• 开源项目推荐 - SmartIDE的一个重要特点就是帮助开源社区的小伙伴快速的体验新项目，我们会继续这个做法，为大家喜欢的开源项目适配 IDE配置文件，并在Meetup为大家展示这些项目的能力。之前我们已经适配过的项目包括：若依项目、Gin-Vue-Admin和飞致云的Metersphere。
• 云原生相关技术分享 - 作为一款云原生IDE，SmartIDE不仅会利用云原生技术让开发者的工作变得更加简单高效，也同样在践行着各种云原生开发实践，比如我们之前就介绍过如何使用SmartIDE来开发调试Dapr应用。后续我们会继续这个方向的摸索，并将最棒的云原生开发实践推介给大家。
• 敏捷/精益/DevOps/研发效能相关实践和案例分享 - SmartIDE的定位是成为DevOps和开发者的桥梁，那么我们的Meetup也同样会承载类似的职责。我们会不定期的邀请行业内的专家大咖来给大家分享各种最佳实践和案例。

另外，在每一期的活动上我会邀请一位观察员，从用户的角度给予一些反馈，提出一些问题，帮助我们打磨产品，拓展使用场景。

S01E03 回顾

• 时间：2022.9.13 晚20:30
• 主持人：徐磊
• 观察员：施慧斌、FIT2CLOUD北区解决方案负责人

上周的Meetup距离之前的活动已经有了一段时间，因此我们首先对SmartIDE的一些进展给大家做了介绍，然后针对 Codespaces for Azure DevOps 插件进行了重点介绍。这次Meetup我们也邀请到了FIT2CLOUD北区解决方案负责人施慧斌作为观察员参与了整个演示。

CodeSpace for Azure DevOps 插件

SmartIDE产品定位于开发人员的的DevOps入口，基于这个定位我们在微软的DevOps平台Azure DevOps上进行了首次尝试。通过在Azure DevOps的电子看板，代码库，流水线和拉取请求的不同位置提供一键创建云端工作区的入口，为开发和测试人员提供快速稳定获取可用环境的入口。这个插件充分利用了SmartIDE的标准化环境编排能力，将原本静态的开发环境转变为随用随起，用完即焚的临时性环境，让原本很重的环境管理编程一键非常轻量而且便捷的事情。

对于用户而言，可以利用以上能力解决一些日常开发协作中的问题：

• 特性分支规范化： 特性分支是当前软件开发团队普遍使用的一种分支模型，要求开发人员根据不同的开发任务拉取独立的特性分支，并在这个分支上完成所对应任务的开发工作，起到聚合和隔离代码变更的作用。特性分支对于大型团队隔离不同特性之间的相互影响，做到灵活控制上线周期和发版方式来说效果非常明显。但是特性分支在企业落地中普遍存在几个问题：1）特性分支命令不规范，因为分支需要开发人员自己创建，经常会出现各种不规范的分支名称增高管理成本；2）代码夹带，很多开发人员认为特性分支操作太繁琐，经常会为了省事儿把多个特性在一个分支上一起开发，这样会造成后续发版过程中无法拆分清楚代码，造成未经审核的代码被夹带上线，严重的时候可能造成生产问题；3）操作流程复杂造成的误操作，特性分支要求开发团队具备非常严格的流程执行纪律，特性分支到发布分支再到主分支的合并过程不能随意跨越，但实际操作过程中很多团队并不能很好的执行这个流程，教育和培训成本都很高。这些问题的根源在于，git分支操作过于灵活并且可以在开发机本地完成，使得这个流程无法完全在线上闭环完成。使用云原生IDE之后，可是实现整个编码开发过程的线上化，不再依赖开发人员本地环境，实现完整的流程线上化闭环。
• 测试环境独立化： 测试环境的获取一直都是软件测试流程中的一个难题，受限于企业资源和自动化能力问题，大多数的开发团队仍然依赖开发人员手工部署测试环境。对于测试来说，最好能够给每个测试目标都提供独立测试环境，比如：手工测试应该针对每个测试人员的每个测试轮次提供，自动化测试应该针对每个被测版本的每个测试轮次提供。考虑上测试环境被测试用例污染的问题，还需要提供快速重置测试环境的能力。传统模式下，以上这些问题都没有特别好的解决方案，关键问题在于2个环境标准化能力不足（IaC实践没有被引入到开发测试阶段）和资源限制（容器化实践没有被引入到开发测试阶段）。使用云原生IDE，随用随起，用完即焚的环境调度能力可以有效解决标准化的问题，VMLC能力可以有效应对资源限制问题。开发环境独立化问题得到完美解决。
• 基于代码评审上下文的临时环境： 拉取请求时有效的代码评审机制，但是代码库所提供的拉取请求只能帮助评审者比较代码，无法帮助评审者从功能的角度验证代码的正确性。虽然CI/CD流水线中可以嵌入各种质量门禁，但是都无法让评审这从用户的角度了解应用行为的正确性。使用云原生IDE我们可以针对代码评审的上下文创建一个临时的让评审者可以直接进行操作，从用户的角度进行验证功能，辅助完成代码评审过程。

以下是本次Meetup的视频回访，Codespaces for Azure DevOps的演示部分在视频的43分钟开始。

另外，以下视频中也对这个插件进行了完整的演示和介绍

S01E04 预告 - CLI 详解

• 时间：2022.9.21 周三晚20:30 （本周特殊原因临时改在周三）
• 观察员：衣明志，烟台易云网络创始人/资深.NET开发者/前微软最有价值专家MVP
• 主题：SmartIDE CLI 详解

本周的Meetup将围绕SmartIDE的使用场景展开，CLI是SmartIDE产品架构中与其他类似产品最大的差异。大多数CloudIDE都会提供CLI工具，但是这些CLI都是作为辅助性工具存在的，也就是说用户使用CLI连接到CloudIDE服务来完成类似端口转发，如果脱离的CloudIDE服务，这些CLI本身是无法单独使用的。

SmartIDE的CLI则不同，用户可以使用CLI直接创建、停止，删除，清理远程/云端工作，这个过程无需CloudIDE服务（SmartIDE Server）的存在。

这样设计的目的是为了方便个人开发者可以非常轻量的管理自己的远程/云端工作区，无需预先部署Server。这样，个人开发者可以在需要的时候使用一个 smartide start 指令即可在任何资源上启动远程/云端工作。

从开发和调试的角度来说，CLI工具的迭代速度是带有WebUI或者API类型的应用无法比拟的。因为CLI极度简单的操作方式，我们无需处理界面的布局，美观，操作体验，各种边界条件等问题，可以专注于业务目标的实现。这种快速迭代能力让我们可以更早的触达用户，验证产品核心功能并及时调整产品方向。在过去的6个月，CLI的发布速度是平均每天3.8个版本。

CLI封装了管理远程/云端工作区的所有能力，这让用户利用CLI来搭建自己的CloudIDE系统，实际上SmartIDE Sever 本身就是这样工作的，通过将 CLI 打包成 tekton流水线任务，SmartIDE Server 的所有工作区操作都不会直接调用虚拟机或者k8s集群，而是通过CLI来完成。借助CLI的快速迭代特性，我们的Sever开发人员可以更加专注于用户体验和企业级功能，而不用关心底层工作区调度问题。 对于希望构建企业内部CloudIDE平台的组织来说，利用CLI的这种可集成特性，可以非常快速底层本的完整平台的搭建，不用去关注与虚拟机以及k8s集群进行操作的细节问题。

我们当前已经提供了gitlab-ci的集成示例，未来我们会提供更多各种类型的DevOps系统场景。

Meetup内容

本次Meetup将详细演示以下操作：

• SmartIDE CLI 安装和基本操作
• 使用 start 指令在本地，远程主机和k8s集群上启动远程工作区
• 使用 host 指令将Linux主机注册为开发环境
• 使用 list/start/stop/remove 指令管理远程工作区生命周期
• 使用 new 指令从预制的开发环境模板启动新开发环境
• 使用 init 指令对现有代码库进行初始化，自动完成 IDE配置文件 的生成和适配
• 使用 login/logout/connect 为Server工作区提供端口转发支持
• 辅助功能指令 config/version/reset/debug
• 第三方系统集成：在 gitlab-ci 中集成smartide cli实现云原生IDE调度能力

报名方式

扫描海报中的二维码通过B站直播间预约

直播抽奖

• 一等奖1名：JetBrains全系列产品激活码（价值1500元）
• 二等奖2名：SmartIDE 文化衫

市值200亿美金的Slack：远程开发如何提高开发效率

Slack简介：Slack 是聊天群组 + 大规模工具集成 + 文件整合 + 统一搜索。截至2014年底，Slack 已经整合了电子邮件、短信、Google Drives、Twitter、Trello、Asana、GitHub 等 65 种工具和服务，可以把各种碎片化的企业沟通和协作集中到一起。2014年初拿到了4000多万美元融资之后又完成1.2亿美元的融资。其估值也达到了 11.2 亿美元，这家公司成立仅仅 8 个月，这也使得它成为了有史以来发展最快的SaaS公司。2019年6月20日晚，创业公司Slack正式登陆纽交所。2020年市值一度突破200亿美金。

作者：Michael Deng, 在Slack平台部们任软件工程师。他已经在Slack工作超过3年时间（截至本文发布的2020年），在这个过程中，他曾经参与了各种类型的项目，包括用户界面，API基础设施以及增长性实验项目。 原文地址：https://slack.engineering/development-environments-at-slack/

译者：徐磊，开源云原生SmartIDE创始人、LEANOSFT创始人/首席架构师/CEO，微软最有价值专家MVP/微软区域技术总监Regional Director，华为云最有价值专家。从事软件工程咨询服务超过15年时间，为超过200家不同类型的企业提供过软件研发效能相关的管理和技术咨询工作。

原文地址：https://slack.engineering/development-environments-at-slack/

在本文中，开发环境特指那些用于在发布软件之前进行测试的环境，这个环境与集成开发环境（IDE）比如大家常用的Eclipse或者微软的Visual Studio不同，不是同一个环境。

开发环境对我来说一直都是一个谜团。虽然在加入Slack的第一天就学习过这个环境，而且之后每天都在使用它，但我从来都没有把这个环境是如何工作的搞明白。

大概半年前，我决定把这个开发环境彻底搞明白。于是我访谈了几位Slack最资深的工程师，阅读了大量的文档以及好多年积累下来的slack聊天记录。最终我发现，Slack所使用的开发环境其实经历了一个令人惊叹的发展过程。

为什么我们需要开发环境？

开发环境实际上是一个完整的Slack系统的副本，而且是一个允许我们随意进行修改的副本。这个环境的核心作用就是允许开发者可以在不影响真实用户，不会造成数据损失的情况下测试我们的改动。 这个环境对于我们进行快速迭代非常重要，而且允许我们将改动发送给同事进行评审。 总而言之，开发环境的存在大幅提高了我们的开发速度和安全性。

##工作机制

Slack的开发环境实际上是运行在远程服务器上的完整Slack系统，我们使用AWS的EC2服务器来承载这些资源。这些开发环境实例运行着完整的Slack系统，包括非常多的服务以及这些服务所依赖的其他资源（比如中间件）。 每个开发环境都有自己独立的slack二级域名，我们可以直接访问这些域名就可以通过浏览器查看我们的改动。 在开发环境里面的改动不会对真实用户造成影响，因为我们使用了隔离的基础设置，比如：与生产环境独立的数据库。

图：开发环境和生产环境是完全独立的而且隔离的。

本地开发 vs. 远程开发

在Slack，我们使用远程开发模式，意味着我们的开发环境全部位于远程服务器上。当然，另外的选项是使用自己本地的个人电脑作为开发环境，本地电脑对于小型项目很适合，因为速度快而且不需要联网就可以工作。但是对于大型项目来说，远程开发模式提供了非常多的好处。

• 第一，我们不需要在本地部署整个Slack系统。Slack的系统架构非常复杂，有大量的服务以及依赖，无需在本地配置这样复杂的系统对于我们来意义重大。
• 第二，如果我们的改动在开发环境工作正常，那么基本上可以确保在生产环境也可以工作正常。因为我们的开发环境在配置上尽量与生产环境保持一致。当然，如果开发环境实例运行了很久，那么它和生产环境就会有比较多的差异，但即便如此，相比让开发者使用自己本地的个人电脑所带来的各种差异而言，仍然可靠的多。
• 第三，远程开发环境不依赖个人电脑，而个人电脑经常会崩溃或者卡顿。云端资源性价比更高，更加可靠而且容易扩展。特别是，云端资源允许我们使用多台服务器进行开发，而且还可以非常容易的将改动共享给其他人。

总之，随着网络越来越快和稳定，远程开发模式越来越有优势。

Slack内部的日常开发流程

说明我们Slack内部工作流程的最佳方式是给大家展示一个示例。比如：因为某种原因，我们决定修改Slack主页的文字为全部大写的紫色Comic Sans字体。

为了完成这个任务，我们首先会创建一个特性分支（feature branch），然后使用 slack sync-dev 工具将分支和开发环境进行绑定。这个工具会随机选择一个可用的开发环境，并开始将本地的修改同步到这个环境，后续我们在本地所进行的任何改动都将自动同步到这个环境。

这个工具的底层其实使用了2个大家熟悉的工具，fswatch（检测修改）以及 rsync （同步修改）。

图：将改动同步到开发环境。

如果我们修改了前端页面，那么我们会在本地使用webpack进行构建和打包，然后运行 slack run build:watch ，这个指令会构建我们的前端资源并允许给我们通过 localhost 访问开发环境。 当我们完成开发，我们就可以直接访问上图中出现的 dev575 二级域名，我们改动就出现在远程开发环境中了。

图：右侧的首页就是我们的成果，是不是更加吸引人？

现在，我们就可以进行各种测试，调试甚至直接共享给其他人进行评审。

记住，到现在位置，我们仍然在使用我们构建的前端资源，如果我们希望在关闭个人电脑后仍然可以访问这些改动，那么就需要在开发环境中生成一个静态构建。

改进我们的命令行工具

让我们简单说一说这个命令行工具。在上面的实例中我已经展示了它的部分工具，就是 slack sync-dev 指令。这个工具对我们非常重要，因为它让我们的开发工具变得更快而且更加简单。

在没有这个工具之前，我们必须要手工同步改动到开发环境，这个过程非常繁琐而且容易出错。现在，我们不再需要手工操作60种不同的命令行工具，而只需要这一个工具就可以完成所有操作。

除此之外，我们还有 slack bot-me 指令，可以在开发环境自动创建一个机器人用户；以及 slack tail-dev 指令，可以将远程环境的日志同步到本地。如果你对Slack的内部工具该兴趣，可以参考我们2016发表的博客：构建内部工具是一件快乐的工作。

开发环境扩容历程

在2014年，我们只有一个开发环境，所有人都使用这一个开发环境。如果有人把环境搞坏了，其他人都只能停工。在当时，这并不是太严重的问题，但是随着slack变得越来越庞大，我们增加了越来越多的环境。到2019年底的时候，slack内部在同时维护550个开发环境，基本上每一个slack开发者都有自己独立的开发环境。

但是，这个于是并没有继续下去，实际上在2020年这个趋势被彻底扭转。在具体解释这个变化之前，让我先来展示以下这个图表：单个虚拟机所承载的开发环境数量。

这个数字在持续下降的原因是我们希望隔离每一个开发环境实例。因为当多个环境共享同一个虚拟机资源的时候，任何一个开发者所运行的复杂操作都会影响其他开发者的正常工作。

这带来一个副作用 - 当我们减少每个虚拟机所承载的环境数量的时候，我们就必须使用更多的虚拟机，这意味着更多的费用。同时，因为这些环境都需要被管理和维护，随着环境示例数量的增长，维护这些环境也带来了大量的开销。更糟糕的是，环境实例运行的时间越久，就越不稳定而且会积累大量和生产环境的差异，变得不适合使用。

为了解决这些问题，我们构建了一个可以动态按需初始化开发环境的系统。这个系统让上图中疯狂增长的环境数量得到了有效的控制。我们不再同时运行几百个开发环境示例，而是在需要的时候动态初始化一个给到开发者。而当开发者完成测试以后，这个实例就会被自动销毁掉。这个系统让我们可以更加高效的管理我们的开发环境。我们将在后续的博客中详细说明我们是如何做到的。

设计精良的开发环境对于任何一个科技企业的成功至关重要。在Slack，我们的开发环境，我们的工具和基础设施正在向着全面自动化和可扩展的方向发展。

开放原子开源峰会 - SmartIDE正式开源并发布v1.0版本

开放原子开源基金会是致力于推动全球开源事业发展的非营利机构，于 2020 年 6 月在北京成立，由 阿里巴巴、百度、华为、浪潮、360、腾讯、招商银行 等多家龙头科技企业联合发起。本次开源峰会是开放原子的年度品牌活动、全球开源领域的高端峰会。包括 工信部副部长王江平、北京市副市长靳伟、中国科学院院士梅宏，Linux基金会执行董事Jim Zemlin，Eclipse基金会执行董事Mike Milinkovich 以及来自阿里，腾讯，蚂蚁，华为，中软国际，英特尔等来自国内外的重磅嘉宾参与了本次会议。SmartIDE在本次峰会的云原生论坛上展示了项目当前的进展以及下一代云原生CloudIDE的使用场景。

产品开源地址：

• https://github.com/SmartIDE
• https://gitee.com/SmartIDE

彻底解决软件开发环境标准化问题

如今，软件确实已经深入我们生活的方方面面，没有软件你甚至无法点餐，无法购物，无法交水电费；我们生活的每一个环节都已经被软件包裹。在这些软件的背后是云计算，大数据和人工智能等各种高新科技；这些现代IT基础设施在过去的几年得了非常显著的发展，我们每个人都是这些高科技成果的受益者 … … 但是，提供这些高科技成果的 开发者们自己所使用的软件（开发工具）却仍然像 “刀耕火种” 一般落后。

你可能会觉得这是危言耸听，那么让我来举一个简单的例子：大家一定都通过微信给自己的朋友发送过图片，这个过程非常简单，拿出手机，拍照，打开微信点击发送图片，完成。收到图片的朋友直接打开就可以看到你拍摄的照片了。但是对于开发者来说，如果要将一份代码发给另外一位开发者，那么对方可能要用几个小时甚至几天的时间才能看到这份代码运行的样子。 作为普通人，你无法理解这是为什么，如果你是一名开发者，你一定知道我在说什么！

上面漫画中的场景是不是很熟悉？开发环境的搭建对于开发者来说理所当然的是要占用大量时间和精力的，但是对于 “产品经理/领导/老板” 来说，开始写代码就应该像打开Word写个文档一样简单，只有开发者自己知道这其实很不简单。当然，这件事情确实应该更简单，只不过开发者整天 忙着让别人的生活变得简单，却忽视了自己就的生活正在变得越来越复杂。

解决以上问题的终极方案就是云端工作区，从IDE产品本身的发展历程来看，在经历了超过30年的三代产品的发展演进后，主流IDE厂商都在向着云端工作区的方向发展。SmartIDE正是在这个大背景下应运而生的下一代IDE云端工作区管理工具。

用云原生技术赋能开发者

我们的使命是 用云原生技术赋能开发者，我们定位于“开源云原生CloudIDE”，希望将云原生中各种先进技术针对开发者的工作场景进行优化，让开发者也能享受云原生带来的好处。同时，针对现有CloudIDE存在的种种弊端，SmartIDE也会从开发者的诉求出发予以优化，比如：当前的CloudIDE大多数采用WebIDE+容器的技术基础来搭建，但是WebIDE本身有很多局限会影响开发者的体验和工作效率，比如：快捷键、多窗口、操作延迟等；针对这个问题，SmartIDE提供了Hybrid模式，允许开发者使用本地IDE（VSCode或者JetBrains）连接到云端工作区进行操作，让开发者既可以享受云端开发的强大又不需要改变自己的操作习惯。

容器技术虽然对于应用运维来说提供了很多优化，但是因为容器技术从一开始就是为了生产环境而设计的，并不适合直接用于承载开发调试环境。为了能够为开发者提供适合作为开发调测环境的容器，SmartIDE特别研发了VMLC（类虚拟机容器）容器，给予开发者在容器内极大的自由度，同时又可以确保对主机环境的安全保障。

在本次峰会的云原生论坛上，SmartIDE现场演示了以上两个场景。我们也会继续践行我们的使命，设计和开发一款真正为开发者解决问题、消除痛点、提高效率的开发者乐于使用的CloudIDE产品。

从新定义IDE

如果把Vscode和JetBrain这些IDE称为传统IDE的话，他们最大的问题是：虽然在 I (Integration) 和 D (Development) 上面传统IDE都做的非常不错，但是他们都没有解决 E (Environment) 的问题。

SmartIDE是 第一个提供完整环境标准化能力 的新一代IDE产品，拓展了传统IDE的的边界，对IDE的概念从新定义并且专注打造围绕这一全新IDE概念的开发者生态系统。加入开放原子基金会是SmartIDE继续拓展新一代开发者生态的重要里一步，我们将继续围绕开发者的体验重新定位现有的研发工具链体系，为个人开发者和企业提供一体化研发环境标准化解决方案，补齐传统IDE的短板。

SmartIDE可以完成开发环境的一键搭建，如果你熟悉命令行操作，那么安装我们的cli，只需要学会一个命令 smartide start 就可以一键完成任何项目的开发调测环境搭建，不再需要安装任何工具，SDK，调试器，编译器，环境变量等繁琐的操作。如果不喜欢命令行操作，也可以使用我们的 Server 通过网页完成全部操作。

SmartIDE提供了三种运行形态，针对个人开发者以及企业研发面临的不同场景，提供了简单方便一站式的开发调试环境解决方案。彻底解决环境（E）的问题。

• 本地模式： 面向 个人开发者 提供完整闭环的容器化开发调试环境调度，开发者可以在Windows/MacOS/Linux三种操作系统上使用 smartide start 指令一键启动任何开发语言的项目代码，直接进入调试状态，不必安装任何SDK以及开发工具。

• 远程主机模式： 面向 专业开发者和团队 的远程容器化工作区（云端工作区）启动模式，开发者可以将任何linux主机转变为一台全功能的CloudIDE服务器，使用同样的 smartide start 指令就可以完成远程服务器的管理和维护。对于需要使用云端服务器的强大算力、高速网络以及超大规模存储的人工智能，大数据，微服务开发场景，可以极大简化开发者管理远程开发环境的复杂度。

• k8s模式： 对于 企业团队开发 场景而言，能够将开发环境集中管理并标准化可以大幅减少开发团队花费在环境管理上的精力，同时提升 开发环境的安全性，稳定性以及开发效率。大型企业中使用标准化开发框架是普遍的实践，但是如何简单高效的推广这些开发框架是是一件非常困难的的事情，使用SmartIDE的k8s模式可以很好的解决这些问题。当前企业中已经有大量的k8s集群在使用，但绝大多数仅被用于测试和生产环境的管理，开发调测的环境在很多企业处于无管理或者疏于管理的状态，这为企业级研发来了大量的安全和稳定性隐患。SmartIDE k8s模式是针对企业级开发调测环境管理而设计的完整解决方案，为以上痛点提供了体系化的解决方案。

SmartIDE v1.0 已经发布

SmartIDE v1.0版本（CLI Build v1.0.23.4650，Server Build v1.0.23.4646）已经发布，在发布了超过4000 Builds 之后，我们终于发布了v1.0版本。当前的版本已经完成了 企业级云原生CloudIDE的特性闭环，允许 个人/团队/企业用户 在 Windows/Mac/Linux 上使用 VSCode/JetBrains全家桶/OpenSumi 三种IDE开发7种技术栈下的任何项目，并且支持WebIDE，Hybrid混合模式以及WebTerminal 的三种工作区访问方式。

SmartIDE产品体系包含 CLI，Server，开发者容器与模版以及插件市场四大组件，构成了企业级CloudIDE的完整生态环境。四大组件全部开源，为企业构建自主可控的私有化CloudIDE提供了一站式的解决方案。

个人开发者和企业用户可以从以下地址获取相关安装包、脚本和说明文档，立即开始体验：

• CLI 工具
  • 安装 https://smartide.cn/zh/docs/install/cli/
  • 快读启动教程 https://smartide.cn/zh/docs/quickstart/cli/
• Server
  • 安装 https://smartide.cn/zh/docs/install/server/
  • 快速启动教程 https://smartide.cn/zh/docs/quickstart/server/
• 开发者镜像和模版
  • 使用说明 https://smartide.cn/zh/docs/templates/
  • 开发者镜像和模版指令列表 https://smartide.cn/zh/docs/templates/#镜像和模版指令列表
  • 模版使用说明 https://smartide.cn/zh/docs/templates/#模版库
• 插件市场
  • 安装 https://smartide.cn/zh/docs/install/marketplace/
  • 配置IDE使用SmartIDE插件市场 https://smartide.cn/zh/docs/manual/marketplace/config/
  • 配置自动插件同步机制 https://smartide.cn/zh/docs/manual/marketplace/extension-sync/
  • 将你的插件发布到SmartIDE插件市场 https://smartide.cn/zh/docs/manual/marketplace/publish-extension/
  • 插件安装手册 https://smartide.cn/zh/docs/manual/marketplace/usage/
  • 使用自签名证书进行插件市场私有化部署 https://smartide.cn/zh/docs/manual/marketplace/self-signed-certificate/

我们也提供了多种开发语言技术栈的快速启动文档，方便开发者使用

• Node/前端开发 https://smartide.cn/zh/docs/quickstart/node/
• Java https://smartide.cn/zh/docs/quickstart/java/
• DotNet https://smartide.cn/zh/docs/quickstart/dotnet/
• Python Jupyter Notebook https://smartide.cn/zh/docs/quickstart/jupyter/

• CLI： 是一个使用go语言开发的简单易用的命令行工具，可以在Windows/MacOS/Linux三种操作系统上运行，同时支持x86和arm两种cpu架构。覆盖了当前几乎所有主流的桌面，笔记本，服务器，边缘服务，IoT设备和移动操作系统环境。为SmartIDE提供了在任何平台上进行CloudIDE管理和调度的能力。其关键特性包括：

  • 一键创建容器化工作区
  • 本地、远程主机、k8s三种模式支持
  • 自动创建SSH安全隧道，避免开放远程主机端口
  • 使用环境模版一键创建预制的环境和代码框架
  • 工作区状态管理登录SmartIDE Server实现远程端口监听
  • Headless运行模式，支持流水线集成（比如：在GitLab CI中利用cli创建云端工作区环境）

• Server： 采用vue.js + go语言开发的 开源企业级CloudIDE管理平台，支持单机和高可用两种部署模式，可以在隔离的企业环境内部署，支持多集群管理。主要特性包括：
  • 资源集中管控，支持纳管多台Linux主机或者k8s集群
  • 端到端的代码安全，实现研发过程全程代码不落地
  • 工作区入口，聚合所有研发资源
  • 环境模版，一键创建标准化开发环境
  • 团队管理，自由组合开发人员，按团队分配资源
  • 工作区策略、统一管理开发人员“本地”环境配置
  • 环境共享和协同开发

• 开发者镜像&模板： 一整套完整的容器化环境镜像和可扩展的模板系统，支持7类主流开发语言并可以扩展到任何开发语言和框架的支持。主要特性包括：
  • 加速工作区加载
  • 三种主流IDE支持，VSCode, JetBrains全家桶和阿里OpenSumi
  • 多种工作区接入方式：包括WebIDE、Hybrid混动、WebTerminal和Web文件管理器以及SSH直连
  • Hybrid混动模式同时支持 VSCode Remote和 JetBrains Gateway 两种接入模式
  • Rootless安全保障，使用非root用户运行容器内进程，避免容器越权
  • 支持在容器内运行嵌套完整Docker和Kubernetes集群（VMLC，Rootless安全模式），完美支持云原生开发场景

• IDE插件市场： 现代IDE需要使用大量插件扩展自身能力，在企业内部提供统一受控的插件市场有助于企业对开发调测环境、代码安全以及应用架构进行有效管控。我们基于Eclipse OpenVSX扩展开发了SmartIDE Marketplace，支持在隔离私有网络进行本地化部署并提供插件同步机制。主要特性包括：
  • 插件自动同步，使用预制脚本自动同步插件（包括历史版本）
  • 支持多种类VSCode IDE，比如：VSCodium, Code-Server, OpenVSCode Server，Eclipse Theia，OpenSumi

产品进展

SmartIDE的开发工作采用敏捷（Scrum&Kanban）方式进行，2周一个Sprint并且采用了高度自动化的流水线完成代码的构建，自动化测试和发布工作。到今天为止，我们已经完成了 超过4000个版本的发布，CLI每周下载量超过1000次。

过去的6个月中，我们完成了超过 400个特性的开发和交付，CLI完成了698次构建，Server完成了701次构建。

当前我们已经有来自几十家企业的超过200名早期使用者

开源进展

SmartIDE采用 GitHub和Gitee双地址开源 方式，并且支持社区开发者使用任何一个开源平台与我们的产品团队进行协作。为了满足开源社区协作和产品商业化开发同步推进的诉求，我们设计了 SmartIDE开源工作体系，帮助产品团队和社区开发者统一认知，高效协作。

具体可以参考：开源工作体系

在GitHub和Gitee有非常多的小伙伴与我们互动，收获了超过 500个star和80个Fork。同时也被gitee评选为 2022最有价值开源项目。

当前，SmartIDE已经进入 开放原子基金会项目捐赠的TOC审核阶段，我们认同并相信 “软件定义世界，开源共筑未来” 的理念，希望借助开放原子基金会的力量，继续扩大我们的社区影响力，吸引更多的共建单位一起构建开发者生态。以IDE这一软件开发基础软件为切入点，为更多的开发者和企业赋能，在开源开发者工作模式、企业级研发效能和信创领域打造世界级的下一代IDE工具平台。

欢迎更多的开发者和企业加入SmartIDE的开发协作，让我们一起做一个自己喜欢的工具。

徐磊 2022.7.29日于北京

埃隆马斯克五步工作法

开挂20年

截至2022年7月，埃隆马斯克（Elon Musk）个人财富为 2214亿 美金，他同时还是多家公司的CEO和创始人，包括：特斯拉，SpaceX，SolarCity，The Boring Company, Neualink 以及 OpenAI。但是大家恐怕没有注意到在马斯克众多的CEO头衔的后面，他也是特斯拉和SpaceX两家公司的首席工程师（Chief Engineer）。作为全球首富，这个首席工程师的头衔恐怕是绝无仅有的。实际上，马斯克确实是一位非常专业以及敬业的工程师，而他自己也更愿意被称为一名工程师而不是CEO。

如果看一下马斯克过去的20年，那绝对是开挂一样。2002年将PayPal卖给了eBay公司，个人获利1.8亿美金，如果你纳闷为什么这个叫做PayPal的产品这么值钱，那么我只需要告诉你支付宝的原型是PayPal，淘宝的原型是eBay，你就可以理解1.8亿美金其实一点都不多。如果现在让马云把支付宝卖掉，那绝对不只是这个数字。马斯克将这1.8亿美金全部投入到三家公司中，分别是：SpaceX（1亿美金），特斯拉（7000万美金） ，SolarCity（1000万美金）。2008年，SpaceX拿下美国国家航天局（NASA）价值16亿美元的大单，负责为国际空间站（ISS）提供货运飞船服务以及后续的载人航天任务。2021年，特斯拉所生产的 Model 3 轿车成为人类历史上销量最好的全电动汽车，总销量超过100万辆；同年，根据福布斯杂志的数据，埃隆马斯克成为世界首富。2022年，SpaceX成功实现了人类历史上第一家实现载人航天任务的私人公司，并且将三位亿万富翁送上了国际空间站，每人的火箭票价为5500万美金。在SpaceX之前，只有三个国家有能力将人类送入太空，分别是：中国、美国和俄罗斯。

在同样的时间线上，我们还可以看到另外一个经历了无数失败的马斯克。在SpaceX获得NASA的16亿美金订单之前，SpaceX已经炸毁了3枚火箭，准确的说猎鹰1号的前三次发射全部失败，这三次失败的发射已经几乎烧光了马斯克投入到SpaceX的1亿美金。在这个时间点，没有人相信马斯克的SpaceX可以成功发射火箭，因为在他之前，发射火箭这件事情一直被认为是只有国家这样的实体才能完成的任务。庆幸的是，2008年，猎鹰1号的第四次发射任务终于成功，也因此才有了NASA的订单，SpaceX才活了下来。即便如此，后续的SpaceX发射任务也不顺利，猎鹰9号火箭的首级回收经历了多次失败，而且在2015年最大一次事故中，整个火箭空中爆炸，价值600万美金的火箭和飞船全部报废。这个过程中，特斯拉的发展也不顺利，2009年就因为质量问题召回了345辆已经售出的Roadster，后续又出现了多起特斯拉自动驾驶事故将这个公司推入风口浪尖。而最大的挑战莫过于2017年特斯拉宣布推出 Model 3 车型以后经历的 “量产地狱”。马斯克在这一年的大多数时间都一直睡在特斯拉工厂的沙发和地板上，每天和工人一起解决生产线上出现的各种问题。Model 3的生产其实几乎让特斯拉到达破产的边缘，最严重的时候特斯拉距离破产只有几周的时间。

马斯克的5步工作法也诞生于这段时期马斯克自己对于 “量产地狱” 的亲身体验和经验总结。

五步工作法

下面这段视频来自 平民宇航员（everyday astronaut） 于2021年8月4日发布在Youtube上的一段采访，在采访中 everyday astronaut 的主播和马斯克一起参观了星舰（starship - 马斯克用来建立火星基地的飞船）的制造和发射基地。在参观过程中，马斯克突然回忆起自己在构建 Model 3 生产系统过程中的种种惨痛经历，总结了五步工作法并明确表示他正在全公司强力推广。

五步工作法并不复杂

1. 验证你的需求： 所有的需求都是假设，既然是需求，就是仍未实现的事情，你如何证明一个还不存在事物的正确性？ 马斯克特别强调了，在收到需求的时候一定要质疑，特别是那些来自专家的需求，因为你会不假思索的被对方的专业性所麻痹。但是任何人的专业性都来自他已经完成的事情，这种专业性只能说明他过去是对的，无法保障对未知事物的准确预测。

2. 最少的流程： 对于一个组织来说，如果没有觉得流程不够用，就说明流程已经太多了。 组织中存在流程是一件好事，但是如果所有的事情都有流程，那么组织中的个体就失去了创新和探索的能力，因此流程用于那些已经验证过的问题，无法应对未知的场景。当一个组织用既定的方式去应对不相匹配的全新问题的时候只有2种结果，1）流程会失效无法推进；2）按照既定流程做出错误的决策并造成不可预料的结果。无论哪种情况，最终受到伤害的都是组织本身。出现类似问题的时候，需要组织中个体站出来创造性的解决问题，只有这样组织才能充分适应未知的情况。当然这还必须依赖组织中鼓励创新的激励措施，有关于这一点马斯克也在很多场合提到过自己公司中是如何激励创新的。

3. 简化和优化： 所有的管理理论都在提简化和优化，但是 简化和优化的前提是目标的正确性（第一步）和鼓励创新的组织文化。 否则要么方向错误，要么找不到简化和优化的余地。“这个事情没有办法，流程就是这样”，这样的说法大家一定都听到过，其实这就是组织缺少创新激励文化的体现。

4. 加速迭代： 注意我们需要 加速的是迭代，而不是速度。 迭代是一个循环，通过这个循环我们可以不停的验证当前推进的方向，并且持续的进行改进和优化。因此，五步工作法不是一个单向一次性的行为，而应该在最小可执行粒度上持续的循环推进。 也意味着，你需要持续的质疑需求，持续的优化流程，持续的探索加速这个循环。这个过程的最终状态是组织进入一个自我推动，自我加速的状态，形成持续的创新和响应异常情况的能力，其实就是我们常说的敏捷性（agility）。

5. 自动化： 自动化水平恐怕是很多行业展示自身能力的一个特别吸引眼球的地方，相信大家所看到的大多数介绍特斯拉工厂的视频中展示的也都是高度自动化流水线，机器人以及空无一人的厂房。实际上，按照马斯克自己说法，他一直都希望特斯拉工厂中能够有更多的工人而不是全部都由机器人来工作。自动化的弊端有3个，分别是 1）高昂的成本；2）极高的出错几率；3）妨碍引入新特性。 实际上，特斯拉工厂中的工人数量大大多于其他汽车生产厂家，这其实也是马斯克有意为之。 一来是因为特斯拉汽车几乎所有的零部件都是自己生产/非外包的，这让特斯拉的工厂承载了几乎普通汽车厂家的整个产业链上工人的数量。其次，机器人/流水线都只能在非常严苛的固定条件下才能顺利工作，一旦出现异常，整条流水线都必须停下来等待问题的解决。这让整个流水线变成一个严重前后依赖的单线程系统，而马斯克真正希望构建的是一个可以随时更换组件、流程、探索新特性的并行系统。

特斯拉如何像造软件一样造汽车

这里不得不说明一下特斯拉革命性的汽车生产流水线，和传统汽车厂的流水线相比较有非常大的不同。并不是说特斯拉的生产线使用了更多的自动化机器人，而是特斯拉的生产线可以随时引入新特性，新部件和新的生产工序；这个特性 非常像在互联网软件开发中所使用的灰度发布方式。 相对而言，传统车厂的流水线只能重复生产同样的型号汽车，不具备随时更换配件，工序以及引入新型号的能力。

为了做到这种高度灵活的生产流水线，特斯拉做到了3点传统车厂望尘莫及的事情：1）高度模块化的车辆设计；2）生产中测试的能力；3）灰度制造流水线。

1）高度模块化的车辆设计

首先，特斯拉的车辆设计是高度模块化的，每个模块之间用明确的接口定义（API）来进行对接，这种设计模式让特斯拉可以围绕车辆形成多个独立工作又可以相互协作的小型团队（Scrum团队）。

来源: Agile Hardware https://www.youtube.com/watch?v=_rySu6FZ18c (2021.3.30)

2）生产中测试的能力

其次，生产中测试的能力（Test in Production） 是特斯拉能够实现高度自动化流水线，同时允许引入新特性的重要前提。在以上模块的基础上，特斯拉开发了可以在生产线上执行并验证的大量自动化测试，这些测试不需要等到车辆下线以后再执行，而可以在车辆的装配过程中随时执行。这些大量的自动化测试所构建的Test in Production能力，让特斯拉可以放心的随意更换车辆组件，同时确保最终的产品质量。

有了模块化和自动化测试得保障，特斯拉可以放心大胆得实施自动化，并且可以随时引入新功能，新组件。

" Humans are for creative problem solving, automation is for EVERYTHING ELSE."

" 人的作用是创造性的解决问题，剩下的所有重复性工作交给 自动化。

3）灰度制造流水线

有了以上模组化的架构和在生产中测试的能力，特斯拉可以实现以下的 Agile NPI（新产品引入） 能力。这整个的过程非常像互联网公司的软件灰度发布过程，比如你会看到APP中所显示的商品价格和其他人不同，或者你能够尝试一些新的功能而其他人还看不到。类似这样的产品发布方式称之为灰度发布。特斯拉在的汽车（硬件）生产线上实现了类似的能力，这个过程简单来说有这样几个步骤：

• 在某个生产工序之前和之后各安装一个路由器，注意这个路由器上运送的是组装中的汽车
• 当特斯拉的某个组件团队（Scrum团队）需要尝试安装新组件的时候，会通过以上路由器从主线上提取一辆汽车作为实验品（fork a car - 类似于软件开发中拉代码分支的过程）
• 这个组件团队在这辆实验品汽车上安装新的零件，同时确保这个新安装的组件可以通过和主线一样的质量验证步骤；这里涉及两个重要的措施，DoR(Definition of Ready 就绪标准) 和 DoD(Definition of Done 完成标准)。就绪标准和完成标准，一前一后，利用前面提到的生产中测试的能力，确保进入工序和离开工序的试验品车辆的质量。
• 通过了质量验证的实验品车辆合并回到主线，于其他车辆一同下线并直接发送到最终用户手中

具备了 Agile NPI 能力的特斯拉生产线，每一辆下线的汽车都可以是不一样的。特斯来对于已经发售汽车的跟踪方式也和传统车企不同，传统车企一般会用年度型号来标识汽车的类型，比如：2021款，2022款，每一个款型的配置是一样的；但是特斯拉的每辆汽车都是被独立跟踪的，因为每辆汽车的零部件和程序可能都是不同的。下图中可以看到，特斯拉可以 每周推出多达27项 产品改进，而传统车厂需要 2.5-4年的时间才能推出一款新车。

简单粗暴的计算一下，特斯拉的创新速度是传统车企的 27 * 52 * 2.5 = 3510倍。

这其实就是为什么传统车厂会处于绝对的劣势，因为特斯拉已经将敏捷能力根治于生产系统中，采用的是和造软件类似的方式，而传统车企还在使用100年前福特T型车的古老生产方式。当然，构建这样的生产系统是一件非常复杂而且困难的事情。

马斯克自己说过：构建特斯拉生产线的难度高于设计特斯拉汽车100倍。

2017年的多数时间，马斯克都住在特斯拉的加州工厂中和工人一起改进这个生产线。以下这段视频中马斯克讲述了这个过程中的一个优化点，你无法想象从生产环节中删除一个小小的玻璃纤维垫竟然可以节省超过200万美元的生产制造成本。

敏捷思维方法

以上出现了很多大家可能并不熟悉的词汇，比如：Scrum, DoR, DoD等等。其实这些概念都来自于敏捷思维方法。实际上马斯克的五步工作法就是典型的敏捷思维体现，其中前3个步骤解决的是 做正确的事 的问题，后3个步骤解决的是 正确的做事 的问题，中间的第三步是衔接前后的关键，也是 形成组织敏捷性（agility）或者自驱力 的关键。

如果用最浅显的语言来解释敏捷，那就是：一切都在变化，不变应万变的唯一方式就是响应变化。

虽然敏捷思维来自西方（敏捷的准确定义来自 The Agile Mainfesto 敏捷宣言 )，但其实中国文化中一直都存在类似的说法和思维模式，比如：天下武功唯快不破，这里的快指的的就是敏捷。当然，这里的快所指的并不是速度快，而是反应快。这一点我相信看过武侠小说的小伙伴都能理解。真正的高手从来不会拘泥于某种招式，兵器或者套路，而是见招拆招，手中无剑胜似有剑。这其中的境界其实就是可以应对世间万物风云变化，我自岿然不动的唯一方式：敏捷。

黄金圈理论

黄金圈理论（The Golden Circle） 是管理大师西蒙斯涅克2010年在一段TED演讲中提出的，其核心思想是希望大家在关注事物的时候多关注背后的 WHY 而不要只看到外部的 WHAT。实际上马斯克的五步工作法也可以用黄金圈来进行解释，其中第一步就是在回答 WHY 的问题，为什么我们要这么做，这个需求到底是为了解决什么问题？然后，我们再来回答如何满足这个需求的问题（HOW），用最少的流程和持续的改进以最快的速度找到当前的最优解。方向正确以后再提出明确的任务（WHAT）并以最快的速度完成这些任务。

马斯克用五步工作法构建了 一种持续的WHY-HOW-WHAT的迭代循环，推动企业内部形成一种高效的创新文化。这其实就是为什么马斯克所创办的企业能够在这么短的时间内创造出这么多令人惊叹的成果的原因。

马斯克曾经在自己的Twitter上写过这样一段话：

“Pace of innovation is all that matters in the long run！”

我会把它翻译成

“长跑冠军的秘诀从来都不是速度、而是配速！”。

相信热爱跑步的小伙伴一定知道我在说什么。

徐磊

2022年7月8日 于北京

参考资料

• Insights of Agile at Tesla with Joe Justice
• How Elon Musk plans to occupy Mars, the agile way
• Joe Justice | The Secrets to Agility at Tesla | Elon’s Master Plan to Infinity
• Model 3 production hell
• Evidence that Musk is the Chief Engineer of SpaceX
• Tesla Model 3 Has Passed 1 Million Sales
• Model 3 Wikipedia Page
• The 5 Failures of Elon Musk and How He Overcame Them

【开源云原生大会】现场演示：k8s套娃开发调试dapr应用

k8s集群套娃（嵌套）是指在一个k8s的pod中运行另外一个k8s集群，这想法看上去很疯狂，其实这想法也非常实用。 试想，当你开发一个k8s应用的时候候一定会希望在自己的环境中先测试一下，这时你有几个选择：1）自己找服务器搭建一个完整的集群；2）在自己的本地开发机中搭建一个精简的集群，比如使用minikube或者docker desktop；3）直接在生产环境部署。无论哪种做法，你都需要面临很多难以解决的问题，自己搭建完整集群操作复杂而且还需要额外准备服务器资源，本地搭建集群对开发机要求高，没有个8核16G的高配笔记本是不可能的，更不要说minikube和docker desktop 只支持单一节点的阉割版集群，做简单的测试可以，如果要完成一些复杂的集群调度实验就会显得力不从心。最后，如果你打算直接在生产环境部署，那么需要足够的胆量并且随时做好怕路的准备。

其实，这是当前云原生开发的一个普遍困境，开发环境变得越来越复杂，以往我们只需要拿到源代码就可以开发调试的日子不再有了。k8s环境使用起来方便，但是对于开发者而言，要获取一个用户开发调试和测试，或者随便可以折腾的环境太困难了。今天要给大家介绍的k8s套娃就是为了应对这个困境的，让开发者可以实现 随用随启、用完即焚！

云原生IDE的优势和困境

云原生开发的最佳环境其实就是云原生环境本身，既然我们的应用会运行在容器中，那么我们为什么不直接到容器中开发；既然我们的应用会运行在K8s中，为什么我们不直接在k8s中进行开发？先不用关心如何实现，我们先来看看这样做会带来怎样一些好处：

• 适用于任何人、任何时间、任何地点的标准化环境：将开发环境放入容器意味着我们可以像管理容器一样管理开发环境，类似系统配置、开发语言SDK，IDE，测试工具，配置项等等都可以利用容器技术进行标准化；同时因为是容器，我们可以实现 Lift & Shift （拿起就走&插上就干活）的能力。你只需要对开发环境定义一次，就可以让任何人在任何地方复制出同样的环境。

• 彻底消除项目上手和切换成本：基于以上能力，我们将开发环境配置文件也放入当前项目的代码库，开发者只要拿到了代码就拿到了环境（因为环境配置文件和代码版本是统一管理，版本保持对齐）。这样开发者再也不用为了调试某份代码重新搭建环境，可以随时随地的切换到应用的任何版本上，甚至可以同时开发调试一个应用的不同版本。这其实就 IDE as Code 的概念体现，具体请参考 这篇博客。

• 端到端的代码安全：既然开发环境位于容器中，我们就可以将这个容器放置于一个完全受管控的云端环境中，项目的代码完全在这个容器中被处理，开发者不需要下载代码；所有的代码操作，包括：编写，编译，打包，测试和发布过程全部通过网页在云端完成。对于需要很高代码安全性保障的行业，比如：金融、军工、通讯和高科技企业来说；这个特性可以彻底解决代码安全问题。而且，使用云原生IDE还可以在保障代码安全同时允许企业放心的使用外包开发人员。在当全球疫情持续发展的情况下，远程开发基础设施变成了企业的必备能力，云原生IDE在这方面有天然的优势。

• 解锁云端超算力环境：很多大规模系统动辄需要几百个服务组件才能运行，要在本地完成这种环境搭建是完全不可能实现的，即便有专业运维团队的支持，在云端复制类似的环境也困难重重，这造成在很多大规模开发团队中，开发/调试/测试环境的获取变成了一个普遍的瓶颈。而利用云原生IDE所提供的IDE as Code能力，复制一个环境和启动一个普通的开发环境没有本质上的区别，开发者在代码库中随意选取一个代码版本一键完成整个环境的搭建变得非常简单。测试环境的获取能力是评估一个团队DevOps能力的通用标准，采用基于 IDE as Code 的之后，获取这项能力的门槛将被完全抹平。开发人员也因此可以完全解锁云端的超强算力，存储和高速网络环境，对于AI，大数据，区块链，Web3.0这些需要复杂环境支撑的开发场景，云原DE更加是一个必须品。

当然，云原生IDE也并不是没有缺点，使用容器作为开发环境本身就会遇到很多的问题。

容器化开发环境的困境和解决方案VMLC

容器化技术出现以后，绝大多数的使用场景都是生产环境，因此对容器的优化目标都是围绕精简，单一进程，不可变状态的目标来实现的；对于开发人员来说，按这种目标设计的容器并不适合作为开发环境来使用。相对于生产环境中已经预先确定的配置，开发环境的配置则需要进行持续的调整，在Inner Cycle中，每个环节（包含了编码，编译打包，部署，测试，修复）都会产生环境变更的诉求。

VMLC（类虚拟机容器） 是 VM Like Container 的缩写，其设计目标是为开发者在容器中提供类似虚拟机的环境，包括：systemd服务管理能力，sshd远程登录能力，docker/k8s嵌套能力等。

使用VMLC技术实现容器嵌套

SmartIDE 是完全基于 IDE as Code 理念设计和开发的一款 云原生IDE 产品，开发者既可以使用 SmartIDE CLI 在个人开发环境中一键拉起 云原生IDE 开发环境，也可以由企业管理员部署 SmartIDE Sever 统一管理。SmartIDE 支持跨平台,Windows / MacOS / Linux 均可以使用，开发者也可以选择自己习惯的 IDE工具，比如：VSCode, JetBrains全家桶 以及 国产开源的OpenSumi。 SmartIDE 通过 开发者镜像和模版 同时支持7种主流开发语言技术栈，包括：前端/Node/JavaScript, Java, DotNet/C#, Python/Anaconda, PHP, Golang, C/C++；如果这些内置的镜像和模版都无法满足开发者的需求，也可以通过定制的Dockerfile和模版定义来进行扩展，这些 Dockefile和模版 全部都采用GPL3.0开源协议免费提供给社区使用。

以下演示是在 2022年6月11日举办的 开源云原生开发者大会 上的展示的使用 SmartIDE VMLC开发者容器 完成一个 dapr 应用的开发调试场景：

以下是视频中演示的操作手册，感兴趣的小伙伴可以自己操作体验一下；示例采用 dapr-traffic-control 应用代码，代码库地址如下：

• https://github.com/SmartIDE/sample-dapr-traffic-control

所有操作脚本都可以在以上代码库中找到。

创建支持VMLC的AKS集群

使用以下脚本创建 Azure Kubernetes Service

如果没有安装 Azure CLI 命令行（az 指令）工具，可以通过这个地址安装 https://docs.microsoft.com/zh-cn/cli/azure/install-azure-cli

## 以下脚本可以在Windows/MacOS/Linux上运行

## 创建aks
## 登录并切换到你需要使用的订阅
az login 
az account set -s <订阅ID>

## 创建资源组，资源组可以方便你管理Azure种的资源，后续我们可以直接删除这个资源组就可以清理所有资源
az group create --name SmartIDE-DEMO-RG --location southeastasia
## 创建一个单节点的AKS集群，使用 Standard_B8ms 节点大小，可以根据需要修改脚本
az aks create -g SmartIDE-DEMO-RG -n SmartIDEAKS --location southeastasia --node-vm-size Standard_B8ms --node-count 1 --disable-rbac --generate-ssh-keys
## 获取链接密钥，密钥文件可以自动保存到当前用户的默认位置 ~/.kube/config 
## 获取后本地可以直接私用 kubectl 操作集群
az aks get-credentials -g SmartIDE-DEMO-RG -n SmartIDEAKS

完成以上操作后，我们就获取到了一个可用的AKS集群，整个操作不超过5分钟；下面使用k9s连接到集群进行状态监控，k9s是一个基于命令行的可视化k8s管理工具（Windows/MacOS/Linux都可以使用），非常方便而且轻量，安装地址如下：

• https://k9scli.io/

激活VMLC支持

VMLC容器需要底层容器运行时的支持，以下指令可以完成sysbox container runtime的安装

有关sysbox的详细信息可以参考 https://github.com/nestybox/sysbox

## 获取节点名称
kubectl get nodes
## 在节点上添加 sysbox-install=yes 的 label
kubectl label nodes <节点名称> sysbox-install=yes
## 安装 sysbox container runtime
### 国内安装地址
kubectl apply -f https://gitee.com/smartide/SmartIDE/raw/main/deployment/k8s/sysbox-install.yaml
### 国际安装地址
kubectl apply -f https://raw.githubusercontent.com/SmartIDE/SmartIDE/main/deployment/k8s/sysbox-install.yaml

执行后可以在k9s中实时查看安装进度，等待以下这个安装进程结束即可开始使用。

部署sysbox container runtime是集群级别的一次性操作，只需要管理员在创建集群的时候执行一次即可。

部署VMLC开发环境

所有VMLC开发环境均通过开发者镜像的方式提供，在 smartide-dapr-traffic-control 这个代码库已经放置了适配好的 VMLC开发环境部署 manifest 文件，文件内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: smartide-dev-container
  annotations:
    io.kubernetes.cri-o.userns-mode: "auto:size=65536"
spec:
  runtimeClassName: sysbox-runc
  containers:
  - name: smartide-dev-container
    image: registry.cn-hangzhou.aliyuncs.com/smartide/smartide-dotnet-v2-vmlc
    command: ["/sbin/init"]
  restartPolicy: Never

使用以下脚本即可获取源码并完成 VMLC开发环境部署

git clone https://github.com/SmartIDE/sample-dapr-traffic-control.git
cd sample-dapr-traffic-control
kubectl apply -f vmlc/smartide-vscode-v2-vmlc.yaml

执行以上操作以后，通过k9s查看名为 smartide-dev-containter 的 pod 的部署状态，部署状态为 running 即可开始使用了。

执行以下指令进入 smartide-dev-container 容器

kubectl exec -i -t -n default smartide-dev-container -c smartide-dev-container "--" sh -c "clear; (bash || ash || sh )"

现在我们就可以在这个运行在 k8s 集群 pod 的容器内进行操作了

## 切换到 smartide 用户
su smartide
## 切换到 smartide 的默认目录
cd
## 将 smartide-dapr-traffic-control 代码克隆到容器中
git clone https://github.com/SmartIDE/sample-dapr-traffic-control.git

在VMLC容器中内置一个叫做 smartide 的普通用户，这是一个非 root 用户，默认情况下VMLC容器全部通过这个用户进行操作，避免越权访问主机资源。 这个容器中已经内置了dotnet开发环境以及dapr cli工具，但是使用 terminal 操作确实不太方便。下面让我们切换到 VSCode WebIDE 进行后续的开发工作。

使用VSCode WebIDE访问VMLC开发环境

在SmartIDE所提供的VMLC开发者镜像中已经内置了 VSCode WebIDE，下面让我们将容器的3000端口映射到本地的6800端口，并通过浏览器访问我们的VMLC开发环境。

## 在你本地开发机的另外一个terminal中运行以下指令
## 注意不要使用以上已经进入 dev-container 容器的terminal
## 这个指令会将远程k8s pod中容器的3000端口映射到你本地的6800端口
kubectl port-forward smartide-dev-container 6800:3000

现在，你就可以打开 http://localhost:6800 端口并访问内置于 VMLC 容器中的 VSCode WebIDE 了，点击 Open Folder 按钮，并打开 /home/smartide/sample-dapr-traffic-control 作为我们的工作目录

点击 OK 之后，你就可以开始愉快的编码了，注意你现在使用的是 smartide 用户访问 smartide-dev-container 的开发环境

通过VMLC的开发者镜像，我们已经在这个环境中内置了 dotnet sdk， 以及 dapr cli, kubectl, helm，docker 等常用云原生开发工具。你可以按照 这篇博客 的操作完成这个dapr应用的 self-hosted 模式的开发调试。这个模式其实是将容器作为你的本地开发环境，并通过容器中的docker嵌套支持来提供 dapr所需要的中间件环境。

你会发现使用WebIDE进行类似的操作非常方便，这同时也意味着你已经脱离了你本地的开发机，可以在任何地点访问这个位于云端的开发环境。 当然，如果你不习惯在浏览器中操作IDE环境，也可以通过你本地的常用IDE来访问我们的远端 VMLC开发环境。

使用Hybird模式访问云端工作区

在 SmartIDE VMLC 开发环境中，除了内置 WebIDE 之外，也内置了 ssh 服务。也就是说，你现在可以像访问一台普通的云端虚拟机一样访问你的 VMLC 容器开发环境。 运行以下指令将 VMLC 的22端口映射到本地的 22002 端口上

kubectl port-forward smartide-dev-container 22002:22

现在你就可以打开本地的命令行通过标准的SSH协议访问这个 VMLC 开发环境了。

## 使用以下指令建立SSH连接，默认密码 smartide123.@IDE (这个密码可以通过后续的SmartIDE CLI或者Server进行重置）
ssh smartide@localhost -p 22002

当然，通过命令行的方式并不是每个开发者都习惯的方式，那么我们可以通过 VSCode 的 Remote SSH 插件或者 JetBrains Gateway 所提供的SSH通道连接方式，将你本地的VSCode或者JetBrains IDE连接到这个远程的 VMLC云端云端工作。这个就是 Hybird（混动）模式。

Hybird 模式兼顾了本地IDE和云端工作区双方的优势，让开发者在编码的过程中既可以享有本地工具的快速跟手的操作体验，又可以方便使用云端的超级算力。

VSCode Remote SSH 连接

在VSCode中连接云端工作区非常简单，你只需要在 SSH Remote 插件中点击添加连接，然后输入以上 SSH连接指令即可，这个过程与使用SSH连接一台远程主机完全一致。如果你看不到这个远程连接工具链，那么请从 这里安装 SSH Remote 插件 即可。

连接以后，设置工作区到 /home/smartide/sample-dapr-traffic-control 目录，即可看到如下界面。

JetBrains Gateway 连接

启动Gateway之后，选择 New Connection，并按我们的SSH指令填写信息，并点击 Check Connection and Continue 按钮

这时Gateway会要求你输入SSH登录密码，输入之后会进入以下IDE类型选择界面，根据需要选择你希望使用的IDE，因为dapr是一个基于dotnet 6.0的项目，我们在这里选择Rider作为我们的接入客户端IDE。

然后制定工作区目录为 /home/smartide/sample-dapr-traffic-control 目录，点击 Download and Start IDE。这时Gateway会自动在远程工作区启动 Rider IDE Server，并在本地启动 JetBrains Client，通过我们设定的SSH通道连接

启动完成的运行 JetBrains Client 如下

现在，我们已经完成本地IDE和远程工作区之间的Hybird模式连接。开发者可以根据自己的喜好和操作习惯选择使用WebIDE或者Hybird模式连接到基于VMLC的远程工作区。WebIDE的优点在于随时随地轻量编程，对本地开发机基本没有任何资源压力，即使使用一台ipad也可以完成开发工作；而Hybird模式的优势在于编码体验（特别在一些复杂的键盘操作和窗口布局控制上），特别是重度IDE用户会面对非常复杂的大规模项目，这种项目要完全运行在本地开发机是不可能的。

以下操作使用VSCode Remote SSH模式完成。

在容器中创建k8s集群

下面，让我们来将这个应用部署到 容器中嵌套的k8s集群 中。首先执行以下指令，使用kind创建一个多节点的k8s集群。

备注：Kind (Kuberentes in Docker) 是k8s开源项目下的一个sig，项目地址 https://kind.sigs.k8s.io/，希望了解KIND详细背景和使用方法的小伙伴可以自行参考

cd vmlc
kind create cluster \
    --config multi-node.yaml \
    --image registry.cn-hangzhou.aliyuncs.com/smartide/nestybox-kindestnode:v1.20.7

以上指令执行完毕后，我们可以在容器中运行k9s指令，实时查看容器内运行的集群状态，如下图可以看到2个节点已经处于Ready状态

编译打包并部署dapr应用到k8s集群

现在我们可以进入 src/k8s 目录执行 build-docker-images.ps1 脚本，这个脚本会完成所有应用的docker images的构建。

cd src/k8s
pwsh build-docker-images.ps1

现在我们来登录到 docker hub 并将打包好的 images 推送上去（这个步骤你在执行时可以跳过，所有镜像已经推送并设置为公开模式，可以直接拉取使用）。

docker login
pwsh push-docker-images.ps1

最后，我们使用以下脚本在k8s集群上部署dapr基础服务和示例应用的服务。

## 在默认的k8s集群中部署dapr基础服务
dapr init -k
## 部署 dapr-traffic-control 应用
pwsh start.ps1

下图：dapr基础服务启动中

下图：dapr-traffic-control 相关服务启动中

至此，我们就完成了k8s套娃旅程。如果我们不再需要这个环境，就可以通过以下指令一键清理掉这个 VMLC 环境，其中的所有内容也就从我们的集群上彻底清除了。

kubectl delete -f vmlc/smartide-vscode-v2-vmlc.yaml

这个过程中，大家应该可以明显体会到使用套娃方式运行K8s集群的好处，那就是简单轻量，节省资源。当然这个过程中容器的安全也是得到充分保障的，VMLC内部使用时非root账号，开发者在容器内无论进行怎样的操作都不会对所在集群的底层节点资源造成影响，是完全隔离的rootless环境。

使用SmartIDE一键启动VMLC环境

当然，以上操作过程中大家也会有另外一个直观感受，就是太复杂。完成类似的操作需要开发者对容器，k8s以及网络有充分的了解；这对普通开发者来说过于复杂。 SmartIDE的设计出发点就在这里，让开发者可以在 不学习/不了解 云原生技术的前提下享受云原生技术带来的好处。在刚刚结束的 SmartIDE Sprint19中，我们已经发布了 Server版私有部署手册，开发者可以使用一台linux主机就可以自行部署一套完整的SmartIDE Server环境，并用它来管理自己的云端工作区。

特别说明：SmartIDE Server的基础版功能是开源免费的，任何人和企业都可以免费获取并无限量使用。

使用SmartIDE Server云端工作区启动一个工作区就会变得非常简单，开发者复制Git仓库地址粘贴到如下界面，即可启动一个远程工作区；这个远程工作区可以运行在远程主机或者k8s环境中，对于很多开发者而言，K8s仍然是一个过于复杂的存在，但是几台云端的linux主机已经基本上是每个开发者的标配了。现在，你可以将这些Linux主机资源利用起来，使用 SmartIDE Server 将他们转换为高效的云端开发工作区。

下图：使用SmartIDE Server创建云端工作区

下图：运行在SmartIDE Server中的基于VMLC的远程工作区，正在部署dapr基础服务的状态

最后，希望每一名开发者都能寻找到云原生时代的原力；May the force with YOU!

社区早鸟计划

如果你对云原生开发环境感兴趣，请扫描以下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

让我们一起成为 Smart开发者，享受开发如此简单的乐趣。

为什么Dapr是比SpringCloud和Istio更优雅的微服务框架？

Dapr 是微软主导的云原生开源项目，2019年10月首次发布，到正式发布 V1.0 版本的不到一年的时间内，github star 数达到了 1.2万（现在已经超过1.7万星），超过同期的 kubernetes、istio、knative 等，发展势头迅猛，业界关注度非常高。

Dapr 这个词是是 「Distributed Application runtime」的首字母缩写，非常精炼的解释了 dapr 是什么：dapr 是一个为应用提供分布式能力的运行时。

Dapr官网 https://dapr.io

Dapr已经在多家大厂支撑生产环境

随着各家大厂的IT系统规模扩大，微服务架构已经成为了必需品和标准品，这也催生了 Dapr 这类非侵入式的（或者叫边车模式SideCar）的微服务开发框架的使用。根据Dapr官方仓库中的记录，已经有非常多的大厂在 生产环境 中使用Dapr来支撑自己的微服务开发。这里面不乏大家熟悉的腾讯，阿里，丁丁等国内大厂。

参考：

• https://github.com/dapr/dapr/issues/3169
• https://github.com/dapr/community/blob/master/ADOPTERS.md

Dapr比较SpringCloud或者Istio的优势在哪里？

这个可能是大多数人的第一个问题，简单总结几点供大家参考

• 全栈多语言支持：这一点上Dapr和Istio是等同的，因为都采用了边车模式，与应用进程之间没有有侵入性，相比SpringCloud这种只能支持Java语言（当然现在有很多其他语言提供SpringCloud的SDK）的侵入性框架，具备先天的跨语言优势。微服务化给开发人员带来的一个重要价值就是可以随意的选择不同开发语言框架进行组装，对于企业来说也可以避免被某一种技术框架绑定，甚至在招聘程序员的时候也可以有多的选择。因此当微服务的理念开始在业界流行以后，采用者的团队中必然出现多语言并存的状况。当你面对一个Java/.Net/Python/Node/JavaScript/Golang多语言并存并且相互依赖的应用环境的时候，就会发现SpringCloud无法这种需求，变成了微服务支撑框架的瓶颈。

• 多云/非云环境支持：这一点上Dapr和SpringCloud是等同的。SpringCloud作为云原生时代之前出现的框架，它本身的根基就在非云或者虚拟机环境上，因此SpringCloud本身就具备跨云/非云环境支撑，因为它本身和云环境并无绑定关系。你当然可以在容器/k8s中运行SpringCloud，但这仅仅是给SpringCloud应用换了一种打包部署方式而已。Istio 在这一点上有天然的弱势，因为Istio从一开始就诞生于云原生的基础设施k8s之上，也就顺其自然的利用了k8s所提供的很多基础能力，这些对于新生类应用来说非常合适，但是对于传统/现存应用来说就面临改造的问题。Dapr的设计则从根基上就兼容了多云/非容器和非云环境，同时也借鉴了云原生环境的特点来进行设计，因此你完全可以在传统的主机/虚拟机/非云环境中获得和云原生平台类似的微服务体验。这一点上对于已经有大量现存应用的传统企业来说，是非常重要的一个福音。×备注：Isitio也已经开始支持与虚拟机环境的集成，这一点大家可以自行查阅资料。

这个链接中介绍了阿里是如何引入 Dapr 以及背后的各种考量

• https://blog.dapr.io/posts/2021/03/19/how-alibaba-is-using-dapr/

简单来说，Dapr 从设计上就借鉴并考虑了之前的2种类似框架各自的优势，并将所有的好处融合进来，将弊端剔除掉；是当前最先进最有前途的分布式微服务开发框架。

搭建Dapr开发环境的痛点

以下视频是展示了在容器中使用 VSCode WebIDE 开发一个 Dapr 应用的整个过程

既然是一个面向微服务的开发框架，Dapr 环境本身可以变得非常复杂。因为要引入各种类型的中间件，很多开发者会发现搭建一个可以运行使用Dapr的环境，可能需要先安装一堆的各种服务。比如下面这个 Dapr 示例应用 Dapr-Traffice-Control

代码库

• https://github.com/SmartIDE/sample-dapr-traffic-control

虽然应用本身并不是特别复杂，只用到了3个服务组件，但是支撑这3个服务的中间件却有5个之多，包括：

• 作为 MQTT Broker 的 Mosquitto
• 常用的缓存中间件 Redis
• 消息队列 RabbitMQ
• 电子邮件发送中间件 SMTP 服务
• 密钥服务 Secrets

简单介绍一下这个示例的业务背景， dapr-traffice-control 模拟了一个常见的超速摄像头系统的实现，通过检测车辆通过道路上2个摄像头之间的耗时，计算车速，并发送罚单给司机。如下图：

这里用到的业务组件只有3个，分别是：

• TrafficControlService 是交通控制服务，也是主服务，其业务逻辑是根据公路上的2个固定位置摄像头反馈的数据，计算车辆通过摄像头的车速，以便判断是否存在超速行为。
• FineCollectionService 是罚单处理服务，根据 TrafficControlService 发送过来的车牌数据，查询车辆注册数据库（VehicleRegistrationService）获取联系人信息，并发送邮件
• VehicleRegistrationService 是车辆注册数据库，提供车辆信息查询，可以通过车牌号码获取车主信息，比如邮件地址。

这其实是微服务开发中一个非常普遍的问题：基础环境往往比应用本身还要复杂。这一点上和微服务的理念是相符的，微服务就是希望通过对不同业务组件的抽象尽量减少开发人员花在通用组件上的投入，而专注于业务本身。从这个角度来说， dapr-traffice-control 非常完美的诠释了这个理念；同时也非常直接的展示了这个困境。

从开发人员的角度来说，这带来的一个非常麻烦的问题：单体时代只要拿到代码就可以开始调试，现在的应用开发环境的搭建变得越来越复杂，开发人员需要了解的知识范围也被放大了。

实际上，以上这个问题在运维领域早就被完美解决了，方案其实就是容器和云原生技术本身。但是开发者作为云原生技术的使用者，自己没有从中获益，反而招来了更多的麻烦。

开发者不使用容器？

首先说明，这里所说的不是使用容器进行部署，而是使用容器进行开发。云原生的典型部署模式一定是容器化的，开发者在这个问题上并不纠结。开发者的现状是，虽然应用最终要在容器内运行，但是在开发的时候并不希望在容器内进行开发，主要原因是不方便，操作太繁琐以及对容器技术的不了解。这样带来的问题也非常显而易见，因为开发环境和生产环境不一致，就必须通过配置的方式，流水线自动化的方式来解决这些不一致的问题，造成整个发布系统变得更加复杂和难以维护。

要解决这个问题，我们必须降低容器的使用门槛，让开发者在 不了解/不学习 容器技术的前提下使用容器进行开发。SmartIDE就是为了解决这个问题而设计的，与繁琐的环境搭建脚本不同，SmartIDE 允许你使用一个简单的指令 smartide start 来启动 任何应用 的开发调试环境，而且这个环境从一开始就是容器化的。

对于上面这个 dapr-traffic-control 而言，启动命令如下

smartide start https://github.com/SmartIDE/sample-dapr-traffic-control

也就是说，开发者可以使用 smartide start 加上代码库地址来启动任何应用的开发调试；而且，如果开发者自己有一台可以运行Docker环境的云主机，那么就可以将这个 环境一键漫游 到这个主机上，整个过程只需要2个指令

## 添加主机到SmartIDE工具并获取 主机ID
smartide host add <Docker主机IP地址> --username <SSH登录用户名> --password < SSH登录用密码>
## 一键漫游环境到远程主机
smartide start --host <主机ID> https://github.com/SmartIDE/sample-dapr-traffic-control

完成以上操作后开发者就可以启动整个 dapr-traffic-control 的 环境进行开发调试了，效果如下

Dapr-traffic-control 开发调试过程

使用以上指令启动环境以后，开发者首先会获得一个类似VSCode的WebIDE界面，SmartIDE会自动启动浏览器并加载VSCode和应用代码，这时开发者可以打开内置的终端工具，使用 dapr init 初始化 Dapr开发环境。

这时，dapr 会启动3个docker容器，分别是 dapr: 1.7.4, zipkin 和 redis。默认情况下，dapr 会利用 docker 为开发者提供必要的中间件组件。要完成 dapr init 动作，开发者必须首先在本地安装 docker 环境，而在刚才的操作中，我们使用的是一个已经预装了 docker 的容器环境，也就是在容器内提供了 docker 的支持，这样开发者的环境完全处于容器内部，不再需要在开发机或者远程服务器上安装这些服务， 这种环境我们称之为 VM Like Container （VMLC），也就是类虚拟机容器环境，后续我们会专门针对VMLC进行更加详细的介绍。这种方式也同时保证了无论开发者在什么地方启动这个环境，都可以获得一致的体验。

现在，键入 docker ps 就可以看到这3个容器已经启动完毕

现在，我们通过一个预先准备好的 PowerShell 脚本来启动 Traffice-Control 应用的其他中间件环境，同样，这个过程中你也不必考虑 PowerShell 工具是否存在的问题，因为这些都已经通过标准化的 开发者镜像 提供了。你只需要在终端中执行

cd src/Infrastructure/
pwsh start-all.ps1

你会注意到我们实际上在容器内执行了一系列的 docker build 和 docker run 的动作，完成了另外3个中间件容器的启动，分别是：

• Maildev: 1.1.0 - 负责模拟电子邮件发送和接受的调试工具
• Rabbitmq: 3-management-alpine - 消息队列服务
• Mosquitto: 1.0 - MQTT Broker 服务

如果再次运行 docker ps，你可以看到现在我们已经有了6个容器运行在环境中，构成了当前应用的完整中间件环境。现在我们就可以依次启动3个业务组件，完成整个 traffic-control 应用的开发调试了。分别启动3个终端窗口，进入 src/TrafficControlService, src/VehicleRegistrationService, src/FineCollectionService，并运行启动指令

## 使用PowerShell脚本启动服务
pwsh start-selfhosted.ps1

最后，我们来启动模拟器。进入 src/VisualSimulation 目录并运行以下指令

dotnet run 

现在，我们可以开启另外2个浏览器窗口，分别打开

• http://localhost:5000 - 模拟器窗口，可以看到随机出现的汽车通过摄像头的场景，同时调用以上业务服务，模拟交通流量。
• http://localhost:4000 - 邮件模拟应用，可以持续收到邮件/超速罚单的过程

至此，我们完成了整个 dapr-traffic-control 示例应用的调试。在这个过程中，开发者不必了解背后的 Docker，远程SSH隧道，容器镜像环境的各种配置；而且，无论开发者在自己的本地开发机，还是远程主机，或是k8s集群中启动这个环境，都可以使用统一的 smartide start 指令来完成。

SmartIDE 的设计初衷就是希望能够最大程度的降低开发者上手一个应用的复杂度，无论这个应用是一个简单的hello-world，还是一个复杂的微服务应用；也无论应用所需要的环境只是简单的SDK，还是各种复杂中间件以及繁琐的网络配置，都只需要一个指令：smartide start

SmartIDE支持跨平台，全技术栈和多种IDE工具（VSCode/JetBrains全家通/OpenSumi)；对于独立开发者以及中小型企业用户是完全免费并且开源的。如果你希望马上尝试一下这种全新的应用开发方式，请参考以下链接：

• 官网 https://SmartIDE.cn
• B 站频道 https://space.bilibili.com/1001970523
• GitHub 开源地址 https://github.com/smartide
• Gitee 开源地址 https://gitee.com/smartide

社区早鸟计划

如果你对云原生开发环境感兴趣，请扫描以下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

让我们一起成为 Smart开发者，享受开发如此简单的乐趣。

README.exe

作为开发者，拿到一个新的代码库的时候一般都会先去看README文件，通过这个文件可以知道这套代码所需要安装的环境，工具和操作方式。这件事情本来应该是一件很愉悦的事情，因为每一套新代码其实都是开发者的新玩具，拿到新玩具的心情那肯定是不错的。但是，当你阅读玩具说明书之后，发现这份说明书完全不配套的时候，那心里一定是一万匹草泥马在奔腾。当然，这也很容易理解，开发者不爱写文档，特别是那些没有用的文档。至少，README对写的人来说其实没啥用，因为写的人都已经清楚了文档中的内容，至于看的人感受如何，那就呵呵吧。

这个问题的根源在于README只能看，不能运行！如果我们能够让README活起来，从 README.md 变成 README.exe，那是不是就可以解决这个问题了呢？答案是肯定的！因为写的人自己也可以用这份文档来启动项目。这样，写文档的人有了动力，看（运行）文档的人也会很爽。

这就是SmartIDE的核心功能: IDE as Code能力。

神奇的IDE配置文件

SmartIDE最初始的设计灵感就是如何能够让README活起来？为了做到这一点，我们设计了一个 IDE配置文件 (默认文件名 .ide.yaml）文件格式。这个文件中完整描述了运行当前代码所需要的环境配置，包括 基础环境SDK，应用服务器，应用端口，配置文件，网络依赖以及所使用的IDE工具。有了这个文件，开发者就可以真正实现一键启动开发调试，而不会再听到：“在我这里工作呀，是你的环境问题！” 这种骇人听闻的抱怨。

有了这个文件，任何人都可以使用一个简单的指令来一键搭建一模一样的开发环境，指令如下：

smartide start https://github.com/idcf-boat-house/boathouse-calculator

这个指令会自动识别代码库中的 IDE配置文件，根据文件中对开发环境的描述完成获取开发者镜像、启动开发容器、克隆代码、运行初始化脚本等一系列动作，最终一个 完整可运行的环境 呈现在开发者的面前，下面这段视频展示了整个运行过程：

IDE配置文件详解

以上示例中所使用的 .ide.yaml 文件如下

version: smartide/v0.3
orchestrator:
  type: docker-compose
  version: 3
workspace:
  dev-container: # 开发者容器设置
    service-name: boathouse-calculator
    
    ports: # 申明端口
      tools-webide-vscode: 6800
      tools-ssh: 6822
      apps-application: 3001
    
    ide-type: vscode  #sdk-only | vscode | opensumi | jb-projector
    volumes: # 本地配置映射，支持映射git-config和ssh密钥信息进入容器
      git-config: true
      ssh-key: true
    command: # 环境启动脚本
      - npm config set registry https://registry.npmmirror.com
      - npm install
  services:
    boathouse-calculator:
      image: registry.cn-hangzhou.aliyuncs.com/smartide/smartide-node-v2-vscode:all-version
      restart: always
      environment:
        ROOT_PASSWORD: root123
        LOCAL_USER_PASSWORD: root123       
      volumes:
      - .:/home/project
      ports:
        - 3001:3001
        - 6822:22
        - 6800:3000
      networks:
        - smartide-network

  networks:
    smartide-network:
      external: true

这个文件内容非常通俗易懂，是个程序员应该都能看明白，不过我还是简单说明一下：

• orchestrator - 环境调度工具设置，用来制定调度容器环境的底层工具，这里我们使用的是 docker-compose
• workspace - 工作区配置，工作区 是SmartIDE中最重要的概念，包含开发者用来进行开发调试的所有环境信息
  • dev-container - 开发者容器设置
    • service-name - 开发者容器所对应的 docker-compose 服务名称
    • ports - 开发者容器对外暴露的端口
    • ide-type - 开发者容器所所用的IDE类型，支持：vscode, sdk-only, jb-projector (Jetbrains系列全家桶）和 opensumi
    • volumes - 配置映射，支持将开发者的git-config和ssh密钥导入容器
    • commands - 开发环境启动脚本，对环境进行初始化；比如以上脚本中就完成了2个关键操作：1）设置npm国内镜像源 2）获取npm依赖。这部分脚本开发者可以根据自己代码库的情况设置，SmartIDE会在环境启动后自动运行这些脚本，让程序处于开发者所希望的状态上。
• services - 开发环境内的服务列表
  • 这里其实就是一段标准的 docker-compose 配置文件

IDE as Code 重新定义IDE

这种做法称为 IDE as Code 也就是 “集成开发环境即代码”，将你的开发环境配置变成一个 IDE配置文件 的配置文件放置在代码库中，然后根据这个配置文件生成对应的自动化脚本，完成“集成开发环境” 的创建。因此，SmartIDE中的IDE不仅仅是一个开发工具，而是 包含了环境的IDE。

IDE as Code 的做法源自DevOps的核心实践 Infrastructure as Code ，也就是 “基础设施即代码” 简称 IaC。其核心思想是将环境配置代码化，常见的k8s的yaml文件其实就是典型的基础设施即代码实现。在运维领域常用的工具比如chef/puppet/ansible，还有 HashiCorp 的 Terraform 也都是 IaC 的经典实现。IaC 的主要价值和目标就是将环境搭建过程标准化，让任何人在任何环境中都可以获得 一致、稳定、可靠 的环境搭建体验。SmartIDE所创造的 IDE配置文件 延续IaC了的使用场景，并将其基本思路应用到了开发测试环境中，这其实就是 SmartIDE 的产品核心能力。

基于 IDE as Code 的实现，SmartIDE在产品实现过程中一直秉承一个原则：能够让用户通过配置文件实现的东西，就不要通过代码实现。这个核心原则给予了SmartIDE非常强的灵活性，比如以下这段视频中所演示的 若依管理系统 项目

这个项目包括比较复杂的环境配置，包括：

• JDK 基础环境
• MAVEN 包管理工具
• MySQL 服务器
• Redis 服务器
• 可选：数据库管理工具 PHPMyAdmin

若依项目的官方文档用了整整2页的篇幅描述开发环境的搭建 (参考链接：环境部署 | RuoYi） 。使用了 SmartIDE 以后，开发者可以一个统一的指令 smartide start 来启动这个复杂的项目，不再需要去阅读这个文档。无论项目的代码是简单亦或复杂，smartide start 指令都可以进行适配，因为其背后的复杂配置已经全部通过 IDE配置文件 和代码保存在一起了。使用 IDE as Code 的另外一个好处是，由于配置和代码保存在一起，进行代码变更的开发者可以同步更新环境配置，并且一起提交进行评审，也就是说：你的环境也和代码一样是可评审，可审计的。

IDE文件配置就是README活文档。

当然，SmartIDE能做的绝不仅仅如此，我们已经发布了 SmartIDE Server 版，允许开发者在网页上即可完成开发环境的搭建和完整的开发调试过程。Server与CLI一样使用这个 IDE配置文件 来识别和搭建环境，与cli保持一致的体验。这一切的目的都是让开发者的日常工作变得简单，让开发者体验 #开发从未如此简单 的快乐。

如果你对云原生开发环境感兴趣，请扫描以下二维码加入我们的 SmartIDE社区早鸟计划

谢谢您对SmartIDE的关注，让我们一起成为云原生时代的 Smart开发者, 享受 开发从未如此简单 的快乐。

2022年5月10日