2023年KubeCon芝加哥大会精华回顾

这次 KubeCon NA 对我来说是一个非常不同的体验，因为我并不是代表任何公司，也没有自己的展位。不过，我还是玩得非常尽兴，能够和这么多云原生社区的朋友交流真是太棒了。能再次回到芝加哥也让人感到非常高兴，这座城市也对我们照顾得非常周到——我才发现我又有多么喜欢芝加哥的深盘披萨！

参加完 KubeCon NA 2023 后，我有几点主要收获：

1. 云原生社区正在缓慢地拥抱AI/大模型…
2. DevOps已经out了：平台工程才是王道！
3. 那些山里有金子！平台热潮中卖铲子和镐头
4. Kubernetes最好保持未完成状态（并不断进化）
5. 记得开发者体验也很重要哦！
6. 更关注应用程序的开发和集成
7. 云原生通信：捆绑销售更划算？
8. 安全领域大有可为
9. 更多关注可持续性：可观测性、扩展性和FinOps（注：FinOps是指财务管理在云环境中的应用）
10. 社区，社区，社区也很重要

主题演讲中重点提到了开发者体验。

首先，我要对CNCF（Cloud Native Computing Foundation）组织这次活动表示衷心的感谢，同时也要特别感谢所有的演讲者、赞助商、志愿者和参与者。你们真是太给力了！谢谢大家！

参加 KubeCon Chicago 后，我感觉我们已经非常进入云原生技术的晚期采用者阶段。

当然，参加像KubeCon这样的会议，你可能会有一种错觉，认为整个世界都在运行Kubernetes。这并不完全准确，根据Gartner的最新报告，“到2027年，50%的关键企业应用程序将位于集中式的公共云之外[1]”。但如果你仔细观察，大约50%的工作负载已经在云中运行，或即将运行这一事实表明，晚些采用云技术的企业也开始跟上步伐。

创新的传播，维基百科

我从主题演讲和展商在展厅中提出的价值主张中感受到了这种转变。更多地强调了可靠性与可信度，而不是创新；产品套件和易于集成，而不是“最佳”单一解决方案；合作与协作，而不是单个组织的创新更有价值。

考虑到这一点，让我们更深入地看看重点内容。

与同一天举行的 KubeCon NA 伴随活动中的 OpenAI DevDay 形成鲜明对比的是，KubeCon 上没有多少与 AI 相关的内容。如果你还没有观看 OpenAI DevDay 的主题演讲，我鼓励你观看，以一窥未来的趋势。Ed Sim 也在他在每周 What’s Hot in Enterprise IT/VC 通讯 中提供了出色的总结，我的 InfoQ 同事 Andrew Hoblitzell 在 InfoQ 的文章 “OpenAI 在首次开发者日大会上宣布新的模型和 API” 中分享了他的看法。

当然，第一天的 KubeCon 开幕 keynote 确实提到了 AI，但这感觉有点像是“附加”的内容，更侧重于如何为 AI/LLMs 提供基础设施，而不是在开发或运营工作流中实际使用这些技术。不过我也不好太过苛求，因为像 KubeCon 这样的大型活动通常需要几个月的筹备时间，而 AI 的发展速度几乎每天都在变化。

有几个展位专注于“针对云的 ChatGPT”，但我和赞助商的大多数对话都集中在当前的平台建设上。Andrew Fong，Prodvana 的 CEO，在 LinkedIn 上说的“AI 在 KubeCon 实际上并不存在”很好地表达了我对此的看法：

如果你对平台领域中AI和大语言模型的潜力感兴趣，我最近一期与几位云原生和DevOps领域的领导者讨论了这个话题，包括Helen Beal、Abby Bangser、Matt Campbell和Steef-Jan Wiggers。你可以在最近一期的InfoQ云和DevOps趋势报告播客中了解更多。

我相信大家现在都已经看过“小黄人/格鲁”平台工程与DevOps相关的梗了（如果没有看过，我在KubeCon EU 2023总结中提到过），在KubeCon上，大家都在强调这一点。如果你搜索议程安排，你会发现，关于平台工程的演讲数量至少是提到DevOps演讲的两倍。几乎没有任何演讲直接以DevOps为标题，尽管它们都秉持了DevOps的精神。

我认为这是空间自然演变的一部分，伴随着这种变化的所有好处和坏处。

“好处”在于我们正在围绕这个主题形成一个社区，并在行业内凝聚最佳实践。特别感谢云原生计算基金会（CNCF）应用交付团队发布的“平台工程成熟度模型”（特别感谢来自Syntasso的Abby Bangser，她成功地协调了云原生社区的成员，就像在管理一群“云原生猫咪”一样）。

