最近我一直在使用容器进行分配，为红帽峰会准备一个非常酷的实验室。该实验室称为“面向 Java 开发人员的 Docker”，参与者将在此实验室中学习如何在开发和测试中使用容器。他们还将了解 Kubernetes 如何随着容器数量的增长帮助进行编排。
与此同时，我正在准备一个关于微服务的网络研讨会。微服务是一种架构方法，以良好的软件设计实践为基础，以当今数字业务所需的速度和质量交付和维护复杂的软件系统。这种架构的好处是多方面的，包括：团队敏捷性、灵活的工具和框架、易于扩展、弹性、更好的容错性和易于维护。
组合容器和微服务可以共生工作，真正加速交付并提高质量。
没有微服务的容器仍然很强大，但是如果你将传统的整体应用程序迁移到容器中而不将它们分解成专注于做好一件事的小服务，你很快就会发现容器只是完成同一件事的另一种方式.是的，您可能会在交付管道中拥有更好的自动化，但好处仍然有限。
没有容器的微服务同样受到限制。微服务市场上的所有早期采用者都会告诉您，微服务带来了一系列新的挑战。我认为这些挑战中的大多数都不是新的，它们对早期采用者来说只是新的，因为他们在迁移微服务之前只有一个大型单体应用程序。
在我看来，容器和微服务是解决两个不同问题的方法。与所有新解决方案一样，它们也有自己的缺点。这就像“前进两步，后退一步”的陷阱。然而，由于容器解决了微服务的挑战，反之亦然，将它们结合起来只会导致向前迈进。
最终结果是质量呈指数级提高，交货时间呈指数级改进，从而及时提供更好的业务服务以满足市场需求。
如果你有兴趣从我和微服务领域其他知名演讲者那里听到更多关于这个的信息，比如来自 Battery Ventures 的 Adrian Cockcroft、来自 Red Hat 的 Arun Gupta 和来自 Red Hat 的 Babak Mozaffari。然后确保您 在此处 注册网络研讨会系列“以微服务方式构建企业应用程序”。