DOP 285: Navigating the Challenges of Legacy Software in Modern Enterprises
45:49 Share

#285: 在快节奏的技术世界中，组织机构常常发现自己身处一个复杂的境地：一方面要拥抱最新的技术进步，另一方面又要处理几十年历史的旧基础设施。这种微妙的平衡在当今企业中尤为突出，因为它们试图将遗留系统与微服务等现代解决方案集成。技术和组织方面的挑战都提出了关于软件开发和商业战略未来的一些关键问题。在本期节目中，我们与《自信承包商》(Confident Contractor)一书的作者尼尔·米拉德(Neil Millard)进行了交谈，探讨了企业如何每18-24个月就经历一波咨询顾问的循环，这扰乱了管理这些复杂系统的连续性和专业知识。 尼尔的联系方式： X（前身为Twitter）：https://x.com/neil_millard 领英：https://www.linkedin.com/in/neilmillard/ YouTube频道：https://youtube.com/devopsparadox 在Apple Podcasts上评价播客：https://www.devopsparadox.com/review-podcast/ Slack：https://www.devopsparadox.com/slack/ 联系我们：https://www.devopsparadox.com/contact/</context> <raw_text>0 但我们作为开发者自己也知道，这段旅程永无止境。无论软件写得多么好，总需要进行维护。这是DevOps Paradox播客，第285集。探讨现代企业中遗留软件的挑战。欢迎收听DevOps Paradox播客。这是一个关于各种随机话题的播客，在其中，达伦和维克多假装自己知道自己在说什么。

大多数时候，我们会通过在任何可以放的地方都加上“DevOps”这个词来掩盖我们的无知，并将其与Kubernetes、无服务器、CICD、团队生产力、快乐岛屿以及其他让我们听起来像知道自己在做什么的花哨表达之类的随机流行语混合在一起。偶尔，我们会邀请一些确实懂行的人做客，但我们不会经常这样做，因为他们可能会让我们显得无能。

真相就在那里，我们不可能找到它。附言：这是达伦在读这段文字，并为维克多让我这样做而感到尴尬。以下是您的主持人，达伦·波尔克和维克多·法森。维克多，你有多久没有使用过真正古老的企业遗留软件了？

直接来说，已经很久很久了。现在，我合作的公司或多或少都会有一些遗留系统，但幸运的是，我没有直接参与其中。我过去听到的一件事是，有时当你试图将新技术添加到旧技术上时，可能会很有挑战性。也许甚至不是新技术到旧技术，而是中等技术到旧技术。在今天的节目中，我们邀请了尼尔·米拉德。尼尔，你好吗？你好，谢谢邀请我。

所以我们有Nulon。我们讨论了我们要讨论的内容。他说他有一个客户试图做那种阶梯式方法，拿出一段中等年代的旧软件，并试图将其与一段非常古老的软件结合使用。这个故事听起来对吗？是的，听起来差不多。他们试图让这两段软件一起工作。而且它们都是非常不同的时代写的。

而且几乎没有交叉点可以一起工作。试图让一个与另一个对话是可以的，但这感觉非常笨拙，就像推着一块巨石上山一样。我一直对这些情况以及我对这些情况的解读很着迷，当然不是针对这个具体案例，对吧？我的意思是，我们有一些东西被我们放弃了，因此它很旧。否则，如果我们没有放弃，我们会随着时间的推移继续使用它并对其进行改进等等。所以它是被遗弃的，就像被遗弃的房子一样，对吧？是的。

然后很多年后，我们说，我们不希望它被遗弃。我们想把它和一些东西连接起来等等。对我来说，这总是很有趣的。我总是有一堆问题，比如，

你为什么一开始要放弃它？我认为那是一座没有人居住的房子，但实际上你确实住在里面。但你选择不修理管道，对吧？不修理电线和所有这些东西，也不从屋顶上移除洞。但你确实住在那里，对吧？而且你确实想做些什么，但你选择不去忽视它，对吧？我认为这是可能的，尤其对我来说。我知道我过去……

