Lightbend 就收购 OpsClarity 一事与 InfoQ 的对话

在收购了咨询公司BoldRadius 九个月后， Lightbend 宣布了其收购 OpsClarity 的消息。OpsClarity 是一家专业做交互式应用监控的公司。

Lightbend 成立于 2011 年，刚成立时叫 TypeSafe，直到去年才改名为Lightbend 。收购了BoldRadius 和OpsClarity 之后，Lightbend 如今的员工人数已超过了130 人，这个数字是2015 年12 月时候的两倍。当问到公司的成长时， Mark Brewer ，Lightbend 的董事长兼 CEO，告诉 InfoQ：

Mark Brewer：这是好事，同时也很有趣。我很开心公司能以这种方式成长，我们得到了一个专业的团队，他们知道他们在做什么，也清楚地知道自己的角色，脚踏实地好好做事。我们很快就有了新的产品。不只是那个团队，而是我们有了一个产品可以投入市场。已经有很多客户在频繁地使用它，并且用得很开心。

Alan Ngai ，现任 Lightbend 云服务的 VP，在 2012 年底与人合伙创立了 OpsClarity。他们在监控交互式应用方面的专业性为 Lightbend 及其客户带来价值，同时也对 DevOps 在四个方面提出了挑战：

• 容器
• 微服务和交互式框架
• 持续集成
• SMACK stack 中的技术

InfoQ 采访了 Mark Brewer 和 Alan Ngai 以对他们新的合作关系做更多了解。

InfoQ：你当前在 Lightbend 的主要职责是什么？你的日常工作都有哪些？

Alan Ngal：收购是最近才发生的，因此我近期主要专注于让 OpsClarity 更好的集成进 Lightbend，并在 OpsClarity 的路线规划里提供更多关于 Lightbend 技术的见识，也就是说，找到更好的方式来集成 Lightbend 提供的产品。至于每天的日常工作，我更专注于为 Lightbend 提供云服务。

---

Mark Brewer： Alan 的角色，当然是要继续管理 OpsClarity 团队。他和他的团队给我们带来了 Lightbend 之前不具备的经验。我们之前毫无关于云服务运维的经验。当然，我们的客户经常在云上构建应用。所以对于在云上构建应用，我们是知道如何去做的。我们只是还没有运营过云服务，或者说，在 OpsCalrity 成为我们公司的一部分之前我们没有做过。所以我们为此感到非常兴奋，我们会有更多这方面的经验。你在这个公司将会看到更多的云服务。

而我作为公司 CEO 的任务是运营这个公司。我来这里已经五年了，这个公司也将成立满六年。它创建于 2011 年 2 月，正好是六年前。我在公司成立一年后加入，并成为职业 CEO，来运营公司并搞清楚要将什么投入市场。我之前已经做过几次类似的事情。我在加入之前就已经知道这个公司了，那个时候公司名字还叫 TypeSafe，我还在 VMware 和 SpringSource 的时候，我们的一些客户使用了以 Scala 和 Akka 见长的 TypeSafe 服务。

InfoQ：你有参与 Spring 并入 Pivotal 的事件吗？

Brewer：我那个时候还在 SpringSource，这个公司在 2009 年被卖给 VMware。 Pivotal 于 2013 年被分拆出 VMware。我参与了拆分出 Pivotal 的计划。

InfoQ：能介绍下 OpsCalrity 的历史和时间线吗？

Ngai：我和我的合伙人在 2012 年末创建了这家公司，那个时候，我们在努力探索在这个领域我们能做什么来增加价值。我曾经在 eBay 和 Yahoo 的搜索和云团队工作过。我的合伙创始人，一个曾在 Google 和 Yahoo 工作，另一个曾在 Cisco 从事数据运营业务。因此，我们对于这个领域是什么样的有很好的理解。当时我们就看到了开源和云的趋势。我们认为，我们能提供的是我们在数据体系里的专业性和经验——采集大量的数据，从数据里分析出有价值的信息，让信息易读、易用。在 2013 到 2014 年，我们主要致力于打造一个平台。我们有一些测试客户，但是因为我们做的是数据密集型的应用，我们用了很长的时间去做调整和收集足够的数据以验证我们的平台是可以工作的。我们有相当一段时间处于测试周期，大概有六个月，或者是将近一年的时间，然后在 2016 年我们去了 GA。那个时候，我们对数据应用的专注更加专业，因为我们跟 Lightbend 一样，看到了未来的趋势——越来越多的人在使用 Kafka 和 Spark 来构建以数据为中心的应用。实际上，那时我们才刚刚第一次见面，那是在一个 Kafka 会议上，我们讨论了在这个领域如何做监控。Lightbend 的 Brad Murdoch 也在关注同样的领域，所以来找我们讨论。也正是在那个时候，我们开始相互认可，并逐渐意识到我们对未来看到了同样的愿景。

