Serverless Devs
Replies: 4 comments 1 reply
-
|
Serverless Devs面向应用DevOps，Terraform面向云资源，是两个不同的context，没有可比性（Hashcorp面向应用的工具是WayPoint），但并不表示不能在某些层面有交集或者不能集成，集成和被集成能力本来就是开源工具是否标准化的一个衡量标准。拥抱Terraform没啥问题，连阿里云都在积极拥抱Terraform而且不咋发展自家ROS了。 Terraform解决的是云资源的Provioning，这个领域是有非常清晰的方法论的。而Serverless Devs更应该强调如何用好云资源，两者的关系可以用几个场景说明：
Serverless Devs自身不用和Terraform耦合，而是应该让Terraform的hcl很好的在Serverless Devs的组件生态里玩转起来，可以认为是Serverless Devs支持多语言的能力。对开发者的价值是可以比较低代码的完成基础设施的搭建，把精力投入到和Serverless应用生命周期管理相关的开发上，不然就得用sdk开发大量的云资源crud代码，这个是非常低效的。 之所以用户会对两者关系有些疑问，我觉得主要还是在通过Yaml不容易一眼看出Serverless Devs最硬核的能力，s.yaml声明了各个FC或者其他云资源的配置，然后在宣传上非常突出 s deploy，导致新用户很难快速get到工具真正的能力，所以会自然的联想到terraform apply。根本上还是产品本身抽象度表达的不太够，比如WayPoint用最突出的篇幅强调build->deploy->release，这个就是Hashcorp对其workflow的抽象，这种抽象在其各个产品上随处可见，这点是非常值得我们学习的。 后续Serverless Devs应该在文档以及pr上更多突出如何用workflow来快速建立起用户心智，这个是需要不断思考的。 |
Beta Was this translation helpful? Give feedback.
-
|
再多提一下Pulumi，Pulumi的设计思想也是很好的，也非常值得去使用。Pulumi帮开发者基于SDK来管理基础设施这个想法很好，但这类项目最终能成与否还是在于云厂商的支持程度，如果云产品的OpenApi都是标准的那就大概率能成功。如果使用AWS那用Pulumi是可以的，但是国内3家就很坑了。另外Pulumi这种GPL的模式其实对于开发者的模型抽象能力是有一定要求的，Serverless Devs的组件使用了Pulumi来管理云资源，这仅是一种实现方案，还上升不到Serverless Devs要不要拥抱Pulumi上（如果ROS好用，那Serverless Devs组件开发者当然就会选择），不过从结果上看用Pulumi是交了学费的。 |
Beta Was this translation helpful? Give feedback.
-
|
同意 anycodes 和 lowkeyrd 的说法，Serverless Devs 是 Serverless产品领域最好用的工作, 在具体的客户实践中，看到最多的是这样的场景：
|
Beta Was this translation helpful? Give feedback.
-
|
作为一个踩过坑的人来说， terraform 确实只适合做资源的部署，具体应用之间的关系建立还是要交给serverless 工具 |
Beta Was this translation helpful? Give feedback.
-
相信，能看到这篇文章的各位，都已经是知道或者使用过Terraform的了，作为目前云计算领域，非常优秀的基础架构管理工具，Terraform在某些层面上，已经逐渐的成为了一种实施标准，或者说是一种更为通用的规范。而Serverless Devs作为Serverless领域的开源开放的工具链体系，在随着时间发展的过程中，在一些人眼中，Serverless Devs与Terraform的关系变得扑朔迷离起来，尽管，作为向发起人的我以及团队的很多小伙伴，依旧保持清晰冷静的头脑，但是我们也不得不在这里来“蹭一蹭Terraform的热度”，一方面想要说清楚Serverless Devs与Terraform的关系，另一方面也想给那些存在疑惑的小伙伴们一个“交代”。
Serverless Devs 不是 Terraform，也不会朝着 Terraform 的方向去做
在诸多的质疑中，疑问最大的四个可能是：
在这四个灵魂拷问之前，我希望的是，可以做一个很明确的前提设定，这个非常重要：
在明确了上面三点之后，我将会针对上面四个问题，展开一个基础的说明。
首先，要明确的是， Serverless Devs 是 Serverless 应用全生命周期管理工具：
在全生命周期管理的过程中，部署阶段是不可获取的一环，所以Serverless Devs存在部署的能力，但是并不能说Serverless Devs存在部署的能力就和Terraform有冲突，在我的认知中，这里有三种可能：
这其中，第三点是我非常看重的一点，也是我觉得Terrform和Serverless Devs的重要结合点，所以我认为Serverless Devs的存在，是在给Terraform做加法，至于Serverless Devs的部署能力，完全是给用户在Onboarding的过程做加法，完全是为了降低部署难度，或者降低部分部署复杂度而存在的，就类似于，我们从工作地回老家，传统走路，骑马也是可以回去的，可能比较麻烦，但是有飞机，有高铁这些更为舒服，更为便捷的交通工具，用户也是可以选择的。单纯的走OpenAPI，用户相对难度比较大，但是用Terraform和Serverless Devs来部署，就做其他更便捷的交通工具的过程了，那么以阿里云函数计算为例，Serverless Devs在部署层面，较Terraform有哪些优势呢？
其实用户完全可以使用其他工具+Terraform来做这些事情，但是我更相信对于很多中长尾用户，甚至部分企业用户，在不需要一定使用Terraform的前提下，这种幸福感提升的小细节，可能会多一度感动，尤其对于Onboarding的用户而言，可能效果也会更好一些。所以，我们的目标，不是做“基础架构管理工具”，不是做第二个Terraform，我们要做的是一个提升用户幸福感的Serverless应用全生命周期管理工具，部署只是其中一环，这一点和Terraform完全不冲突。
关于资源编排的事情，我想说的是，Serverless Devs的资源编排能力取决于这套模型的天然优势，只能说是模型的一个特点，并不是Serverless Devs主打的，这就相当于你买了一个手机，一定要用手机的摄像头，和专业的相机去比效果，我觉得除了营销噱头之外，可能还真没啥价值，同样Serverless Devs的编排能力仅仅是模型架构带来的一个特点，并不是Serverless Devs主打的，仅仅是对这个“全生命周期管理工具的一个锦上添花而已”。
关于Serverless Devs有很多产品组件，这些产品组件是不是和Terraform有冲突？其实站在我的角度还真的没冲突，首先我以阿里云函数计算为例，说一说Serverless Devs目前需要支持的产品（包括真实的用户使用情况）：
粗略地评估，支持了上面强烈相关的5个产品，可以满足80%Serverless用户的需求，支持了上面的十个产品，可以满足90%Serverless用户的需求；而这些产品所支持的相关功能，还真不是Terraform能够搞定的，例如NAS产品，阿里云Serverless团队对NAS产品的支持（除了创建NAS之外），还支持把本地的文件上传到NAS，把NAS中的文件下载到本地，以及在NAS文件系统中执行一些命令（例如创建文件夹等），而这些操作，可以通过命令来直接实现（额外说一下，如果没有Serverless Devs，你想要单纯上传文件到NAS，你可能要有一台ECS），所以这就说明了一个问题，Terraform所支持的成百上千个产品业务，其实并不是Serverless Devs能覆盖的，也不是Serverless Devs需要覆盖了，或许很长很长一段时间，我们只需要支持好四五款产品的部分功能，就可以解决绝大部分用户的问题。所以，Serverless Devs在不断支持更多产品的时候，与Terraform并不冲突，因为Serverless Devs关注的是业务需求，而不是去做基础架构管理，Serverless Devs更多的是在封装上层的业务逻辑，而不是在做部署操作。
另外，值得一提的是，Serverless Devs是组件化的工具，任何人都可以根据自己的需求来做支持，而并不一定指望着官方来做（例如，我就已经看到了有部分的用户，在做属于自己的组件，来满足自身的需求，这其实也是Serverless Devs生态中重要的一环），再换句话来说，Serverless Devs不会无穷无尽的支持各种产品部署，只会支持相关的，且有限的功能，在上层做封装，做支持。
关于用户用着用着Serverless Devs想要突然换到Terraform的问题，Serverless Devs是足够灵活和自由的工具，用户可以自由选择和升级或者切换到其他工具，如果说想要两个工具并行，Serverless Devs也是支持编程式的模式，也是有IaC的一种能力或者说是一种支持，所以在一段代码或者脚本中，同时使用两个工具，在我看来，并不是一个困难的事情。
再多墨迹一句，Serverless Devs是Serverless应用全生命周期管理工具，部署只是其中一环，这一环尽管因为Terraform也能部署，而被一些人认为是有冲突，但是两者的目标并不一致，因为Serverless Devs做的部署是为了更简单，更方便，难度更低，更容易做Onboarding，就像汽车和汽车之间，大奔和比亚迪F0都是汽车，但是绝对没有冲突，尽管二者都在给用户提供汽车所具备的能力，但是二者却有着不同的目标。
综上所述：
Terraform已经做了这些功能，Serverless Devs要怎么做
众所周知，Terraform已经支持了多云多产品的部署等相关的能力，即便在上文已经表达了Serverless Devs作为Serverless应用全生命周期管理工具，有做一些部署能力的必要，但是仍然会被很多人Diss和挑战：
在对上面问题进行讨论之前，我同样希望可以明确几个前提：
针对Terraform已经做了部署，Serverless Devs是否还需要做部署这件事情，其实在上文中已经完成了一波的探索，其Serverless Devs在Serverless领域来做部署，其实并不是做基础资源管理，而是希望让用户的业务逻辑快速的在云上跑起来。所以，你会发现，当你用Serverless Devs进行项目构建之后，在部署环节，是会存在已经关联的提醒，例如问用户已经完成了构建，是否要把构建的产物上传，并增加对应的环境变量，以确保安装的依赖及时生效。这不是基础资源管理，这是业务逻辑帮助开发者提升幸福指数。所以可以这样认为，Terraform的目标和Serverless Devs是不同的，所以功能表现，用户使用的感觉，以及最终的应用场景也是不同的，如果你要说你要编排数十个云产品，那么你来用Serverless Devs，你要用ECS你来用Serverless Devs，你要用ACK你来用Serverless Devs，其实我也不能说你要用，但是你可能也不是很容易能用的起来或者用得爽，因为这不是Serverless Devs的目标，也不是Serverless Dev是要做的事情，就像前文所说，同样是汽车，同样可以上路，几百万的汽车和几万的汽车，也许基础功能都类似，但应该不冲突，也应该不具备竞争性，毕竟二者的目标不同，给用户的呈现也不同，对用户的感觉也不同，目标用户群体也是不同的。
Serverless Devs在生态上，本着合适的轮子要积极用，不合适的轮子也不要强行配，所以像JSON Scheme这样的规范内容，这就是合适的鞋子，Serverless Devs就在更为积极的拥抱。而关于Serverless Devs和Terraform的结合点，站在我的角度，就是加法。我相信，做好加法，才是一种平稳而又和谐的态度。
至于有人说Serverless Devs的部署等功能，是否可以用Terraform来做，其实没问题的，但是站在我的角度，极度不推荐，因为如果以产品角度，接口角度做集成，那么你所要做的工作，以及后期的维护成本，或许会比你单纯的使用API高的很多；如果你要以一种更为上层或者抽象的能力做集成，包掉Terraform，那么为什么不直接用Terraform？或者Pulumi也是一个不错的选择。甚至有人曾提过，是不是可以给我一个Terraform的编排文件，用s deploy就可以部署，那么问题来了，你都有了这个文件为啥不用Terraform工具？所以Serverless Devs和Terraform的最大结合点，在我眼里，就是做好加法。例如，我是一个Terraform用户，我开发完了应用，要部署，是不是可以用Serverless Devs做构建，做测试，做调试？
总结
Serverless Devs工具，从建立之初，就不断的在被要求和其他产品找好边界，也在不断的“被对比的过程”。
例如，有人一直在挑战，Serverless Devs和Serverless Framework有啥差异点；Serverless Devs和ROS有啥差异点；Serverless Devs和Terraform有啥差异点；Serverless Devs和Pulumi有啥差异点？甚至还有人问过我Serverless Devs和控制台有啥差异点，为啥不直接用控制台？
其实站在我的角度，Serverless Devs没有创造任何东西，都是在已有的内容上，做了一些完善，从一些细节不断的提升用户的使用幸福度。所以，就算没有Serverless Devs，大家也可以用很多的功能，只不过这些功能能不能更为简单轻松的用起来。就像今天和老板聊天的时候，提到的Serverless Devs和Terraform在部署层面的一些区别，我说尽管都是部署，但是两者部署的操作从目标，行为，到最后的结果，其实都是不同的。例如Serverless Devs帮助用户做Zip操作，帮助用户做Ignore操作，帮助用户做Upload操作，帮助用户做Add Env操作，甚者帮助用户绑定测试域名操作，而这些Terraform理论都不会去做，那么Terraform的用户能不能做？答案一定是肯定的，写一个脚本啥都可以做了，但是我们真的需要让所有有类似的需求的用户来写这些脚本么？这些脚本真的都是所有用户可以接受的么？我们做工具的目标是什么？更简单，更方便，更快速，这就是Serverless Devs的加一个价值；从Serverless应用全生命周期发挥作用，就是Serverless Devs的价值和目标。
Beta Was this translation helpful? Give feedback.
All reactions