从技术的角度来看，就像，看，这个东西已经在这里放了多年了，我们就是不能把它拆掉，因为它是一个赚钱的东西，或者它是我们赚钱的关键部分。所以我们会继续把它变成弗兰肯斯坦的怪物。但这最终是一个悲伤的故事，对吧，尼尔？是的，绝对的。你可以继续把东西添加到旧的遗留系统上。

但最终，我想我们几乎是在谈论技术债务，对吧？你有一段代码可以完美地完成某些事情，但由于新员工、员工流动、所有这些事情，它几乎被视为一个黑盒。没有人想碰它。是的，它很好。你只需要把它放在那里或继续让它运行。但最终会发生一些事情。

这意味着你必须打开那个盒子。你必须查看内部。你必须了解它的实际工作原理，以便最终用更合适的替代品替换它，更现代化，能够跟上那些安全修复，并确保它与其余系统协同工作。因为虽然它是一个小黑盒，但它对企业来说是一个巨大的未知数，一个巨大的风险。

就像你刚才提到的，如果它是一个赚钱的东西，而且它突然停止了，那将是一个非常非常大的商业风险。但我们真的关心商业风险吗？也许在这个房间里我们不太关心，但作为一个承包商，我喜欢我的发票得到支付。所以我认为保持业务健康，金鹅等等，很重要。

这很重要，但这可能很难推销。当然，如果企业需要投入大量资金来修复这个还没有坏但可能会坏的东西，这确实很难向企业推销。我认为潜在的问题在于，我觉得

五年或十年不碰它之后再修复它实际上比保持它更新要昂贵得多。就像你提到的安全风险一样，对吧？任何一个月或更短时间内未更新的库……

都是安全风险，对吧？因为发现了新的漏洞，对吧？而且我认为，当我们谈论的是一个黑盒时，我们谈论的是库以及其中可能多年未更改的内容，要么该公司或实体不知道安全是如何工作的，要么他们正在忽略安全，直到发生某些事情，对吧？是的。通常，如果很安静，没有人会注意到它。

就像大多数引起你注意的事情一样，它们必须大声或引人注目，然后你才会注意到它们的存在。确实，就安全而言，是的，如果某些东西很安静，而且很久没有被触碰过，我的意思是，我们在今年或过去12个月里听说过多少个漏洞？

其中实际漏洞已经存在了10年、15年甚至20年，而它才刚刚被发现。是的，然后你就会处于一种你可能甚至无法用修复该漏洞的补丁来更新该库的境地，因为你落后了10年。它不可能向后兼容。这个更新不可能不会破坏某些东西，对吧？

是的，我的意思是，我有一些项目，我可能已经两个月没有构建它了，突然之间所有依赖项都过时了，而且那个东西根本无法构建。所以，是的，如果你说的是几年而不是几周，那么你就会处于一种为了修复一件事情，你几乎必须重建整栋房子，用你的比喻来说。那么，什么时候重写比更新被忽视的东西更有效呢？哎呀，这是一个很难回答的问题。

戴着我的顾问帽，我可以说这取决于具体情况。我的意思是，我们已经说过，运行它的成本通常较低，但替换它的成本将非常高。它能否再次带来商业价值？它有多重要？这有点像我们是否应该自动化某些事情的争论。每件事都有流程，但如果你一年只接触一次该流程，那么如果你一年只运行一次，就不值得花两天时间去自动化该流程。

所以完全替换某些东西是一项相当大的工作。除非，当然，你可以从现成的软件包中获得帮助，或者有很多库可以减少开发时间。所以它真的真的取决于项目的具体情况。因为那将是一个艰难的局面，对吧？重写，它不是一个经济上可行的选择吗？保持现状，

不是一个选择，因为需求，比如说，那是10年前的。10年前，我们的需求是需要100个并发请求。现在我们的需求是需要10,000个并发请求。我们无法应用任何修复来使该事物正常运行。所以基本上它处于一种困境，对吧？它不能做它需要做的事情。它不安全。重写不是一个选择。调整它也不是一个选择。那么公司还有什么办法呢？我想……

尝试使该组件过时。这将是一种重写，对吧？是的，这是一种重写，但它是一种有目的的重写。所以我可以想到我们参与的另一个项目。有一个小库，它接收一堆YAML文件

