为什么我移回开源以进行消息传递，集成和流处理

在TIBCO Software工作了三年之后，我回到了开源领域，加入了Confluent （一家专注于开源项目Apache Kafka的公司），以构建用于消息传递，集成和流分析的关键任务，可扩展基础架构。 Confluent是一家硅谷初创公司，仍处于起步阶段，2016年业务增长700％ ，预计2017年将再次显着增长。

在这篇博客文章中，我想分享一下为什么我看到开源技术中的中间件和大数据分析的未来，为什么我真的喜欢Confluent，在接下来的几个月中我将重点关注什么，以及为什么对接下来的事情如此兴奋步入我的职业生涯。

行业主要业务趋势：大数据，实时流分析，机器学习

让我们简短地谈谈三个前沿主题，这些主题在当今的任何行业以及中小企业中都变得很重要：

• 大数据分析 ：在大历史数据集中查找见解和模式。
• 实时流平台 ： 实时将洞察和模式应用于新事件（例如，用于欺诈检测，交叉销售或预测性维护）。
• 机器学习 （及其热门的子主题深度学习）：利用算法，让机器自己学习，而无需明确地编写所有程序。

这三个主题如今扰乱了每个行业。 请注意，机器学习与其他两个主题有关。 尽管今天，我们经常将其视为独立的主题。 实际上，许多数据科学项目仅使用很小的数据集（通常小于千兆字节的输入数据）。 幸运的是，这三个主题将越来越多地组合在一起，以增加附加的业务价值。

一些行业（例如银行，电信公司，保险公司）才刚刚开始颠覆和数字化转型，而其他行业（例如零售商，航空公司）已经实现了一些变革和创新。 除上述主题外，一些行业还出现了其他一些前沿的成功案例，例如制造业中的物联网（IoT）或银行业中的区块链。

随着市场上所有这些业务趋势的发展，我们还看到了所有这些主题的关键技术趋势：开源项目的采用。

关键技术趋势：采用“真正的”开源项目

当我说“开源”时，我指的是一些特定的项目。 我不是在谈论非常新的，不成熟的项目，而是那些已经在生产中成功部署了很多年并被各种不同的开发人员和组织使用的框架。 例如， 诸如Kafka REST Proxy或Kafka Schema Registry之类的Confluent的Docker映像已被下载超过100.000次 。

一个“真实的”，成功的中间件或分析开源项目具有以下特征：

• 开放性 ：可以免费使用，并且可以在许可的情况下真正开放，即您可以在生产中使用它并进行扩展，而无需购买许可证或订阅（当然，可以有商业的，专有的附件-但是他们需要置于项目之上，而不在后台更改已使用的开源项目的许可证）
• 成熟度 ：在与业务相关甚至是关键任务的环境中使用至少一年，通常更长
• 采用 ：各种供应商和企业通过提供（源代码，文档，附加组件，工具，商业支持）或实现项目来支持项目
• 灵活性 ：可以在任何基础架构上进行部署，包括内部，公共云，混合。 支持各种应用程序环境（Windows，Linux，虚拟机，Docker，无服务器等），多种编程语言（Java，.Net，Go等）的API
• 集成 ：独立且松散耦合，但也高度集成（通过连接器，插件等）到其他相关的开源和商业组件

在定义成功的开源项目的关键特征之后，让我们看一下一些发展势头强劲的框架。

尖端开源技术：Apache Hadoop，Apache Spark，Apache Kafka

我定义了以上三个关键趋势，它们与任何行业以及许多（开源和专有）软件供应商都相关。 某些开源项目作为新项目的事实上的标准存在明显的趋势：

• 大数据分析 ： Apache Hadoop （及其子项目如Hive，Pig，Impala，HBase等的动物园）和Apache Spark （同时经常与Hadoop分离）存储，处理和分析庞大的历史数据集
• 实时流平台 ： Apache Kafka –不仅用于高度可伸缩的消息传递，而且还用于集成和流分析。 平台可以仅使用Kafka Streams来构建流处理应用程序/微服务，也可以使用“外部”框架，例如Apache Flink，Apex，Storm或Heron。
• 机器学习 ：这里没有明显的“赢家”（在我看来，这是一件好事，因为它涉及面很广）。 提供了许多出色的框架-例如R，Python和Scala提供了各种机器学习算法的出色实现，而诸如Caffee ， Torch ， TensorFlow或MXNet之类的特定框架则专注于深度学习和人工神经网络。

