播客 > Ep. 177 - How to automate on premise data center workflows
Ep. 177
How to automate on premise data center workflows
Rob Hirschfeld, CEO & founder, RackN
Tuesday, May 16, 2023

在这一集中,我们采访了RackN的首席执行官兼创始人Rob Hirschfeld 。 RackN 通过跨 IT 系统、平台和应用程序的无缝自动化,将人们用来管理基础设施的工具连接到工作流管道。

在这一集中,我们讨论了运营本地数据中心的挑战以及在公司采用边缘计算时自动化流程的必要性。我们还探讨了数据中心在过去 25 年的演进过程中的发展、改进的地方以及需要改进的地方。

关键问题:

  • 当今云基础架构面临哪些挑战?
  • 物联网和数据中心在过去 25 年中是如何发展的?
  • 企业如何适应边缘计算?

音频文字.

埃里克:罗伯。欢迎收看今天的播客。

罗布:埃里克,谢谢你邀请我。我对谈话感到兴奋。

埃里克:是的,我也很期待。很高兴知道您也是一名播客。所以我想这将是一个非常顺利的过程。也许在我们开始谈话之前,我很想听听一些想法。你的播客封面是什么?所以它被称为 Cloud 2023。哦,2030。

罗伯:Cloud2030。它被设计为一个 10 年的前瞻性圆桌讨论会,我们记录下来。我们是在 COVID 期间开始的,因为我们对我们在会议中失去的东西感到非常绝望。它实际上真的被认为是——我认为它是一条走廊轨道,一条持续的走廊轨道。所以我们坐下。我们选择一个主题。我们有一个议程,然后我们讨论事情的进展。我们有一个战略会议,我们将讨论人工智能、政府的大数据云与云环境交叉,就像大话题一样,然后把它带回到事情的进展上。非商业性,所以它不是供应商的事情。这只是我们在考虑事情将如何发展。然后我们为 DevOps 做一个单独的主题,讨论 DevOps 中的大主题以及如何分解这些主题。

其乐无穷。这是一种开放的形式,因此它不是由推销产品的客人或具有特定专业知识的客人驱动的。我们有时会这样做。它更多地围绕着一个我们都想谈论的话题。太棒了。我们已经运行了三年。我们有机会回去做连续的话题。当我们的时间用完时,我们就回去,我们挖得越来越深,越来越深。我从未见过其他类似的东西,而且跑步很有趣。

埃里克:是的,好吧,这就是这个话题的奢侈之处,对吧?它在不断发展。所以你总是可以回头说,好吧,我们在 12 个月前讨论过这个。今天有什么不同?进化在这里看不到尽头。

罗布:看不到尽头。当然不。

埃里克:太好了。好吧,我认为这可能是我们今天谈话的一个很好的框架,基本上,在这种情况下我们应该考虑什么?但是,显然,还要更加关注物联网。我敢肯定,通常情况下,您可能会涵盖更广泛的范围。所以我们可以缩小一点,在那里有一些定义总是很有趣的。但在我们去那里之前,Rob,我想多了解一下你自己。我认为你有一个迷人的背景。我的意思是,你是——让我们看看。你什么时候开始你的第一家公司?回到1999年了吗?是对的吗?

Rob:是的,我们确实建立了最早的云基础设施公司之一。在这样做的过程中,我们是第一个在 VMware 大厅之外安装 VMware ESX beta 的人,并在 2000 年构建了第一个云并开始构建云基础设施。所以我们一直在为从操作的角度来看很长一段时间。可想而知它有多难。即使在某些方面,它并没有变得更容易。我们一直在努力,让这些东西变得更难。不容易。

埃里克:是的,没错。所以这是一场比赛。你曾经做过很多事情。到目前为止,它们已经高度自动化。但是,当然,技术堆栈也总是会出现新的复杂性。

Rob:是的,我认为我们对云基础设施工作的挑战是人们已经习惯了云。有人正在为您运行基础设施。它非常受 API 驱动。不一定更简单,但至少是 API 驱动的。我们还没有将同样的精力投入到人们必须自己经营的事情上。这里的观众是那些将不得不运行自己的基础设施的人。如果您正在运行物联网,或者甚至是物联网,您仍然可以连接到云端登录,这表明您拥有一个设备。您正在运行该设备。您实际上担心连接到所有部件和部件的网络。基础设施工作仍然是您关心的问题。你无法摆脱它。那个,我不认为我们在行业中做了很多工作来简化。

事实上,云是我们在那里缺乏进展的反应。所以这令人沮丧。在创立 RackN 之前,我做了一段时间。我在戴尔工作了很多年。这是启动 RackN 的部分动力。在客户中成功运营数据中心是多么困难。 RackN 的成立是为了让这个过程变得更好。这真的非常非常痛苦。

