美国(United States)

“Mux”是“多路传输”的简写，即在数字媒体中将多路信号整合成为一路。 自 2015 年创建以来，Mux 已经整合了所有资源，旨在“让在线流媒体视频对每个人来说都很容易”，共同创始人 Adam Brown 说，“我们的目标就是从创造高品质的流媒体体验入手，消除技术层面的复杂性。我们在易于使用的API背后帮助自动化决策，如编解码器、编码设置和CDN分发。” Mux 的两款产品之一是数据产品，为世界各地的视频播放器提供用户体验质量（QoE）指标，而视频产品让开发者能够按己所需，方便快捷地创建、编辑视频或进行直播。 有了这两个工作流程，特别是视频流程，“就会涉及到很多移动组件，”Mux 技术与架构主管 Brown 说，“我们管理来自全球各地的大型文件，很多文件都需要转码。然后还有数据流水线用于算法决策，决定使用什么转码参数，生产什么比特率，通过什么 CDN 发布。” 公司为了有效管理复杂的流程，公司很早就采用了容器化，于 2015 年 12 月第一次部署了 Docker 容器。最初，Mux 用 Rancher 堆栈管理容器，“貌似从这里入手最为简单，” Brown 说，“Kubernetes 那时还处于早期，集群和运行都比现在要复杂得多。” 一段时间之后，公司遇到网络稳定性的问题，随着 Kubernetes 生态逐渐成熟，Brown 重新把所有组件再次迁移到 Kubernetes 上。他一一考虑了众多云供应商部署、管理的 Kubernetes...

美国国防部实现 DevSecOps 前，大型武器系统的软件交付通常需要 3 年到 10 年。 “多数团队使用 waterfall，没有最小化可行产品（MVP），没有增量交付，也没有最终用户的反馈回路，”美国空军首席软件官 Nicolas M. Chaillan 说。此外，“网络安全也大多是事后才会去考虑。” 2018 年夏天，Chaillan 加入，尝试改变这种现状。他的解决方案非常简单，却给国防部带来一场革命。他和 DoD 负责信息企业的副首席信息官 Peter Ranks 共同创建了 DoD 企业 DevSecOps 参考设计，该设计要求 DoD 系统必须使用 CNCF 许可的 Kubernetes 集群和其他开源技术。“DoD 企业 DevSecOps 参考设计规定了 DevSecOps 管道的入口。”Chaillan...

从 Netflix 到 Fox Sports，再到 Vice，诸多知名的视频与影片内容创作者都在使用 Frame.io 平台实现云观看和多团队协作。 就客户关心的保密性问题，公司在2014年程序上线之初，就对其安全性和可靠性做出承诺，而这一切都要归功于云原生技术。 2017年，Abhinav Srivastava 加入公司、担任副总裁兼信息安全和基础设施主管后，就开始着手为 Frame.io 视频云创建绝对可靠的安全程序。视频云搭建在 AWS 上，最为关键的组件是 ML/AI 异常检测系统外围基于签名的网络应用防火墙，借以筛除恶意请求。 Frame.io 的全部工作负载都在 Docker 容器中完成；高峰期30万个容器同时运行，处理网络请求或完成视频转码，时间跨度从数秒到数小时不等。“一个小时之内，我们就能完成10天的工作量，因为多个容器同时在运行，” Srivastava 说，“容器上线，火力全开。容器内，我们需要 100% 的可见度，我们要保证它们的安全。我们开始研究入侵检测和容器安全工具，这时我们发现了 Falco。” Falco 是保证容器原生运行时间安全的开源项目，貌似非常适合 Frame.io。“Falco 搭建简便，规则却非常有效，”他说：“制定自己的规则之后，架构扩展非常简单。我们想要的正是这些。” 要最大化利用 Falco，鉴于 Frame.io 的特殊需求，团队“进行了整个微调过程，” Srivastava 说，“我们使用...

2007年上线，目标是帮助机构组织便捷地使用客户服务。Zendesk 提供的产品包括实时信息、语音聊天和数据分析。 所有的产品和服务都在单体 Rails 应用上提供，该应用程序利用 MySQL 数据库，在公司自有硬件上的共址数据中心中运行。 最初的7年中，系统运行良好。但随着 Zendesk 日益壮大，2014年上市，目前已有145,000个付费账号和3,000名员工，显然需要我们对基础设施进行改造，这就需要我们开始使用微服务、容器和 Kubernetes。 “我们意识到：把越来越多的东西塞到一个单体 Rails 上会拖慢团队的速度，高级总工 Jon Moter 说：“部署真的很难，风险也很大。Zendesk 的团队散布在全球各地，但所有工程设计室都被捆绑在同一个应用上。” 转向微服务是一个符合逻辑的做法。但在当时，我们仍有一个中心运维团队，“资源供给效率非常低下，”他说：“要建立、部署一项服务，通常需要提前一个季度提出硬件需求。”此外，“大量” Chef 逻辑用于配置服务器，“登台环境和生产环境大不相同，因为网络不同，一个在 AWS 上，另一个在数据中心，”Moter 说：“很多不一致的情况。” 有些团队最后提出把代码放在一起，或者“最后形成几个小型单体，映射到办公室所在的单体应用里。”他补充说。 2014年底，Zendesk 高级技术工程师开始研究寻找一个更好的解决方案。他们迅速决定采用 Docker 容器，随后便开始了长达6个月的微服务最佳实践研究，探索在 Zendesk 应用的有效方法。 Moter 团队制作了一套称为“ ZDI ”（Zendesk Docker...

