【ArchSummit】如何通过AIOps推动可量化的业务价值增长和效率提升?>>> 了解详情
写点什么

上云还是下云,最大挑战是什么?| 对话章文嵩、毕玄、王小瑞

作者:AutoMQ

  • 2024-01-18
    北京
  • 本文字数:8607 字

    阅读完需:约 28 分钟

上云还是下云,最大挑战是什么?| 对话章文嵩、毕玄、王小瑞

近半年来,公有云领域频频发生阿里云、滴滴等平台崩溃事件,与此同时,马斯克的“X 下云省钱”言论引起了广泛关注,一时间,“上云”和“下云”成为热议话题。


在最近举办的 AutoMQ 云原生创新论坛上,AutoMQ 联合创始人兼 CEO 王小瑞作为圆桌主持人,与 AutoMQ 联合创始人兼 CSO 章文嵩、贝联珠贯创始人兼 CEO 林昊(毕玄)两位技术大咖,围绕上云与下云的趋势之争,以及面临的挑战展开思想碰撞。


Q1:云厂商的营收一路飙升,但同时又听到各种下云的案例,比如推特下云节省了 60% 的成本,未来趋势是什么?


章文嵩:我觉得上云肯定是大势所趋。因为云是给客户创造价值的,就云计算的本质来说是资源的聚合与复用,通过超卖的方式实现成本的降低,从而帮助客户实现成本节省,同时也为云厂商创造盈利机会。以一个简单的例子来说明,原本 A 用户和 B 用户分别在白天和晚上使用机器,每个时段都需要花费一个单位的成本。然而,云厂商的出现让 A 和 B 都不再需要购买机器,而是通过租赁的方式,付给云厂商较低的费用如 0.6,使得云厂商的收入 1.2 超过了 1 个单位的成本,实现了盈利,客户也省钱了。通过错峰使用,A 用户和 B 用户仍然可能没有消耗掉全部的计算资源,云厂商有机会还能将未使用的资源卖给其他用户,实现了资源的高效复用。另外还有研发资源的复用,随着系统规模的增大,边际成本降低,云计算成为一个能够持续创造价值的解决方案


比如美国的一份报告说明,在所有的 IT 支出里面,2022 年美国云计算的渗透率将近 10%,而 Gartner 预测到 2026 年,这一比例将上升至 20%。在中国,尽管 SaaS 行业发展尚未成熟,但 IaaS 和 PaaS 模式已经在云厂商中得到广泛应用。以阿里云为例,过去两年一直保持盈利,阿里云所有云资源的收入加在一块,大概是一年 1000 亿左右,阿里云市场份额占比 30%-40%,整个中国云市场的规模约为 3000 亿。通过工信部公布的中国整体 IT 行业的收入 10 万亿,可以得知中国云市场渗透率大概 3% 。


当然中国未来 SaaS 空间会很大,所以美国如果四五年后达到 20% 的云渗透率,那中国有可能到 10% 以上的渗透率,未来 50% 甚至 70% 以上的渗透率,所以我觉得上云是大势所趋。


毕玄:创业后,我接触到了更真实的情况。以前代表阿里云拜访客户时,客户因我可能促使他们购买更多阿里云产品而避免说实话。现在作为中立方,客户更愿意分享真实想法。从整体趋势上来看,我坚信云计算有巨大增长空间。尽管中国云市场增速下降,甚至阿里云是比前两年有下滑,但这有很多综合原因,总体上我觉得云肯定还会继续增长。


许多公司衡量云成本的方法很简单,即比较线下机器支出和搬到云上的费用。但考虑到人工成本,难以简单对比。大公司即使迁移到云上,人工成本仍然存在,因基础设施管理人员短期内难裁员。我之前跟某互联网头部公司的人聊到底是要往云上搬,还是继续保持自建的话题,核心还是要搬到云上,充分发挥云的弹性,而不是静态使用


纯静态用对大公司来讲成本难以平衡。弹性使用云,尤其是按量计费,就像现在中国按量计费比包年包月其实单价贵很多。在折扣谈判中,按量付费和包年包月分开谈,通常包年包月方案能获得更低的折扣,因为按量收入不确定性较大。