平台工程成熟度模型（一个由云原生计算基金会 (CNCF) 应用交付团队发布的模型）
领英链接：https://www.linkedin.com/posts/danielbryantuk_platform-engineering-maturity-model-activity-7125465574360412160-LktQ?utm_source=share&utm_medium=member_desktop&source=post_page-----3de5ca13b375--------------------------------

在 KubeCon EU 2024 还将有一个 [平台工程日] 活动。自从我在 2022 年的 KubeCon 上整理了社区中关于平台工程的一些想法，并做了 “从 Kubernetes 到 PaaS 再到…… 接下来会是什么？” 的演讲以来，我们已经走了很远的路。

每个人采用平台工程的“坏”一面是，许多供应商有危险将他们的产品进行“平台洗白”。诚然，许多现有的CNCF景观所启发的产品在官方定义之前就已经帮助人们构建平台了。但我不确定我在KubeCon上看到的标榜为平台工程友好的产品实际上都是如此。这意味着最终用户在购买产品时必须更加仔细地选择，以确保它们真正符合他们的需求。

如果一个工具不能很好地与现有的云原生堆栈集成，没有针对明确的使用场景进行设计（即解决一个“待解决问题”的需求），且不具备自助服务的功能，那么它可能并没有按照平台工程的概念来构建的话。

当然，在任何（平台工程）热潮中，出售铲子和镐头总是可以赚到钱，像Crossplane和KubeVirt这样的技术总是进入我的视线。

我非常喜欢 Tim Hockins 的主题演讲 “关于愿景的展望——Kubernetes 的第二个十年展望”，他在演讲中讨论了为了长期愿景而在短期内做出权衡的重要性。

对于社区来说，这样做其实很容易，即尝试解决所有云原生挑战，并将所有平台工具整合到 Kubernetes 中。然而，Tim 强调这种方法之前在 OpenStack 上也试过……而且结果不算理想。

这个概念在Tim Bannister在推特上分享的一条推文中得到了很好的总结：“Kubernetes应该一直保持未完成的状态。”正如我最喜欢的漫画和电影中所说的，Kubernetes可能“是哥谭市现在所需要的英雄，但并不是它现在应得的那个”[1]。

[1] https://batmanfactor.com/not-the-hero-we-deserve-why-the-quote-is-significant/

很高兴在 KubeCon NA 的主旨演讲中强调了开发者体验及其重要性。KubeCon 一直以来都是一个以基础设施和运营为重点的活动，但我们不能忘记我们的主要用户：开发者。

我的朋友卡斯珀·尼森在推特上关于开发者体验的帖子表现得很出色，捕捉了 keynote 环节的内容。

此外，还有一部分来自后台大会（Backstage Con）活动的宝贵想法。

我也听说了很多关于AppDeveloperCon与其他会议同时举行的活动的好事。在关于这个活动的讨论中，Dapr（后面会详细讨论）被频繁提及，同时还有用于测试的TestContainers、用于CI/CD的Dagger，以及由Okteto团队提供的短暂存在的集群和基于拉取请求的预览环境的好处。我还几次听到了关于devcontainer规范，以及云开发环境的概念，通常都会提到Loft Labs的DevPods项目和GitPod的云开发环境（CDEs）。

作为一个毫不掩饰的自我宣传，我目前正帮助几位在云原生开发工具领域的客户进行产品营销和市场策略，并且在这项工作中，我特别注重开发者体验和“要完成的任务”。

如果你不清楚你的用户是谁以及他们最大的痛点，就无法成功定位你的产品。开发人员很聪明，喜欢自己解决问题，而你的产品往往要与那些用创可贴和尼龙绳勉强凑合但“足够好”的现有解决方案一决高下。

更加注重应用开发和整合

我一直对Dapr社区的工作印象深刻，他们可以说正在云原生社区中引领突出应用程序开发者的需求。对于那些不熟悉CNCF项目的朋友们来说，Dapr‘提供了集成的API，用于通信、状态管理和工作流’。对于那些老道的人来说，可以把它视为为云时代量身定做的企业级中间件（做得不错）。

即使在云原生领域中AI和大语言模型被迅速采用，我们依然需要专注定义恰当的抽象，否则可能会产生大量难以理解的代码。

在我看来，,Dapr提供了构建分布式应用非常有用的几个抽象概念，比如发布-订阅、状态管理、分布式锁等等。

我参加了几场关于 Dapr 的演讲，印象非常深刻。如果我要构建一个全新云原生应用（甚至是一个正在演进的应用），我首先会考虑使用这个项目：

