引入 Kubernetes 是过早优化的危险信号

标签: kubernetes 优化 信号 | 发表时间:2022-09-19 00:27 | 作者:colstuwjx
出处:http://weekly.dockone.io

【编者的话】引入 Kubernetes 是过早优化的危险信号?且听听本文作者怎么说吧。

如果你所在的企业引入了 Kubernetes,那么你们很有可能会把精力花在一些偏离主线的事情上。

乍一听这句话可能会感觉到很奇怪,毕竟我们花了这么长的时间来布道和兜售 Kubernetes 的发行版以及咨询服务,致力于帮助人们能够更加充分地利用它,但是事情就是这样! 你也许不应该针对你的产品使用 Kubernetes 以及其他一堆“酷”的东西

绝大多数的初创以及扩张阶段的企业在构建软件时都应该避免使用 Kubernetes 以及其他的一些过早优化。如果你所在的企业使用了 Kubernetes,那么你们很有可能会把精力花在一些偏离主线的事情上。你们可能已经跌入了过早优化的陷阱。

请不要觉得这篇文章只是针对 Kubernetes。不是的。这篇文章针对的是工程师们在构建软件的过程中可能做出的所有过早优化。

以下是我见过的一些例子:
  • 将 Kubernetes 用于一个应用(还是个 Web 应用)的企业;
  • 应用程序用到了不只一种语言。比如,后端用的是 Golang、Ruby 或者是 PHP 等语言,然后前端 Web 用的是 React 或者 Vue 等框架;
  • 没有用云服务来托管应用。比如可以用 Heroku、Vercel、Netlify 或者 Fly.io 等。对于绝大多数产品团队来说,如果他们必须组建一个运维或者基础架构团队的话,他们的解决方案也将会是过度设计的。


试想一下,一个人在真正开始玩他的爱好之前花费了大量的时间和金钱为这个爱好挑选最好的装备。

当然,这里面有一些观点是比较主观的。也许你知道你会长期坚持你的新爱好,而且你有一个朋友刚好是这方面的行家,他可以帮你挑选合适的装备。不得不说,我自己就很擅长为自己辩解为什么要挑选精英装备,尽管我可能永远不会真的注意到这其中的区别。

好钢要用在刀刃上

如果你所在的企业认为它需要 Kubernetes,那么你也许正处在一个试图过早地为未来优化的地方。一个可能永远不会出现的未来。当你采用任何一项技术时,换个角度,也即是在为你所在的组织作出一个有效期长达数年的承诺,这将会增加产品的表面积,同时也会给开发人员带来心智负担。最终,你将不得不组建一个专门的团队来维护它。这一切都会从你的核心使命里夺走资源。

工程师们很容易跌入这个陷阱。我们很容易被新兴的炫酷技术分散注意力。我们想要学习和成长,而实现这一点的最佳途径就是把最新的技术融入到我们的产品里。然后,我们会想出各种理由来证明我们的决定是合理的。

我来给你们讲几个故事吧,关于我是如何跌入这个陷阱的。

我记得在我刚加入 OCUS 的时候我们有过一次讨论,我发现我们当时正在使用 Kubernetes。我说了一些话,类似于,“哦,那太好了。万一有一天我们如果想要弃用 AWS ,那么引入 Kubernetes 刚好可以帮助我们解决这个问题”。你能看出当时我有多疯狂吗?

还有一次,我们的数据科学团队告诉我们,他们的数据管道需要一个编排工具。我倾向于选用 Argo Workflow(它跑在 Kubernetes 里),而不是他们已经做了 PoC 的 Perfect(一款 SaaS 产品)。对于这个决定,我可以给出种种理由。不幸的是,它们都是基于过早优化的前提。故事的最后,我们的团队需要去构建一组新的 Terraform 和 Helm Chart 来自动化部署 Argo Workflow,然后把它集成到我们的 SSO 等等。对于这个决定我感到很遗憾。我认为正是由于做出了这个决定,这导致我们延误了数周甚至数月的时间才向最终用户交付功能。这就是过早优化!

如果我们能够避免过早优化,我们将可以比竞争对手更快地行动,取悦我们的用户,构建一套可持续和可行的产品的可能性也会提高。

那么我们怎样才能打破这种思维呢?

用户有没有提这个要求?

解决沿途遇到的问题而不必再提前考虑。我们所做的工作都应该切实地解决用户的问题。问问自己,我试图通过我的工作影响哪些人类行为?

如果你可以始终专注于用户行为,并且只解决那些它们自己冒出来的实际问题,那么你将会对自己产生的影响力感到惊讶。你也许还会对自己曾经向用户作出的诸多假设感到惊讶,因为你已经很久没谈论这些了。

我相信,严格坚持这种方法的企业将会为他们的用户和股东们创造更大的影响力并且产生更多的价值。

如果我把所有的精力都倾注在我的新爱好而不是研究设备上,那么我自然会知道我想要的到底是什么。在起步阶段,我并不需要最 “Gucci” 的装备,即便我有最好的装备,我甚至也会因为不知道如何使用它而显得格格不入。最好是用一套入门级设备来碾压别人,因为我所有的精力都用在了学习我的新爱好上。然后当我确实想要升级到 “Gucci” 装备时,它就会真的变得不同凡响。

事半功倍

值得庆幸的是,科技界正在经历一场大规模的路线修正。随着利率上升,廉价债务和风险资本开始枯竭。现如今的初创企业再也无法获得疯狂的资金,他们必须更加专注于他们的使命。能够生存下来的将是那些拥有坚实基础的企业。