在这些框架之上，各种供应商会构建开源或专有工具，并提供商业支持。 考虑关键的Hadoop / Spark供应商： Hortonworks ， Cloudera ， MapR等，或KNIME ， RapidMiner或H2O.ai，作为在可视编码环境中进行机器学习的专用开源工具。

当然，还有许多其他伟大的开源框架在这里没有提到，但在市场上也很重要，例如，用于消息传递的RabbitMQ和ActiveMQ或用于集成的Apache Camel 。 此外，新的“最佳实践堆栈”正在出现，例如结合了Spark，Mesos，Akka和Kafka的SMACK堆栈 。

我对Apache Kafka和Confluent感到非常兴奋，因为它已经在任何行业以及许多大小企业中使用。 Apache Kafka的生产部署在2016年加快了步伐，现在已被《财富》 500强企业的三分之一使用 。 而这仅仅是个开始。 Apache Kafka并不能全面解决所有问题，但是它的功能非常强大-用户，贡献者和生产部署的数量不断增长，证明了这一点。 它与许多其他框架和工具高度集成。 因此，在我的新工作中，我将不仅关注Apache Kafka和Confluent，还将关注稍后讨论的许多其他技术。

接下来让我们考虑一下Apache Kafka和Confluent与专有软件的关系。

开源与专有软件–一场永无止境的战争？

如今，趋势正在转向开源技术。 这不是问题，而是事实。 在过去的几年中，我没有看到一个客户没有围绕Hadoop，Spark和Kafka进行项目和巨额投资的。 同时，它从实验室和第一个小项目转变为企业事实上的标准以及公司范围内的部署和策略。 为了降低成本，越来越多的封闭式遗留软件正在更换，但是对于更灵活，最新和创新的产品而言，更为重要。

对于某些主题，我对专有解决方案没有太多的吸引力或需求。 在过去约20年的时间里，封闭式软件统治着两个非常相关的示例：消息传递解决方案和分析平台。 在新项目中，开放框架似乎可以取代任何行业和企业中的几乎所有地方（有充分的理由）。

新的消息传递项目基于MQTT之类的标准或Apache Kafka之类的框架。 使用R和Python以及scikit-learn或TensorFlow等框架进行分析。 这些选项利用了灵活但非常成熟的实现方式。 通常，在其之上不需要大量专有的，不灵活的，复杂的或昂贵的工具。 即使IBM 的大型供应商，专注于围绕开放源代码产品在此期间。

IBM向Apache Spark投资了数百万美元，用于大数据分析，并让3500多名研究人员和开发人员从事与Spark相关的项目，而不仅仅是推动自己的各种专有分析产品（例如IBM SPSS） 。 如果您搜索“ IBM Messaging”，则会发现基于AMQP标准的产品和基于Apache Kafka的云服务，而不是寻求新的专有解决方案 ！

我认为IBM是当今软件市场如何变化的一个很好的例子。 对于硅谷初创公司来说，融合（刚开始的时候）或Cloudera（ 刚刚成功上市 ）就是很好的例子。

在我看来，一款优秀的专有软件可以利用Apache Kafka，Apache Hadoop或Apache Spark等开源技术。 供应商应将这些技术与本机集成。 供应商的一些机会：

• 可视化编码（供开发人员使用）以生成代码（例如，图形组件，为Hadoop或Spark作业生成框架兼容的源代码）
• 可视化工具（例如，用于业务分析师或数据科学家的工具），例如连接到大数据存储以查找见解和模式的可视化分析工具
• 用于管理和监视开源基础结构的基础结构工具（例如，用于监视和扩展Apache Kafka消息传递基础结构的工具）
• 与开放源代码框架本地集成的插件（例如，集成供应商应该在开放式云本机平台（如Kubernetes或Cloud Foundry）上部署其集成微服务，而不是使用自己专有的运行时和消息传递基础结构，并利用Apache Kafka等开放式消息基础结构而不是追求专有解决方案）

开源软件和专有软件相互补充

因此，我不认为这是对“开源软件”与“专有软件”的讨论。 两者相得益彰。 在决定开源软件，专有软件或两者结合之前，您应该始终询问以下问题：

