马斯洛的自动化需求层次理论

如果现在有什么比容器更热门的话，那很可能是基于容器的东西，比如无服务器。 它不仅是目前最“酷”的技术，而且还关注自动化和编排*对现代应用的重要性。

几乎每天都会为容器架构带来一些新组件，并随之带来适当级别的自动化。 如果在容器世界中某些东西可以实现自动化，它就会实现。 大量的 API 和对基于配置/基于模板的工件的依赖推动了基于容器的环境中自动化的近乎持续的演变。 如果说API经济对于企业的数字化转型很重要，那么其他API经济对于IT的数字化转型也至关重要。

容器环境也不例外，随着它们不断进入生产环境，上游（N-S）服务不仅能够在这些高度不稳定的环境中交付正在扩展和服务的应用程序，而且还能够在自动化和编排层与它们集成，这一点变得越来越重要。

这是因为这种技术“堆栈”中的某些层比其他层更不稳定。 例如，容器的创建和销毁比整个集群的创建和/或销毁要频繁得多。 事实上， Data Dog HQ 的 Docker 采用报告指出，“截至 2017 年 3 月，大约 40% 运行 Docker 的 Datadog 客户也在运行Kubernetes 、Mesos、 Amazon ECS 、Google Container Engine 或其他编排器。” 自动化/编排对于容器的成功至关重要，尤其是其核心。 这意味着，随着我们的前进，必须尽快（彻底）满足一些自动化需求，因为它们是一切的基础。 

对于云环境来说也是如此。 毕竟，推动自动化和编排需求的不仅仅是波动性，还有敏捷性。 与云计算相关的复杂“自助服务”模型要求自动化来支持效用计算模型中云计算的弹性、按需架构的概念。 云和容器都有一组可识别的共同自动化需求，这为理解其对业务的价值奠定了基础。

与马斯洛的需求层次理论非常相似，自动化需求层次理论建立在这样的前提之上：存在着“缺陷”需求，必须满足这些需求才能向上发展到能够实现增长的更高层次的需求。

必须先满足较低水平的赤字需求，然后才能继续满足更高水平的增长需求。 当缺陷需求得到满足时，它就会消失，我们的活动就会习惯性地转向满足下一组尚未满足的需求。 这些就成为我们的首要需求。 然而，增长需求仍旧存在，而且一旦投入使用，增长需求甚至可能变得更加强烈。 一旦这些成长需求得到合理满足，人们就能够达到称为自我实现的最高水平。—— https://www.simplypsychology.org/maslow.html

从本质上讲，这个特定的自动化需求层次结构重点关注扩展应用及其复合服务的基础需求。 正如最先提出这一概念的才华横溢的 F5 工程师所解释的那样： “底层的自动化最有价值，因为它发生得最多，而且对于应用保持在线至关重要。 顶部的自动化价值最低，因为它发生的频率较低（可能仅“一次”），并且发生的时间恰好是许多人已经在进行手动操作的时候。”

这些是自动创建/销毁容器/虚拟机和应用程序的“基本”需求，不仅对规模至关重要，而且对规模的功效也至关重要。 这种功效对于限制成本和减轻传统上（昂贵的）手动操作所带来的规模负担非常重要。 考虑到如今此类事件发生的数量和频率，自动化是一项要求，而不是可有可无。 这是一种缺陷需求，也就是说，如果它得不到满足，就没有理由担心更高阶的、不太频繁发生的自动化。 

对于容器来说尤其如此，Data Dog 再次证实了这一点，它指出“容器的平均寿命为 2.5 天，而在所有公司中，传统和基于云的虚拟机的平均寿命为 23 天”。 这似乎受到了自动化的影响。 “在使用编排器运行 Docker 的组织中，容器的典型生命周期不到一天。 在运行没有编排的 Docker 的组织中，容器的平均存在时间为 5.5 天。”

自动创建/销毁容器以及随后的应用程序的能力对于实现组织在传统和基于云的环境中获取容器优势所需的速度和规模灵活性至关重要。

更高阶的自动化需求基本上是路由需求，属于增长需求。 一旦基本需求（缺陷需求）得到满足，就会寻求增长需求。 集群创建/销毁和路由更改很少发生，并且只有在应用程序到位并能够扩展后才变得有价值。 一旦环境从开发/测试迁移到生产环境，这一点就变得至关重要，并且依赖于通过提供应用来实现商业价值。 毕竟，路由到无法响应的应用程序就像给饥饿的人一个拥抱。 温暖、舒适的感觉并不能满足对食物的基本需求。 Mesosphere 在 2016 年对其用户进行的一项调查发现，62% 的用户已经在生产环境中使用容器。 Portworx 在 2017 年以容器为重点的会议 DockerCon 上进行的一项调查发现，67.2% 的受访者在生产中使用容器。 这意味着路由需求很快变得重要，至少对于采用容器的组织子集而言是如此。

企业自我实现的最终目标——增长——只有当整个层级结构都得到满足时才能实现；也就是说，只有当整个“堆栈”实现自动化和协调时才能实现。 因此，应该假设那些主要位于 NS 数据平面上的人员将从下至上进行协调，首先满足环境的扩展需求，然后再满足路由需求，即从 NS 到 EW 流量的转换。 这也体现在围绕容器编排器本身的更紧密耦合的生态系统（如 Kubernetes）的持续发展中。 最近的一项发展重点是“路由”需求，其中包括在第 7 层（URI / API）进行路由的入口控制器，以确保 NS 到 EW 服务的过渡无缝进行。 该组件最终也必须被集成（自动化）以满足路由需求，并继续推动组织在层次结构中向上发展以实现增长。 

将其转换为特定于容器的构造使我们能够将容器环境自动化需求映射到网络中支持其扩展需求以实现增长的服务。 容器和网络/应用服务构造都需要自动化。 创建一百个容器来扩展应用程序，但是却不同时自动化负责在交付过程中管理它们的服务，这将导致无法满足的需求。 这些网络结构可以作为本机容器结构存在，也可以作为适合本容器环境的现有应用服务存在。 实施细节将根据架构和运营要求而有所不同，但两组构造的存在对于满足实现成功的基本（规模）和增长（路由）需求都是必要的。 

在所有情况下，容器和云的成功在很大程度上依赖于它们的生态系统，这意味着依赖其他 API 经济来实现通过数字化转型计划实现对业务增长至关重要的自动化和编排。 

* 我发现令人沮丧的是，自动化和编排的概念似乎在容器世界中混淆了，并将它们并列在一起。 但是现在，我们先忽略这一点，我会尽量让这个学究保持其应有的地位。 在我的脑海里。 尖叫。 拼命地。