InfoQ：关于 OpsClarity 加入 Ligntbend，你有什么想说的或者更多信息可以分享的吗？

Brewer：在 Lightbend 我们看好的市场机会是把新类型的应用和对老应用的现代化结合起来。在这个新的世界里，要么是用微服务架构来对这些新系统进行设计和编程，要么就是把一个庞大臃肿的老应用拆分得更容易理解、更加可扩展、更易管理；这就是所谓的微服务。这个市场里我们看到的另一个有趣的趋势是，一些公司因为需要流式的应用来找我们。这些应用本身是跟动态数据打交道的，而不是静态数据。而这两个市场趋势，微服务和数据流，正好成为了当下最热门的事情之一。说实话，它使得大部分的人来到我们平台。这些趋势被包装成 Reactive Manifesto ，它描述了当代应用需要满足当今现实需求的特点。

而对 OpsClarity 的收购其实有两个原因：其一，他们跟我们紧密合作，用户得以看到使用 Lightbend 技术创建的应用的内部信息，看到 Akka 的内部信息，看到 Akka 信箱或者 Akka 服务集群之间的通信消息；其二，对流式技术做监控，比如对 Kafka 做监控。我们正在建立合作关系，把他们的产品和我们的平台结合起来，然后就有了我们收购这家公司的机会。二者的结合非常有意义，现在我们的客户一次性能得到两个产品：我们的产品和 OpsClarity 的产品。

InfoQ：这个其实回答了我们的一个问题。我们本就准备问 OpsClarity 会带来什么以及在加入 Lightbend 之前他们的客户是如何使用 OpsClarity 的。看来 OpsClarity 加入 Lightbend 是天作之合。

Brewer：确实是天作之合。还有一点我可以告诉你的是，OpsClarity 是使用 Lightbend 技术设计和构建他们的系统的。所以大量使用了 Scala 和 Akka。这个使得集成变得非常容易，当然这也使得做出收购的决定变得更容易。

---

Ngai：我只有一点要补充的，就是我们看到的愿景和 Lightbend 非常相似，就是越来越多的公司在使用开源技术采取分布式的方式构建他们的软件栈。我们从运维的角度看到的是，对于 DevOps 和开发工程师来说，让人们理解环境里发生了什么越来越难，更别说监控了。与此同时，Lightbend 在帮助客户构建这样的分布式系统，而 OpsClarity 是用来帮助人们监控这样的系统，所以说确实是天作之合。

InfoQ：对于我们的读者来说，他们可能并不熟悉 OpsClarity，也不知道如何监控交互式应用。您能针对如何做监控和使用什么技术做个概括性介绍吗，如果不涉及专有性的话？

Ngai: 我认为最关键的因素是，人们越来越多地使用各种各样的开源技术来构建他们的应用，甚至 Lightbend 本身，你也可以看到 Play、Akka、Lagom、Scala 等技术。而目前大多数的应用还需要其他技术，比如需要 Kafka 来做消息队列，或者某种 NoSQL 数据库，或者像 Spark、Flink 之类的数据处理技术。我们就是针对这样的环境做的设计，因为我们认识到，对于任何工程师或者 DevOps 来说，在所有这些领域都成为专家是不可能的，更不用说去做监控或者去搞明白要监控什么了。OpsClarity 提供的平台的关键点在于，关于这些系统的信息是内建在产品中的。你并不需要在你的团队中有一个 Kafka 专家、一个 Cassandra 专家、一个 Spark 专家以及一个 Akka 专家，我们已经包含了很多这些方面的知识，告诉你如何去监控这些系统，错误范例是什么，关键指标是什么，以及如何结合产品去做监控。这就是 OpsClarity 能为我们的客户在分布式领域提供的最有价值的东西。

---

Brewer：有一件事我相信 OpsClarity 也看到了 ，就是在这个新的时代，你的容器和微服务可能只存活非常短的一段时间，而不像在应用总是很庞大的服务器时代，使用 WebSphere 和 WebLogic，服务器永远处于运行状态。其实有的服务是长期使用，有的只是临时使用。在这个新的分布式和积木式的微服务世界，你可以在 Docker 容器中运行或者单独运行只存在几秒钟的服务。去做监控，或者说具备监控的能力，第一很困难，第二，使用老的监控方案是行不通的。或者说在新的世界是行不通的。

