长年从事IT咨询工作，Jan Kammerath看到了很多公司的IT基础设施和系统架构。在过去十年里，他观察到这样一个现象：Kubernetes和Apache Kafka变得非常普遍和流行，但对一些企业来说，部署效果却并不那么尽如人意。这家公司的SaaS产品运行良好，商业化也很成功。在过去几十年的发展中，已经从面向Windows的桌面软件产品成功过渡为一个具有微服务架构的成熟SaaS产品。这位CEO本人在20世纪90年代中期编写了最初的产品。随着产品的升级迭代，他不再参与具体的开发工作。一般来说，管理层可能不太了解开发团队的具体事宜，但当事情的发展似乎要出现偏差时，他们通常会有某种直觉。在多数情况下，他们只是想让我检查一下，并希望得到一些来自外部的肯定，来确保他们的IT基础设施和开发流程都很好。接到这位CEO的电话时，我也是这么想的。不过事情显然没有那么简单。公司业务的利润率很好，运营成本也在可接受范围内，真正令CEO头疼的是，“我们的可用性只有87%，我们的SLA是95%，我已经为下一个财年的运营增加了50万欧元的预算。”尽管到目前为止他们还没收到任何客户投诉，但是这位老板依旧对于他们的服务质量和不断上升的运营成本深表担忧。对此，我非常理解：50万欧的额外投入对于这种体量的公司来说并非小事。即使在2019年，87%的可用性也非常糟糕。而且95%的SLA依旧意味着总共两周的中断。通常来说，SaaS的SLA在一年中大多在97-99%左右。97%仍然相当于11天的总停机时间。我了解到：他们使用了一个托管的git存储库和一个大型存储库主机，并使用Jenkins作为CI/CD管道，将每个微服务部署到Kubernetes集群中。服务总线，微服务之间的通信，是通过Kafka完成的。在现代化进程中，曾经有一个顾问来为他们的IT基础设施起草整体的现代化和迁移方案，包括在Kubernetes上运行重构应用程序，并通过Kafka传递消息。如今这个顾问早就离职了，现在的运营和工程团队对于这种设置并不感冒，还有人直接问我有没有更简洁的替代方案。在我查看了所有的项目文档之后，发现最初使用Kubernetes和Kafka的主要理由是“与云无关”。与云无关是指一种云设计策略，其中应用程序、工具和服务旨在以混合模式在多个云平台之间或本地和云之间无缝迁移，而不会中断服务。这种策略的一些原则是支持独立于底层操作系统的无缝可移植性，确保迁移中工作负载的有限中断，并限制应用程序停机的风险，同时提高成本效率。公司可以轻松地以简化和直接的方式构建与云无关的应用程序。这是因为 Kubernetes 创建了一种跨不同公共云和私有云环境管理和运行应用程序的标准方法。在那段时间里，有人认为最好“独立于任何云提供商”。而且我认为风险是CEO脑海中萦绕的一个念头。虽然与云无关的方法为组织提供了一些好处，让相关的公司组织在与云无关时可以避免被锁定在单个供应商中，但这也可能是其工程团队的劣势。比如，一个云提供商提供了对贵司的应用程序很重要的关键功能，那么如果其他云提供商没有此功能，则可能无法在与云无关的方法中使用它。无法使用云提供商的创新服务可能会减慢团队的速度并使竞争对手处于优势地位。另外一个潜在缺点就是处理意外的数据传输成本。众所周知，这些成本很难预测和理解。对于许多组织来说，构建多个云提供商可能不经济。可替代方案是什么呢？在这个案例中，我给出的建议是：无服务器。考虑到他们拥有的吞吐量和资源利用率，他们几乎不会达到AWS任何无服务器产品的服务限制。在AWS SNS上每秒不会超过200条消息，更不用说达到AWS SQS队列限制了。他们用Kafka所能做的一切没有什么是SNS或SQS所不能做到的。由于他们已经在AWS上运行了Kubernetes和Kafka，他们可以很容易地迁移到无服务器产品(Lambda、API Gateway、SQS、SNS)，而且他们的基础设施账单也有很好的成本降低潜力。很明显，他们的主要问题是Kubernetes集群的运行占用了大量的时间，而且没有云基础设施本身的成本。针对这些情况，我做了一个演示，解释了团队将如何迁移到无服务器产品。最重要的是，我提出了一个风险缓解路线图，我的蓝图甚至提供了一个完整的“灾难撤退到本地部署”。退回到本地部署的选择听起来很荒谬，但在大多数情况下可以缓解担忧。毕竟，我能够说服团队和管理层逐步转向无服务器。我还说服他们用CI/CD管道产品取代他们的Jenkins，他们已经为他们的存储库主机支付了费用。我同意他们的意见，之后我会继续观察事情进展如何。大约在我拜访的7个月后，他们问我是否可以对他们迄今为止所构建以及迁移的东西做一个架构回顾。我又去了他们的办公室，基本全天都在看架构图。老实说，并没有什么神奇之处：带有API gateway和Lambda的微服务，带有SNS的中央服务总线，以及带有SQS的几个扇形架构。许多DynamoDB表和S3桶。从技术的角度来看，他们的产品没有很高的复杂性。他们的产品优势在于，他们与他们所在的特定行业的现有客户生态系统紧密集成。他们还将客户高度专业化的业务流程完全自动化，并开发了许多令人印象深刻的功能。他们拥有的最“复杂”的系统是关系数据库和搜索引擎。由于大部分基础设施运营已经外包给了亚马逊，因此可用性的显著提高也就不足为奇了。与此同时，他们已经通过云账单削减了成本，因为他们从Kubernets迁移的服务将不再永久运行，而是只在需要时运行。这不是Kubernetes和Kafka的错，但是……Kubernetes和Kafka在技术上没有任何问题，但是Kubernetes和Kafka有可能成为一个经济问题。虽然从技术上讲，这是一个非常好的解决方案，但很多企业既没有人力也没有财力来运营Kubernetes和Kafka。当企业，更具体地说是内部人员，最初决定使用k8s和Kafka时，他们没有将TCO(总拥有成本)与其他替代方案(如AWS、谷歌Cloud或Azure上的无服务器)进行基准测试。运行Kubernetes集群需要人力、时间和预算。在我参与的大多数业务案例中，Kubernetes在经济性方面总是落后于无服务器，甚至是负载均衡器与多az部署的虚拟机。无论你的技能有多好，如果Kubernetes集群的TCO是第二备选的2 - 4倍，你就会陷入麻烦。随着越来越多的公司转向FaaS(功能即服务)，所需要做的只是尽职调查或技术审计，你将需要解释为什么要运行Kubernetes集群。当你的管理层看到其他公司的标杆时，“每个人都这么做”是一个相当站不住脚的理由。结果是你的老板可能会因为Kubernetes集群或昂贵的Kafka环境而责怪你。我的建议是：积极地对Kubernetes和/或Kafka集群的总拥有成本进行基准测试（AWS、谷歌Cloud、Azure或IBM/Red Hat的无服务器产品都有该测试）。评估你是否需要Kubernetes和/或Kafka，以及为什么没有合理的替代方案。当你有Kafka和Kubernetes的经验时，它肯定会在你的简历上看起来很好，当你把它们扔到一边，节省了50万欧元的成本时，它会看起来更好。你的雇主花在超重基础设施和系统上的每一分钱，都不能花在你的下一次加薪上。比起运行Kubernetes集群的辉煌，你更有可能因为削减成本、提高服务质量和缩短上市时间而获得回报。原文链接：
https://medium.com/@jankammerath/how-kubernetes-and-kafka-will-get-you-fired-a6dccbd36c77
免责声明：本文内容来源于网络，所载内容仅供参考。转载仅为学习和交流之目的，如无意中侵犯您的合法权益，请及时联系Docker中文社区！
还没有评论，来说两句吧...