云不可知架构是一个神话

供应商锁定-通过使用特定于该云提供商的服务锁定到特定云提供商

在过去的两年中，我一直在云中工作，并且有一点可以肯定–至少在传统意义上，不可知云的架构是一个神话 。

在本文中，我将讨论云服务的当前状态，以及如何真正做到云不可知不仅是我们无法完全实现的，而且为什么它不一定是您可能想要实现的。

Docker化您的应用程序

我们的第一站是Docker。 我是诸如Docker之类的容器化技术的忠实拥护者，最近发表了一些演讲，展示了这些技术如何极大地改善我们构建和部署软件的方式。

我想强调的Docker的主要优势之一是，它能够减少从一个云服务提供商迁移到另一家云服务提供商时的摩擦。 您可以在运行时，环境变量和任何安装脚本方面指定应用程序需要运行的所有内容，并且几乎可以在任何地方启动所述容器。 我说*几乎*是因为有一些非常小的例外，例如仅Windows图像等。

从本质上讲，这意味着我们需要运行的Python应用程序可以被容器化，并放入任何托管容器服务（例如ECS）中。 然后，底层的容器平台将管理容器的生命周期，并提供其他好处，例如我们希望的日志记录和监视。

然后，符合OCI的基础容器运行时将处理主机之间的所有差异，并按您希望其运行的要求而以最小的麻烦运行您的应用程序。

在避免供应商锁定方面，集装箱化是一个难以置信的低谷成果。

地形的成长

Terraform是我旅行中最喜欢玩的最新“有趣的东西”，我非常喜欢CLI，以及它如何使您将基础架构定义为代码。

您可以指定要使用的提供程序以及访问**和秘***，并且当您运行terraform apply ，CLI将消失并启动适当的基础结构，然后在您之上进行部署：

如果随后需要拆除基础架构，则可以轻松使用terraform destroy命令，该命令听起来简直太棒了。

如果您正在寻找有关Terraform的良好参考手册，那么我强烈推荐Yevgeniy的书：

现在，这非常适合在特定的云提供商上扩展系统所需的基础架构，但这意味着我们将不得不为每个不同的云提供商编写多个Terraform脚本。

这并不是完全不可能的，但是我们接下来必须以某种方式维护这些脚本，以便在我们需要故障转移到给定提供程序时可以确保它们的正确性。 还需要对底层平台有一定程度的了解，以便明确了解正在旋转的实例类型或这些实例的大小。

从应用程序开发人员的角度来看，您可能不必一定要或不关心您要从中创建t2.micro实例的AMI，您可能只是在乎开发应用程序并拥有一个稳定的运行环境。应用程序，以便可以为您的付费客户提供服务。

服务之间的细微差别

我已经看到的对此的潜在解决方案之一是在所有云服务提供商之上实现抽象层，并从本质上将应用程序的基础架构定义为一系列块。 本质上，这是Terraform之上的扩展，可以扩展与云平台无关的基础架构。

然后，这个Terraform风格的抽象层将与它选择的任何云平台进行接口，并扩展所述基础架构。 这样一来，您可以将一个简单的Web应用定义为1x“ Load Balancer”和2x“ Small Server”。

在某些人看来，这似乎是显而易见的解决方案，但是当要实现此抽象层并处理不同服务公开方式之间的细微差别时，这几乎是不可能的。

试图在应用程序级别上解决这个问题几乎是不可能的，并且您的代码库将充满成百上千个（如果不是成千上万个）条件标志，以覆盖大量服务。 我们可以将其抽象为服务代理或SDK吗？ 也许可以，但这只是将我们最初的问题向左移。

Kubernetes

因此，Kubernetes令人难以置信，我在这里讨论了它对企业环境的一些潜在好处：

当涉及到不可知论时，Kubernetes结合Docker和Terraform可能实际上是一个很好的答案。 许多不同的公司和个人也已经对此进行了探索，我们开始看到诸如Triton之类的托管解决方案。

然后，可以将这些联合的kube-clusters（klusters？）视为一堆计算量，然后可以运行和管理您可能希望运行的任何基于容器的应用程序。

这样做的最大好处是，应用程序开发人员只需担心他们希望其应用程序如何外观并提取基础架构。

但这还不是完美的，这些服务还很年轻，还没有成为主流。 这些服务变得足够成熟以至于可以被大型企业采用，这将有一段时间。

托管服务的价值

供应商锁定—利用云提供商的特定服务为客户提供价值的艺术

我看到人们在谈论供应商锁定时无视的最大事情之一就是事实，利用这些托管服务为自己谋取利益具有巨大优势。

在考虑使用这些托管服务时，开发团队需要权衡这些服务提供多少优势，并考虑通过将自己锁定在所述服务中而随后带来的劣势。

如果来自AWS，Azure或GCP的服务X可以为您提供超越竞争对手的巨大优势，那么由于供应商锁定，避免使用该服务肯定没有任何意义。 如果有的话，通过积极利用这些服务，您可能会发现自己可以更快地采用新的想法进行迭代，并突破了我们目前的能力范围。

如果考虑到AWS的RDS之类的东西，如果我们试图在EC2实例上托管我们自己的数据库实例并自己进行管理，那么我们最终将花费数百小时来尝试达到与弹性或性能相同的水平。现成的RDS产品提供。

本文将对自托管与RDS进行更详细的比较：

结论

虽然供应商锁定的东西设计和开发应用程序时，你应该有所考虑，我会放得多的股票在使用所述管理服务的优势，只要你充分理解它的约束。 从长远来看，牢记您严重依赖这些服务这一事实很有价值，如果您以适当的方式利用这些服务，则可以给您带来优势。

但是，就目前情况而言，不可能完全不了解云提供商。 为了提供上述提供者之上的抽象级别，还需要做更多的工作，这时，它只是乌龟。

希望您喜欢这些杂乱无章的事情，如果您不同意或想补充一下，请随时在下面的评论部分中告诉我！

如果您想支持我，请随时在Twitter上关注我：@Elliot_f或订阅我的YouTube频道！

注意：我的好朋友艾伦·里德 （ Alan Reid ）对这篇文章进行了同行评审，因此，如果发现任何错误，请@他！

From: https://hackernoon.com/cloud-agnostic-architecture-is-a-myth-53eac80be85d