文字记录 · CC BY 3.0

主题小组讨论:企业中的 SMACK - 由 Mesosphere 的 Elizabeth K. Joseph 主持

本页标题、字幕、摘要和阅读笔记为已保存的 AI 译文,可能有误。时间戳与来源一致,可展开查看原始字幕,并对照原视频核对。

企业小组成员讨论 SMACK 数据栈、联网汽车分析、基础设施选择以及跨云环境管理数据。

The Linux Foundation · 发布于 · 19 分钟 · 英语 · 许可证:CC BY 3.0 · 来源:在 YouTube 上观看

转录来源:Vidleaf上的自动语音识别(可能包含错误)。AI标点由Vidleaf添加;保留原始措辞和时间戳锚点。原始转录可在下方获取。

AI生成的摘要

来自奥迪、德国电信、ASML 和一家荷兰设备制造商的小组成员介绍了各自的公司及其对 SMACK/SMAC 栈的使用。奥迪在灵活平台上收集并处理汽车产生的数据,其联网汽车后端使用 SMACK 的全部五个字母来摄取数据、用 Spark 进行实时分析并将反应发送回汽车;它运行在亚马逊上,但力求保持云无关,DCOS 帮助在多个提供商之间分散负载。德国电信使用 DCOS 和 SMACK 栈,在帮助客户选择接入网络方面创造更多价值,而一个 Georgia Telecom 案例使用 Mesos 和 Kafka,并计划采用 Spark。这家荷兰设备制造商选择 Mesos 作为基础设施,以扩展计算和存储,并应对从单个故障模式一直到跨数据中心可用性的问题。小组成员将速度、实时分析、不丢失数据和分布式工作负载列为关键优势,并讨论了容器、迁移建议、文化与技能,以及 SMAC 栈 2.0 的优先事项。该片段表示必须将更多 AI 组件纳入该栈,并称这对于构建带有实时事件的地图层、从而在未来实现自动驾驶至关重要;即使包内容不同,SMAC 栈这一标签很可能仍会保留,类似于 LAMP 仍可下载,未来在基础设施层面预计会有很大变化,例如新的编排框架,而构建在客户处运行的产品需要关注可维护性、监控、安全性以及静态和传输中的加密,实际上就是创建一个“SMAC 企业”。

根据文字记录生成。请对照原始视频检查链接段落。

带时间戳的章节摘要

小组成员自我介绍及其公司

  • [0:00] 在提问开始前,每位小组成员被要求简要介绍其公司、公司业务以及自己的背景。
  • [0:14] 来自奥迪的 Stefan Bauer 领导一个部门,负责收集并处理汽车在使用过程中产生的所有数据。
  • [0:28] 奥迪主要在建一个灵活的平台,以处理大量数据并为客户提供良好的新产品。
  • [0:41] Stefan 在奥迪工作了大约 15 年,过往主要做嵌入式软件,现在正扩展到后端软件,使汽车成为物联网世界的一部分。
  • [0:58] 同样来自奥迪的 Hubert Fischer 是收集每周传感器数据的物联网项目的高级项目经理,也是公司从纯硬件公司向物联网公司转型的一部分。
  • [1:19] 来自德国电信的 Oliver Goldisch 是网络与服务领域的经理,使用 DCOS 和 SMACK 栈,在帮助客户选择接入网络方面创造更多价值。
  • [1:45] Christian Worps 是 ASML 的产品架构师,从事计算与数据平台工作,他表示他们接触 SMACK 栈相当晚,今年年初才开始,目前并未使用全部字母。

荷兰设备制造商的基础设施需求

  • [2:32] 该公司是一家荷兰设备制造商,向客户发送机器。
  • [2:42] 这些机器会产生大量数据。
  • [2:48] 其计算平台需要适当地扩展计算和存储。
  • [2:55] 它还需要应对从单个故障模式一直到跨数据中心可用性的问题。
  • [3:06] 该公司选择 Mesos 作为基础设施,以运行计算和数据能力。

Georgia Telecom 使用 SMAC 栈实现 Wi-Fi 自动化

  • [3:20] 他们正在使用 Mesos 和 Kafka 部分,并计划未来转向 Spark 计算。
  • [3:31] Georgia Telecom 的问题大约始于两年前。
  • [3:45] 他们尝试实现自动化,让客户能够接入质量非常好的 Wi-Fi 网络,而如果 Wi-Fi 真的很差,就无法接入。
  • [3:55] 他们开始构建一个移动应用,收集关于客户所面对接入网络的大量信息。
  • [4:06] 他们希望在已部署的移动应用上给出建议,说明客户将被引导至哪些 X 网络。
  • [4:17] 采用旧式栈基础设施是相当大的挑战。
  • [4:24] 他们预计客户群会更大,而 SMAC 栈的分布式设计方式给了他们相当多的机会。