埃里克:是的,你会比我更了解这一点。我看到一些数字表明系统集成成本大约占总成本的 30%、40%。我的意思是,基本上,您购买硬件。你购买了你的技术,然后你要付出非常沉重的代价来基本上弄清楚如何操作等等。我不知道这在过去十年左右的时间里是否发生了如此大的变化。看起来还是挺重的。

罗布:它没有动弹。我认为它根本没有动摇。不,实际上,我创办第一家公司的起源故事是我为人们编写软件,然后进行安装和类似的事情。当时我还很年轻,所以我会预算写软件需要多少时间。我对此非常准确。但是当我去安装它时,我发现我花在编写软件上的时间完全相同,实际上是让它在软件所在的环境中运行。这就是让我首先关注云的原因。就像,等一下。如果我们可以将它与浏览器一起使用,我就不必跑来跑去在每个人的桌面上安装软件,而这会花费这么长时间。做到这一点非常困难。

对我们来说,我们将这种基础设施即代码的兴起视为第一种打破壁垒的方式,即我们如何在流程中创建可重复、可重用的自动化,以便我们可以在客户到客户站点之间使用。因为你所描述的是,做这项工作并不是那么困难。部分问题是我们没有太多的重复,我们从做一次中学习,然后在下一次改进它。我们可能会把东西写下来,并有一张备忘单,让事情变得更容易。但我所看到的以及我们试图在 RackN 解决的 RackN 循环中的问题是这样的想法,即每次我去一个新客户,一个新站点,我都在重新发明我的所有东西有过。然后,如果我在下一个客户中修复某些东西,那么前一个客户就永远不会从中受益。这就是挑战。我们必须停止同时进行 IT 和运营、物联网和运营。一次性。我们必须找到模式。我们必须从中获得更好的可重用性。否则,就是螺旋式下降。

埃里克:是的,我知道。那很有意思。在 CIO 进行投资之后,作为 CIO,这些似乎也很常见。但是,您拥有传统技术。你永远不会完全取代它,对吧?所以你只是在构建它们并做这些,破解这些集成等等。因此,每家公司最终都会拥有自己的怪物,这些怪物已经建立了 10 年、20 年。是的,标准化比 Azure 标准化云服务要难得多,对吧?

罗布:对,是的。现实是复杂性——我们在行业中经常谈论复杂性,但不是以非常实用的方式。我看到并听到人们说他们都害怕复杂性。他们担心复杂性。他们认为解决复杂性的唯一方法是标准化或简化。我认为你的观点非常有道理。一个人的标准化是下一个人的遗留基础设施。您只会获得标准化层。这就是结局。我的标准与下一个人的标准或下一个人的标准不同。因此,当我们审视复杂性时,我们所做的并不是将其视为具有特定解毒剂的问题。它不像,“哦,我只是要简化事情并消除复杂性。”我是说你也必须管理和设计它们。对我来说,这是迈出的第一步,是我在建造时的第一个恍然大悟的时刻。

RackN 专注于物理基础设施。我们自动化所有类型的基础设施。但我们已经做得很好,因为我们将这种复杂性视为一个正常问题,能够很好地管理有很多例外和规则的事情。你必须考虑不同的环境如何影响性能,所有这些。它很复杂,但它是必要的复杂性。因此,与其走进去说,“我们要把这块板擦干净,然后假装我们没有任何其他世代或任何其他要求,”你相反的方向说,“好吧。根据构建这些东西的方式,可能需要很多这样的东西。让我们看看我们是否可以接受。”然后围绕它进行自动化,或者以防御性的方式进行自动化。它需要更多时间,但它创建了更多可重复的自动化,更多可重用的自动化。然后,在我看来,它也是对以前所做的事情的尊重。

当我们的 IT 专业人士基本上把上一代人当做——他们是工作中的最后一代人时,这真的让我感到沮丧。他们就这样离开了。他们出现了。然后突然间,他们在想,“哦,在我之前的人所做的一切都是错误和糟糕的。他们怎么会如此短视?”我们这样做。这是人类的正常倾向。但我们需要承认,这些东西是存在的,而且它正在发挥作用。让我们看看我们是否能让它继续工作。

埃里克:是的,当然。这似乎是正确的哲学。你还必须承认,跟在你后面的人也会有同样的反应。您希望拥有一个架构,让他们能够重视您正在做的工作,并随着它的不断发展将其融入更大的整体。

