根据在挪威所做的研究，当被问及创新的最大障碍是什么时，59%的技术领导回答了“技术债”。我对此的解决办法是，你可以“外包”技术债。
根据在挪威所做的研究，技术债是创新的最大障碍。今天，我们知道如何避免技术债，至少在新项目中如此。但这并不意味着我们不会在新的项目中积累技术债，因为人类的本性就是一次又一次地重复同样的错误。但至少在理论上，我们知道如何避免技术债，而且秘诀其实很简单。
永远不要重新发明轮子，而是尽可能使用已有的构建块；
使用微服务来降低最终结果的耦合；
尽可能地自动化；
尽可能地外包。
如果你遵循以上 4 条简单的指导原则，技术债不会发生，至少原理上不会。这是因为你所做的基本上是“外包”你的技术债——要么是外包给“机器”（自动化），要么是外包给开源库（组件），要么是外包给第三方供应商（组件和外包服务）。我碰巧经营过这样一家公司，其唯一目标是通过“承包你的公司的技术债”来收取费用。其理念是，这为其他人带来了价值，释放了内部资源，使他们能够自由地创新，而不会受到内部技术债的阻碍。
通过外部化技术债，技术债没有消失，只是简单地转移到第三方——因此在这个过程中不会违背自然法则。事实上，在整个计算历史上，我们已经见过数百次这种情况。例如，如果你是一家成熟的公司，你可能会使用 Microsoft Teams 或类似的东西来组织你的团队。在这种情况下，创建你自己的替代选项是疯狂的。即使你将 10 位最优秀的开发人员投入到这项工作中数月，也不会接近 Microsoft Teams 提供给你的开箱即用的现有解决方案的质量。
适用于产品的也适用于微服务
然而，很少有人意识到，适用于 Microsoft Teams 这样的产品的，也适用于微服务。如今，我们可以用现有的组件组装产品，作为微服务松散地绑定在一起，进行一些布线，在这些组件之上添加一些我们自己的业务逻辑，我们就得到了一个独特的应用程序——就像你从预先存在的产品中构建一家独特的公司一样。以上基本概括了我的公司的价值主张。
上述结果表明，你不需要再维护自己公司的聊天客户端，因为你可以购买一个现有的微服务。对于你外包给开源项目或第三方供应商（例如我们）的每一个组件，你都可以减少内部的技术债。当你将技术债的很大一部分外部化之后，你就可以更自由地创新。
一个无代码微服务应用商店
我们最近刚刚发布了一个产品“The Bazar”。Bazar 基本上是一个微服务应用商店，完全集成到我们的旗舰产品 Magic Cloud——100%开源且免费使用。点击下面的链接去下载并试一试吧。
然而，从最新版本开始，我们现在对微服务模块收取费用。这意味着我们有提供优质产品的财务激励，这证明我们有理由花时间改进上述产品。与开发这些组件所需的内部资源相比，费用相当低。例如，你可以让你自己的一位开发人员花几个月的时间来是实现一个糟糕的企业聊天客户端微服务模块。在 Bazar 中，你可以用从头创建的相关成本的一小部分来购买一个。而且我们打算尽可能灵活地管理我们的 Bazar。
众包敏捷无代码微服务
对于我将要解释的内容，实际上还没有现成的词汇可以很好地描述，但我们打算将我们的微服务应用商店作为一个“敏捷项目”来运行。我们的意思是，如果你对某个微服务模块不满意，你可以在一定程度上提出改进建议。因此，我们目前的微服务都不是“一成不变的”，而是半生不熟的，这实际上对你有利——因为你可以影响其未来的功能图。
我们的想法是，大多数功能让你高兴，也让其他人高兴，从而使你能够与其他公司分担开发成本。由于由你和你的公司建议的大部分功能，都是其他人可能会满意的功能——这导致了“客户驱动的微服务 Bazar”，在这里，功能几乎都是通过达尔文进化论的过程实现。我们目前只有 3 个这样的微服务。
Babel，一个聊天客户端微服务
Babel Mail，一个邮件发送微服务
Babel Fish，一个翻译微服务
所有这些都处于“beta 状态”，如果你遵循了我上面的观点，应该很容易理解这对你有利！
因此，我们正在寻找一些勇敢的开发者和/或公司，他们愿意尝试这种全新的软件创建模式，可以说你的大部分技术债都外包给了我们。简单来说，因为我们知道，如果我们能够取悦你，我们就能取悦 80%有类似需求的公司。那么，请到ServerGardens.Com，我们来聊一聊吧 :)
如果你可以将技术债外包给我们，则无需积累技术债
以上总结了我们的价值主张。使你能够将时间花在最新的认知深度学习库和组件上，以及所有真正有趣的事情上——而我们则将所有枯燥的东西做成开箱即用的微服务提供给你... ;)
作者介绍
Thomas Hansen Traders Trust 的开发负责人，痴迷于自动化到想要电脑自动写代码。
原文链接
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论