基于云无关栈的联网汽车数据平台

  • [4:36] 数百万辆汽车配有车载通信单元,通过监听汽车的 bus 系统来收集数据。
  • [4:48] 这些单元将生成的数据发送到后端。
  • [4:53] 该后端项目使用 max 栈的全部五个字母来摄取数据。
  • [5:01] 后端进行实时分析以识别模式,并在汽车中向客户引发反应。
  • [5:14] Spark 正是用于这一特定目的。
  • [5:20] 该基础设施目前基于亚马逊,但其方针是保持云无关。
  • [5:28] DCOS 有助于在不同云提供商之间分散负载,以利用昂贵的云资源,并保持独立于任何云提供商。
  • [6:00] 作为一家全球性公司,全球解决方案非常重要,而像中国这样的一些国家的法律不确定性使得独立于单一基础设施提供商变得至关重要。
  • [6:28] 混合解决方案是可能的,作为大众集团的一部分,有大量内部数据中心容量可以在未来与外部数据中心一起使用。

用于实时汽车数据的 SMACK 栈

  • [6:48] 一些小组成员使用完整的 SMACK 栈:Spark、Mesos、Akka、Cassandra 和 Kafka。
  • [7:02] 一位小组成员使用了三种 SMACK 技术。
  • [7:24] 对一位小组成员来说,最重要的好处是速度,实现实时分析。
  • [7:35] 他们希望立即对单次通话中发生的情况做出反应。
  • [7:44] 他们需要从车队其余部分收集知识,并直接发送到单次通话中。
  • [7:57] 重要的是不丢失任何数据,数百万辆汽车每秒发送数百万条数据。
  • [8:12] 他们需要能够收集这些数据而不丢失任何数据的基础设施。
  • [8:18] 分布式工作负载是 SMACK 栈的一个优势。
  • [8:24] 在没有客户的情况下,基础设施可以缩减规模,这也不错。

容器和 SMAC 栈基础设施

  • [8:53] 过去一年的项目表明,他们获得了扩展的能力和灵活性,实现了高可用性,并动态使用和重用硬件级资源用于应用程序。
  • [9:16] 他们在计算和数据平台中构建的是构建在上面的应用程序的基础,为应用程序开发者提供了一个中间层。
  • [9:30] 将所有内容放入容器并非易事,他们完全重新构建,而不是逐步进行。
  • [9:44] 思维转变相当困难,技术目标有时可能显得有点过时,人们会问虚拟机在哪里。
  • [9:55] 他们期待软件定义网络和软件定义存储作为整个 SMAC 栈的良好下一步。

SMACK 栈迁移建议

  • [10:30] 建议从全新领域开始,从头获得 SMACK 栈的所有优势。
  • [10:46] 从开源 POC 开始,但尽快转向企业版本。
  • [10:58] 大公司需要专业支持和专业服务。
  • [11:06] 董事会可能会问,当出现问题时该找谁,例如停机或错误。
  • [11:22] 许多董事会成员认为开源是给怪人的,不是给企业的。

云迁移:文化、技能、沟通

  • [11:42] 企业版本有助于说服利益相关者,这是一种专业的工作方式。
  • [11:58] Greenfields 很幸运能在干净的亚马逊基础设施上开始一个新项目。
  • [12:09] 另一个团队必须说服管理层部署在 Azure 上而不是与运营团队一起,因为他们使用公共云服务更快。
  • [12:20] 他们直接开始使用高级支持和高级企业许可证,这在供应商支持下更容易。
  • [12:29] 以非常小的周期进行迭代对他们帮助很大。
  • [12:51] 一家公司有一个硬件平台运送给客户,它必须从中发展出来,将部署转移到客户的数据中心。
  • [13:12] 他们必须在创建与客户一起的新流程的同时,保持现有计算栈投资活跃。
  • [13:33] 从 Java 企业世界迁移到更细粒度的容器化架构是可行的,也是可以做到的。
  • [13:52] 挑战包括内部新的软件栈,需要说服人们并展示它确实有效。
  • [14:22] 在客户方面,硬件栈的所有权必须从业务人员转移到他们自己的 IT 部门。
  • [14:52] 沟通和信任非常有帮助,包括依赖软件开发人员和架构师,而不是用太多的比较和 POC 来打扰他们。
  • [15:29] 在 SMAC 栈上工作需要完全不同的技能组合,找到优秀的人才相当具有挑战性。

