商品微服务_微服务是商品

商品微服务

我是西蒙·沃德利 （ Simon Wardley）的忠实粉丝。 我无法了解他所写的所有内容，但是即使是以前的著作也很有趣，而且回顾起来在某种程度上都有意义。 如果你还没有读他的任何事情，这个视频是一个良好的开端（或几年回去了更长的通话 ）。 在本文中，我将尝试使用沃德利的理论（和图表 ）弄清微服务世界中正在发生的事情。

事情如何发展？

任何想法，产品，系统等，都始于它的起源，如果成功，它就会演变，其他人会复制它并从中创建新的自定义解决方案。 如果它仍然成功，它将进一步传播，其他人将创造新产品，这些产品将得到改进，扩展，并变得普及和可用，“无处不在”，广为人知，甚至更像是一种商品。 多年来，在许多成功的产品中都可以观察到这种生命周期，例如计算机，移动设备，虚拟化/云计算等。

如果我们考虑微服务，架构风格，支持微服务的项目，从中诞生的平台，容器，DevOps实践等……它们每个都处于上图中的某个阶段。 但总体而言，微服务运动现在是一个非常普遍的，易于理解的概念，并且已经变成商品。 从出版物，会议，书籍，已确认的生产成功案例等方面，有许多迹象可以证明这一点。毫无疑问，这一点已经不再存在。

我们是怎么来到这里的？

微服务的起源始于5-6年前，ThoughtWorks的Fred George和James Lewis分享了他们的想法。 在接下来的几个月中，Thoughtworks进行了大量的思考，编写和讨论，而Netflix进行了大量的黑客攻击并创建了第一代微服务
图书馆 。

这些库中的大多数仍然不是很受欢迎，并且可以被更广泛的开发人员社区使用，只有先锋和初创公司才能有时尝试它们。 然后，SpringSource加入了潮流，他们将Netflix库包装并打包成产品 ，并使Java开发人员可以访问所有易于使用的自定义构建解决方案。 同时，对微服务的所有这种兴趣推动了进一步的创新，并且容器诞生了。 这带来了另一波创新浪潮，更多的资金，洗牌，新的工具集，使DevOps理论成为一种实践。

容器是部署微服务的主要手段，不久就产生了对容器编排（即Cloud Native平台）的需求 。 如今， Cloud Native格局正在过渡，即将形成新格局 。 如果环顾四周，就会发现有多个Cloud Native平台，每个平台都是从不同的时间点和独特的价值主张出发的，但是却逐渐进入了一个共同的功能集，相似的概念甚至是标准。

例如，AWS ECS，Kubernetes，Apache Mesos，Cloud Foundry等平台的功能奇偶性越来越接近，每种功能都很丰富，已在生产中使用，并且具有可比的原语。 从上图可以看到，现在，作为技术战略，重要的是押注具有开放标准，开源，庞大社区和长期成功机会的平台。

这意味着，例如，选择符合OCI的容器运行时，选择基于Open Tracing 标准而不是自定义实现的跟踪工具，以支持行业标准的日志记录和监视解决方案，并由商品产品良好的公司提供支持。

组织类型

根据Wardly的说法，存在三种类型的人员/团队/组织，每种类型在发展的某些阶段都很出色：

• 开拓者擅长探索未知领域和未发现的概念。 他们将疯狂的想法变成现实。
• 定居者擅长将半熟的原型制作成对更多观众有用的东西。 他们建立信任，理解和完善概念。 他们将原型变成产品，使其可制造并实现盈利。
• 城市规划者擅长利用某种东西并利用规模经济将其产业化。 他们构建了未来需要大量技能的可信赖平台。 他们找到了使事情变得更快，更好，更小，更高效，更经济和足够好的方法。

通过此定义和上表显示了每种类型的组织的特征，我们可以进行以下假设分类：

• Netflix绝对是先锋。 他们所拥有的富有创造力，探索者的人们，公司围绕试验的方式，不确定性，围绕自由，责任的文化 ，他们带入微服务服务世界的一切都使他们成为开拓者。
• 对我来说， SpringSource更像是定居者类型。 他们已经有了一个流行的Java堆栈，并且设法发现了微服务的趋势，并以Spring Boot和Spring Cloud的形式创建了一个很好的易耗品。
• 亚马逊，谷歌，微软是城市规划师。 它们可能来晚了，但是它们已经做好了充分准备，并定义了长期战略，网络规模解决方案和无与伦比的定价。 诸如Kubernetes，ECS之类的平台（由于它相当封闭，因此并不完全确定后者）是建立在10多年的经验基础上的，并且可以持续很长时间，并成为了行业标准。

本节的一个重要内容是，并非先驱者发明的所有东西都是供普通消费者使用的。 先驱者行动Swift，除非您的组织具有类似的特征，否则可能很难一直跟踪。 另一方面，城市规划者可以基于开放标准来创建可互操作的产品和服务。 从长远来看，这将成为重要的自由轴心。

结论

在微服务世界，事物正在从未知的方向发展到工业化的方向。 大多数活动并不是那么混乱，不确定和不可预测。 规划，设计和实现微服务几乎变成了无聊而乏味的活动。 而且，由于这是一项利润率很低的工业化工作，因此工具的选择以及交换这些平台的能力将发挥重要作用。

最后但并非最不重要的一点是，这种演变的一个很好的副作用是，我们在会议期间应该较少了解Conway定律，两个比萨饼和断路器，而应该更多地了解大规模管理微服务，自动化，业务价值，无服务器和新的微服务。来自我们行业先驱者的神秘想法。

翻译自: https://www.javacodegeeks.com/2016/12/microservices-are-commodity.html

商品微服务