并输出更多YAML，因为当然它会这样做。它的主要目的是输入的YAML都是加密的，而输出的YAML都是解密的，并且可供应用程序使用。这个库非常被视为一个黑盒。因此，当团队在依赖这个库的其主要产品中构建更多功能时，

该库的不同方面只是被一次性地提取并替换。所以这是一个重写，但它并不是一个作为项目的重写。当我们接触使用该组件的代码库时，我们只是将东西移过去并在很长一段时间内重写它。几乎消失在日常业务成本中。

你说的那段代码，就是加密解密内容的代码，对吧？是的。这也很奇怪，对吧？我不知道是否是这样，但总的来说，对吧？公司编写了一些执行某些操作的代码，它编写了执行某些操作的代码，因为没有项目能够完成相同的函数，对吧？

但与此同时，就像现在一样，我们有数十种工具，例如外部密钥操作符、SOP、密封密钥等等，对吧？数十种执行这些操作的工具。当公司甚至应该切换并说，好吧，实际上对我来说，将其作为我自己的代码没有意义时，它们该如何做？所以如果你正在更新上游，即主程序，那么切换是有意义的。

这是你可以重新评估它的机会。让我们想象一下——这段代码创建配置。因此，如果你正在更改部署代码的方式，因此正在提取此配置，那么这是一个合理的时间来评估你是否要使用此遗留代码，或者是否要将其升级到另一个产品，因为你已经在

使用它的过程中。是的，你可以在那时解决该依赖链。我想在这里玩一个小游戏。尼尔，我作为一家公司向你发布一份招标书，让你作为承包商投标。这是高级内容，只是高级主线。我需要有人进来，因为我不希望我的全职员工处理这个问题。我需要有人进来处理我的代码

并消除今天和将来永远存在的安全问题。你会接受这份合同吗？不会。我对第一个要求没问题，但一旦你说，将来所有的一切，我们不可能知道将来会发生什么。所以我要么让他们删除这个要求，要么说，是的，这

对我来说风险太大了，我无法给你承诺。我无法保证未来的事情不会破坏它。好的。所以我要，我要继续深入挖掘一下。所以你告诉我的是，你对目前的情况没问题。是的。我可以接受，但这对我们来说是一个业务需求，永远不会有任何，呃，

问题，任何与我们拥有的任何软件相关的安全问题，无论是我们编写的软件还是我们从开源获取或使用的任何软件。你告诉我你无法阻止我们或保护我们免受将来任何软件的任何安全问题的侵害。不是在一个解决方案中。它必须是一个持续的过程。不，我只需要在接下来的两个月内完成。当然。现在我可以为你提供一些尽可能安全的软件。

但我认为我的保险公司甚至不会为我投保，这可能在下周就不安全了。我们到此为止角色扮演。你用“我的保险公司不会为这投保”来处理业务。是的。你写了一本关于咨询的书。它更多的是基于英国的。有一些全球性的东西，但如果你过去做过承包工作，那么这个保险问题就非常重要，我做了大约10年。携带E&O……

排放和什么？不是排放。错误和遗漏。我把这两个词放在一起了。错误和遗漏。可能还有其他英国特有的保险。这是一件大事。如果你认为你只是要开始做一些合同工作，如果你与一家企业合作，而不仅仅是你的朋友，你以后可能会遇到一些问题。

是的，当然。因为事情可能会出错。事情总是会出错。这只是时间问题。我想无论如何都会发生，但如果企业因你所做的事情而遭受损失，他们希望能够强烈地将责任指向你并收回这些损失。这还包括纠正任何出错的事情。我们不会再深入探讨这个话题了，但是

当你早些时候谈论安全问题时，我现在必须处理其他问题，以及将来可能出现的任何问题。因为我最近在浏览论坛时看到有人提出这样的要求。就像，嘿，我们公司发生了太多安全问题。我们需要确保我们的软件将来永远不会再出现安全问题。我看了看，翻了翻白眼，然后悲伤地笑了。