SMAC 栈 2.0 和未来企业需求

  • [16:46] SMAC 栈目前正在实施并运行良好,引发了关于其未来形式以及缩写是否会改变的问题。
  • [16:57] 对于 SMAC 栈 2.0,关键优先事项是软件定义网络和软件定义存储。
  • [17:29] 产品和 SMAC 栈中每个应用程序的紧密集成将是一个巨大优势,有助于避免迁移到更高版本时的停机时间。
  • [17:33] 必须将更多 AI 组件实施到栈中,这对于构建具有实时事件的地图层以实现未来的自动驾驶至关重要。
  • [18:05] 即使包内容不同,SMAC 栈标签可能会保持不变,类似于 LAMP 仍然可以下载。
  • [18:16] 未来的大部分变化预计将在基础设施层面,例如出现新的编排框架。
  • [18:34] 构建在客户处运行的产品需要注意可维护性、监控、安全性以及静态和传输中的加密,有效地创建一个“SMAC 企业”。

[0:00] 所以我只想快速请各位分别介绍一下自己。说说你们来自哪家公司,以及简单介绍一下你们公司在做什么。就在我们进入提问环节之前,简要说说,也许还有你们自己的背景。那么,好吧。从Devin开始吧。我叫Stefan Bauer。我来自奥迪。我负责一个部门,这个部门负责,嗯,这么说吧,收集和处理我们汽车在使用过程中产生的所有数据。所以……我们主要是在搭建一个平台,这个平台应该能够非常灵活,并且能够处理大量数据。

[0:36] 的ZB人员。能够为我们的客户做出好的新产品。所以就我个人而言,我在奥迪已经——我猜有15年了。我们在软件方面有历史。当然,主要是在嵌入式软件方面,而现在我们也在扩展到后端软件,这样汽车就成为物联网世界的一部分。是的,我是Hubert Fischer,也来自奥迪。我是物联网项目的资深项目经理,负责收集每周传感器数据。我之前在公司内部参与过几个项目,现在我是公司从纯硬件开发公司向物联网公司转型的一部分。

[1:19] 你好,我叫Oliver Goldisch,来自德国电信。我是网络与服务领域的一名经理。我们特别在使用DCOS和这套Mac技术栈,为客户在选择接入网络方面创造更多价值。所以我们——我稍后可以简要提供更多更新。但是,嗯……是的,我们为此使用smack技术栈。是的。早上好。我叫Christian Worps。我是产品架构师,或者是在ASML内部。

[1:51] 所以我在为一个计算和数据平台的项目做这件事。我们,我想,在SMAC技术栈方面还相当新。所以我们今年年初才开始。而且我们现在并没有使用所有的字母。所以我渴望在接下来的两天里学习和交流信息。很好。那么我们还是从你开始。我有点想问,尽可能多地分享你们的基础设施情况,关于你们使用什么技术、基础设施的规模,任何你们愿意分享的内容,我相信。

[2:28] 很多观众会有兴趣知道。是的。嗯……对我们来说,挑战在于我们是一家荷兰设备制造商,我们把机器发送给客户。这些机器在运行并产生大量数据,而我们的计算平台现在需要能够适当地扩展计算和存储。但也需要能够真正妥善地处理单个故障模式,直到跨数据中心可用性。

[3:04] 那就是——我们选择了Mesos作为基础设施,这样我们实际上可以运营——计算和数据能力。所以我们——在这个技术栈中,我们——使用Mesos和Kafka部分。我们未来将走向Spark计算。这就是我们——Josephine。Oliver,你跟我们说说德国电信什么情况?是的,所以我们有一个问题,大约两年前开始的。我想每个人都知道,至少……

[3:41] 我们的胸牌上有所有Wi-Fi密码。但实际上我们试图将其自动化,这样我们的客户可以接入Wi-Fi网络,但要有非常好的质量。所以如果Wi-Fi真的很差,你就连不上。所以我们开始构建的是一个移动应用,它收集大量关于接入网络的信息。作为客户你所面对的网络,我们希望在已部署的移动应用上给出推荐,告诉你将被引导到哪些X网络。

[4:17] 而用旧的技术栈基础设施来做这件事相当有挑战。而且既然我们——我们预计会有更大的客户群到来。SMAC技术栈设计的分布式方式在这里给了我们很多机会。是的,所以我们有数百万辆汽车配备了用于数据收集的车载通信单元。所以它们在监听汽车中的总线系统。

[4:48] 并将生成的那些数据发送到后端。所以后端是我们要建立的项目。我们使用这个max技术栈的全部五个字母。来摄取那些数据,对进来的那些数据进行实时分析,识别模式,并在汽车中向客户引发反应。而且我们确实为此特定目的使用Spark。

