防止云厂商绑定是怎么做的？

[COW]

是不是应该写一个抽象层，IaC 里把各个云厂商 provider 接到抽象层下面，如果 AWS 不想用了，改一下 provider 类型，就随时能切换到其他云？

[yinmin]

只用云服务器，所有服务都在云服务器上自建

[kapr1k0rn]

不要使用云厂商专有的产品

[opengps]

你这个想法，是建立在单机背景下的，单机用途其实本身就不需要什么云。
真正需要用云来发挥价值的都是集群用户，数量大客随时增减，组件多可以减少配置难度，这种客户下云非常困难，甚至为此都会主动去设计多云架构

[renmu]

想得很美好，实际每个云厂商提供的功能千奇百怪

[COW]

@renmu 所以在最小化使用云厂商功能的前提下，做一个抽象层，云厂商切换还是可以实现的吧，剩下的就是服务本身的迁移了

[Ketteiron]

多云架构，抽象与实现有很多种，多活/双活/热备/温备/冷备等。
双活/多活就是多个云上都准备好了服务，方便某个厂商拉跨时迅速撑起流量。
冷备份是以单个云作为主力，出现灾害时通过自动化流程临时去其他云买/租机器然后迁移服务。
热备/温备介于二者之间。
但想法是理想的，现实是。。。
99.999%服务并不会因提高可用性而提高实际可用性，反而引入了更多的复杂度。

[COW]

@Ketteiron 你提到的这个单云主力 + 冷备，出现灾害时通过自动化流程临时去其他云买/租机器然后迁移服务，跟我的想法是一致的。至于跨云多活，我就没想过，感觉是不可能完成的任务。

[Zarc9609]

我觉得企业在决策是不是上多云的主要问题是成本问题

[salmon5]

这个说说很动听，实际绝大部分公司，执行不好
云上的每一个产品，都搞一个抽象层，那开展业务就像带上了脚镣

[wanniwa]

我们公司就是的，我实现的跟你思路是一样的，都抽象出来，可以随时来回切换云厂商流量，我云函数和云主机都是这么实现的，支持云函数动态切流，云主机使用完动态关机……
领导今天要接个京东云明天要接个腾讯云，后天华为云又过来说更便宜，确实会来回换。

[julyclyde]

听起来很 java

[salmon5]

还有多云，说说简单；
就像房子，你会为了某 1 套房子偶尔停水 1 天，搞 2 套房子热备、冷备？那成本是巨大的
你说你有多套房子？那行，你有私人飞机？你会为了偶尔某 1 架私人飞机可能的故障维修，搞 2 架热备、冷备？
你有 2 架私人飞机？那行，你有 2 个地球吗？地球曾经发生过恐龙灭绝？你有能力再备 1 个地球？

[salmon5]

@salmon5 多云 多活、热备、冷备，成本至少增加 50%、甚至 100%，还不算人力成本，故障概率也会增加
很多决策者往往会忽略、无视这些因素

[salmon5]

A 供应商对象存储 10 万 QPS 、100Gbps 带宽、DB 10 万 QPS
抽象层 怎么保证：
B 供应商对象存储 10 万 QPS 、100Gbps 带宽、DB 10 万 QPS ，业务基本上无感知？

[zhengfan2016]

你是否想寻找 docker 和 docker-compose ？

[salmon5]

这个抽象层有点像皮包公司（ 2-3 个员工）（ 2-3 QPS 的业务），随时可以换办公室；
如果是很大的业务量呢？（ 20000-30000 个员工）（ 20000-30000 QPS 的业务），随时可以换办公室？公司停业 30 天？

[salmon5]

所以这个抽象层，终究是个鸡肋，很难通用，小业务玩玩可以

[COW]

@salmon5 我没说搞跨云多活，看我前面的回复，我只是针对 IaC 这一层实现，目的是云厂商之间快速迁移

[salmon5]

@COW 没这么简单，还涉及到有状态的数据同步

[salmon5]

比如 OSS 和 S3 ，如果担心 S3 炸了，但是 S3 又有 N PB ，甚至 EB 级别的数据？怎么快速迁移呢？这部分往往是最难的