Rob,让我退后一步,问你一些关于 Digital Rebar 项目的问题,因为它总是很有趣。你在 2011 年设立了它。然后你在 2014 年创立了 RackN。所以当有人基本上建立一个时,我总是很感兴趣,我想这就像一个非营利组织或一个在他们成立公司之前围绕这个主题的组织。那里的逻辑是什么?

Rob:这方面的历史可以追溯到我们在戴尔内部所做的事情。今天的 Digital Rebar,男孩,我们成立公司时已经过去了两代人,这本身就是我们在戴尔所做的事情的另一代人。所以当我在戴尔的时候——实际上,RackN 的大部分创始团队都在戴尔。这是在 OpenStack 时代,2000 年,2009 年初,2010 年。我们为 OpenStack 构建了一个安装程序。

在戴尔内部,我们正在帮助超大规模企业构建他们的下一代数据中心。我们尝试使用 Hadoop 和 OpenStack 之类的东西。如果您的听众不熟悉这些项目,其中之一就是虚拟化经理。一是大数据分析平台。它们都是为大数据中心设计的。所以多系统自动化,多层计算。其中一些东西已经变成更小的足迹,但它在操作上总是具有挑战性。我们发现,戴尔可以向他们出售服务器。我们可以从社区获取软件。但实际上,在该设备上以可靠的方式运行该软件确实很苛刻,而且更糟糕的是不一致。这又回到了我的职业主题。如果你考虑一下,我有软件,我有硬件。但是每次我设置那个,我创建一个新的独特系统,这对我来说真的很糟糕。我真的很努力地与之抗争。所以我们已经建立了一种在系统上一致地安装该软件的方法。

它的原始版本称为 Crowbar,以其命名——它是您开始游戏的《半条命》中的第一个工具。这是你唯一拥有的东西。这是撬棍这就是您启动整个系统的方式。迭代这个过程,它最初是戴尔的一个开源项目,然后在我们努力改进它并使其达到我们的可重用性目标时在 OpenStack 社区中广为人知,这变成了 Digital Rebar,这是非常不同的。我们今天为 Digital Rebar 提供的产品有一些 API 重叠。但从那个角度来看,它几乎完全不同。

其中一件值得注意的事情是,开源部分非常重要,因为我们希望人们重用他们的自动化。这里的目的是,如何让客户对客户、人对人、操作站点到操作站点真正能够共享和重用自动化?这是我们迄今为止一直在谈论的主题。如果我自动化一些东西并创建流程,我如何确保这些流程及时持久,这样我就可以继续添加它们而不是必须重写它们?而且,站点到站点——如果我有多个站点——或者客户到客户,或者社区成员到社区成员。如果我们不断地重写东西,我们就不会分享。我们没有一起工作。我们正在为同样的工作而努力。对我来说,这一直是物联网领域最大的挑战之一,可以追溯到我职业生涯的最初几天。

埃里克:好的。迷人。帮助我理解这一点。如果我是 RackN 的客户,我会部署您的平台来帮助运行我的本地数据中心。然后通过该平台,我可以访问您开发的工具,也可以访问以前的客户或以前的社区成员开发的工作流程,然后我可以立即开始利用这些工具,这样我就不必从头开始构建东西了。就是它?

Rob:这正是我们所做的主要事情。 Digital Rebar 的开源部分已经发展成为社区中的所有自动化。因为那是我们希望人们重用的地方。 RackN 销售的部件实际上是平台部件,让你有一个地方来运行所有这些。我们从这个角度看到的是,客户真的不需要了解数据是如何存储的或者引擎是如何工作的。但他们真的非常需要了解,为了进行这种共享和重用,他们必须了解自动化如何将所有其他部分放入其中。因为如果他们看不到而且他们实际上没有看到——他们就无法改变它。他们不能通知它。他们不能回馈。但是当新客户出现时,他们会安装所有这些开放内容,有时我们称之为通用工作流程。这推动了我们所谓的基础设施管道。

这里的想法是,当您启动时,您实际上是在构建经过充分验证、高度执行的工作流,这些工作流将安装操作系统,完成安装、合格系统、发现、分类、配置之外的工作。所有这些工作实际上从一开始就内置于系统的运行方式中。然后在这些管道内部,您可以添加任何您想要的自定义部分。这确实是一个关键的部分。所以我们必须回到目标。目标是您可以从经过充分验证和测试的工作主体开始,这些工作主体可以提供 90%、95% 的所需功能。然后在不删除该层的情况下,您可以添加到它来完成您需要的工作。