[5:20] 整个基础设施目前基于亚马逊,但我们的方针是现在和将来都保持云无关。为此,嗯,DCOS对我们帮助很大。在不同云提供商之间分散负载,以完美利用昂贵的云资源,并且我们保持独立于任何云提供商,所以我们可以使用DCoS从一个工具切换到另一个工具。

[5:56] 很好。也许让我再补充一些方面。由于我们是一家全球公司,对我们来说,拥有全球解决方案也非常非常重要。为此,我们知道在不同国家,也许我们可以使用MSR,也许我们不能使用,也许看向中国,总是有一点。这么说吧,法律——不确定性。你能做什么,所以能够独立于单一基础设施、基础设施提供商,是非常非常关键的。

[6:28] 甚至有可能作为大众集团的一部分做一些混合解决方案。我们也有很多内部数据中心容量。所以未来,我——我的想法是我们真的可以为此目的同时使用内部和外部数据中心。很好。所以我想我从你们中几个人那里听到了一些关于使用完整smack技术栈的内容。Spark、Mesos、Akka、Cassandra和Kafka。所以你们在使用所有字母,我想,这里的大多数小组成员。

[7:02] 然后你用了其中三个,对吧?是的。好的。所以我想具体说到 SMAC 技术栈和这一系列技术,也就是说,在应用层面上,你已经稍微提到了一些,但如果你还有什么想补充的,这个特定的数据驱动管道为你带来了什么。嗯,对我们来说,我想最重要的是快,最快。因为我们想在这里做实时分析。所以我们真的想走出去,进入能够对单次通话中发生的情况立即做出反应的领域。

[7:42] 因此,我们必须能够——了解外面正在发生什么,并且能够将从车队其余部分收集到的知识直接发送到单次通话中。所以这对我们至关重要。是的,除了整个分析方面,对我们来说不丢失任何数据也很重要。你可以想象,我们有数百万辆车在几秒钟内发送数百万条数据。所以我们需要某种基础设施。

[8:12] 它能够收集这些数据并且不丢失其中任何一条。是的,当然。再补充一点,分布式工作负载是这套 Mac 技术栈的一大优势。哦。特别是如果你那里没有客户,你确实可以缩减基础设施规模,这也不错。是的,这正好引出了我的下一个问题。我们从那里开始。这算是谈到应用层面,但也谈到基础设施层面,使用容器、DCOS、Mesos 和 SMAC 技术栈如何真正帮助你们构建基础设施并为未来做规划。如果你能稍微谈谈这一点。

[8:52] 谢谢。所以我们所期待的是,而且该项目过去一年也表明,我们实际上获得了扩展的能力和灵活性,获得了高可用性,也能够动态使用和复用硬件层面上可供我们应用程序使用的资源。而我们在计算和数据平台中构建的东西,是构建在其之上的应用程序的基础。

[9:23] 所以我们也为应用程序开发者提供了一个中间层。当然,再补充一点,把所有东西都放进容器并不是一条容易的路。你们是逐步完成的,还是一次性大切换?我们完全新建了它。新建的?因为思维转变相当困难。嗯,技术目标有时可能显得有点老派。所以当我启动这个项目时,我们问,你们,那虚拟机在哪里?所以——是的。

[9:55] 是的,既然谈到容器,我们期待软件定义网络和软件定义存储。所以那将是整个 SMAC 技术栈非常好的下一步。谢谢。那么正如你们所看到的,我们观众中有很多人正计划迁移到 SMAC 技术栈,或者才刚刚开始。如果你们能谈谈在迁移到 SMAC 技术栈过程中遇到的一些挑战或成功经验,让大家可以从中受益。谢谢。

[10:26] 我想我们在历史上有一个经验,我总是可以推荐。尽量从全新环境开始。嗯……真正从零开始,才能获得这种 SMAC 技术栈带来的所有优势。第二个问题是,当然先从一些基于开源基础的概念验证开始。但我们真的想要达到企业级水平。因为对我们公司来说,我们是这一带的大公司。

[10:58] 你需要专业支持,你需要专业服务,所以。尽快切换到企业版本。是的,这不是在这里做广告。我没让他说这个。不,正如你所看到的,在我们看来,当他们去我的董事会说,好,你要引入新架构、新软件,所以——对比支持结构。当出问题时谁能响应,停机怎么办,一些问题、一些缺陷怎么办,等等。因为很多董事会成员认为开源是给怪人用的东西。