另外一个问题是中国的按量错峰效应不够明显,云厂商对此不太热衷。尽管按量计费可能增加成本,但之前通过推演,我们发现在折扣谈判后,每天使用 8 小时左右能够实现成本打平。


一些大公司进行了假设推演,从线下切换到按量计费和完全弹性系统,能显著节省成本。然而,由于技术改造较多,很多公司不愿采用这种方式,但我认为这是技术的趋势,很多公司一定会越来越弹性。


对于大部分中小企业而言,云计算的灵活性比成本更为重要,因此它们更自然地采用云服务。从成本角度来看,随着技术的演进,整体用云的成本将逐渐降低,比自建更具优势。同时,云计算的应用不断增加也是因为壁垒的存在。在 AI 时代,大多数企业首选使用云而不是自建,因为自建的门槛较高,而云服务为业务快速创新提供了重要支持


章文嵩老师补充 : 云厂商的核心追求指标是超卖率,因为超卖率是能够真正提高整个业务的经营效率。如果客户愿意购买包年包月,但又因为在一年 365 天中,很多时间客户并不需要使用这些资源,实际上增加了云厂商的利润。关键在于客户要有弹性,根据需求变化使用云,以节省成本,而不是根据峰值去保留资源。


在上云方面,我这边是有个规模公式的,当基础设施规模较小时,在云上购买资源非常便宜;但随着基础设施规模的增大,成本上升的速率略有增加。自建的成本虽然一开始较高,但随着规模的增大,其斜率逐渐降低。两种模式的斜率不同,必然存在一个交叉点。在这个交叉点左侧,规模较小的情况下,使用云的成本较低,而自建的成本较高。然而,当规模超过一定阈值时,由于自建的起点较高但斜率较低,自建可能更加划算。云厂商针对交叉点右侧提供让利打折的机会,因为对于云厂商来说,已经投入的人力和各方面成本会随规模的进一步扩大而降低,使得边际成本更低。


回到 Twitter 事例,Twitter 原来有三个数据中心,波特兰、Sacramento 和亚特兰大,应该做了类似的三活。马斯克挑战团队在仅六天内把三个数据中心缩减为两个节点,结果在平安夜他与工程师们直接关闭了位于 Sacramento 的一个数据中心,通过货车把服务器拉到波特兰数据中心。现在应该是双活架构,波特兰数据中心的服务器就富裕出来,把云上的资源优化并迁移了一部分到波特兰数据中心中,这一举措实现了约 10 亿美元的巨额成本节约,但他更多的成本节约主要来自人力资源方面。将员工数量从 8000 人裁减至 2000 人,美国工程师平均年薪 30 万美元,裁员的工资节约了近 18 亿美元,所以在总体运营成本上取得了显著的 60% 节约。然而,有些文章直接写 Twitter 下云节省 60% 了云资源成本,媒体的这个表达不正确,也容易误导观众。


Q2:云计算巨头都曾发生过大规模故障,公有云不稳定?


章文嵩:作为曾在阿里云工作多年的前员工,我找相关同学了解到,故障的根本原因在于一个全局鉴权服务存在软件缺陷,导致正常鉴权请求被拒绝,而且没有很好的故障恢复预案。虽然有时候故障不可避免,但云厂商确实还有很多改进空间。


首先,像全局依赖的中心系统应该是多区域多活的。当一个区域发生故障时,不应该影响其他区域的服务,流量应该迅速转移到其他可用的区域。这种架构可以最大程度地减少单点故障带来的影响。另外,即便是软件缺陷,我们也需要有充分的预案。在多个区域同时因为软件缺陷而宕机时,我们应该能够快速将其重启并拉起,以缩短止损时间。另外,提前演练这些预案是至关重要的,当触发潜在的软件缺陷时,有了相应的预案,一旦出现问题,重启就能够快速恢复服务。而不是在事发现场去查找问题,浪费宝贵的时间。


另外,我认为云厂商也会因为这些不可靠的故障而承担一定代价的。通常,云厂商们都会按照一定的规则进行赔付,一般是不可用时长大概是 100 倍赔付规则,他们也会不断改进,避免再次陷入相同的故障。