很多时候,我们想像画千层蛋糕一样画 IT 图。我们头脑中有这个美好的愿景,我们有一个网络层和一个硬件层、一个操作系统层、一个应用程序层、一个平台层和一个应用程序层。所有这些都整齐地堆叠在一起,我们可以把碎片放进去,就像把蛋糕里的一层切掉一样。我喜欢把它描述为水果蛋糕。因为我们所做的一切都会对所有其他部分产生影响。因此,在 IT 系统中,您不能更换网络并假装它只是网络。更改 IP 地址会更改您的 DNS,从而更改您的证书。所有这些片段都碰撞在一起。因此,我们没有奢侈地认为我们可以通过分层来摆脱复杂性。我们必须以不同的方式管理复杂性。我们这样做的方法是,我们实际上将这些管道构建在一起,然后在该管道中来回传递信息,然后很容易将新操作注入管道。

所以我可以说,哦,你知道吗?在我的系统上,我需要在完成引导程序配置之后但在安装我的应用程序之前运行此脚本。我们使您能够做的是在不中断管道的情况下将这一操作添加到系统中。因此,您可以使用标准管道并利用其演变、改进和错误修复。您可以留在流水线中,但现在您已经添加了那一块而不破坏它。

从历史上看,发生的事情是,人们接受了所有的自动化。他们复制了它。这是我们过去不得不做的。然后你添加你的一件,现在我有一个副本,我的自动化的 2023 版本。如果 RackN 继续改进它,或修复它,或改进它,我就不会从这些工作中获益。大多数人接受了那部分自动化,然后他们会说,“哦,我不需要 RackN 插入的任何这些额外的东西来支持安全性。我要把它去掉。”然后开始开箱。现在我们回到复杂性与简单性的问题上。你会说,“好吧,我会去掉所有我不理解的东西,让它变得更简单,因为它很复杂。”你最终得到了当下对你有用的东西。但是你失去的是所有的学习,所有的战斗伤痕,防御性的东西,下周你可能需要的东西。你没有意识到你只是把它撕掉了。

我们看到这种模式一遍又一遍地发生,这就是我们以这种方式构建平台的原因。因为拥有所有这些部件对您来说真的非常重要,即使您还不需要它们。它们都有一个目的。这实际上是我没有说完什么是复杂性的解毒剂的妙语。这不是简单的。是运动。所以如果你看到一些东西并且你在想,“哇,这是一个非常复杂的自动化,或者一个复杂的系统,或者一台复杂的机器,”你处理这项工作的复杂性的方式是通过做它更频繁。在开发方面,他们谈论发布更多。如果发布很难,请更频繁地发布。你越多地使用这个系统,你就越能抵御这种复杂性。

因此,RackN 所做的是,当我们构建这些管道时,我们实际上非常努力地工作,而不是拥有数千条管道,以尽可能少的管道为大量公用事业服务。因为我们知道,如果您正在使用该管道,即使您没有使用它,作为个人客户,我们也会有客户在各地疯狂地使用这些管道。所以我们找到了错误。我们添加功能。我们增加了更好的防御。我们根据行使自动化的社区将新功能添加到这些管道中。从这个角度来看,它具有根本性的变革性。因为这意味着每个人的自动化都在持续测试,即使他们没有那么多地使用自动化。这就是我们在早期的 OpenStack 时代一直回到戴尔的事情——我认为,对于任何从事 IT 工作的人来说,这是一个重要的洞察力——个人而言,你可能不会经常做一项任务。但是,如果您可以加入一个经常完成该任务的社区,那么您就会从该练习中受益。这是我们应对复杂性的方式之一。

埃里克:是的,在物联网(一种互联企业)的背景下,这是一种引人入胜的方法。因为,至少,与我合作的许多公司显然已经拥有 30 年、40 多年的 IT 系统。但在那段时间的很大一部分时间里,它们相对稳定。就像,好的,我们部署。我们有我们的 ERP。我们有我们的 MES,我们有我们的通用后台系统等等。除此之外,情况相当稳定。我们每隔一段时间就更新一次。现在我们正在进入一个环境,在这个环境中,公司有 50 个用例的积压,不同的 SaaS,不同的路径。他们的客户要求集成到不同的数据流中。他们围绕企业 5g 做出了决定。他们有销售人员过来说,“嘿,你应该部署一个校园 5g 网络,然后你可以重新考虑你的架构并从根本上启用新的用例等等。

当然,他们正在看这个并且他们说,好吧,我们知道如何管理我们的 MES 和我们的 ERP 等等。我们如何确保我们拥有能够扩展以满足所有这些新要求的架构?显然,这意味着他们必须重新考虑如何发展他们的 IT 骨干网,使其成为一个更加灵活的架构。听起来这就是你的心态。它使人们能够做到这一点。那么我很好奇,在开源方面,是否默认情况下任何时候在此平台上开发的代码都可以供社区使用?或者人们是否必须基本上选择加入并说,我将提供我开发的这个工作流程?如果是这样,确保人们基本上不会搭便车的激励模型是什么?

