我们项目的新基础架构（AWS，GCP）

Question

我上个月开始在一家新公司工作。我将负责SAAS的基础架构和后端。

我们目前每个客户只有一个小滴/实例。在公司当前阶段，这是一个不错的选择。但是在将来实例数量增加时，将很难维护它。目前有150个实例联机，每个实例具有1个CPU和1GB内存。

我们的客户仅在一周，一个月或一年的时间内使用环境。所以大多数时候，他们什么都不做。所以我们要改变它。我在想Kubernetes，Docker Swarm或其他工具。

您能给我们什么建议？我们应该迈入Kubernetes还是Docker Swarm，还是在DigitalOcean，AWS或GCP停留在Droplet / VM上？

如果我们改用AWS或GCP，我们的平均价格将从每平方米5美元上涨至每平方米10美元以上。

我们希望采取下一步措施，以减少资源浪费，同时还要考虑每月的账单。在我看来，最好让我们的3个较大的VM中有2个运行Kubernetes或Docker Swarm，以降低每月账单并减少我们的预留资源。

你怎么看？

Answer 1

如果您认真考虑扩展，那么应该重新考虑您的应用程序体系结构。计算最昂贵的部分是内存（RAM），因此每个客户拥有专用内存将无法扩展。

您不应将此逻辑上的分隔移至数据层，而应使用小滴使客户分隔开。因此，每个客户都可以使用相同的水平扩展计算服务器和数据库，但是该软件会根据数据库中的用户标识符将其数据和访问分开。

想一想... Gmail是否为每个特定客户保留RAM？不，每个人都使用相同的计算和数据库，但是该软件将其消息与其他用户分开。这使他们可以扩展到大量客户，而无需分配每个客户资源。

这是另外两个例子...

Atlassian曾经拥有您所拥有的。每个JIRA Cloud客户将被分配给他们自己的虚拟机，该虚拟机具有CPU，RAM和数据库。他们不得不将数据中心扩展到疯狂的规模，而且价格昂贵！

然后，他们开始了迈向多租户的旅程，首先是将数据库与每个客户分开（并使用公共数据库池），然后转向共享微服务，最后他们删除了每个客户的所有资源。

看到：

Salesforce从一开始就选择了多租户。他们定义了SaaS的概念，并自称为“云”（在我们现在知道的云计算之前）。尽管他们的系统分片以允许扩展，但多个客户在一个分片内共享相同的资源。客户数据的分离是在数据库级别完成的。

看到：

底线：当然，您可以尝试使用容器对当前体系结构进行优化，但是如果您想认真考虑规模问题（我说的是10倍或100倍），则需要重新考虑该体系结构。