我相信随着云技术的不断改进,云系统会变得越来越可靠。云厂商的技术能力和系统可靠性在各方面都远远高于自建系统。一般情况下,自建系统可能规模较小,故障发生时都不太引人注意,但云厂商由于有大量客户在上面使用,故障的影响就更加显著。然而,正是因为有这么多的客户在不断使用云服务,云系统会得到更多的锤炼,变得越来越可靠。而且一定会比自建的系统可靠性高非常多倍,这是毋庸置疑的。


毕玄:对于故障问题,我认为云厂商相对来说故障次数要比自建系统更少。但云厂商通常因为集中化的特性,一次故障的影响面较大。相比之下,自建系统的故障可能并不为人所知,实际上累积的故障次数比云厂商会更多。


总体而言,我认为用云是更好的选择。这实际上是一个自有团队的问题。许多公司还会选择使用云厂商 PaaS 的服务,因为很难找到具有专业技能的人才。在中国,从事基础设施技术的工程师数量相对较少,人才储备有限。这类人才通常待遇较高,我接触到的很多中小型客户群体,他们希望由专业公司提供服务,而不是自己搭建,因为自己搭建的话,一方面做不好,另一方面人才难以留住,这是一个非常现实的问题。


因此,我认为在这些方面,云厂商的壁垒会越来越高。至于稳定性这个话题,没人敢说永远不会发生故障的。实际上,所有云厂商都曾出过严重的故障,没有一家例外,只是影响的程度取决于客户规模的大小。有时候我们会看到,阿里云发生故障时,有人回应说另一家云更好,也有人回应说另一家云可能存在更多问题,只是你不知道而已。总的来说,我相信云厂商的人才密度会更好,因此我也认为使用云服务总体上会更安全、更稳定。



Q3:如何做云上的成本治理,最优路径是什么?


毕玄:从我接触的一些客户来看,许多企业在迁移到云平台后往往对云成本一无所知,尤其是大型集团公司。相较于繁琐的 IDC 流程,云的便利性导致一些公司对于机器的创建者和用途一无所知。因此,首次迁移到云上时,许多公司可能简单地将资源放上去,但缺乏对资源创建和用途的了解。这可能导致付费后公司在月底账单出来时才发现一些资源的存在,无法追溯。尽管这些费用必须支付给云厂商,但实时监控账单变化对成本管理至关重要。


另外,我们认为在云上有很多复杂的用法,而许多公司目前还无法很好地应对。例如,资源包是一种优化成本的方式,实际上,在采购资源包的情况下,可能比原来的折扣更便宜。资源包的本质是为你提前准备好一些资源,当然,这需要一些算法,但技术含量并不是很高。有些公司购买存储资源包,就像购买手机流量一样,预先准备了一定量的资源,而这个资源在购买后必须在下个月内使用,否则不能退款。但如果公司确信能够充分利用这些资源,那么这笔钱肯定比折扣更便宜。


我们知道对于很多公司来说,更省钱的方式是大量启用弹性化的机制,就像许多公司采用无服务器架构(Serverless)的方式一样。当然,这涉及许多新技术的投入,在一些公司中推动这一点可能并不那么容易。虽然这可以大幅降低成本,但要将其推广并真正应用到实践中是一项庞大的工程。相比之下,之前提到的改变采购策略、调整策略等相对来说更为简单,只需要进行一些调整即可。


此外,公司还需要了解成本结构。在过去,成本分析可能并不被认为是非常重要的事项,但我们最近与一些金融、汽车等行业的客户进行合作时发现,他们非常关心集团公司的资金花在哪些部门,这些部门的业务情况,比如与业务 ROI 是否对齐。我们提到 IBM 之前收购的一家公司,主要做是做成本分析和分摊,以及与业务挂钩。例如,如果一个业务的目标是每日活跃用户(DAU),它将查看 DAU 的增长情况以及当月的 IT 支出变化情况,如果没有达到预期,管理层将进行问责。因此,这种产品在国外非常受欢迎。


