在本文中，我们将讨论随着组织采用微服务、码头、容器和持续交付实践而出现的许多挑战中的一些。这篇博文并不是为了解决你所有的问题，而是想让你知道在哪里你可能会遇到摩擦，以及你如何以一种与你的组织相一致的有机方式来解决这些问题。
何时使用码头集装箱
您会发现大量关于利用Docker容器和微服务模式的文章，所以我不会重复至少在其他20个地方已经说过的话。经常被忽略的是，Docker允许我们打包在过去10年中构建的几乎任何应用程序(如果您面临挑战的话，时间更长)，并使用大量成熟的工具交付该应用程序。你可以从库伯奈特斯, 马拉松式DC/OS, 码头群，而现在Netflix公司。这就是Docker背后的秘密：它允许以一种固执己见的方式交付软件。这个软件可以是微服务，也可以是遗留服务，每个服务都有自己的挑战集。如果你能掌握自动作为打包应用程序的工具，您将处于为您的业务、微服务交付下一代服务的最佳位置。
真正重要的是什么？管道。
作为一名工程师，我将利用每一个机会尝试最新和最流行的工具、语言、框架和平台。这是可以理解的，因为工具，如竹或汞，肯定会感到过时或负担似乎过多的人工干预，以适当地自动化。这里要小心，采用额外的新技术会增加整个组织的复杂性，因为它们开始吸收新的过程和生态系统。
仔细评估组织中现有的技术，如果您能够找到使用这些解决方案完全自动化的方法，那么您应该这样做。尽管如此，您可能会被迫升级一些较旧的技术或完全替代其他技术。如果设置或定义您的构建过程需要任何类型的手动干预，它将是不可持续的。一个小的工程师团队(10)一个月可以生产几个新的微服务。在这个美好的新世界里，没有时间让吉斯。采用容器和微服务需要通过配置来修饰软件构建和交付生命周期中的所有组件，并通过API或事件触发操作。
我再怎么强调自动化构建和交付管道的重要性也不为过。在许多情况下，您会发现自己在开始部分自动化，但很快就会识别模式，以充分实现端到端的自动化。别让这件事走投无路。不断改进和规范你的管道，否则你以后会感觉到后果。当您的工程师开始快速创建新的微服务应用程序时，这通常会表现为瓶颈和复杂性的增加。对于组织来说，还有一些可以实现自动化的非琐碎的东西，让我们深入研究一下。
遗留变革管理
拥有现有变革管理政策的组织将很快被快速创新的步伐淹没。您的团队会意识到，为了管理他们大部分的变更，必须在他们的项目和任务开始时进行管理。适当地测量和管理更改的影响将变得越来越明显，因为您开始意识到您可以多快的速度开始对您的基础结构和应用程序进行更改。这并不是灵丹妙药，这一非常重要的业务流程的发展需要仔细的规划和沟通。
有许多组织已经学会了利用特性切换、金丝雀部署，并掌握了每天部署数千次更改的技巧。对于大多数组织来说，利用这些技术更不用说开始实现这些技术了。从“小”开始，在这里或在那里设置一个功能标志。现代工具，如詹金斯和库伯奈特斯开始加那利部署即使是小团队也是可以管理的。
这里的要点是，在任何利用微服务的组织中都必须努力实现变更管理的自动化，但有时我们面临的事实是，我们还没有实现这些方法的民主化程度。
监测和观察贵组织的变化
您可能没有金丝雀部署，也没有完全流水线化的变更管理流程，但您所拥有的是您的业务，要求您进行创新并快速发布更多的软件。更多无论您在容器之旅中的位置如何，唯一成功的方法就是能够观察和监视您的基础设施和在您的容器平台上运行的应用程序的健康状况。
当您决定如何处理容器监视时，需要回答一些非常大的问题。随着应用程序的复杂性迅速增加，您是否已经有了一个团队来不断地配置、改进和操作您的监视堆栈？你想要一个专门管理你的监控工具的团队吗？如果是这样的话，有许多开源工具可以帮助您实现观察自定义业务度量的目标，并回答组织总体健康状况背后的问题。团队正在意识到利用普罗米修斯为了测试关键的业务度量，并在一段时间内将它们与应用程序(如格拉法纳。这些解决方案不是关键，但是，它们需要大量的努力来实现、维护和发展您的应用程序生命周期。
大多数公司希望专注于为他们的业务开发软件，而不是照看他们的监控解决方案。这就是供应商，比如因斯塔纳可以毫不费力地自动收集有关生态系统的信息并深入了解容器化应用程序的生命周期，通过追踪, 机器学习和人工智能来提供关于容器工作负载之间高度复杂的交互的有意义的数据。
由于您的组织已经开始通过制度化的DevOps实践来革新他们的软件工程团队，比如持续部署、测试和集成。12因子应用、Docker容器和无服务器，请始终记住，您需要一个适当的解决方案来监视和观察这些新系统。