[11:33] 某种东西,是的,你可以在家里做软件开发,但不是给企业用的。所以——为了说服他们这是一种专业的工作方式,企业版本非常有帮助。那么快速回到全新环境,你们有需要迁移的现有基础设施吗,还是真的能够从新项目开始?谢谢。是的,我们很幸运。能够从一个新项目开始。

[12:03] 使用干净的 Amazon 基础设施。补充一下。我们也有同样的挑战。我们需要说服我们的管理层,我们不跟运营团队走,而是部署在 Azure 上,因为我们使用公有云服务更快。我们直接开始使用高级支持——高级企业许可证。有供应商的支持就是更容易。我们以非常小的周期迭代。这对我们帮助很大。

[12:34] 不要走太远。只领先一步。那么你们有遗留基础设施需要迁移吗,还是从零开始?一切都是新的,是的。一切都是新的?那是最简单的方式。我相信是的,是的。那——所以是的,我们实际上是两条路。所以我们确实有一个目前交付给客户的硬件平台。我们的软件运行在其上。但我们必须摆脱那个基础设施?所以我们进入客户的数据中心,部署我们的平台。

[13:08] 第二个方面是,我们必须保留已经投入到计算栈上的投资。因此,我们首先必须与客户共同创建新流程,并保持紧密协作。其次,我们必须确保我们的投资在计算层面仍然保持活跃。因此,我们从 Java Enterprise 世界迁移到更细粒度的容器化架构。它是可行的。它是做得到的。

[13:40] 这就是我们过去所做的。你能再多给一些细节吗——或者有没有什么挑战、具体的事情可以给些建议?关于迁移?两个挑战,它也是一个新的软件栈,而且也在我们组织内部。所以你确实必须做大量的——是的,说服人们并展示它确实有效。这是一种不同的开发方式。但是,是的,你必须做好功课,才能把它带给合适的受众。

[14:15] 嗯……这也有点像社区管理。可以这么说,而第二个方面是在客户那边,他们也面临同样的挑战。从把……是的,那套硬件栈的所有权从业务人员转移到他们自己的 IT 部门。这也是……你需要沟通的事情。你必须在这一点上保持开放,而且,是的。这是做得到的。是的。是的,就像我们在上一场演讲中听到的那样。这不仅仅是技术问题。沟通在这些项目中确实至关重要。完全正确。我对此完全赞同。

[14:50] 嗯。谢谢。也许让我补充一下沟通和信任。所以我认为,对我们来说,非常有用的是——真正能够依靠我们的软件开发人员和架构师,说,好吧,这就是我们想要前进的正确方式。不要用太多的比较、太多的 POC、太多的“哦,请再给我一些见解,为什么我们确切地使用这个特定产品而不是那些”来打扰他们。在 20 其他产品中。

[15:21] 信任他们。还要补充一点,我们在那里遇到的一个挑战实际上是,你需要完全不同技能组合的人才能在 SMAC 栈上工作。所以找到真正能做这项工作的优秀人才相当有挑战性。所以这确实是个难题。这就是为什么我们在那边设了一个 HR 展位,供你们中感兴趣的人了解。我的意思是,你们是否发现已经能够在内部培训一些人,让他们快速上手?或者,你知道的。最后但同样重要的是,我们必须提到,做这个转变并不纯粹是技术问题。在大公司里,这主要是一种必要的文化转变,也是工作模式、你已经提到的技能的转变。所以这远不止纯粹的技术。

[16:11] 是的。关于沟通,我想补充一点,我认为 Ben 昨天在 DCS 下午场。幻灯片上有一句话谈到了沟通。实际上,那里有一个——主题,你可以在那里与任何类型的——是的,与任何主题交流,但归根结底,沟通是关键。是的。那个我真的很喜欢。好的,那么我对你们所有人的最后一个问题是有点展望未来的。所以现在实施 SMAC 栈,它运行良好。几年后我们会在哪里看到 SMAC 栈?SMAC 栈 2.0 是什么?这个缩写会改变吗?

[16:57] 你们怎么想?也许吧,但对我们来说,SMAC 栈 2.0 的重要事情是获得我已经提到的东西,软件定义网络、软件定义存储,那会是件好事。而产品的紧密集成对我们来说也会是一个巨大的优势,可以避免在迁移到更高版本等过程中出现停机。而那是 SMAC 栈内部的组件本身吗?集成还是其他?

[17:29] 是的,SMAC 栈本身以及其中的每个应用。而另一件事是,我们必须在该栈中实施越来越多与 AI 能力相关的组件。这是我们在构想环境、构建带有实时事件的地图层以让汽车自动驾驶方面取得成功的关键因素之一。