在中国,企业逐渐关注业务状态,对 ROI 等因素越发在意。对于 IT 结构,我将其分为业务系统、大数据和人工智能(AI)三类。业务系统的优化方案往往与业务方的具体情况紧密相关,涉及较大的实施代价。而大数据和 AI 在降成本方面展现出通用方案的可能性,这也是我们公司(贝联珠贯)主要专注的领域。在大数据方面,我们公司产品能帮客户降低 30%-40% 成本,AI 方面虽然目前降成本效果有限,但通用方案已实现 10% 的成本降低。


总体而言,大部分公司目前最大的 IT 投入是业务系统,而大数据和 AI 投入较大的主要是头部公司。尽管大数据和 AI 很热门,但在 IT 支出上占据更高比例还需要时间。因此,我认为业务系统优化应根据实际情况进行。


章文嵩:我有一个想法,除了明确成本,更重要的是将其与公司业务深度结合。以淘宝为例,作为一个买卖交易平台,其核心是交易。我们是否能算出每一笔交易的 IT 支出?比如通过计算一个月内的所有 IT 支出以及完成的订单数量,我们可以得知每一笔交易的成本。


对于滴滴这样的出行平台,同样适用。它是一个撮合交易的平台,供需匹配也是其中的一环。我们可以计算每一笔交易的平均成本是多少钱。对于视频网站,观众每分钟观看视频,我们花费了多少钱呢?这实际上是可以提炼出来的,将其与业务深度结合,老板们更容易理解。


比如,淘宝的客单价是多少?假设是 200 多块钱。而我们只花了几分钱的 IT 成本。其中的成本结构是什么样的?是谁支付的?过去与现在相比,哪些地方可以不断优化,持续降低运营成本?另一方面,例如从单活变为双活,这是增加的新投资,所有这些都需要清晰阐述。实际上,将成本结构与业务深度结合,不仅有助于运营优化,而且对于公司的客户沟通也非常有帮助。我在淘宝和滴滴的经验告诉我,通过将账单与核心业务本质结合,管理者能够清晰地理解 IT 成本和业务的关系。这确实是一种非常有效的方法。


Q4:如何确保系统的最终成本与业务保持一致?


章文嵩弹性是最关键的,系统能不能有随着业务需求进行弹性的能力?因为任何一家公司的业务需求都不是全天候平稳的,会有早晚高峰,甚至午休时的购物高峰。因此,如果我们按照需求曲线的最高点来分配资源,显然是不划算的,因为我们会为闲置的资源花费大量的资金。最理想的情况是,根据需求曲线的波动,我们的花费能够完全匹配需求曲线下的面积。


实际上,这需要弹性,而弹性的能力并非易事,需要有一些共性的组件。如果每家公司都自己做弹性,涉及研发的方方面面,需要大量投入。然而,不同的企业,比如 A 企业和 B 企业,在弹性方面需要的一些公共组件是相似的。如果有一家企业已经实现了这些组件,那么 A 企业和 B 企业可以复用,这提高了效率。同时,做这些组件复用的企业也能够获利,因为它可以服务多家客户。每家公司实际上只需在某些模块上进行弹性改造,而不必对所有东西都进行改造。比如,像我们 AutoMQ 云原生的 Kafka,它在第一天就天然具备弹性,能够随着业务规模或云数仓自动伸缩,这样的组件是非常好的云原生创业机会。


在云上部署时,为了获得弹性,我们要尽可能地复用一些标准组件,这对研发方面的投入是最低的,效率是最高的。当然,像之前提到的 Spot 实例,由于它们的特点是云厂商的库存资源,价格较低,但这样的 Spot 实例是随时可能被回收的。因此,如果应用程序能够适应,可能采用无状态的 Serverless 架构是一个解决方案,即使被回收了也没关系,其他地方可以接管过来。这实际上对应用程序提出了更高的要求,但在一些情况下,利用 Spot 实例这样的资源是可行的。