• 专有解决方案的附加价值是什么？ 这会增加复杂性并增加运行时和工具的占用空间吗？
• 一个项目的预期总拥有成本（TCO）是多少，即许可证/订阅+项目生命周期成本？
• 如何实现项目？ 谁会支持您，您如何找到交付专家（通常是咨询公司）？ 集成和分析项目通常需要大量投资，因此规模巨大，那么如何确保可以交付（实施，测试，部署，运营，变更管理等）？ 我们能否为关键任务部署（24/7）获得商业支持？
• 如何将此项目与其余的企业体系结构一起使用？ 您是否将所有内容都部署在同一群集上？ 我们是否要在不同部门和业务部门中设置一些（开放的）事实上的标准？
• 我们是否要在新环境中使用相同的技术而不限制30天的试用期或烦人的销售周期，甚至可以将其部署到生产中而无需任何许可/订阅费用？
• 我们是否想自己对平台进行更改，增强或修复（例如，如果我们需要立即而不是六个月内需要特定功能）？

考虑一下这些问题，让我们考虑一个具体示例：

在过去的24个月中，我面临着很多问题，尤其是趋势转向了灵活，敏捷的微服务（不仅用于构建业务应用程序，还用于集成和分析中间件）。 请参阅我的文章“微服务是否拼写了ESB的结尾 ？”。 简短的摘要：尽管当今的需求有所不同，您仍然需要中间件（将其称为ESB，集成平台，iPaaS或其他方式）。 开源和专有ESB产品都是如此。 但是，过去24个月中发生了其他变化……

过去，开放源代码和专有中间件供应商提供了ESB作为集成平台。 该产品包括一个运行时（以确保集成服务的可伸缩性，关键任务操作）和一个开发环境（用于可视化编码和更快的上市时间）。 最近两年改变了我们对构建新应用程序的看法。 我们现在（想要）构建在Docker容器中运行的微服务。 可扩展的，关键任务运行时由Kubernetes或Cloud Foundry等云原生平台管理。 理想情况下，DevOps可自动进行构建，测试和部署。 如今，ESB供应商采用了这些技术。 到目前为止，一切都很好。

现在，您可以将中间件微服务部署到这些云原生平台，例如任何其他Java，.NET或Go微服务。 但是，这完全改变了ESB平台的附加值。 现在，它的好处仅在于视觉编码，关键参数是上市时间（您应该始终对其进行质疑和仔细检查，如果它是有效的参数）。 运行时实际上不再是ESB的一部分。 在大多数情况下，这完全改变了确定您是否仍需要ESB的观点。 再次问自己上市时间，许可/订阅费用和总拥有成本！ 还要考虑与纯源代码（例如Java的.jar文件）相比，工具构建的服务（通常是某种大的.ear文件）（通常）增加的资源需求（内存，CPU，磁盘）。

ESB是否仍具有足够的附加值，还是只应使用云原生平台和消息传递基础结构？ 在实际开始使用可视编码环境之前，编写一些源代码而不是设置ESB工具（在您经常难以导入REST / Swagger或WSDL文件）以及许多其他配置环境的地方，是否更容易？ 在大型，长期运行的项目中，您可能最终会获得胜利。 虽然在敏捷，瞬息万变的世界中，它具有快速失败的意识形态，各种不同的技术和框架以及自动化的CI / CD堆栈，但是您可能只会增加新的复杂性，而不再像在旧世界中那样获得预期的价值。 ESB还是关键任务运行时。 其他中间件组件（例如流处理，分析平台等）也是如此。

ESB替代方案：Apache Kafka和Confluent开源平台

作为替代，您可以使用例如Kafka Connect，它是基于Apache Kafka的非常轻量级的集成库，用于构建大规模的低延迟数据管道。 Kafka Connect的优点在于，围绕可扩展性，故障转移和性能的所有挑战都可以从Kafka基础架构中获得利用。 您只需要使用Kafka Connect连接器即可实现非常强大的集成，并且只需几行配置即可实现源和接收器 。 无论如何，如果您使用Apache Kafka作为消息传递基础结构，则需要找到一些非常有说服力的理由，以便在顶部使用ESB，而不要使用复杂程度不那么高，重量轻得多的Kafka Connect库。

我认为本节解释了为什么我认为开放源码和专有软件在许多用例中是互补的。 但是，在每种情况下都添加重量级，资源密集型和复杂的工具是没有意义的。 开源不是免费的（您仍然需要花费时间和精力在项目上，并且可能需要花钱来获得某种商业支持），但是在没有太多额外的专有工具的情况下，开源通常是更好的选择，因为它涉及复杂性，缩短开发时间。市场和总体拥有成本。 您可以找到有关开源项目的无穷成功故事； 不仅来自Google，Facebook或LinkedIn等科技巨头，而且还来自许多大型传统企业。 当然，任何项目都可能失败。 不过，在具有Hadoop，Spark或Kafka之类的框架的项目中，这可能不是由于技术问题引起的……