Rob:这是一个很好的观察和问题。我们将内容开放平台关闭的原因之一就是搭便车问题。在开源中搭便车可能有点挑战。我们设计它的方式是随着时间的推移而演变的。我们这样做已经有 15 年多了——你可以追溯到戴尔时代。哪里开放,哪里有社区,哪里有协作,这些都非常重要。因为我们支持的其中一件事是高度安全的气隙环境,甚至只是像银行这样的敏感环境,他们正在建立他们不希望公众看到的自动化。它不能公开。因此,设计的一部分必须是这种非常有意的平衡,这些是我内部的东西,我保留,这些是开放的,在我分享的社区中。

很多时候人们所做的是,与其试图取得所有权——这对我们来说变得很重要——而不是表现得好像每个人都应该合作并为开源做出贡献并制造压力,许多开源社区都这样做.这对他们的模型很有意义。这对我们的模型没有意义。与其制造压力让人们公开承诺以获得证书并在社区中建立起来,我们要做的是,如果客户有他们认为可以共享的作品,我们可以帮助他们将其纳入共享内容即使它没有显示为来自他们。

所以我们试图通过这个实现的是我们得到共同的重用。与其尝试构建,嘿,你必须回馈开源,如果人们有他们想要共享的东西并且他们可以直接或通过我们回馈社区,两者都很好。因为目标是重用,而不是社区,每个人都在这里获得社区证书和信誉。这些是运营商。这是开发人员非常擅长分享此类内容的事情之一。运营商没有那么多。我实际上可以解释为什么这对我来说是一个重要的时刻。当您是操作员时,当您从其他人那里获取新代码时,它不会针对您的环境和场景进行测试。这是让我们很难达到 RackN 解决这个问题的原因之一。运营商往往不会。对于运营商,我将包括 IIoT、构建边缘基础设施的 IT 人员。对于从环境之外获取代码,他们应该非常紧张,实际上是紧张,因为这可能会破坏他们的操作系统。

没有人愿意花时间在自己的环境中测试其他人的东西。他们只是没有开销来做这件事。因此,您面临着这样的挑战,他们不想编写很多负面的自定义软件。这意味着他们必须维护它。但他们对引入超出其范围的软件自动化感到非常紧张。我们与很多运营商进行过这样的对话,他们总是很紧张。他们就像,“等一下。我不想拿——我是一家惠普商店。我不想拿任何与戴尔相关的东西。我不需要它。这很复杂。这很糟糕。我要么把它踢到路边,要么不接受。”这是我们不断回归的经典平衡。

这就是为什么在正在发生的事情中有一个策划过程非常重要,并且实际上能够打电话给某人说,“好的,你已经对我的自动化进行了这些更改。你能帮我让它工作吗?”因为如果你在另一家银行或电信公司工作,你不会打电话给她的其他接线员或去银行参加社区会议,然后说,“嘿,我需要帮助修理你坏了的东西。 “这是它掉下来的地方。这就是我们在 OpenStack 时代遇到麻烦的地方,操作员没有时间帮助别人解决与他们正在解决的问题不同的问题。如果相同,则可以。但是,如果它甚至略有不同并且每个环境都略有不同,那么当你有很多负担时,花时间解决别人的操作问题就会困难得多。但是这个锻炼能力真的很重要要了解。所以你必须仔细考虑这意味着什么。

对我们来说,这意味着我们正在努力与客户取得更大的成功,让他们实现 90% 以上的共享自动化。当您开始达到这样的阈值时,它又回到了您的第一点。你开箱即用了多少?从这个角度来看,你有多少开箱即用的工作?这是一个完全变革的观点。但是你问的是开源。我们的一些客户会分享一些东西,因为他们不想维护它们,他们意识到他们不想拥有它。对我们来说,这通常意味着他们正在将那段代码的所有权转让给我们,转让给 RackN——一般来说是社区,但具体来说是 RackN。如果出现问题,我们将修复它。这成为开源的一个非常重要的部分。

如果您接受代码进入开源社区,社区必须愿意接管其运作方式的所有权。通常,代码的作者可能在操作环境中。这确实是运营商不太可能在很长一段时间内成为某物的所有者。他们完成了。他们继续运行它。他们不担心社区如何处理它。为了让我们所描述的模型发挥作用,您必须有一个管理者来维护和支持这些东西的进展。它对于创建重用至关重要。

