为什么从第一天起就应该在Kubernetes上构建应用

如果你正在从头开发一个新的项目，诸如一个新的APP ，服务或者网站，你主要的关注点通常不是如何在高可用的网络中大规模的运行它。相反，你可能会专注于为你的目标客户打造合适的产品或寻找适合市场的产品。如果你正在为一家初创公司创建一个MVP ，你需要在大规模扩展（scaling）之前完成这个最小可用产品，否则，你在为谁扩展？如果你是企业的开发人员，你希望确保的是当前做的业务满足期望和需求。规模化运营充其量只是明天的事情。
因此，在选择正确的技术集时， Kubernetes（通常与大型分布式系统相关）现在可能不在你的关注范围内。毕竟，它带来了很大一部分工作量：设置和操作集群、容器化你的应用程序、定义服务、部署、负载平衡器等等。这在早期看起来可能有点矫枉过正，你可能认为你的时间最好花在其他任务上，例如编写实际应用程序的前几次迭代。
当我们在2008年开始构建StackOverflow时，我们没得选择。没有Docker（2013年），也没有Kubernetes（2014年）。云计算还处于起步阶段：Azure刚刚推出（2008年），而AmazonWebServices大约成立两年。我们构建的东西是为特定硬件设计的，并对其做了很多假设。现在我们正在对我们的代码库进行现代化改造并迁移到云端，我们必须投入大量工作才能使Kubernetes和容器正常工作。
经历了这个过程，我们获得一个全新的视角。如果你今天正在构建一个新应用程序，那么仔细研究一下使其成为云原生并从一开始就使用Kubernetes可能是值得的。设置Kubernetes的工作量比你想象的要少。同时，它也比以后重构你的应用程序来支持容器化所需的工作量少。
以下有三个原因说明为什么从一开始就在Kubernetes上构建你的应用程序不一定是一个坏主意。
托管的Kubernetes完成了繁重的工作
几年前，当我们在StackOverflow建立我们的第一个内部Kubernetes集群时，我们花了将近一周的时间才能启动并运行所有内容：配置虚拟机、安装、配置、配置、配置。一旦集群启动，后面就是持续的维护工作。这个过程对我们最大的触动是Kubernetes对我们来说太棒了——但我们希望其他人也能来使用它。
如今， Amazon的ElasticKubernetesService（EKS）、Microsoft的AzureKubernetesService（AKS）或Google的GoogleKubernetesEngine（GKE）等托管Kubernetes服务允许你在几分钟内设置自己的集群。例如，在AKS中，你只需单击门户中的几个按钮并填写几个表单：

这很方便，但你可能不想在工作流结束时创建集群这种快捷方式。先完成这个向导（wizard），但不要点击最后那个蓝色的“创建”按钮！相反，将你刚刚创建的配置下载为ARM模板[1]并将其纳入到你的源代码控制系统。现在你拥有两全其美的优势——易用性和基础设施即代码（IaC）！
一旦你在此处完成设置，那么对于规模化你的应用程序，剩下的就没有什么可做的了，除了向你的云提供商提供更多的写检查（writebiggerchecks）。任何额外的资源分配都很容易。规模化带来的问题——容错、负载平衡、流量整形（trafficshaping）——已经得到处理。在任何时候，都不会出现你被成功淹没的那一刻；你无需付出太多额外工作就可以使你的应用程序面向未来。
你可以保持云无关（cloudagnostic）
如果你的项目成功了，那么在早期阶段做出的技术决策很可能在未来数月或数年仍会产生影响。例如， StackOverflow最初是用C#编写的。 13年后，它仍然是用C#编写的，但它曾经也是。偶尔有人建议我们用Node.js重写它。但直到现在也没有发生。