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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

---

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

---

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

---

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

---

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

---

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;\u0026#xD;

---

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

\u0026#xD;

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

\u0026#xD;

\u0026#xD;\u0026#xD;

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

\u0026#xD;\u0026#xD;

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

\u0026#xD;

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