关于数字化转型的惊人事实： 规模不经济
这是有关数字化转型带来的挑战的系列博客的第四篇。
规模不经济。
当你发展业务时，特别是随着时间的推移，你往往会积累一些需要处理的负担。 您很少会减少必须支持的应用数量。 通常，它会在几年内增加，有时甚至呈指数增长。 在平常时期，应用每四年就会翻一番。 当一项新技术强行闯入时，这个数字就会增加。
每个应用程序都需要更多的操作支持（对于初学者来说，也就是网络、计算、存储和安全）。 但正如我们知道垂直规模只能带你走这么远（你只能投入这么多硬件来解决问题），我们知道人力资源也是如此。 我们不能仅仅通过增加操作来适应应用程序的增长。 这样做会增加管理费用（开销），减慢沟通速度，因为我们很难弄清楚谁负责什么，更不用说真正与那个人交谈了。
这就是部署递减规律向我们展示的。 到了一定时候，操作的数量实际上会阻碍部署，并且我们会看到权衡的开始。 就像浮士德与魔鬼讨价还价一样，我们选择速度而不是安全，选择规模而不是稳定。 最终，我们到达了一个转折点，到达了理论的极限，开发、运营和企业开始在其他地方寻找解决方案。
简而言之，在违反部署递减定律之前，你只能雇佣这么多的操作员来处理不断增长的应用程序数量。
这就是为什么自动化对于运营至关重要，以跟上应用的增长和更快部署的需求。 因为无论你打字有多快，计算速度都更快。
但请记住，自动化不仅仅是脚本。
我们已经完成了大量脚本编写，这无疑是让我们至少在部署竞争中保持领先地位的一个因素。 为了使自动化真正成功，它不应该在每个设备或应用的基础上执行。 这不应该。 这不具有可扩展性。 如果您为每个设备或应用程序编写一个脚本，那么您的自动化程度就不够高。
自动化需要关注过程（因此它实际上是一种编排，但这是一个我一直在努力但始终不肯倒下的风车）以及一致的执行。 这意味着您需要采用自动化 - 而不仅仅是脚本更改。 这意味着一种新方法，它融合了 DevOps 的原则，例如基础设施即代码。
基础设施即代码
基础设施即代码是一个比喻。 这意味着实际的基础设施可能是软件、硬件、云或内部部署。 该实现与部署目的无关，因为我们将使用 API 和部署工件来实现基础设施即代码的行为。 通过将配置与设备分离，我们可以将设备视为一个黑盒子。
重要的是部署工件——用于为所需服务配置设备的模板、脚本和策略。 它们都存储在存储库（ON-PREMISES）中。 这些完整描述了给定的服务 - 无论是网络、安全、存储还是应用程序基础设施 - 并且可以用于随意重新创建服务。 这些工件可用于自动执行各个任务 - 添加防火墙规则、部署负载均衡器、配置 WAF - 然后组合成一个协调的流程以实现持续部署。
这对于解决规模不经济问题非常重要，因为纯脚本编写仍然是每个设备的任务。 有了脚本，五分钟的琐事就可以变成五秒钟的任务。 但它仍然是手动调用的，并且需要人们来推动这一过程。 它没有解决整个过程自动化的更大需求——而这正是在数字经济中竞争所需的规模经济所需要的。
请继续关注本系列的最后一篇文章，我们将在其中深入探讨如何安全地交付在容器化环境中部署的越来越多的应用程序。