埃里克:是的,很清楚。好吧,这听起来像是一个很好的双赢。这样他们就可以将长期所有权转让给您。通过这样做,他们可以从每个人那里受益,包括 RackN 和任何其他在未来改进该工作流程的人。然后作为回报,您可以与更广泛的社区分享。

罗布:对,是的。这是一个非常良性的循环。因为这意味着随着情况的改善,他们会不断受益。我还没有遇到过任何一个客户认为他们能够通过设置 BIOS 来增加商业价值。我们的客户有非常具体的权重,他们需要高频交易环境的 BIOS 设置。那个,我明白了。但是设置它的实际过程并没有给他们增加任何商业价值。所以他们很高兴所有这些都标准化了。安装操作系统、安装应用程序或进行安全审计也是如此。它们通常对每个客户都是独一无二的,但它们之所以独一无二,是因为人们没有办法共享和重用该自动化。这要求您必须达到可重用性的阈值并使其物有所值。

埃里克:清楚。好吧,帮助我了解公司采用 RackN 解决方案的情况。因为,当然,他们都有自己现有的遗产,所以他们将以某种方式将其整合到他们已经在使用的东西中。也许我们可以先快速回顾一下您实际与谁一起工作。我想这是一个非常水平的技术,所以它可能是世界上的任何人。但是,当然,公司仍然倾向于专注于特定市场,即使它们可以假设为任何人服务。也许首先,你和谁一起工作?那么,如果您只是想选择一个示例来说明某人将如何实际部署 RackN 并开始使用该解决方案,那会是什么样子呢?

罗布:我很乐意。你说得对。这是非常横向的。我们跨越了很多不同的行业。我们确实有很多银行业务。这是最初的用例之一,因为银行需要能够从头开始构建全新的数据中心作为应急响应。所以他们不能失去数据中心。他们必须能够在一周内从无到有地构建一个。所以我们被召集进来,因为这个过程通常需要几个月的时间。他们需要花几个小时。所以我们被要求这样做。有趣的是,边缘和电信在构建新的手机、塔式站点或新的远程站点方面有非常相似的要求。我需要能够自动化它。所有这些供应商都有多个硬件供应商。所以它们也不能单流。抽象硬件然后完全自动化该过程的能力,这两者都是我们的关键要求。

让我非常具体和具体地说明它的样子。因为 RackN 不寻常,因为我们不是 SaaS。我们是一家软件公司。我们出售的东西之一不仅仅是软件,还有控制——自我控制和自我管理。因此,我们的客户会在他们的数据中心下载并安装 Digital Rebar。它非常小,运行简单,可执行。您可以在与 Raspberry Pi 一样小的空间上运行它。然后从这个角度来看,它将处理带外管理、引导提供、整个生命周期控制过程。初始安装中包含的所有内容都可以进行版本控制并作为一个包放在一起。因此,您可以带着一个 USB 记忆棒出现,它具有您的数据中心或站点需要运行的确切版本,包括您的自定义部分或标准库部分、二进制文件本身、ISO。所有这些东西实际上都放在一起,我们称之为版本集,然后运行到系统中。然后当机器启动或连接时,它们将被识别、发现、验证和配置。所有这些都是直接从系统中出来的自动化工作流程。但这一切都从基本上只是在数据中心运行一项服务开始,然后安装该内容。

内容的版本控制很重要。基础设施即代码对我们如何做这件事以及我们做什么有着难以置信的深刻理解。因此,我在这里说的不仅是 Digital Rebar 服务,而且还有我运行网站所需的所有内容。它是版本控制的和不可变的。意思是,它不能改变。它以只读副本的形式出现。支持它来启动一个站点,这就是 Digital Rebar 的工作原理。不需要外部网络。没有 VPN。没有回 RackN 的电话。从这个角度来看,它基本上都是一个独立的包。

让我们做的一件事,真正值得注意的是,通常,该站点带来的体验并不是您第一次运行该软件。我们这样做的方式以及我们所有最有效的客户所做的是,他们将构建一个开发环境,他们可以在其中获取并修复他们拥有的东西。他们通常会运行他们需要的硬件版本或他们将构建的软件版本,所有这些都在一起。他们将采用精确的自动化,因为它现在可以作为一个版本提升,将其移至测试环境。他们会让另一个人完成整个过程,测试它使网站上下移动,排练,排练,排练。

