微服务和容器：需要去防范的 5 个“坑”
微服务 容器

> 
> 微服务与容器天生匹配，但是你需要避开一些常见的陷阱。
> 
> 
> 


![](/data/attachment/album/201801/19/153328uzw2zrg4k1ntrwgg.png)


因为微服务和容器是 [天生的“一对”](https://enterprisersproject.com/article/2017/8/5-advantages-containers-writing-applications)，所以一起来使用它们，似乎也就不会有什么问题。当我们将这对“天作之合”投入到生产系统后，你就会发现，随着你的 IT 基础的提升，等待你的将是大幅上升的成本。是不是这样的？


（让我们等一下，等人们笑声过去）


是的，很遗憾，这并不是你所希望的结果。虽然这两种技术的组合是非常强大的，但是，如果没有很好的规划和适配，它们并不能发挥出强大的性能来。在前面的文章中，我们整理了如果你想 [使用它们你应该掌握的知识](https://enterprisersproject.com/article/2017/9/microservices-and-containers-6-things-know-start-time)。但是，那些都是组织在容器中使用微服务时所遇到的常见问题。


事先了解这些可能出现的问题，能够帮你避免这些问题，为你的成功奠定更坚实的基础。


微服务和容器技术的出现是基于组织的需要、知识、资源等等更多的现实的要求。Mac Browning 说，“他们最常犯的一个 [错误] 是试图一次就想‘搞定’一切”，他是 [DigitalOcean](https://www.digitalocean.com/) 的工程部经理。“而真正需要面对的问题是，你的公司应该采用什么样的容器和微服务。”


**[ 努力向你的老板和同事去解释什么是微服务？阅读我们的入门读本[如何简单明了地解释微服务](https://enterprisersproject.com/article/2017/8/how-explain-microservices-plain-english?sc_cid=70160000000h0aXAAQ)。]**


Browning 和其他的 IT 专业人员分享了他们遇到的，在组织中使用容器化微服务时的五个陷阱，特别是在他们的生产系统生命周期的早期时候。在你的组织中需要去部署微服务和容器时，了解这些知识，将有助于你去评估微服务和容器化的部署策略。


### 1、 在部署微服务和容器化上，试图同时从零开始


如果你刚开始从完全的单例应用开始改变，或者如果你的组织在微服务和容器化上还没有足够的知识储备，那么，请记住：微服务和容器化并不是拴在一起、不可分别部署的。这就意味着，你可以发挥你公司内部专家的技术特长，先从部署其中的一个开始。Sungard Availability Services][5](https://www.sungardas.com/) 的资深 CTO 架构师 Kevin McGrath 建议，通过首先使用容器化来为你的团队建立知识和技能储备，通过对现有应用或者新应用进行容器化部署，接着再将它们迁移到微服务架构，这样才能最终感受到它们的优势所在。


McGrath 说，“微服务要想运行的很好，需要公司经过多年的反复迭代，这样才能实现快速部署和迁移”，“如果组织不能实现快速迁移，那么支持微服务将很困难。实现快速迁移，容器化可以帮助你，这样就不用担心业务整体停机”。


### 2、 从一个面向客户的或者关键的业务应用开始


对组织来说，一个相关陷阱恰恰就是从容器、微服务、或者两者同时起步：在尝试征服一片丛林中的雄狮之前，你应该先去征服处于食物链底端的一些小动物，以取得一些实践经验。


在你的学习过程中可以预期会有一些错误出现 —— 你是希望这些错误发生在面向客户的关键业务应用上，还是，仅对 IT 或者其他内部团队可见的低风险应用上？


DigitalOcean 的 Browning 说，“如果整个生态系统都是新的，为了获取一些微服务和容器方面的操作经验，那么，将它们先应用到影响面较低的区域，比如像你的持续集成系统或者内部工具，可能是一个低风险的做法。”你获得这方面的经验以后，当然会将这些技术应用到为客户提供服务的生产系统上。而现实情况是，不论你准备的如何周全，都不可避免会遇到问题，因此，需要提前为可能出现的问题制定应对之策。


### 3、 在没有合适的团队之前引入了太多的复杂性


由于微服务架构的弹性，它可能会产生复杂的管理需求。


作为 [Red Hat](https://www.redhat.com/en) 技术的狂热拥护者，[Gordon Haff](https://enterprisersproject.com/user/gordon-haff) 最近写道，“一个符合 OCI 标准的容器运行时本身管理单个容器是很擅长的，但是，当你开始使用多个容器和容器化应用时，并将它们分解为成百上千个节点后，管理和编配它们将变得极为复杂。最终，你将需要回过头来将容器分组来提供服务 —— 比如，跨容器的网络、安全、测控”。


Haff 提示说，“幸运的是，由于容器是可移植的，并且，与之相关的管理栈也是可移植的”。“这时出现的编配技术，比如像 [Kubernetes](https://www.redhat.com/en/containers/what-is-kubernetes) ，使得这种 IT 需求变得简单化了”（更多内容请查阅 Haff 的文章：[容器化为编写应用带来的 5 个优势](https://enterprisersproject.com/article/2017/8/5-advantages-containers-writing-applications)）。


另外，你需要合适的团队去做这些事情。如果你已经有 [DevOps shop](https://enterprisersproject.com/article/2017/8/devops-jobs-how-spot-great-devops-shop)，那么，你可能比较适合做这种转换。因为，从一开始你已经聚集了相关技能的人才。


Mike Kavis 说，“随着时间的推移，部署了越来越多的服务，管理起来会变得很不方便”，他是 [Cloud Technology Partners](https://www.cloudtp.com/) 的副总裁兼首席云架构设计师。他说，“在 DevOps 的关键过程中，确保各个领域的专家 —— 开发、测试、安全、运营等等 —— 全部都参与进来，并且在基于容器的微服务中，在构建、部署、运行、安全方面实现协作。”


### 4、 忽视重要的需求：自动化


除了具有一个合适的团队之外，那些在基于容器化的微服务部署比较成功的组织都倾向于以“实现尽可能多的自动化”来解决固有的复杂性。


Carlos Sanchez 说，“实现分布式架构并不容易，一些常见的挑战，像数据持久性、日志、排错等等，在微服务架构中都会变得很复杂”，他是 [CloudBees](https://www.cloudbees.com/) 的资深软件工程师。根据定义，Sanchez 提到的分布式架构，随着业务的增长，将变成一个巨大无比的繁重的运营任务。“服务和组件的增殖，将使得运营自动化变成一项非常强烈的需求”。Sanchez 警告说。“手动管理将限制服务的规模”。


### 5、 随着时间的推移，微服务变得越来越臃肿


在一个容器中运行一个服务或者软件组件并不神奇。但是，这样做并不能证明你就一定在使用微服务。Manual Nedbal， [ShieldX Networks](https://www.shieldx.com/) 的 CTO，他警告说，IT 专业人员要确保，随着时间的推移，微服务仍然是微服务。


Nedbal 说，“随着时间的推移，一些软件组件积累了大量的代码和特性，将它们放在一个容器中将会产生并不需要的微服务，也不会带来相同的优势”，也就是说，“随着组件的变大，工程师需要找到合适的时机将它们再次分解”。




---


via: <https://enterprisersproject.com/article/2017/9/using-microservices-containers-wisely-5-pitfalls-avoid>


作者：[Kevin Casey](https://enterprisersproject.com/user/kevin-casey) 译者：[qhwdw](https://github.com/qhwdw) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
Because microservices and containers are a [match made in heaven](https://enterprisersproject.com/article/2017/8/5-advantages-containers-writing-applications), it might seem like nothing could go wrong. Let’s get these babies into production as quickly as possible, then kick back and wait for the IT promotions and raises to start flooding in. Right?

(We’ll pause while the laughter subsides.)

Yeah, sorry. That’s just not how it works. While the two technologies can be a powerful combination, realizing their potential doesn’t happen without some effort and planning. In previous posts, we’ve tackled what you should [know at the start](https://enterprisersproject.com/article/2017/9/microservices-and-containers-6-things-know-start-time). But what about the most common problems organizations encounter when they run microservices in containers?

Knowing these potential snafus in advance can help you *avoid* them and lay a more solid foundation for success.

It starts with being realistic about your organization’s needs, knowledge, resources, and more. “One common [mistake] is to try to adopt everything at once,” says Mac Browning, engineering manager at [DigitalOcean](https://www.digitalocean.com/). “Be realistic about how your company adopts containers and microservices.”

**[ Struggling to explain microservices to your bosses and colleagues? Read our primer on how to explain microservices in plain English. ]**

Browning and other IT pros shared five pitfalls they see organizations encounter with containerized microservices, especially early in their production lifespan. Knowing them will help you develop your own realistic organizational assessment as you build your strategy for microservices and containers.

## 1. Trying to learn both from scratch simultaneously

If you’re just starting to move away from 100% monolithic applications, or if your organization doesn’t already a deep knowledge base for containers *or* microservices, remember this: Microservices and containers aren’t actually tethered to one another. That means you can develop your in-house expertise with one before adding the other. Kevin McGrath, senior CTO architect at [Sungard Availability Services](https://www.sungardas.com/), recommends building up your team’s knowledge and skills with containers first, by containerizing existing or new applications, and then moving to a microservices architecture where beneficial in a later phase.

“Companies that run microservices extremely well got there through years of iteration that gave them the ability to move fast,” McGrath says. “If the organization cannot move fast, microservices are going to be difficult to support. Learn to move fast, which containers can help with, then worry about killing the monolith.”

## 2. Starting with a customer-facing or mission-critical application

A related pitfall for organizations just getting started with containers, microservices, or both: Trying to tame the lion in the monolithic jungle before you’ve gotten some practice with some animals lower on the food chain.

Expect some missteps along your team’s learning curve – do you want those made with a critical customer-facing application or, say, a lower-stakes service visible only to IT or other internal teams?

“If the entire ecosystem is new, then adding their use into lower-impact areas like your continuous integration system or internal tools may be a low-risk way to gain some operational expertise [with containers and microservices,” says Browning of DigitalOcean. “As you gain experience, you'll naturally find new places you can leverage these technologies to deliver a better product to your customers. The fact is, things will go wrong, so plan for them in advance.”

## 3. Introducing too much complexity without the right team in place

As your microservices architecture scales, it can generate complex management needs.

As [Red Hat](https://www.redhat.com/en) technology evangelist [Gordon Haff](https://enterprisersproject.com/user/122076) recetly wrote, "An OCI-compliant container runtime by itself is very good at managing single containers. However, when you start using more and more containers and containerized apps, broken down into hundreds of pieces, management and orchestration gets tricky. Eventually, you need to take a step back and group containers to deliver services – such as networking, security, and telemetry – across your containers."

"Furthermore, because containers are portable, it’s important that the management stack that’s associated with them be portable as well," Haff notes. "That’s where orchestration technologies like [Kubernetes](https://www.redhat.com/en/containers/what-is-kubernetes) come in, simplifying this need for IT." (See the full article by Haff: [5 advantages of containers for writing applications](https://enterprisersproject.com/article/2017/8/5-advantages-containers-writing-applications). )

In addition, you need the right team in place. If you're already a [DevOps shop](https://enterprisersproject.com/article/2017/8/devops-jobs-how-spot-great-devops-shop), you might be particularly well-suited for the transition. Regardless, put a cross-section of people at the table from the start.

“As more services get deployed overtime, it can become unwieldy to manage,” says Mike Kavis, VP and principal cloud architect at [Cloud Technology Partners](https://www.cloudtp.com/). “In the true essence of DevOps, make sure that all domain experts – dev, test, security, ops, etc. – are participating up front and collaborating on the best ways to build, deploy, run, and secure container-based microservices.

## 4. Ignoring automation as a table-stakes requirement

In addition to the having the right team, organizations that have the most success with container-based microservices tend to tackle the inherent complexity with an “automate as much as possible” mindset.

“Distributed architectures are not easy, and elements like data persistence, logging, and debugging can get really complex in microservice architectures,” says Carlos Sanchez, senior software engineer at [CloudBees](https://www.cloudbees.com/), of some of the common challenges. By definition, those distributed architectures that Sanchez mentions will become a Herculean operational chore as they grow. “The proliferation of services and components makes automation a requirement,” Sanchez advises. “Manual management will not scale.”

## 5. Letting microservices fatten up over time

Running a service or software component in a container isn’t magic. Doing so does not guarantee that, *voilà*, you’ve got a microservice. Manual Nedbal, CTO at [ShieldX Networks](https://www.shieldx.com/), notes that IT pros need to ensure their microservices *stay* microservices over time.

“Some software components accumulate lots of code and features over time. Putting them into a container does not necessarily generate microservices and may not yield the same benefits,” Nedbal says. “Also, as components grow in size, engineers need to be watchful for opportunities to break up evolving monoliths again.”