利益相关:我们团队从2016年开始使用腾讯云,是腾讯云的公有云业务的第一批用户。
背景
我们使用的云资源相比于我们现在的业务和团队规模是非常大的。由于整个技术体系高度云原生化,目前我们在活跃使用的产品线(产品线下有不同产品)超过20个,云资源规模大约有一个中型企业的规模。大部分资源都是按量计费和弹性扩缩容,随着集中上线和业务规模增长,费用也会很快增加。维护这个体系的核心团队只有四五个人。
我们云的主要用途之一是支持我们的在线编程学习平台量潮课堂,截止文章发布时处于技术预览版状态,很多特性因为很多主客观原因无法上线,其中主要是背后的云不太可靠导致的。由于我们自己非常熟悉腾讯云的全线产品,就在我们自己的云计算教程和DevOps教程里使用了腾讯云和Coding作为教学对象。
主题
我们的观点是,今年腾讯云产品涨价和渠道政策收紧,配不上他们糟糕的产品和服务质量,所以我们要为和我们一样被腾讯云坑惨的朋友们争取应有的权益。
关于涨价
今年中旬,腾讯云各个产品线推送了一大批短信和站内信告知定价调整和免费额度调整。免费额度从原来的在研发阶段基本不需要额外购买,到现在稍微用量大一些就会超出额度。比如,日志服务CLS取消了免费额度,而云函数SCF的日志依赖日志服务不可更换,就产生了额外的费用,而且是用量规模越大费用越高。AI类的服务,初步影响是从免费额度几十万变成了几万的水平。
最让整个社区的开发者恶心的是云开发和云函数收最低使用费用。云开发是每个月20元;云函数更离谱,每个地域一个月收10块钱(这种收费方式真的,匪夷所思)。在这个政策出来的时候,我看到了各个平台(包括知乎、头条、小红书、微博、微信)都在抱怨这条政策,并且把自己的业务迁移了出来。我和他们私信或群聊沟通一下,都表示产品质量比较一般,只是看价格不高且比较方便才用的。
我们这里由于用的云的种类很多,所以虽然只看一个产品线的涨价不高,但整体加起来就很多了。而涨价并没有带来产品和服务质量的提高。相反地,由于频繁的内部架构调整,我们原本好不容易建立起来的合作关系都被一个一个破坏了,新对接我们的人一个一个都越来越敷衍。并且,我们反复提了三四次的问题,数量很多,很多都没有下文,特别是对我们特别重视的文档提出的纠错,几乎全都是石沉大海。
互相摆烂,是云厂商和开发者们双输的结局。我们天天被坑;我们的研发效率低和成本高、业务规模起不来,云厂商自然也挣不到钱。这个道理我们以为是一个行业共识,但大部分云计算的从业者似乎并没有意识到这一点,他们只想着怎么从我们这里坑更多的钱。很早以前我就明确地很多产品线说过,我们可以接受你们定价,但你们得拿出过硬的产品和服务质量支撑。但你们没有。
关于产品质量
我们最头疼的问题是文档和产品不一致,导致我们浪费了大量不必要的时间在熟悉用法上。
我们在20年刚开始云原生改造的时候开始大量扩展用云。以我当时的学习能力,大概需要一个星期才能摸透产品怎么用,然后才能初步判断能不能用、如果用需要付出多少额外的改造成本。这个周期经过了我们的同行的验证,大部分团队都是这个情况,并且普遍抱怨文档根本看不懂。即使是熟悉了,还是经常需要抄配置文件一类的文档。但离谱的是,配置项居然是错的,我扒了源码才发现问题。
随便截个日常沟通的图。
文档里是serviceName和serviceId:
而我扒到的源码的位置是name和id:
这么基础的问题,为什么这么多用户在用,都一直没有维护?
类似的导致文档几乎不可用的问题,每个产品的文档我们都可以找出十几个以上。
后来我们总结了两条经验:
- 腾讯云的大部分产品都是照抄AWS然后说自己自研的,所以看AWS的文档基本就可以知道腾讯云的文档怎么抄过来的。只要英文水平过关,看AWS的理解以后,再根据腾讯云文档里提供的信息推测,基本上可以猜个八九不离十。如果英文不好,就去看阿里云的,也是理解以后回头看。
- 没有产品团队直接对接的产品不能用,因为出了问题找不到人问,还不如自研来的快。
关于商业模式
价格高和易用性差影响了新用户激活和留存意愿(AARRR模型定义的激活和留存),不仅影响云厂商的收入,也影响我们课程的技术选型。我们可不敢给客户推荐使用规模相对阿里云和华为云较小、并且价格还涨了起来以后相比于阿里云和华为云高、并且还比阿里云和华为云难用、并且还不如华为云的技术支持的产品的。
原本我们计划主要以腾讯云为主展开教学。现在我们需要慎重地考虑把我们的教程换成阿里云和华为云了,我们不能教用户他们不打算用的云。
我们有一些给客户做的大数据项目,这部分实际上在我们的云计算成本结构里是比例最大的(最高可以到60-70%,主要是TB级规模的存储),我们的主要业务系统为这些项目提供系统的方案。这部分只要有云厂商提供可靠的云原生Serverless成套方案,我们就会考虑先迁移这部分到其他云厂商。**欢迎华为云和阿里云的同学和我们接洽联系,我们很愿意了解你们的容器和函数计算相关的解决方案。**如果我们使用体验良好,我们会把我们的课程也换成对应的云服务。
也欢迎腾讯云的同学和我们谈。如果我们为腾讯云填坑付出的成本可以得到补偿,我们不仅可以考虑继续使用腾讯云,也可以考虑进一步加入腾讯云生态的建设。我们手上有很多经过我们优化和项目验证的云SDK即将进入Alpha阶段。下面是一个简单的列表。
腾讯云:
- Python:github.com/quanttide/q…
- Django:quanttide.coding.net/public/qtop…
- CLI:github.com/quanttide/q…
腾讯云对象存储:
- Flutter:github.com/quanttide/f…
Coding:
- Python: github.com/quanttide/c…
- Django: github.com/quanttide/d…
微信(包括登录、支付、云开发、云托管、公众号、小程序):
- Python:github.com/quanttide/w…
- Django:github.com/quanttide/d…
微信云托管:
- Flutter:github.com/quanttide/f…
企业微信:
- Python:github.com/quanttide/w…
- Django:quanttide.coding.net/public/qtop…
最佳实践(大部分内部文档尚未开源):
- Serverless:github.com/quanttide/q…
- 云计算:github.com/quanttide/q…
请腾讯云的同学看看我们给你们已经填了多少坑。如果你们让我们彻底失望,这些我们就会当做沉没成本整体放弃掉。
当然,如果我们转投华为云或者阿里云,上述的轮子只需要简单地替换协议即可使用。以我们的效率,封装基础协议只需要一下午的工期即可完成从开发到正式发布到PyPI或者pub.dev,改造API也只需要做一些边际成本不高的适配。厂商中立是我们所有项目设计方案的出发点,我们早在进行云原生改造的时候已经对现在的局面有所预期。也就是说,如果我们转投某家,你们除了会获得一个用量比较大、使用覆盖面广、乐意反馈和协助改进的优质客户,同时还可以获得一个不错的生态共建者。
言尽于此。接下来我们会在全平台集中批评各个产品线长久以来积压的各种问题,直到我们的诉求得到妥善的解决。作为整个行业最早上云、最早上云原生的一批团队,我们当然有能力评判你们的产品水平,我们相信我们对产品专业层面的判断、深入浅出的讲解能力、渠道宣发能力,可以影响很大一批潜在云用户的厂商选择和技术选型。不知道你们的高层看到有个资深客户一个小团队手撕几十个云产品会作何感想。
出于维护我们的核心商业利益,我们不接受任何带着人情的说客。你们不尊重我们为你们的产品做出的贡献,我们自然也不会给你们好脸色看。我们只是想要回应该属于我们的。