开源社区非常强大，Diagrid团队提供了一系列优秀的商业解决方案，可以减少管理您基础设施时遇到的摩擦和运营负担。我与Mark Fussell和Bilgin Ibryam进行了几次精彩的交谈，鼓励您关注他们在X上的内容。我的InfoQ好友Thomas Betts还写了一篇关于Diagrid最新商业版本的介绍文章：“Diagrid发布Catalyst，一个无服务器、完全管理的Dapr解决方案”。

正如曾任Netscape首席执行官的吉姆·巴克斯代尔曾经所说， “在商业中赚钱只有两种途径：一种是捆绑，另一种是解绑。”在云原生生态系统中我们看到了很多捆绑的现象！

特别突出的一个领域是云原生通信架构。

我之前多次讨论过这个话题，包括最近的一次演讲：“平台工程师的API网关指南”（https://speakerdeck.com/danielbryntuk/devopscon-the-busy-platform-engineers-guide-to-api-gateways）。大多数忙碌的平台工程师需要这个堆栈中的三个主要组件：API网关（用于管理南北向流量）、服务网格（用于处理东西向流量）和容器网络接口（CNI）（用于管理所有底层软件定义网络）。

我在这里坦白一下我的偏见——我曾在大使实验室工作过，该公司是Edge Stack的制作方，并且一直支持Linkerd团队——我喜欢挑选“顶级”解决方案并进行集成。

然而，商业风向正趋向于打包和整合。我看到这个领域的各种供应商都在其最新的产品中上下延伸，例如，Isovalent（Cilium CNI的创造者）正在通过扩展到服务网格和API网关领域向上延伸。Solo.io则通过将CNI（Cilium）集成到其Istio服务网格和API网关产品中向下延伸。Tetrate、Kong、Tyk、Traefik和其他公司也在采取类似的举措。

如果你跟着这个循环走（尤其是资金流），似乎更明智的选择是选择捆绑服务。

而且我相信这种学习成果不仅仅适用于云原生通信行业。总体而言，企业正在寻求精简供应商，降低DIY解决方案的总体拥有成本（TCO），并将云支出承诺转向云市场提供的端到端解决方案。

与此相关的是，由Keith Mattix主持的服务网格讨论环节是我在这次大会中最喜欢的环节之一。参与者们毫不保留，引发了既有趣又有信息量的讨论，而不是像往常一样大家都点头赞同。

我接下来简短概括最后三条要点，但想提到的是，展商区的各种安全解决方案琳琅满目，从安全供应链解决方案（包括SBOM和SLSA）到网络入侵检测等，中间还涉及到权限管理（包括OPA）。这个领域吸引了大量兴趣（和资金）。

会议还全面地涵盖了各个主题，KubeCon 联合主席 Frederick Kautz 和 CNCF 的成员也非常强调在主题演讲中提到的安全问题以及相关的 CNCF 项目，这一点在他们的发言中得到了充分的体现。

此外，在大会演讲中，可持续发展也是一个重要的话题。有一个有趣的圆桌论坛，“云计算中的环境可持续性并非虚构”，甚至由亚马逊AWS赞助的大会演讲也围绕这个主题展开：

这是一个重要的主题，很高兴看到这些驱动因素通过可观测性、自动缩放和FinOps被探讨，以理解和监控你的云（碳排放）足迹。

在最近我与Roi Ravhon录制的InfoQ播客节目中，我学到了很多关于财务运营、应用单元经济学和云成本优化的知识，这对于那些刚开始接触FinOps的人来说非常有用。节目名为“Roi Ravhon谈FinOps、应用单元经济学和云成本优化”。

写 KubeCon 概述时，我肯定要提到社区的力量。看到 keynote 中提到的那么多成功故事和奖项真的太棒了。

我参加这些活动的主要原因之一是为了聚一聚，聊聊天。云原生之路并不总是平坦的，我喜欢和同行者分享经历。今年我对拍照有点懒，但我的开发者关系团队的 Marino Wijay 和 Daniel Oh 替我补拍了不少照片。【注：devrel 是开发者关系团队的简称】

我还和老的 Ambassador Labs 团队成员一起度过了愉快的时光。

我没有机会和我想见的每个人碰面（KubeCon确实很忙！），所以如果你想通过Zoom聊天，可以通过社交媒体联系我。否则，希望不久后能在各种会议活动中见到你！

正如我在本文开头提到的，参加这次 KubeCon 真是太棒了。社区及其周围的支持体系确实正在变得越来越成熟，我们现在需要小心地平衡标准化和创新。

我对云原生的未来感到非常乐观，它看起来会很光明。不过，我也认为未来我们会看到更多的人工智能/大型语言模型的应用 😊

如果你在开发者关系或技术市场领域工作，一定要订阅我的 Avocado Bytes 电子报。我们将在巴黎的 KubeCon EU 2024 会面（别忘了征文截稿日期是11月26日）。