是的。避免出现这些问题的唯一方法是不使用该软件。是的。但这并不是一个好答案。但不幸的是，这是正确的答案。我想回到你之前说过的一件事，员工流动。是的。你经常作为承包商进来，我说的是承包商而不是顾问。我之所以特别这么说，是因为两者之间存在很大的区别。是的。你如何区分承包商和顾问之间的区别？然后我们稍后再谈员工流动。

所以顾问可以是公司的一名正式员工。该公司可以通过与第三方咨询公司合作来获得顾问的使用权，或者他们可以与类似于我的业务的顾问做同样的事情，该顾问作为自己的业务运营。

顾问是提供的服务，而承包商是提供服务的方式。我过去还用过另一种说法，即劳务派遣公司。是的。只需把车开到路边，把一堆人从车上扔下来，做工作。如果在美国，他们可以待上18个月，然后他们必须离开，感谢微软。感谢微软。然后循环重新开始。

这让我们回到了员工流动的问题。现在让我们回到我们一开始谈论的内容。你目前正在参与一个项目，在这个项目中，我们将中期技术与旧技术集成。事实上，我要让它更难一些，或者更清晰一些。Git是中期技术，而旧技术是……我不打算命名，但让我们假设它是一个企业分析软件。

这样保持非常广泛，因为有很多这样的软件。你离线时说的是，让这两个软件很好地协同工作存在一些问题。现在，由于这个较旧的分析软件可能已经存在了几十年，我想员工流动肯定相当多。而且我假设你正在为其做承包工作的公司是一家大型企业，对吗？是的。那么，除非某些地方员工流动较小，

仅仅是因为福利很好，但嘿，谁知道呢？你认为在这个特定项目中，员工流动情况如何？因为你并没有在那里待很久，但你认为情况如何？我想员工流动可能基于，同样，合同续签。所以那里的大多数员工都是以某种形式的顾问。

而且他们不直接为客户工作。因此，当客户试图调整自己，也许在合同上获得更好的条件时，他们将失去或用其他顾问替换顾问。所以我可以想象，由于他们与不同的外部公司合作，他们可能每隔，就像你说的那样，18个月、24个月就会有新面孔。

对我来说，这很荒谬，我们担心业务连续性，而你却更换了正在从事这项工作的人员。这对我来说似乎很疯狂。现在，让我问这个问题。这有点，我想，我想让除了我和你在这个领域工作的人之外的其他人说这句话，你在这个项目中工作的这个项目有多少全职员工？

有多少承包商？你做一个百分比。你认为这个百分比是多少？全职员工与承包商的比例？在这个项目中，我不知道确切的数字，因为很难看到每个人都来自哪里。但如果我必须猜测，我会说可能有20%的全职员工直接为客户工作，也就是说他们是员工。而80%的人是该公司的外部人员。

看，我觉得软件与其他领域相比，这是一种非常特殊的情况，我认为没有其他任何业务领域，一家公司会同时说这是业务关键的，而我却将其外包。通常，例如，如果它是一家银行，对吧？然后是人员，财务人员，他们是内部人员，因为这是业务关键的，然后我们外包。

清洁服务，对吧？因为这并不是业务关键的。但在软件中，它非常特殊，因为它同时是业务关键的，但它却被视为并非如此，对吧？这难道不是取决于它的资金来源吗？我的意思是，我们可以谈论资本支出与运营支出，软件的开发非常被视为一个项目，一个一次性的东西，它被创建

但我们作为开发者自己也知道，这段旅程永无止境。无论软件写得多么好，总需要进行维护。所以回到你刚才所说的，开发部分通常是资本支出。

但持续的维护通常是，通常是运营支出。是的，没错。我以前参与过一些合同，我们在资本支出中列入了维护费用，这很痛苦，因为某些部分，好吧，我们必须将这一行项目分类为资本支出，并将这一行项目分类为运营支出。我想，好吧，你们在后台弄清楚这一点，然后只给我正确的行项目，我必须在我的时间表上记录。

这也是我不再喜欢承包的原因之一。我厌倦了时间表。是的。时间表很痛苦，但我不知道更好的记录方法。是的，没有。尤其是像我刚才谈到的那种情况，你得到，有一次我一个月做了一个时间表，我将近有70或80个项目，因为我当月提取的工单是70到80个工单，60、70、80，无论数字是多少，我都说了。