[18:03][ 在未来。是的。嗯,SmackStack,我猜,不会改变。我仍然可以下载 LAMP。可能这个包里面仍然有不同的东西。但标签保持不变。我认为大部分或大部分工作将在基础设施层面完成。比如新的编排框架出现。这更多是我看到未来——某些东西会改变的地方。谢谢。嗯……

[18:34] 展望未来,我希望会有一个 SMEC 企业版。无所谓。所以如果你真的构建在客户那里运行的产品,你必须关心可维护性、监控、安全方面、静态加密和传输加密。如果你想自己添加所有这些,那么你实际上就构建了这个 Mac 企业版。谢谢。谢谢。好的。谢谢大家。这很棒。

查看英文原始字幕

[0:00] So I just want to quickly have you each introduce yourselves. say which company you're from and a little bit about what your company is doing. Just briefly before we get into the questions, maybe some of your own background. So, well. Start with Devin. So my name is Stefan Bauer. I'm coming from Audi. I'm heading a department that is taking care of um, let's say, collecting and processing, all the data our cars are producing during the usage of the car. So... We're primarily building up a platform which should be able to be very flexible and to handle a lot of data.

[0:36] of the ZB people. be able to make good new product for our customers. So personally, I'm with Audi since-- I guess 15 years. We have a history in software. of course, mainly in embedded software, and now we are spreading out into the backend software as well so that the car is part of the IoT world. Yeah, I'm Hubert Fischer, also from Audi. I'm the senior project manager of the IoT project collecting weekly sensor data. I've been in several projects before within the company and now I'm part of the transition the company goes through from a pure hardware developing company to an IoT company.

[1:19] Hello, my name is Oliver Goldisch from Deutsche Telekom. I'm a manager in the networks and service area. We are using DCOS in particular and this Mac stack for, uh, creating more value for our customers in terms of selecting access networks. So we're I can briefly give more updates later. But, um... Yeah, we're using smack stack for that. Yeah. Good morning. My name is Christian Worps. I'm product architect or within ASML.

[1:51] So I'm doing this for a project which is a compute and data platform. We are, I think, quite new in the SMAC stack. So we started beginning of this year. and we are not using all of the letters right now. And so I'm eager to learn and exchange information throughout the next two days. Great. So we'll start again with you. I sort of wanted to ask, as much as you can share about your infrastructure with regard to what technologies you're using, the size of the infrastructure, whatever you're comfortable with sharing, I'm sure.

[2:28] Many in the audience would be interested to know. Yeah. Um... For us, the challenge is we are a Dutch equipment manufacturer which are sending out machines to our customers. and these machines are operating and creating a tremendous amount of data and our compute platform now needs to be able to properly scale and compute and storage. but also needs to be able to properly actually tackle individual failure modes down to cross data center availability.

[3:04] And that's-- We have chosen Mesos for an infrastructure that we can actually operate the-- compute and the data capabilities. So we are-- of that stack we are-- using Mesos and the Kafka part. We are heading out to the Spark computations in the future. And that's what we are-- Josephine. Oliver, what do you tell us about Georgia Telecom? Yeah, so we had a problem that we started about two years ago. I think everyone knows it, at least...

[3:41] We have all of the Wi-Fi password here on our badge. But actually we try to automate that so that our customers can get into Wi-Fi networks but with a very good quality. So if the Wi-Fi is really poor, you don't get there. So what we started to build is a mobile application that collects enormous amount of information about the access networks. you're facing as a customer, and we want to give recommendations to own on a mobile application deployed, which X networks you're going to be steered.

[4:17] And this was quite a challenge to go with an old stack infrastructure. And since we're We expect a bigger customer base come there. The distributed way of how the SMAC stack is designed gives us quite a lot of opportunities here. Yeah, so we have millions of cars out there equipped with onboard communication units for data collecting. So they're listening to the bus systems in the car.

[4:48] and sending those data generated out to a backend. So backend is our project to set up. We use all the five letters of this max stack. to ingest those data, to do real-time analytics of those data coming in, identifying patterns, and cause reactions back in the car to the customer. and we do use Spark for that specific purpose.

[5:20] The whole infrastructure is currently based on Amazon, but we have the approach to be and to stay cloud agnostic. And for that, um, DCOS helps us a lot. to spread the load between different cloud providers to get a perfect exploitation of the cloud resources which are are expensive and we stay independent from any cloud provider, so we can switch from one tool to another in using DCoS.

[5:56] Great. Maybe let me add some more aspects. as we are a global company, For us it's very, very important to also to have global solutions. And for that, we know there are different countries where maybe we can use MSR, maybe we are not able to use, maybe in the look to China, there is always a little bit. let's say, legal-- IN CERTAINTY. what you can do, so it's very, very crucial to be able to, independently from the single infrastructure, infrastructure provider.

[6:28] and even to have the possibility to make some hybrid solutions as part of the Volkswagen group. We also have a lot of internal capacity for data centers. So in future, I-- I had the mindset we really could use both internal, external data center, for this purpose. Great. So I think I heard a little bit from a couple of you using the full smack stack. Spark, Mesos, Akka. Cassandra and Kafka. So you guys are using all the letters, I think, most of the panel here.

[7:02] And then you're using three of them, right? Yeah. Okay. So I guess specifically speaking to the SMAC stack and the collection of technologies, that is, what has that on the application level, you've touched upon that a little bit, but if there's anything you'd like to add, what has that specific data-driven pipeline done for you. Well, for us, I guess the most important thing is The fast, the fastestness. as we want to do our analytics here real time. So we really want to go out and to to go into the field of being able to react immediately on situations that are happening in a single call.

[7:42] And with that, we have to be able to-- to know what's happening outside and to be able to to get the knowledge that we gathered from the rest of the fleet to be able to send directly to the single call. So that's crucial for us. Yeah, and next to the whole analytic stuff, it's important for us not to lose any data. You can imagine we have millions of cars sending in seconds millions of data. So we need some kind of infrastructure.

[8:12] which is capable of collecting those data and not losing any of those. Yeah, sure. And just to add, the distributed workloads are quite an advantage of this Mac stack. Oh. And especially if you don't have customers there, you can really scale down the infrastructure as well, which is not so bad as well. Yeah, which sort of leads me into my next question. We'll start over there. It's sort of talking about the application level, but also the infrastructure level, how using containers and DCOS and Mesos and the SMAC stack has really helped you build out your infrastructure and plan for the future. If you could speak to that a little bit.

[8:52] Thank you. So what we are looking forward to and what also the last year of that project has shown that we gain actually the capability and the flexibility to scale, to have the high availability, to also dynamically use and reuse the resources that are on the hardware level available for our applications. and what we build within our compute and data platform. is the foundation for the applications that are built on top of that.

[9:23] So also we are providing a middle layer towards our application. of developers, actually. Sure, and just to add, this was not an easy road to get everything in the containers. Did you do it incrementally, or did you do it like one big switch over? We built it completely new. New one? Because the mind shift is quite hard. Well, Tech goals maybe sometimes uh, occur to be a little bit old fashioned. So when I started the project, we asked, you Yeah, and where's the VM? So-- Yeah.

[9:55] Yeah, and since talking about containers, we're looking forward to software-defined networking and software-defined storage. So that would be a really good next step for the whole SMAC stack. Thank you. So as you're looking, we've got a lot of people in the audience who are planning on moving to the smack stack or are just getting started. If you could talk about some of the challenges or successes that you've had in your migration over to a smack stack people can benefit from. Thank you.

[10:26] I guess one we have in our history, I always could recommend. try to start on a greenfield. Um... to really get up from the scratch to be able to to get all the advantages you get out of such a smack sack. And the second issue is, start with some POSCs, of course, on an open source basis. but we really want to be in the enterprise level So for our companies, we are big companies in the round here.

[10:58] You need professional support, you need professional services, So. as soon as possible change to the enterprise versions. Yes, it's not advertising here. I didn't tell him to say that. No, as you see, in our mind, when they go to my board and say, OK, you're introducing a new architecture, new software, So-- versus support structure. who could recall when something is going wrong, what about a down time, what about some issues, some bugs, whatever. Because a lot of the board members think open source is something for freaks.

[11:33] Something for, yeah, you can do it at your home-based software development, but nothing for enterprise. So-- to to convince them that it's a professional way of working Enterprise versions are very helpful. So to quickly go back to Greenfields, did you have existing infrastructure that you had to move over, or were you able really to start with a fresh project? Thank you. Yes, we were lucky. and be able to start with a fresh project.

[12:03] with a clean Amazon infrastructure. to add there. We had the same challenge. We needed to convince our management that we don't go with our operations team, but rather deployed on Azure because we're faster in using a public cloud service. And we directly started with the premium support--with the premium enterprise licenses. and it's just easier with the support of the vendor. We iterated in very small cycles. This helped us a lot.

[12:34] to go too far. Just one step ahead. And did you have a legacy infrastructure to move over at all, or were you starting from scratch? Everything new, yeah. Everything new? That's the easiest way. I'm sure it is, yeah. How about over-- So yes, we are two-way actually. So we do have a hardware platform that we currently ship to our customers. where our software is running on. but we have to grow out of that Infrastructure? So we move into our customer's data center with the deployment of our platform.

[13:08] And the second aspect is that we do have to keep the investments that we had already to the compute stack So we have to first also create new processes together with our customers, and close collaboration. And second, we have to make sure that our investments stay still active. on the compute level. So the migration that we did from the-- Java Enterprise world into a more fine-grained containerized architecture. It works. It's doable.

[13:40] And this is what we did in the past. Could you give a few more details about -- or were there any challenges, specific things that you could give advice? About the migration? The two challenges, it's also a new software stack, also within our organization. So you do have to do a lot of-- Yeah, convincing people and showing that it really works. It's a different way of doing the development. But yeah, you have to do your homework in order to bring that to the proper audience.

[14:15] um... It's also like kind of community management. You could say so, and the second aspect is On the customer side, they also have the same challenges. from moving the... Yeah, the ownership of that hardware stack from the business people to their own IT department That's also the... things that you need to communicate. You have to be open there and, yeah. It's doable. Yeah. Yeah, it's like we heard in the last talk. It's not just about the technology. Communication is really vital with these projects. Exactly. I couldn't subscribe to that.

[14:50] Hmm. Thank you. Maybe let me add communication and trust. So I think it's For us, it was very helpful to-- to be really Could rely on our on our software developers and our architects to say, okay, this is the right way we want to move. And don't bother them with too many comparisons, too many POCs, too many, oh, please, could you give me some more insight, why we exactly use this specific product and not those? out of the 20 other products.

[15:21] Trust them. And to add as well, one challenge that we had there is actually you need a completely different skill set of people that can work on the SMAC stack. So it's quite challenging to find good people that I actually do the work. So that's really a hard one. That's the reason why we have an HR booth out there for some of you who are interested in. I mean, have you found you've been able to train some people internally already to get them up to speed? or, you know. And last but not least, we have to mention that it's not purely a technical issue to do this shift. It's mostly a cultural shift necessary in big companies and also a shift of the work mode, of the skills that you've already mentioned. So there's lots more than pure technology.

[16:11] Yeah. One thing to add with regard to communication, I think Ben yesterday in the DCS afternoon. had one sentence on the slides which talked about communication. And actually, there was one-- subject that you could exchange there with any kind of Yeah, with any subject, but it all came down to communication as a key. Yeah. That one I really liked. All right, so last question I had for all of you is sort of a future looking one. So implementing the SMAC stack now, it's running well. Where do we see the SMAC stack in a few years? What is the SMAC stack 2.0? Do the -- does the acronym change?

[16:57] What are you thinking? Maybe, but for us, important thing for SMAC stack 2.0 is to get the stuff I've already mentioned, software defined networking, software defined storage, that would be a good thing. And the tight integration of the products together would also be really a huge advantage for us to avoid downtimes while migrating to higher versions and things like that. And that's the components inside the SMAC stack themselves? Integration or the other?

[17:29] Yeah, the SMAC stack itself and each application within And the other thing around is that we have to implement more and more components into that stack regarding AI. capabilities. That's one of the crucial factors for us to succeed in the matters of envisioning environment, building map layers with real-time events on it to let the car drive on its own.

[18:03] in the future. Yeah. Um, SmackStack, I guess, will not change. I can still download LAMP. Probably the package still different things in it. but the label sticks the same. I think that a lot of the majority will do or will be done on the infrastructure level. like new orchestration frameworks appearing This is more where I see future-- something's going to change. Thank you. Um...

[18:34] Looking into the future, I hope that there will be a SMEC enterprise. Doesn't matter. So if you really build products that are running at your customers, you have to take care about maintainability, monitoring, security aspects, encryption at rest in transit. And if you would like to add all this on your own, Then you actually build this Mac enterprise. Thank you. Thank you. All right. Thank you, everyone. This was great.

在Vidleaf工作台中打开

搜索转录文本,选择行,复制带时间戳的引文,翻译。

在工作台中打开 →

署名

“主题演讲小组讨论:企业中的 SMACK——由 Mesosphere 的 Elizabeth K. Joseph 主持”,作者 The Linux Foundation(https://www.youtube.com/@linuxfoundationorg),依据 CC BY 3.0(https://creativecommons.org/licenses/by/3.0/)许可。源视频:https://www.youtube.com/watch?v=NiZFwTWkow0。本页是视频的文本转录,添加了段落分隔和时间戳;创作者与 Vidleaf 无关联,也不为其背书。Vidleaf 添加了 AI 标点和 AI 生成的摘要;原始措辞仍可在本页查看。

您是创作者或权利持有人吗?请求更正或移除:copyright@vidleaf.app(参见关于这些页面)。

最后更新于