InfoQ：微服务在过去几年一直是一个很有趣的话题。基于企业开发者趋势 2016 年度报告，各种组织在以下几种情况的分布很平均：（a）在生产环境使用微服务，（b）正在考虑使用微服务，（c）在沙箱环境试验微服务，（d）对微服务完全没有兴趣。还有不少针对使用微服务的开发者的警告标语，包括“微服务的七宗罪”。这传达出的信息似乎是“小心使用微服务”。针对这些顾虑，Lightbend 有没有什么能做的呢？

Brewer：我们正在尝试。首先，是教育，教会人们如何以正确的方式架构、构建和设计这些系统。我们出版了一些这方面的书。他们大体上都以简短、好读的方式介绍微服务，以及以什么样的方式去思考你的系统和如何用微服务的方式做架构。其次，为开发者提供合适的工具。给他们提供能在构建这些系统时提供帮助的工具。我们在去年二月的时候发布了一个项目，叫做 Lagom ，这是我们的微服务框架。这个名字是个瑞典词，它的意思是“刚刚好”、“大小合适”。这就是我们想要传达的。微服务并不一定要非常小，它的关键并不在于大小，而是如何做事。它可以把一件事做的很好，并以隔离的方式做，这个意味着它方便扩展，并且当一些错误发生时，只在隔离空间里抛错而并不会导致整个系统罢工。Lagom 框架的设计是为了帮助人们以正确的方式构建系统或微服务。当然，还有很多别的事我们可以做，这只是个好的开始。

---

Ngai：关于监控系统这点，Lagom 和 Lightbend 技术致力于帮助行业构建这样的架构：流式的、异步的、消息驱动的等。除了帮助开发者自动构建和监控这些系统，让市场知道这些新型的分布式系统的关键运维难点是很有必要的。比如，你可以回想一下过去对于 Web 服务器人们最关心的东西——请求延迟和请求吞吐量，在一个异步的消息驱动的世界监控这些将会很困难。再比如，在 Lagom，背压是运维会实际关心的大事。那么针对监控和这类指标我们如何提供服务呢？

InfoQ：Alan 在新闻稿里声明过，“加入 Lightbend，我们能够为交互式平台提供更先进的监控能力，实时收集和分析各项指标，在分布式系统自动发现动态组件，以及针对某些特定的开源框架的内建功能。”您能为我们的读者针对这个做一些详细叙述吗？

Ngai：监控不仅仅是收集指标数据。它不只是跟某个 API 或者某个 JMX 终端通信然后收集数据并在仪表盘画图。大部分的监控工具都可能做到这些。我们想要给开发者和运维工程师提供的实际上是洞察力。对于一个服务，他们实际上关心的是什么？现在，每一个服务都会暴露成百上千的数据指标，有各种各样的维度，比如主题名称、分区名称或者其他类似的数据。但是哪些数据，以及这些系统什么方面的性能特征是真正重要的呢？DevOps 和工程师需要保持关注的是什么呢？他们最需要关心的四个或五个指标是什么呢？其中的每一种指标，他们又代表了什么特性？它是群组指标，还是延时指标，抑或是背压指标还是其他别的呢？对于不同类型的指标，你需要用不同的方式做监控。OpsClarity 提供的智能化，就是理解这些指标是什么，如何做监控，然后以合理的方式提供出来。接下来我们要更加专注于 Lightbend 组件并充分理解，除了客户如何使用 Lagom、Play、Akka 等来构建架构，什么是人们需要关注的重要的性能和运维特性。

InfoQ：企业开发趋势 2016 年度报告还说了，“如果你仍然以 12～18 月为周期发布软件，你可能也会回到瀑布模型。”在新闻稿里，四个常见用例之一说到，“那些用持续集成来运行动态环境的，意味着新的代码会频繁发布，经常是每周好几次。”你觉得对于软件更新来说，多长时间是最优的更新周期？

Brewer：很明显，这个要分情况，它取决于组织在敏捷开发方面的专业性和经验，以及他们构建的是什么样的项目。有一些项目需要非常频繁的更新或者发布。有些公司会持续的发布更新，比如 LinkedIn，至少每小时会发布一次，有时候甚至一小时会发布好几次。这是他们的实战经验，他们已经这么做好多年了，他们一直如此运营。所有团队都知道他们会每个小时发布新代码。但这并不意味着每个人在每个小时都会更新代码。如果他们想在某个发布周期更新代码，他们只需要在那个时间点之前提交代码。还有一些公司，有一些是我们的客户，是每个月发布一次。他们也能习惯于每 18～24 个月经历一个版本。我不知道是不是有理想情况，但目前为止我没有找到统一的答案，能针对某人提交代码的频率说“这是完美的敏捷开发实战”。