而且每一个，我都必须保留它。我还必须将我的时间精确到十分之一小时。每六分钟，我必须记录我的时间。在英国怎么样？是不是这么疯狂？我可以想象有些公司可能会这样运作。但幸运的是，根据我的经验，情况有所不同。我想一天四分之一，两小时，将是我必须处理的最小增量，至少在过去一年中是这样。

15年左右。这主要是因为我们以这样一种方式构建合同，它有一个工作说明书。我负责交付这些东西。它并没有深入到你可以称之为行项目的东西。就像，这是我和客户之间的合同，

我负责交付这些东西。就合同而言，它保持在相当广泛的层面。因此，它就变成了客户满意我一直在那里。我在某个日历日、半天都出现过。这就是我目前记录的时间表级别。然而，

有一种情况是，虽然客户可能提供相同的服务，比如说我正在查看用于自动化软件构建和部署的交付管道。这很模糊和广泛，但客户可能希望将其作为费用分配给多个项目，因此你最终可能会在他们的内部时间表上有一个系统，他们说，好吧，你花了

在这个项目上花了两个小时，在这个项目上花了六个小时。这可能到处都是。当然，当我上次为这个客户在这个特定部分工作时，那是大约八年前的事了，情况更像这样。但如今，时间表的要求已经大大减少了，这对我来说很棒，因为它使事情变得更简单了。

让我们回到员工流动的问题，因为我们一直在跳来跳去，而我才是造成问题的人。80-20规则在生活中随处可见。20%的全职员工，80%的承包商将根据谁为采购部门提供了最好的牛排晚餐、最好的假期或最好的高尔夫球赛而被安排进出。正如维克多所说，在软件中，我们把最便宜的人

我在这里做了一个笼统的概括。我们将最便宜的人员安排到我们业务中最关键的问题上。我们希望他们能够在现场，坐在办公桌前，遵守我们所有的规定。所以你可以在不成为你为其工作或做承包工作的公司全职员工的情况下成为全职员工。难怪员工流动率如此之高，因为忘记法律方面的问题，这就像，哇，这似乎是一件很糟糕的事情。就像我做承包商的时候，我，

我是一个人经营的商店。所以如果你愿意，它是一种雇佣枪。这对我来说很棒，因为我可以选择我想要做的工作。我很幸运拥有许多客户，即使我们有这些奇怪的事情，每六分钟都要做一次。但好吧，我克服了。我们如何才能让企业相信，如果他们真的想发展，再次，资本支出，运营支出，我们已经讨论过了。如果他们真的想发展，也许他们需要改变方向。也许应该是

80-20全职员工与承包商？我认为他们必须以完全不同的方式对待软件。所以我们正在谈论资本支出和运营支出。只要他们将软件开发视为短期的事情，他们就不会有那种长期思维，许多企业都希望拥有全职员工，因为他们认为全职员工会在公司待很长时间。

我认为这里的脱节在于，我们知道软件部署需要很长时间。即使它完成了，它也会被调整。我参与的一个较旧的项目，我认为总的来说，它持续了大约九年，然后他们才决定它，如果你愿意的话，是稳定的。开发已经稳定到这样的程度，现在我们只需要维护它就可以了。

安全更新、补丁，但没有新的功能或任何类似的东西。即使那样，他们也只是从两年周期转向两年周期，并没有真正对它进行长期规划。那么，如果他们没有对它进行长期规划，他们为什么要雇用全职人员呢？但我假设那些人实际上是做业务需求文档的人，对吧？我的意思是，有人必须对这件事有一个长期的规划。

通常，你知道，当竞争出现时，这些变化就会发生。我们现在在汽车行业看到了这一点。大众汽车被迫彻底改变其运营方式，原因是比亚迪或其他什么公司，中国汽车制造商和特斯拉以及其他公司，对吧？通常，在我所说的和我在做的事情之间存在很大的差异，以及……