练习代码的次数越多,您就越有信心。然后,当他们真正提升他们需要的一切的确切版本并将其移至他们的生产站点时,他们真的有信心这会起作用,因为他们已经能够对其进行测试。如果他们有问题,他们现在可以复制问题,修复它,采用他们正在工作的自动化版本并将其移动到新站点。这在一定程度上意味着我们还制定了很多第二天的流程。所以这不是你第一次提出来。但是你能重置网站吗?可以添加或更改吗?你能变形吗?所有这些都会影响这些系统的工作方式。这一切都回到了这个想法,我实际上可以准确地说出我的网站上正在运行什么自动化,复制它,克隆它,看看版本中的所有部分到底是什么。这种清晰度对于真正开始那段旅程具有变革性。

埃里克:明白了。不管怎样,时间线是什么样子的——我的意思是,我猜在某种程度上,因为你说的是在几小时内部署的能力。但我想这意味着该公司已经进行了预配置,因此他们可以复制和粘贴并快速启动和运行。也许这就是我的假设。但是当您第一次与新客户合作时,仍然会有一些配置。在这里启动和运行某些东西的时间表是什么样的?

Rob:是的,我的意思是,通常情况下,只需一天或更短的时间就可以获得基础知识,我称之为开箱即用的工作流程。我们已经做了这么多,大多数事情都是开箱即用的。通常会有一些人的网络。他们必须充分了解自己的网络才能将事物组合在一起。然后,根据客户想要做什么、添加或更改什么,通常需要几周的时间来学习如何构建自动化、进行扩展、连接我们的 API,或回拨给您的蜜蜂。这通常是人们花时间的地方。它正在构建,采用标准管道,然后扩展它以运行 Ansible 配置,或者引入他们拥有的脚本,或者打电话给他们需要协调的不同系统,以协调对我们系统的调用。我们做了很多工作来简化这一切。但是拼接在一起实际上是这些过程中非常重要的部分。它不像 Digital Rebar 那样工作。这实际上是您系统中正确的环境工作。

对我来说有趣的部分是观察客户然后接受——他们学习如何将这个基础设施作为代码片段来做。然后将它们拼接在一起,构建为自己的内容包。他们不必与我们分享。这些是他们的内部工作,但他们随后将其添加到组合中。然后,这就成为一个标准化的部分,他们可以在自己的基础设施中重复使用。这通常是有一些学习曲线的部分,然后他们将构建和测试该工作。我们一直在社区频道中看到这种情况。这是人们了解如何使其发挥作用。

人们需要一点时间来习惯的另一件事是我们的多站点功能。由于我们将软件构建为站点独立的方式,它是我见过的唯一可以在每个站点实际运行控制平面的软件之一。然后您可以将另一个 Digital Rebar 服务器附加到每个站点。它不是集中控制。它实际上是一个分布式联邦。但是您可以让 Digital Rebar 服务器连接到多个边缘站点,然后创建一个聚合视图,这样您就可以真正看到您的所有基础设施,即使它由不同的站点管理。如果您在管理站点与 API 对话,它会将请求转发到边缘。因此,即使我们在一天结束时都是站点自主的,您也可以像拥有聚合基础设施一样行事。那是一个非常强大的软件。人们需要一点时间来适应,因为他们随后必须了解他们如何对自动化和控制进行分层。从一致性多站点自动化的角度来看,它非常强大,而且与我在行业中见过的任何其他东西都不一样。特别是,因为它是一个自我管理的软件,所以它不是 SAS。所以我们也不在他们中间。

埃里克:没错,是的。确切地。我知道。我认为这与 SaaS 是一个不同的世界。我正要询问定价。因为你说 SaaS 的定价模型往往非常不同。但是你在你的网站上相当透明地展示了这一点。有物理基础设施、虚拟基础设施、支持层和功能层。因此,就您所工作的公司的要求而言,这听起来也相当灵活。

罗布:是的,完全正确。我们努力使它变得简单。您必须猜测或怀疑的定价对我们来说真的很难。很容易知道您要连接多少个系统。对于虚拟,我们认为这是一个高水位线。我们鼓励从事虚拟工作的客户拥有非常动态的虚拟环境。我们使它变得容易的一件事是创建和销毁虚拟机,并且在构建、销毁、创建方面具有非常类似于云的动态。尽可能快地完成这个过程。我们不想阻止它。我们花了很多时间思考激励和抑制因素。因此,我们希望人们拥有一个充满活力的环境。

我们鼓励的另一件事是我们不对这种多站点功能收取任何额外费用。因此,即使价值巨大,如果您拥有数百个 Digital Rebar 端点,我们也不会收取额外费用。我们称其为站点。这样,如果您想拥有一个开发测试产品,我们不会向人们额外收取拥有这些多个站点的费用。或者,如果您有四个完全自主的团队,然后将数据集中到一个集中站点,我们希望人们使用该功能。它改变了您管理基础设施的方式。所以我们决定保持简单。它是您管理的机器总数或虚拟机的高水位线。就是这样。您可以使用数百个站点来做到这一点。我们没关系。