产品必须交给那些能够以越来越快的速度交付业务成果的更小团队来构建。

在 Kubernetes 完全普及之前,我无法预见到 Kubernetes 在一个精益组织中的位置。即便如此,我认为 Kubernetes 还是可以当作一个扩展引入的。大多数组织可以考虑通过云厂商提供的一些更高层面的构建块来引入它。

别忘了,在 Facebook 以 190 亿美元收购 WhatsApp 时,它只有 35 名开发人员却服务了 4.5 亿用户!

如果要问本文给读者的忠告是什么的话,我想应当会是:高度关注实现组织使命所需的内容。不要被你想学习的东西(比如 Kubernetes 或 Golang)分心 —— 把它留给家庭实验室吧。

如果你可以继续高度专注于对自己的产品进行迭代,以影响业务结果的方式影响人类行为,那么我毫不怀疑你将最终能够脱颖而出。

这就是本周的全部内容,伙计们,祝你度过愉快的一周!

原文链接: Kubernetes is a red flag signalling premature optimisation. (翻译:Colstuwjx)

相关 [kubernetes 优化 信号] 推荐:

引入 Kubernetes 是过早优化的危险信号

- - DockOne.io
【编者的话】引入 Kubernetes 是过早优化的危险信号. 如果你所在的企业引入了 Kubernetes,那么你们很有可能会把精力花在一些偏离主线的事情上. 乍一听这句话可能会感觉到很奇怪,毕竟我们花了这么长的时间来布道和兜售 Kubernetes 的发行版以及咨询服务,致力于帮助人们能够更加充分地利用它,但是事情就是这样.

Kubernetes & Microservice

- - 午夜咖啡
这是前一段时间在一个微服务的 meetup 上的分享,整理成文章发布出来. 谈微服务之前,先澄清一下概念. 微服务这个词的准确定义很难,不同的人有不同的人的看法. 比如一个朋友是『微服务原教旨主义者』,坚持微服务一定是无状态的 http API 服务,其他的都是『邪魔歪道』,它和 SOA,RPC,分布式系统之间有明显的分界.

Kubernetes学习(Kubernetes踩坑记)

- - Z.S.K.'s Records
记录在使用Kubernetes中遇到的各种问题及解决方案, 好记性不如烂笔头. prometheus提示 /metrics/resource/v1alpha1 404. 原因: 这是因为[/metrics/resource/v1alpha1]是在v1.14中才新增的特性,而当前kubelet版本为1.13.

kubernetes移除Docker?

- -
两周前,Kubernetes在其最新的Changelog中宣布1.20之后将要弃用dockershime,也就说Kubernetes将不再使用Docker做为其容器运行时. 这一消息持续发酵,掀起了不小的波澜,毕竟Kubernetes+Docker的经典组合是被市场所认可的,大量企业都在使用. 看上去这个“弃用”的决定有点无厘头,那么为什么Kubernetes会做出这样的决定.

Kubernetes 完全教程

- - 午夜咖啡
经过一个阶段的准备,视频版本的 《Kubernetes 完全教程》出炉了. 课程一共分为七节,另外有一节 Docker 预备课,每节课大约一个多小时. 目标是让从没接触过 Kubernetes 的同学也能通过这个课程掌握 Kubernetes. 为什么要学习 Kubernetes. 在介绍课程之前,先说说为什么要学习 Kubernetes 以及什么人需要学习 Kubernetes.

Kubernetes 监控详解

- - DockOne.io
【编者的话】监控 Kubernetes 并不是件容易的事. 本文介绍了监控 Kubernetes 的难点、用例以及有关工具,希望可以帮助大家进一步了解监控 Kubernetes. 如果想要监控 Kubernetes,包括基础架构平台和正在运行的工作负载,传统的监控工具和流程可能还不够用. 就目前而言,监控 Kubernetes 并不是件容易的事.

Kubernetes 切换到 Containerd

- - bleem
由于 Kubernetes 新版本 Service 实现切换到 IPVS,所以需要确保内核加载了 IPVS modules;以下命令将设置系统启动自动加载 IPVS 相关模块,执行完成后需要重启. 重启完成后务必检查相关 module 加载以及内核参数设置:. 1.2、安装 Containerd. Containerd 在 Ubuntu 20 中已经在默认官方仓库中包含,所以只需要 apt 安装即可:.

Spring Cloud Kubernetes指南

- -
当我们构建微服务解决方案时,SpringCloud和Kubernetes都是最佳解决方案,因为它们为解决最常见的挑战提供组件. 但是,如果我们决定选择Kubernetes作为我们的解决方案的主要容器管理器和部署平台,我们仍然可以主要通过SpringCloudKubernetes项目使用SpringCloud的有趣特性.

喜大普奔:Spark on kubernetes

- - Zlatan Eevee
两个星期前(08/15/2017),spark社区提了一个新的SPIP(Spark Project Improvement Proposals): Spark on Kubernetes: Kubernetes as A Native Cluster Manager,即用k8s管理spark集群. 经过社区2个星期的投票,看上去很快要能合入了.

Kubernetes 日志收集方案

- - IT瘾-dev
Kubernetes 中的基本日志. Kubernetes 日志收集. 以 sidecar 容器收集日志. 用 sidecar 容器重新输出日志. 使用 sidecar 运行日志采集 agent. 前面的课程中和大家一起学习了 Kubernetes 集群中监控系统的搭建,除了对集群的监控报警之外,还有一项运维工作是非常重要的,那就是日志的收集.