我在做的事情，因为我被迫以不同的方式去做，对吧？例如，在一些国家的银行业中也发生了类似的事情，在一些银行说，嘿，这很重要之后。我们认真对待它，对吧？以一种非常不同的方式。它仍然提出了一个问题，即企业认为软件的核心功能对其核心业务有多重要？是的，更多的是朝着……

一件事是我们今天之前的想法，但现在我们要倒闭了，因为这些新公司突然冒出来了。它正在彻底摧毁我们的业务，对吧？这在某个行业中每十年发生一次，对吧？现在我们在汽车行业经历了这种情况。在此之前，我们在其他行业经历了这种情况。也许这就是需要的，对吧？对整个行业进行一些真正的颠覆，对吧？

让公司意识到他们也许应该做一些不同的事情，或者破产。是的，也许吧。因为许多初创公司，如果我可以概括一下，往往是软件公司。他们的核心产品是软件，这在老式的术语中，是指计算机执行的过程，而不是人们执行的过程。所以在英国，颠覆性银行……

好吧，它们在银行业，但它们是软件初创公司。我认为这就是你想要表达的观点。没错。而且你知道，当你达到无法再购买初创公司、无法再将它们收购、无法再购买竞争对手的时候。竞争对手发展壮大到无法被收购的地步。但问题是，如果那是你开始做出反应的时候，是不是太晚了？也许吧，因为当你注意到某些事情的时候……

它足够大，值得注意。所以他们已经有了这种势头。正如我们所看到的，大型组织确实需要很长时间。就像一艘大型船舶一样，它们需要一个很大的转向圈才能改变方向。因此，较小的初创公司将更加灵活，并且可以超越它们，即使大型公司试图改变方向也是如此。

那么让我们看看是否可以将故事带回到我们开始的地方。我们已经讨论了围绕此的所有人为问题。让我们看看是否可以解决技术问题。我所说的中期技术是 Git，它就是 Git。从分析的角度来看，我们有非常旧的软件。我们试图让这两个软件很好地协同工作。现在，作为业务所有者，我会说，嘿，承包商，因为……

这对我来说很重要。这确实是业务关键，但我没有员工了解 Git，因为我们落后太多了。我们仍在使用 CVS 和 RCS。您将如何着手解决这个问题，也就是您现在正在做的事情？我想这些工具无法很好地协同工作的主要原因是遗留软件并不期望有其他

帮助管理它。它像一个整体应用程序一样编写。你知道，一切都在它的控制之下，它不想放弃任何一部分。所以，当我们有了像 Git 这样的东西想要与它成为朋友并帮助减轻一些工作量时，你知道，它没有真正的方法融入其中，它仍然是外部的。

我想我唯一能帮忙的方法就是让外部系统与旧系统尽可能好地配合使用。因为幸运的是，它确实有一个命令行界面，这意味着我们可以编写批处理脚本来处理它。

这些批处理脚本还可以使用 curl 请求或 API 等与其他系统接口。因此，我们可以开发一些中间件来充当这两个系统之间的接口。但它正在做很多繁重的工作，如果更改遗留整体式应用程序以允许它进入，让它有一个可以与之协作的小门，那么这些工作就会更容易。

这是可能的。该软件的供应商正在发布更新，因为他们是软件供应商，因此他们必须在其中保留安全更新。但他们也开始采用更新的技术，这意味着该软件的全新版本。让我们引入微服务的术语。他们感染了微服务的病毒，作为一个

整体类型的软件，他们已经了解到，或者更确切地说，他们被告知，微服务使一切变得更好，这在某些方面是正确的，但我认为它不像任何想法那样容易被滥用，因此他们将用一些稍微更新的东西替换该遗留软件，也许使用微服务架构，他们将

这将使集成更容易，因为这些微服务需要能够相互通信，这为 Git 和 API 等外部软件提供了更多接口点以与之协作。我在微服务方面尽可能保持沉默。我认为你陈述的方式很有趣。这就像企业供应商关注 Git 和微服务等新事物一样。是的。

那已经十多年了。我认为另一件有趣的事情是，你谈到了九年。我们现在认为九年后某些东西是稳定的。我在想，好吧，Kubernetes 刚刚庆祝了它的十周年。它现在才稳定。这与之相符，但它仍然以相当快的速度向前发展。我想知道这个 10 年的标志是否实际上是一个重要的数字。