埃里克:是的,很好。非常清楚。好吧,走着瞧。也许结束我们谈话的好地方是展望未来。我敢肯定,过去几年你一定很忙。我想 COVID 一直是 IT 社区非常不幸事件的一线希望,技术采用的速度大大加快。但现在你可能有一点喘息的空间,也可以考虑未来一两年的发展。有什么好兴奋的?在 RackN 或只是生态系统中更广泛的发展中,你感到兴奋的是什么?

Rob:嗯,对我来说,这些是一致的。我们对这种向更面向 IT 的对话的边缘过渡感到非常兴奋。自我们成立以来,RackN 一直围绕着高度分布式的边缘站点构建,即拥有大量站点并且必须对其进行一致管理的想法。无论他们是不同的客户还是客户内部对我们来说都非常重要。但是,我们参与的所有边缘、物联网、IIoT 对话通常都由业务的运营或 OT 方面主导,而不是业务的 IT 方面。我们一直在观察,因为我们正在慢慢地在该领域进行越来越多的 IT 对话。这真的是我们感到兴奋的地方。我们不是为人们构建 IT 网关网络。我们将使 IT 网关能够在 Kubernetes、K3s 或 NVMS 中运行。引入 IT 管理,使这些事情更加可重复。

但在我们看来,该行业还没有做好准备,一直在寻求这些领域的 IT 解决方案。所以我们很高兴开始看到并进行这些对话,等一下,我有 100 个站点。或者,我在一家工厂里拥有不安全且需要管理的 PLC,以及地板上的 PC 和实际上具有 restful API 和标准协议的物联网设备。我如何开始将其视为必须具有一致的自动化管理的 IT 环境?对我来说,那次谈话让我非常兴奋。我们非常有能力在这些地方提供帮助。

我在职业生涯中学到的一件事是,进行一场有人还没有准备好进行的对话是没有多大用处的。所以如果人们不问问题,等等,我可以自动化所有这些东西吗?我可以标准化流程吗?我可以创建可重用的工作流程吗?当人们开始问这些问题时,我很高兴能就增加您帮助某人管理的设备数量和设备类型进行非常有意义的对话。对我来说,未来两年只是物联网(更传统的物联网)中 IT 对话的出现。

埃里克:迷人。好吧,希望我们可以——我们只是九牛一毛,但我们可以尽自己的一份力量来推动市场的发展。与我们合作的许多公司都处于 IT 和 OT 开始紧密合作的情况,而且环境变得非常复杂,他们确实需要开始大量关注自动化和技术以帮助管理它。此外,他们正在构建比过去发展得更快的系统。

Rob:我让专业人士需要停止做的事情——这一直是我们这次谈话的主题——正在接近现有的技术,这些技术已经过时了。它会在那里。这是我认为的一件事,要让 IT 在 IoT 和 OT 以及讨论中取得成功,你必须放弃“如果它与我想要的方式不完全匹配,那么它就不会起作用。”与此同时,我确实相信云技术将开始被过滤并成为必需品。这是您的听众应该考虑的事情。我们将开始拥有越来越多的控制平面、API 集成或工具。它仅部署在容器中,因此在基于容器的系统中进行管理。因此,这些控制平面从云端返回到本地基础设施和自动化系统、工厂和电话亭,所有这些地方。这就是部署软件的方式。因此,这将在传统上不必做这项工作的地方推动大量 IT 需求。这将是一个巨大的融合,这些不同技术的这一点。人们必须为此做好准备。这将推动物联网对话。

埃里克:是的,嗯,就是这样。这是留给我们观众的一个很好的挑战。让我快速分享您的网站。所以对于听众来说,这是 rackn.com。 Rob,如果人们有兴趣继续对话,他们联系公司的最佳方式是什么?

Rob:是的,最简单的方法是通过我们的网站。您可以找到几种不同的方式与我们联系。我们是@rackngo。在推特上,我是@zehicle。这可以追溯到我的电动汽车时代。在 Twitter、Hachyderm、LinkedIn 上,我们无处不在。很容易找到我们,RackN。

埃里克:太棒了。罗伯,感谢您今天抽出时间。谢谢。谢谢你,埃里克。

联系我们

欢迎与我们交流!

* Required
* Required
* Required
* Invalid email address
提交此表单,即表示您同意 IoT ONE 可以与您联系并分享洞察和营销信息。
不,谢谢,我不想收到来自 IoT ONE 的任何营销电子邮件。
提交

Thank you for your message!
We will contact you soon.