毕玄:以前我在阿里带中间件团队的时候,我们一直在找降低成本的方向。给管理层汇报对于我们来说是一个很重要的任务,因为要说服管理层进行技术投入是非常重要的。从 2017 年左右,成本就成为我们的核心议题。就像正明(章文嵩)刚刚提到的,高层看待成本的指标就是——阿里的 1000 笔交易成本,也就是每完成 1000 笔交易,今年花了多少钱,明年花多少钱,后年花多少钱,他们只会问你这个问题。至于成本背后的含义,你可以有很多种理由,比如解释成本高的原因是我前面有一群人,交易效率不行,他们要更多的精细化运营等等,所以导致我要投更多机器。老板不会关心这些东西,他只关心你到底怎么给我降下去,方案是什么?所以过去我们在这方面每年都受到很大的挑战,这种偏业务型的指标确实挺好。


此外,现在实施成本控制的方案,我认为在云上,弹性一定是永远的第一方案。因为你要回答高层的另一个问题,成本到底做到什么叫合理?如果你解释不清楚这个问题,那这个成本就永远都可以降,对老板来讲你觉得投 10 亿合理,老板说 10 亿太多,投 1 亿,这个是要有逻辑的,你需要向老板证明,如果我们每天的业务请求量是这样的,我所需的成本就是这个请求量覆盖的面积,这笔钱是必须花的。


以前我们做中间件,这就是成本优化能做到的极致。这个极致从现在的技术表现上来看就是 Serverless,只不过 Serverless 现在要做到偏在线型的应用,全部 Serverless 化还是有相当大距离的。


我们在阿里曾经推演过,如果我们只为面积付费,我们单笔交易成本应该能降到现在的 1/10。所以按照这个你推演了一个极致,老板每年就对你都不满意了,因为老板按照我们的逻辑推演后认为,成本应该降到现在的 1/10 才是合理的。我们明白技术上存在各种问题,所以现在 Serverless 肯定是大趋势。然而,观察当前的 Serverless,主要由云厂商和中立厂商提供,为大家设计了通用的 Serverless 方案。在这个 Serverless 的背后,可能是采用了按量付费的机器,很多创业公司和国外的成本优化公司采用类似的逻辑,先将应用投放到 Spot Instance 上运行,然后不够了再切换到按量付费,最后才考虑包年包月。这三层逻辑关系在国外为什么能够实现折扣券的存在呢?我们认为是因为国外许多应用的整体 IT 水平相对更高,业务的无状态能力更强,更容易进行迁移。在大数据和人工智能领域,许多公司背后都是通过大量使用这种逻辑来实现的,实际上,他们屏蔽了这一切,不需要你知道 Spot、按量、包年包月的背后逻辑,他们将这些逻辑完全封闭,卖给你时你觉得价格更便宜,但实际上他们仍然具有竞争优势。


在这三层逻辑基础上,我们觉得是还可以加另外一个逻辑的,另外一个逻辑就是我们以前在阿里做的混部。在很多公司推行这个方案时,我们采用了类似国外公司的弹性策略,先 Spot,再按量,再包年包月。我们的逻辑是先混部,再 Spot,再按量,最后是包年包月。这是因为混部相当于价格是 0,而 Spot 实例是需要支付费用的。另外,Spot 实例的回收可能会导致问题,因为云厂商可能会多次回收实例。我们曾有客户经历被回收了 10 次,而其任务需要连续两个小时完成,无法中断。并非所有任务都支持断点功能,因此它如果两个小时之内被收回掉了,再购买一个 Spot Instance,在重来了 10 次以后它那个价格比按量和包年包月还高,所以这个时候你要处理很多乱七八糟的问题,包括跟云厂商,甚至有商务谈判等等,这种都不一定是技术问题。


所以我们认为,实际上在技术层面,如果你按照这个方案推进,选择一个第三方或者具有研发投入能力的公司,我们觉得也可以自己投资。我们与一家大型公司合作,按照这个逻辑进行四层弹性方案,就像我刚刚说的混部 -Spot- 按量 - 包年包月,他们实施了这个方案,一年应该省下近 3000 万,按照这个方案推进,当然这可能需要一些业务投入。


Q5:对既有自建机房又使用云资源的大型互联网公司(小红书、快手)的建议?自建机房需要哪些组织能力和团队建设能力?