---

Ngai：多长时间为发布周期的都有。我想它取决于这个团队选了什么样的技术栈。如果你用了更多老的技术，比如上一代的技术，那么开发周期可能会长一些。如果你开始用 Docker 和 Mesos，以及这一类的其它技术，几乎可以肯定，开发周期一定会短许多，因为在这种环境下，你只需要一条命令就可以启动整个环境。

InfoQ：每小时一次，这个很频繁呀。LinkedIn 发布的都是什么样的代码？大部分都是改 bug 吗？

Brewer：是功能代码，也可能是 bug 修复。Twitter 也类似。有很多这样的 Web 网站，这是他们的实战经验。一天一次对他们来说太慢了。很多都是一天升级好几次。

InfoQ：这实在很让人振奋。大部分人都知道吗？

Brewer：有一些关于这个的信息，但是你还是会对某些团队感到惊讶的。他们习惯了以这种持续发布的方式运营。即使是在 Lightbend，某些团队也是发布频繁，他们的敏捷开发工作显得其他团队比较慢。

InfoQ：我们可能会认为瀑布式开发已经是过去时了。

Brewer：这方面仍有争论，如果你在构建一个庞大的应用，一个老式的庞大应用，使用的是过去的技术，那么就没有理由去切换或者强迫自己去做敏捷，还是使用瀑布式就好。我并不倡议这个，但是你是可以这么做的。

InfoQ：切换到敏捷是一个很大的改变。好像有很多反对力量，就像 15 年前结对编程和极限编程的出现的时候那样。我们希望，今天，大部分的公司能切换到敏捷，尤其是现有的 J2EE 应用，而 Oracle 似乎对 J2EE 8 缺少支持。我们对于现今还有多少组织仍然在使用 J2EE 很感兴趣。

Brewer：比你想象的要多的多。很多仍然在使用 J2EE 的公司也同时在探索新技术。他们有在新项目中使用 Lightbend 技术以及其他技术，但是他们还有很多线上应用。有很多都是用老的方式写的，在老的应用服务器、WebSphere 或者 WebLogic 上运行，这些仍然需要维护。

---

Ngai：还有一种对持续部署和持续集成发展的理解。大多数我交谈过、接触过的工程师，他们即使在实际中并不会每天发布、每小时发布或者每周发布，他们也知道这个概念。有一种说法是，这是所有人的方向，不管你现在使用的是什么，你将来会需要这么做。所以说，是有这个趋势的。

InfoQ：SMACK－Spark，Mesos，Akka，Cassandra，Kafka。有趣的是，除了 Akka，这些都是 Apache 的项目。你们网站上有描述，Lightbend 支持所有这些 Apache 产品。

Brewer： Akka 不是 Apache 的项目。我们使用了 Apache 开源协议，但是它属于 Lightbend，所以它不是一个 Apache 项目。但是你说的对，其他的那些都是 Apache 项目。这些项目的共性并不只是他们都是 Apache 项目，而是这些都在新的基于流的应用中经常被一起使用。我可以说，OpsClarity 拥有的产品，也就是现在 Lightbend 拥有的产品，很大一部分都是基于 SMACK 技术栈构建的。他们使用了这些技术来创建所谓的下一代监控平台。在我们的客户那里我们看到了类似的事情，尤其是当他们在处理大量的、流动的数据的时候。他们希望能够在应用中实时处理这些数据，而不是等数据写回硬盘再读取。他们的另一个不太明显的共性是，他们大部分都是用 Scala 写的。你也知道我们是一家主要用 Scala 的公司。

InfoQ：有了 BoldRadius 和 OpsClarity 加入 Lightbend，Lightbend 的下一步会是什么？

Brewer：我们会让这两家公司帮助我们履行承诺。首先，作为服务团队，帮助客户接受培训，然后实现和利用这些技术。但是，我们不是一家为人们做开发工作的咨询公司。现在我们有了专家来做知识分享，提供最佳实战培训。其次，有了 OpsClarity，我们就可以提供商业产品，帮助人们能够更好的了解应用的表现如何，以及提供计划如何让应用做的更好。那么，下一步是什么呢？并没有什么我们现下积极追求的东西。但是你会看到，像我刚才提到的那样，Lightbend 会提供更多的基于云的服务。监控是第一个，但是你也会看到更多的 Lightbend 提供的高价值的服务，让公司利用技术构建应用。我们的工作就是让他们成功，并且确保他们在构建这些应用的时候，从中得到最大的好处。

查看英文原文： Lightbend Speaks to InfoQ on Their Acquisition of OpsClarity

感谢刘志勇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。