感觉是这样的。你仅仅根据我们讨论的三个例子得出的结论，确实感觉这可能是一件事。但这意味着什么？这意味着它将被一些新的、更闪亮的东西所取代？还是意味着该产品一旦达到 10 年的期限，就会慢慢地走向消亡，直到最终被取代？我认为这是公司面临的一个大问题，或者说是他们正在犯的错误，对吧？是的，当然，Kubernetes 将被其他人取代。我用它作为例子。当然会的。最终一切都会被取代，对吧？但是如果你从这样的角度考虑，嘿，这会被其他东西取代吗？那么你永远不会做任何事情，对吧？嘿，会的。当然会的。一切都会。

这就是为什么我们回到最初的问题，软件开发是资本支出，因为它最终会被其他软件取代。我的意思是，这可能适用。也许时间框架不同。这适用于一切，对吧？我们没有驾驶 50 年前驾驶的汽车。今天建筑的建造方式与 50 年前不同，等等，对吧？但这通常不再是一个问题了。

当你有一个相当快的采用速度时，对吧？所以五年前采用 Kubernetes 的人仍然领先于它，没有人知道领先多少，对吧？在它被取代之前。现在，如果有一家公司，我希望不再有公司还在考虑这是否是一件事，Kubernetes，那么是的，当然，当他们完成思考时，它将被取代。

但这并不是 Kubernetes 或任何其他技术的错。这是公司行动过于缓慢的错，对吧？如果 10 年不足以让公司采用某些东西，那么任何东西都不行，对吧？是的，因为在业务中经常出现的另一个数字是 20 年的期限。

也就是说，好吧，我们说软件需要 10 年才能稳定，但似乎 20 年是初创公司稳定所需的时间。像 Facebook 或亚马逊这样的公司在成为你可能称之为全球知名公司之前已经交易了 15 到 20 年。据推测，他们在内部拥有比这更年轻的软件产品，内部开发，

一定存在这两者之间的某种关系，或者这只是一个营销策略，导致了这 20 年？我不确定这 20 年，对吧？因为 Facebook 以其为例，对吧？如果有什么不同的话，那就是加速，而不是减速。像 Facebook 这样的公司，他们可能在第一年内做的比传统公司在 10 年内做的还要多。

传统公司 20 年的期限可能更接近于更敏捷的公司的一年期限。当我提到敏捷时，我的意思是字面意义上的敏捷，对吧？例如，看看汽车中的软件，对吧？大众汽车自 80 年代以来一直在开发软件。所以我们甚至没有谈论 10 年或 20 年的期限。我们谈论的是 40 年、50 年。它仍然远未达到

特斯拉或 Rivian 在几年内所做的。哦，看，我认为你错了。好吧，“错”可能太强烈了。Rivian 和特斯拉并非几年。它似乎是几年。没错。但他们可能，我没有他们的出生日期，但他们可能也在 15 到 20 年的范围内。没错。但如果你看看，如果你看看，比如说，呃，

与大众汽车相比，是的。不仅如此，我不一定说今天是特斯拉或特斯拉，对吧？我说的是看看他们在前五年做了什么。我同意这一点。但无论如何，是的。我们谈论的是 10 和 20，让我们先坚持 20。假设你 30 岁时去了一家公司工作。现在已经过去了 20 年，你现在 50 岁了。只是这个基本的数学。

在这 20 年中。当我们说软件 20 年时，就像，好吧，软件 20 年。但是当你把它放在你的身体上说，我 30 岁时开始做这件事，现在我 50 岁了，我还在做同样的事情。这有时会让人非常沮丧，我猜。除非你可能在特斯拉工作，或者你从事的工作感觉总是新的、热门的和不断变化的，而不是可能……

金融服务或保险，在那里它实际上从未真正改变过。是的。我的意思是，我认为它不会改变。你知道，即使你已经做了 20 年的软件，你也没有做 20 年的相同软件。你已经做了 20 年的不同软件。你应该希望如此。是的。20 年前，我们没有 Golang。这是一个没有它的美好的世界。事实上，我认为 Python 只有大约 25 年的历史。