章文嵩:自建的基础设施服务需要相应的研发投入。之前提到的自建和云服务的成本的交叉点,云厂商可以通过让利来提高吸引力。比如以一个拥有 5 万台服务器的互联网服务为例,考虑到硬件、托管和网络带宽资源等成本,每台机器年均花费约 2 万元,总计约 10 亿元。然而,自建还需要额外投入构建分布式系统、操作系统和数据库等,以及维护一个六七百人的研发团队,人员成本高达 5 亿。


对比阿里云的规模,其年收入约 1000 亿元,阿里云应该是 2 万人,人员的成本估计要花掉 200 多亿,机器成本约占据 6、700 亿元,毛利约 300 亿元。如果扣除市场营销、人工成本费用,这个业务还是赚钱的,赚的不多,200 多亿人员成本对应一年六七百亿基础设施支出,阿里云是很有规模优势的,还有产品服务丰富度的优势。


对于规模较大的互联网企业,比如 5 万台、 10 万台机器,云厂商应对于这种体量的互联网用户,应该用这样的策略,了解他的成本结构,给他一个无法拒绝的 Offer。比如云厂商知道企业自建的成本结果是 15 亿,给企业 12 亿元的价格。这样对云厂商来说,规模采购会有一些成本的节约。此外,对于人员成本,如果云厂商能够保持较低的增长,尤其是在已有研发基地的情况下,也可以在整体利润中获得优势。


所以,自建的成本很高且对社会无益,因为云厂商已经做得比自建要好。除非你的体量能达到百万台的机器规模,那就自建。


毕玄:正如正明(章文嵩)所指出的,自建成本是许多公司在构建基础设施时面临的重大挑战。小红书等公司目前仍主要依赖云服务,这仅是考虑中的一种方案。相比之下,快手采用了大量自建,而云厂商若能真正影响中国头部互联网公司,其增长将是显著的,因为头部公司基本上都未完全迁移到云上。


即便是头部互联网公司,如快手、美团、滴滴,虽然主要是自建基础设施,但也在一定程度上使用云服务。然而,这几家公司已经是中国顶级的互联网公司了,但自建团队仍然是一个复杂的问题,需要体系化的团队,而不仅仅是雇佣一两个人,还有 IDC 选址、服务器、网络、芯片等多方面的人才需求等问题。


自建机房遇到的第一个问题是招不到人,即便明确知道需要招聘哪些人才,但实际面临的招聘难度非常大。以操作系统为例,拥有这方面经验的人才相对稀缺,而且他们多分布在大型科技公司中。招聘这些人不仅难度大,而且在大型科技公司中跳槽也相对困难。这些公司规模庞大,面临的问题多,因此有更大的发展空间。


总体而言,这些公司虽然有足够的财力和意愿进行自建,但实际的执行过程非常痛苦。这凸显了人才密度是一个关键问题,不仅在中国,在国外也是一个有限的资源。


结束语


圆桌对话环节在意犹未尽中画上圆满的句号,三位大咖对话涵盖了上云趋势、系统可靠性、成本治理以及下云挑战等关键议题。为业界提供了深刻的见解和实践经验。


由章文嵩与王小瑞老师创立的 AutoMQ 公司的 AutoMQ Kafka RC 版本发布了全新特性,包括多云兼容性适配,Spot 实例强制回收容灾、裸设备 WAL 等。也带来了新版本的全新指标,新版本除了有十倍的成本优势外,支持 4 分钟内完成从 0 到 1GiB/s 的极致弹性,同时在追赶读的场景下有读写隔离的天然优势。AutoMQ 即将发布完整的基准测试白皮书,将会揭秘更多的技术指标。欢迎大家体验!

2024-01-18 08:006246

评论 2 条评论

发布
用户头像
这才是正确的玩法,类似万笔交易成本

此外,公司还需要了解成本结构。在过去,成本分析可能并不被认为是非常重要的事项,但我们最近与一些金融、汽车等行业的客户进行合作时发现,他们非常关心集团公司的资金花在哪些部门,这些

...

业务挂钩。例如,如果一个业务的目标是每日活跃用户(DAU),它将查看 DAU 的增长情况以及当月的 IT 支出变化情况,如果没有达到预期,管理层将进行问责。因此,这种产品在国外非常受欢迎。