2010年，Pinterest在云中诞生，它从第一天起就在AWS上运行，但即使是云原生公司也可能会经历一些“成长痛” 自上线以来，Pinterest已经成为一个家喻户晓的社交平台，每月活跃用户超过2亿，保存了1,000亿个对象。这庞大的体量背后，是1,000个微服务和成千上万个数据任务在支撑。 为应对这种高速增长，Pinterest针对不同的工作负载采用了多层基础设施和各种设置工具与平台，导致出现不一致和复杂的端到端开发人员体验，从而最终降低了生产速度。因此，2016年，该公司发布了迈向新计算平台的路线图，其愿景是帮助工程师最快速地完成从构思到生产的过程，而无需考虑底层基础设施。 路线图的第一阶段涉及迁移到Docker。Pinterest云和数据基础设施部门产品经理Micheal Benedict表示：“Pinterest一直在虚拟机上并且直接在EC2实例上长时间、超负荷地运行。为解决软件打包方面的问题，避免工程师采用良莠不齐的方法，我们规范了打包机制，并将其迁移到虚拟机之上的容器中。个中变化不是很大，我们不想一蹴而就。” 迁移的第一个服务是为大多数Pinterest提供支持的单体架构API。同时，Benedict的基础设施治理团队构建了计费和容量规划系统，以分析公司如何在AWS上使用虚拟机。Benedict说：“很明显，从目前我们所做的工作来看，在虚拟机上运行工作负载是不可持续的。很多资源都没有得到充分利用。我们曾在效率上下功夫，这在一定规模上效果很好。但是发展至今，我们必须采用一种更分散的方式来进行管理。于是我们就想到了编排，也许它可以帮我们走出困境。” 这就进入了路线图的第二个阶段。2017年7月，经过八周的严格评估后，团队从一众编排平台中选择了Kubernetes。Benedict说：“当时Kubernetes还不完善，比如它不能像我们期望的那样运行Spark。但是我们意识到，哪怕我们自己尝试构建一下呢，这对Pinterest和CNCF社区都有意义。我们在大数据特别兴趣小组中进行了反复讨论。我们知道，等真正开始将这些功能投入生产时，社区会为我们提供强大的后盾。” 2018年初，团队开始在Kubernetes系统中启动第一个用例，即Jenkins工作负载。Benedict表示：“虽然我们是在一天中的特定时段开展构建工作，但我们始终需要分配高峰容量。旧系统没有任何自动调整功能，容量会一直保持不变。由于逐渐增加容量非常浪费时间，我们很难加快构建速度。鉴于以上种种原因，我们认为Jenkins是我们开展工作的理想用例。” “Pinterest在全球率先推出视觉搜索引擎。我们致力于帮助用户发现和做自己喜欢的事情。如今，我们的平台拥有超过2.5亿月活跃用户，并且每天提供上百亿条推荐。Pinterest的基础设施规模非常庞大。我们拥有成千上万台服务器、300PB数据、数以千计的任务和工作流，这些都为Pinterest提供非凡的体验打下了坚实基础。” — 基础设施工程主管KARAN GUPTA 他们扩大了集群容量，并与一个四人团队合作，使Jenkins Kubernetes集群为投入生产做好了准备。Benedict表示：“我们还有静态Jenkins集群，但是在Kubernetes上，我们可以进行类似的构建，测试整个管道，并做好构件准备，我们还可以通过比较了解在这里构建需要多长时间。是否满足SLA？生成的构件是否正确？以及是否存在任何问题？” 他补充说：“到目前为止，一切都很好，尤其是能够在Kubernetes共享集群上灵活地配置Jenkins工作负载。这就是我们想要的。” 2018年第一季度末，该团队就已成功将Jenkins Master迁移到在Kubernetes上本地运行，它还与Jenkins Kubernetes插件协同管理员工生命周期。Benedict表示：“我们目前正在这个新集群上构建整个Pinterest JVM堆栈（Pinterest最近采用了Bazel的大型 monorepo之一）。在高峰时段，我们在几百个节点上运行了数千个pod。总体而言，通过迁移到Kubernetes，团队可以构建按需扩展和新故障转移策略同时简化Jenkins等复杂基础设施的整体部署和管理。这不仅缩短了构建时间，还显著提升了效率。例如，团队能够在非高峰时段回收了80％的容量。因此，与以前的静态集群相比，Jenkins Kubernetes集群现在每天的实例时数减少了30％。” “Pinterest从一开始就在云端运行，很明显，随着公司的发展，削减虚拟机管理方面的开销变得对我们至关重要。因此，我们投资Kubernetes作为计算基础设施， 以便工程师能快速迁移，并消除自行管理设备的开销。” — 工程经理MICHEAL BENEDICT Benedict描绘了未来“相当稳健的路线图”。除Pinterest大数据团队在Kubernetes上试用Spark以外，该公司还与Amazon的EKS团队合作开发了ENI/CNI插件。 Jenkins集群正式上线后，Benedict希望建立最佳实践，包括在迁移下一项服务之前，完成治理原语的构建（包括与计费系统相集成）。Benedict表示：“我们有一个正常的用例管道可供使用。在Jenkins之后，我们希望为Tensorflow和Apache Spark提供支持。在某个阶段，我们的目标将是迁移公司的整体API服务。如果我们了解其中的复杂性，便能够自信地采取行动。它可帮助我们为迁移所有其他服务做好准备。” 作为云原生领域的先驱，Pinterest渴望将其多年以来的发展历程分享给大家。Benedict表示：“我们可以在公有云环境中大规模运行，并以许多人可能做不到的方式进行测试。我们能够分享一些宝贵的经验。”