或者我完全错了？因为我自己也老了，所以事情看起来比实际情况更近。好吧，这就是我所说的，我们提到，哦，是的，这件事有 20 年的历史了。但后来我在想，好吧，我 20 年前开始使用它。就像，哦，那时我的左膝盖不疼。那时我开始使用它。所以我们今天已经走遍了所有地方。我们讨论了试图将方形木桩塞进圆孔，而方形木桩实际上比圆孔更大。

提示，提示。总有一种方法可以解决这个问题。只需将正方形做得比孔小。它会直接穿过。讨论了承包与咨询。尼尔，我们还应该考虑其他什么问题？我想，让我问你这个问题。如果有人在想，你知道吗？我受够了这份全职工作。

我看到这些承包商回到 80-20 规则。我看到所有这些承包商都来了。他们早上 9 点来，下午 5 点离开。我早上 6 点上班，直到晚上 9 点才下班。他们每小时都得到报酬。我是拿固定工资的。我没有额外的休息时间，而且我被期望在周末免费工作。你会对那些考虑转行做承包商的全职人员说什么？

真的那么好吗？好吧，我的意思是，你画了一幅非常直观的画面，这正是许多人做出这种转变的原因之一。我同意这种观点，它确实那么好。但这并非没有挑战。作为英国或其他地方的承包商，我们谈到了保险。你需要确保你去年做的事情不会在今年咬你一口。

有一些你必须处理的报告和合规性问题，因为你是一家企业。因此，经营任何企业的一部分意味着你必须进行某种程度的报告，无论是关于保险到位的情况。你知道，如果有人在你面前绊倒摔倒，那么这可能是你的错。

以及你所做的工作的保险。然后是金钱方面的事情。与税务机关的合规性，以确保你支付了正确的税款，并报告你的收入和支出，以便你可以计算出正确的税款。然后谈到现金流，还有确保你得到报酬。所以，当然，作为一个承包商，你可能会去现场，做你的事情，

我在月底发送发票。然后有时好客户会在月底支付该发票。因此，如果你在月初来，你直到月底才开具发票，然后他们直到下个月才支付。所以在你甚至得到报酬之前，你已经做了 60 天的工作，这意味着你必须非常擅长你的个人现金流。当你开始时，当然还有首先获得合同。你知道，你在哪里找到它们？

这有点像找工作，但合同市场有点不同。合同期限要短得多。所以可能会有你有一份为期六个月的合同，然后你两个月找不到任何工作。太好了，你可以给自己一些空闲时间，也许从事一些副业项目，也许进行一些培训，但随后你开始查看你的现金流，并且它开始有点枯竭，这可能会有点压力。

所以有好的一面。是的，当市场充裕时，你可以选择你工作的项目。当市场不像去年那样充裕时，有时你会从事不太理想的产品和项目。所以，是的，总是有风险。总是有不好的事情，总是有好的事情。但是为坏事做好准备会使它们更容易处理。

只要你处理它们，就相当简单。他谈论承包的所有信息都可以在尼尔的书《自信的承包商》中找到，这本书可以在亚马逊上找到。事实上，我前几天看过。在美国，它是 99 美分。现在，它非常以英国为基础。因此，对于在英国以外阅读它的人来说，你可能会说，好吧，这没有意义。只需尝试替换大块内容，你就会明白。但是

仅仅因为你必须作为一名员工在周末免费工作，这可能仍然比试图经营你自己的公司更好。因此，我们将在剧集说明中列出尼尔的所有联系信息。尼尔，感谢你今天与我们在一起。谢谢。这很有趣。我们希望本剧集对您有所帮助。如果您想讨论它或提出问题，请与我们联系。我们的联系信息和 Slack 工作区的链接位于 devopsparadox.com/contact。

如果您通过 Apple Podcasts 订阅，请务必在那里留下您的评论。这有助于其他人发现这个播客。立即在 DevOpsParadox.com 注册，以便在我们发布最新剧集时收到电子邮件。感谢收听 DevOps Paradox。