服务网格已经引起了很多关注，这是有充分理由的。通过在平台层提供可靠性，安全性和可观察性，服务网格可以在Kubernetes应用程序中扮演关键任务。
但是应用情况好坏参半：一些从业者报告说，由于它们看起来很复杂，他们避开了采用服务网格，而另一些从业者则报告说，使它们变得易于运行并运行起来。那是什么呢？服务网格是否过于复杂以至于不值得付出努力，还是准备今天立即采用？
在本文中，我想重点介绍Linkerd，它是Cloud Native Computing Foundation服务网格（和类别的先驱），以强调简单性而闻名。在日益拥挤的服务网格环境中，Linkerd在这种“ less-is-more”的方法以及在数据平面层使用基于Rust的专用“微代理”的过程中都是独一无二的。
Linkerd网站列出了相当多的组织在生产环境中运行它，因此我着手与其中的一些人进行交谈，并听听他们的经验。为什么选择Linkerd，并将其与更复杂的服务网格（例如该领域当前的市场领导者Istio）进行比较？
对于这篇文章，我采访了来自两个不同组织的两名DevOps专业人员。我们讨论了他们在生产中运行Linkerd的过程，并在过程中收集了一些有趣的收获。 大卫Sudia是一个高级的DevOps工程师GoSpotCheck，移动任务管理应用的现场服务团队，在那里他领导的运营小组。David在KubeCon + CloudNativeCon NA 2020上发表了有见地的主旨演讲，“更大的力量，更少的痛苦：使用CNCF工具构建内部平台。”
Freddy Andersen是YouMail（视觉语音邮件和垃圾邮件阻止服务）的CIO 。自大流行之前，YouMail团队一直在进行远程工作。
到目前为止，我们讨论了他们的服务网格之旅，他们很高兴分享他们的经验。虽然我们分开讲，但他们的故事有一些惊人的相似之处。他们两个：
- 对服务网格有类似的要求
- 首先尝试过Istio，但发现它过于复杂
- 偶然发现了KubeCon的Linkerd展台，此后一直在转变。
详细点击标题见原文。
最后，我向他们征求他们对当今服务网格生态系统状态的看法以及对Istio的看法。他们赞同Istio尝试做很多事情的观点，尽管这可能对其他组织也有用，但他们想要的是具有针对性，灵活的事情，并为他们选中了所有合适的框。这正是他们在Linkerd中找到的。
当谈到Istio时，他们并不是特别受“ FOMO”的困扰，他们与Linkerd分享经验的热情充分说明了他们对该项目的支持。