合流+“专有超级供应商”

另一方面，我非常期待与TIBCO ， SAP ， SAS等“主要是专有”大型供应商合作，以解决客户问题并构建创新的，功能强大的，关键任务的解决方案。 例如，如果您想通过可视化编辑器而不是编写源代码来开发流处理应用程序，则TIBCO StreamBase是一个很好的工具。 实际上，它甚至无法与Kafka Streams竞争，因为后者只是您嵌入到任何其他微服务或应用程序中的库（部署在任何地方，例如，在Java应用程序， Docker容器， Apache Mesos中 ，“您选择它” ），而StreamBase（如其竞争对手Software AG Apama ， IBM Streams和所有其他开源框架（如Apache Flink ， Storm ， Apache Apex ， Heron等））则专注于在自己的集群上构建流应用程序（通常部署在Hadoop的YARN上）或在专有群集上）。 因此，您可以使用StreamBase及其Kafka连接器来构建利用Kafka作为消息传递基础结构的流应用程序。

当然，即使Confluent本身也提供了一些专有工具，例如Confluent Control Center，用于在开源Apache Kafka和开源Confluent平台之上进行管理和监视 。 这是您在成功的开源供应商（如Red Hat）背后看到的典型业务模型：拥抱开源项目，为企业级部署提供24/7支持和专有的附件。 因此，并非所有事物都是开源的，也不一定是开源的。 没关系

那么，在所有关于业务和技术趋势，开源和专有软件的讨论之后，我在Confluent的新工作中将做什么？

融合分析，机器学习，区块链，企业中间件的融合平台

当然，在我的新工作中，我将重点关注Apache Kafka和Confluent Platform，在那里我将主要与EMEA的潜在客户和客户一起工作，而且还将继续担任技术传播者的出版物和会议演讲。 让我们在这里更详细一点...

我的工作重点从来不是做过深层次的技术专家，也不是解决生产环境中的问题（但是，我当然会动手编写代码）。 在进行非常技术性的讨论时，许多其他技术专家会更好。 与过去一样，我将专注于设计关键任务型企业体系结构，与潜在客户和客户讨论创新的现实用例，并结合Confluent平台评估最先进的技术。 以下是我接下来几个月的一些想法：

• Apache Kafka + Cloud Native平台=高度可扩展的流微服务（利用Kubernetes，Cloud Foundry，Apache Mesos等平台）
• 带有Apache Kafka Streams的高度可扩展的机器学习和深度学习微服务（使用TensorFlow，MXNet，H2O.ai和其他开源框架）
• 利用Apache Kafka作为基础架构骨干的在线机器学习（即，针对每个新事件实时更新分析模型）
• 用于核心和边缘流分析的开源物联网平台（利用Apache Kafka，Apache Edgent和其他物联网框架）
• 开源流处理框架的比较（Kafka Streams与其他现代框架（例如，Heron，Apache Flink，Apex，Spark Streaming，Edgent，Nifi，StreamSet等）之间的差异）
• Apache Kafka / Confluent和其他企业中间件（讨论何时将专有中间件与Apache Kafka结合，以及何时仅“仅”使用Confluent的开源平台）
• 中间件和流分析是区块链项目成功的关键

就像我在过去几年中所做的那样，您可以期待2017年的出版物，会议和聚会演讲以及有关这些主题和其他主题的网络研讨会。 请让我知道您最感兴趣的内容以及您想听到的其他主题！

我也非常期待与合作伙伴一起围绕Apache Kafka和Confluent Platform开发可扩展的，关键任务的企业架构和强大的解决方案。 这将包括开源解决方案和专有软件供应商的组合解决方案和用例。

最后但并非最不重要的一点是，我很高兴与传统企业，技术巨头和初创企业的潜在客户和客户合作，实现创新的用例和成功案例，以增加业务价值。

如您所见，我非常高兴于2017年5月开始在Confluent。我将在头几周访问Confluent的伦敦和帕洛阿尔托办事处，还将参加纽约的Kafka Summit 。 因此，这家令人敬畏的硅谷创业公司开始令人兴奋的一个月。

请让我知道您的反馈。 您看到相同的趋势吗？ 您是否同意我的观点或不同意？ 期待在即将举行的会议，研讨会，出版物，网络研讨会，聚会和会议演讲中与客户，合作伙伴和其他任何人讨论所有这些主题。

翻译自: https://www.javacodegeeks.com/2017/05/move-back-open-source-messaging-integration-stream-processing.html