2024-01-29 09:51 · 浙江
回复
用户头像
原来如此

回到 Twitter 事例,Twitter 原来有三个数据中心,波特兰、Sacramento 和亚特兰大,应该做了类似的三活。马斯克挑战团队在仅六天内把三个数据中心缩减为两个节点,结果在平安夜他与工程师们

...

万美元,裁员的工资节约了近 18 亿美元,所以在总体运营成本上取得了显著的 60% 节约。然而,有些文章直接写 Twitter 下云节省 60% 了云资源成本,媒体的这个表达不正确,也容易误导观众。

2024-01-29 09:42 · 浙江
回复
没有更多了

【小程序压力测试】一文教你没有文档玩转小程序压力测试

优测云服务平台

小程序 性能测试 压力测试、

Linux虚拟化指南:构建虚拟化环境

高端章鱼哥

Linux 虚拟环境

iOS应用程序数据保护:如何保护iOS应用程序中的图片、资源和敏感数据

雪奈椰子

云智一体,构建汽车智能驾驶解决方案

Baidu AICLOUD

自动驾驶 工具链 异构计算 数据闭环

实用!Python大型Excel文件处理:快速导入、导出与批量处理

树上有只程序猿

Python Excel

2024广州国际导电防静电塑料及导电橡胶展览会

吹吹晚风

2024中国广州国际氟塑料及应用设备展览会

吹吹晚风

TDD、BDD、ATDD都是什么、有什么区别?(上)

禅道项目管理

【运维 Pro】时序场景实践与原理 - 2. 宽表,窄表与 JSON 字段

YMatrix 超融合数据库

json 时序 时序数据 超融合数据库 YMatrix

dapp开发去中心化智能合约DAPP开发的未来

西安链酷科技

dapp开发

Photoshop 2024 (ps2024) for Mac v25.0正式版/25.1beta完整激活版

mac

图像处理软件 苹果mac Windows软件 Photoshop 2024

2023年国产堡垒机就选行云!8大理由看这里!

行云管家

网络安全 堡垒机 国产化 国产

一文详解GPU虚拟化云桌面解决方案

青椒云云电脑

云桌面 云桌面解决方案

新一代私有云的部署原理和步骤

青椒云云电脑

云电脑平台

云服务器哪家最便宜

青椒云云电脑

云服务器

C++ 里 ++i 是原子操作吗?

这我可不懂

c++ i++

一文了解SmartSE

DevOps和数字孪生

虚拟ECU SmartSE

2024广州国际功能薄膜与包装产业展览会

吹吹晚风

BIM遇上GPU云 设计师不换电脑的秘密

青椒云云电脑

cpu

新手入门:买完云服务器怎么搭建网站?

青椒云云电脑

云电脑

英特尔on技术创新大会:加速AI和安全的融合

E科讯

公链系统开发方案 公链开发需要多少钱可以做。

西安链酷科技

公链开发 公链团队

利用亚马逊云服务器 EC2 和 S3 免费套餐搭建私人网盘

亚马逊云科技 (Amazon Web Services)

存储 S3 VPC EC2

Performance of Maxon WiFi 6 Industrial Access Point

wifi6module

该选私有云还是公有云?全面解析企业上云如何选

青椒云云电脑

云服务 私有云 云桌面

信创国产堡垒机怎么样?哪家好?电话多少?

行云管家

云计算 信创 国产化 云堡垒机

dapp定制开发的重要性区块链DAPP搭建见解 区块链dapp开发 dapp系统开发方案

西安链酷科技

智能合约 波场DAPP

2024中国(广州) 国际不干胶标签展览会

吹吹晚风

大学云桌面系统如何部署,有哪些优势

青椒云云电脑

云桌面 云桌面系统

2024广州国际聚四氟乙烯制品及材料展览会

吹吹晚风

QCN9074 vs QCN9024|WIFI6E IIOT 4X4 Triband 2.4G 5G 6G Network Card and Application

wallyslilly

QCN9074 QCN9024

上云还是下云,最大挑战是什么?| 对话章文嵩、毕玄、王小瑞_云原生_InfoQ精选文章