1. 项目概述：一次对2018年云计算格局的“事后复盘”
时间拉回到2017年底，当时我正和团队一起规划来年的数据中心升级路线。那会儿，公有云的势头正猛，几乎所有的技术讨论都围绕着“上云还是不上云”展开。就在这个当口，我在EE Times上读到了Mellanox的Kevin Deierling那篇《2018年云计算的七个预测》。文章观点犀利，甚至有些“反潮流”，比如直言公有云的增长会放缓，HCI（超融合基础设施）将“反击”，以及网络会变得“隐形”。当时，这些预测在业内引发了不小的讨论，很多人觉得这不过是传统硬件厂商对云趋势的“酸葡萄”心理。
如今，几年过去了，我们早已跨越了2018年那个时间节点。回过头看这篇预测，其价值不在于它百分之百地命中了未来，而在于它精准地捕捉到了当时技术演进中的关键矛盾和转折信号。作为一名亲历了从传统虚拟化到云原生、从硬件定义到软件定义整个周期的从业者，我想结合这几年的实际发展，对这篇“旧文”做一次深度的“技术考古”与复盘。这不仅仅是对七个预测的简单验证，更是试图梳理清楚，那些关于网络、存储、计算架构的底层逻辑，是如何一步步塑造了我们今天所见的云与数据中心形态的。无论你是正在规划基础设施的架构师，还是关注技术趋势的开发者，理解这些“预测”背后的推演过程，都能帮你更清醒地看待当下喧嚣的技术概念，做出更扎实的决策。
2. 预测一：公有云增长放缓与混合云现实的崛起
原文第一个预测是“云在商业中的主导地位将放缓”。作者承认SaaS会继续侵蚀传统企业负载，但认为公有云IaaS/PaaS的狂野增长将趋缓，因为企业会找到在本地实现云般敏捷、效率和经济效益的方法。
2.1 预测与现实：一场关于“成本与控制”的拉锯战
从宏观数据看，公有云市场整体规模在过去几年无疑仍在快速增长。然而，增长的“质量”和驱动力发生了深刻变化。预测中提到的“放缓”，更准确地应理解为“企业上云策略的理性化与复杂化”。早期那种“All in Cloud”的狂热确实降温了。核心原因被作者言中：经济性（Economics）和可控性（Control）。
我亲身经历过一个典型案例：某中型互联网公司在2016年将全部业务迁至公有云，初期确实享受了弹性伸缩和免运维的红利。但到了2018-2019年，随着业务量稳定增长并出现明显的波峰波谷，他们发现月度账单中超过30%的成本来自于数据出口流量费和某些托管服务的溢价。更棘手的是，一些核心数据处理任务因为数据重力（Data Gravity）和延迟问题，在云端反而性能不佳。这时，他们开始认真评估“回流”（Repatriation）或采用混合架构。这并非个例，“云成本优化”（FinOps）成为一门显学，本身就说明了问题。
注意：这里说的“放缓”并非指公有云市场萎缩，而是指企业从“盲目迁移”转向“精细规划”。工作负载的分布变得更加深思熟虑：创新应用、前端流量突发型业务放在公有云；数据密集型、合规要求高、稳态的核心系统则倾向于留在本地或专属环境中。这催生了真正的“混合云”模式，而不仅仅是早期的“云备份”或“云灾备”。
2.2 HCI：作为“本地云”基石的得与失
原文将HCI视为实现本地云化、抗衡公有云迁移的关键技术。这个判断大体是正确的。HCI通过将计算、存储、网络（初期较弱）资源池化，并以软件定义的方式统一管理，确实大幅降低了本地数据中心的构建和运维复杂度。它兑现了“像云一样简单”的部分承诺。
在实际选型中，我们评估过Nutanix、VMware vSAN以及一些基于超融合架构的国产解决方案。HCI的最大优势在于部署速度和运维简化。传统三层架构（计算、存储、网络独立）从规划、采购、上架、调试到交付，周期往往以月计。而HCI方案，正如原文所说，几乎是“交钥匙”工程，几周内就能让业务团队用上资源池。这对于需要快速响应业务需求、又因合规或延迟无法全面上云的企业来说，吸引力巨大。
然而，HCI并非万能钥匙。它的局限性在后续几年也逐渐暴露：
- 横向扩展与性能瓶颈：HCI集群规模扩大后，存储网络（通常是基于万兆以太网的vSAN或类似技术）可能成为瓶颈，尤其是在全闪存阵列普及、对延迟极度敏感的应用场景下。
- 成本结构：HCI一体机的初始采购成本（CAPEX）可能较高，虽然它降低了运维成本（OPEX）。企业需要精细计算TCO（总拥有成本），而不是单纯对比硬件价格或云月费。
- 供应商锁定风险：选择某家HCI解决方案，往往意味着在计算、存储（甚至网络）层面与该厂商深度绑定，后续升级、扩展的灵活性可能受限。
所以，HCI的“反击”是成功的，但它并没有、也不可能完全阻止工作负载向公有云迁移。它更像是为企业提供了除传统数据中心和公有云之外的“第三选择”——一个现代化、云化的本地资源池，在混合云架构中扮演着关键的核心或边缘节点角色。
3. 预测二：超融合基础设施（HCI）的进化与网络集成
原文第二个预测聚焦于HCI本身，认为它将改变游戏规则，并特别指出网络是当时HCI部署中的主要痛点，预计网络将在2018年与HCI平台深度集成，从而变得“隐形”。
3.1 HCI部署中的“阿喀琉斯之踵”：网络配置
这个预测精准地戳中了当时HCI推广的痛点。在早期的HCI部署中，计算和存储的虚拟化、池化已经做得相当自动化，但网络配置往往仍需手动干预。我记得在部署一个vSAN集群时，需要专门配置分布式交换器、VLAN、MTU（通常要设置为9000以支持Jumbo Frames提升存储性能）、以及确保多播（Multicast）流量在底层物理网络中的正确转发。任何一步配置错误，都会导致存储网络不通，整个集群无法建立。
正如原文引用“70%的HCI支持电话与网络问题有关”，这绝非夸张。问题根源在于，HCI的自动化层（管理程序）与底层物理网络设备（交换机）是割裂的。网络设备看不到虚拟机（VM）的创建、迁移，它依然工作在传统的MAC/IP和VLAN层面。当VM为了负载均衡或高可用性在主机间迁移时，网络策略（如安全组、QoS）如果不能随之动态迁移，就会导致服务中断或安全漏洞。
3.2 “隐形网络”的实现：从SDN到VXLAN与自动化
“网络隐形化”的实质是网络配置和策略管理的自动化与意图驱动。这背后主要依赖两项技术的成熟与集成：
- 软件定义网络（SDN）：通过集中的控制器（如VMware NSX Manager、Cisco ACI APIC）来统一下发网络策略，将网络配置从命令行（CLI）转换为API调用。
- Overlay网络技术（如VXLAN）：它在现有的三层IP网络之上，构建一个虚拟的二层网络。这样，VM的迁移可以不受底层物理网络拓扑和VLAN ID数量的限制，因为它的网络身份（VXLAN Network Identifier, VNI）是封装在IP包里的，随VM移动而移动。
2018年后，主流HCI厂商都加速了与网络方案的集成。例如，Nutanix与多家交换机厂商合作，支持通过API自动配置交换机端口（如设置MTU、启用特定功能）。VMware的vSphere with vSAN更是与NSX深度捆绑，实现了计算、存储、网络资源的统一软件定义。部署时，管理员只需要在vCenter中定义网络意图（例如：“为财务应用创建一个隔离的网络段，并配置防火墙规则”），NSX控制器就会自动在底层物理交换机和虚拟交换机上完成所有配置。
3.3 实操心得：HCI网络规划的关键点
- 物理网络基础至关重要：“隐形”不代表底层可以随意。必须确保物理网络是高性能、低延迟且全冗余的。推荐使用叶脊（Spine-Leaf）架构，并确保所有HCI节点间的网络路径等距，避免跨机柜的带宽瓶颈。
- MTU一致性检查：这是最常踩的坑。要确保从VM虚拟网卡、虚拟交换机、物理服务器网卡、物理交换机端口，整条路径的MTU都设置为统一的大值（通常是9000），否则会导致存储流量分片，性能急剧下降。
- 多播流量处理：如果HCI方案（如早期vSAN）依赖多播进行节点发现和元数据同步，必须确认物理交换机正确配置了IGMP Snooping等，防止多播流量泛洪。
4. 预测三：开放网络与白盒交换机的兴起
预测四和预测五可以合并来看，它们共同指向了数据中心网络架构的一场静默革命：开放网络（Open Networking）对传统封闭式（Black-box）网络的替代，以及以太网存储网络对专用光纤通道（Fibre Channel）的终结。
4.1 开放网络的逻辑：解耦与最佳组合
传统网络设备的商业模式是“软硬件捆绑销售”。你购买思科、瞻博网络（Juniper）的一台交换机，不仅买了ASIC芯片和硬件，也买断了其操作系统（如IOS， Junos）。升级、维护、技术支持费用高昂，且不同厂商设备间互通性差，形成严重的供应商锁定（Vendor Lock-in）。
开放网络的核心理念是解耦（Disaggregation）：将网络硬件（白盒交换机）与网络操作系统（NOS）分开。硬件可以采用来自博通（Broadcom）、英特尔（Intel）等公司的商用交换芯片，由ODM厂商（如智邦、纬颖）生产成标准机架式白盒交换机。软件则可以选择开源的SONiC（微软发起）、Stratum（开放计算项目OCP发起），或商业化的Cumulus Linux（后被NVIDIA收购）、DANOS等。
这种模式给用户带来了前所未有的灵活性：
- 成本优化：白盒硬件通常价格更低，且避免了品牌溢价。
- 软件自主：可以选择最适合自己运维习惯和功能需求的NOS，并可以自主进行软件升级和定制。
- 自动化友好：开放网络设备普遍提供完整的Linux Shell和丰富的API（如OpenConfig、gNMI），极其适合通过Ansible、SaltStack等工具进行自动化配置管理，无缝融入CI/CD流水线。
4.2 以太网存储一统天下：NVMe-over-Fabrics (NVMe-oF) 的临门一脚
预测五关于“以太网存储结构加速光纤通道的消亡”，在2018年看来可能有些激进，但方向完全正确。FC SAN的堡垒之所以坚固，是因为它在当时为关键业务存储提供了低延迟、高可靠、无损的网络。传统iSCSI over Ethernet在性能和高并发上难以匹敌。
转折点来自于两项技术的结合：
- NVMe协议：取代了古老的SCSI协议，充分利用PCIe通道的低延迟和高并行性，将固态硬盘（SSD）的性能发挥到极致。
- RDMA（远程直接内存访问）技术：允许计算机直接从另一台计算机的内存中读取数据，无需经过操作系统内核和CPU，大幅降低了网络延迟和CPU开销。
NVMe-over-Fabrics正是将NVMe协议扩展到网络上的标准。它可以通过多种传输层实现，包括FC-NVMe（基于光纤通道）和NVMe over TCP或NVMe over RoCE（基于以太网）。其中，RoCE（RDMA over Converged Ethernet）是关键。它使得以太网具备了类似InfiniBand或FC的RDMA能力。
当25G、100G乃至更高速率的以太网普及，结合RoCE技术，NVMe-oF over Ethernet就能提供媲美甚至超越FC的延迟和吞吐量，同时继承了以太网生态庞大、运维熟悉、成本更低的优势。正如原文所说，“云里、软件定义存储里、超融合解决方案里都没有光纤通道”，以太网成为了唯一的、统一的数据平面网络选择。
4.3 实操中的选择与挑战
- RoCE部署要点：部署RoCE网络要求底层以太网是无丢包的（Lossless）。这需要启用数据中心桥接（DCB）系列协议，特别是优先级流量控制（PFC）和增强传输选择（ETS），来为存储流量划分独立的不丢包通道。配置不当会导致网络拥塞和性能抖动。
- 白盒交换机运维转型：采用白盒交换机，运维团队需要从传统的CLI配置模式，转向以自动化脚本和API为核心的运维模式。这需要团队具备一定的软件开发（DevOps）能力。同时，硬件故障的维保责任可能分散在硬件ODM和软件供应商之间，需要明确的SLA划分。
- NVMe-oF启动策略：初期可以从非核心的测试、开发环境开始部署NVMe-oF over Ethernet，熟悉其部署、监控和故障排查流程。对于核心生产环境，建议采用经过充分验证的融合网络适配器（CNA）和交换机，并确保网络团队与存储团队紧密协作。
5. 预测四：容器化浪潮与虚拟机的角色演变
预测六“容器将吞噬虚拟机”是一个极具话题性的判断。容器技术，尤其是Docker和Kubernetes（K8s）的兴起，确实对传统的基于虚拟机的云计算模式产生了巨大冲击。
5.1 容器 vs. 虚拟机：本质差异与适用场景
两者的根本区别在于虚拟化层级：
- 虚拟机（VM）：虚拟化的是完整的硬件层（通过Hypervisor）。每个VM包含独立的客户操作系统（Guest OS）、系统内核、以及应用。优点是隔离性极强，安全性高；缺点是资源开销大（每个OS都需要内存、CPU），启动慢（分钟级）。
- 容器（Container）：虚拟化的是操作系统层（通过容器引擎，如Docker）。所有容器共享宿主机的操作系统内核，但拥有独立的用户空间（文件系统、进程、网络）。优点是轻量（秒级启动）、资源利用率高、镜像小；缺点是由于共享内核，隔离性相对较弱。
容器的优势正契合了云原生应用快速迭代、弹性伸缩、微服务化的需求。开发者可以将应用及其所有依赖打包成一个标准镜像，在任何支持容器的环境中获得一致性的运行效果，实现了“一次构建，随处运行”。
5.2 Kubernetes的崛起与OpenStack的“让位”
原文提到了Kubernetes在容器编排领域的领先，以及OpenStack的受挫。这几乎是过去几年基础设施领域最显著的格局变化。OpenStack旨在构建一个类似AWS的私有云IaaS平台，其核心管理单元是虚拟机。它架构复杂，部署运维难度大，虽然在一些大型企业、电信云中找到了应用场景，但确实未能如预期般席卷企业市场。
Kubernetes则专注于容器编排这个更具体的领域，并且做得极其出色。它定义了声明式的API（YAML文件），通过控制器模式自动确保系统状态与期望状态一致。其庞大的开源生态（Helm、Operators、CNI、CSI插件等）形成了强大的护城河。Kubernetes不仅管理容器生命周期，更成为了云原生应用的操作系统。
5.3 虚拟机的未来：并非消亡，而是定位清晰
那么，虚拟机被“吞噬”了吗？更准确地说，是工作负载的虚拟化单元发生了分化。
- 云原生、微服务化、无状态的应用：几乎毫无疑问地会选择容器和Kubernetes。
- 传统的单体应用、需要特定旧版本OS或特殊内核模块的应用、对安全隔离有极端要求的应用：虚拟机仍然是更合适甚至唯一的选择。
此外，虚拟机与容器正在走向融合。例如：
- Kata Containers、gVisor等安全容器：通过轻量级虚拟机或用户态内核来提供更强的容器隔离性，模糊了二者的边界。
- KubeVirt项目：允许在Kubernetes集群中同时管理容器和虚拟机，将VM作为一种特殊的“工作负载”纳入K8s体系。
因此，预测中“容器吃VM”更多是指在新应用开发、新项目部署的心智份额和绿色领域上，容器取得了压倒性优势。而庞大的存量虚拟机负载，将在很长一段时间内与容器共存。
5.4 容器网络实践：CNI与多网络方案
原文提到的容器网络接口（CNI）是解决容器网络隔离和管理的关键。CNI是一个标准规范，允许不同的网络插件（如Calico、Flannel、Cilium、Weave Net）为容器配置网络。在选择CNI插件时，需要考虑：
- 网络模型：是Overlay（如VXLAN）还是Underlay（如BGP直通）？Overlay更灵活，适合多租户；Underlay性能更好，但需要底层网络支持。
- 网络策略：是否支持Kubernetes NetworkPolicy来实现Pod间的微隔离？Calico和Cilium在这方面功能强大。
- 性能与可观测性：Cilium基于eBPF技术，能提供高性能的网络数据转发和丰富的可观测性能力，是目前的热门选择。
6. 预测五：技术趋势之外的行业观察
原文的第七个预测关于比特币，更像是一个带有个人色彩的行业趣谈。作为技术从业者，我们更应关注其背后提到的现象：加密货币挖矿对计算、网络和存储资源的巨大消耗。这确实在特定时期影响了GPU等硬件的市场价格和供应，也催生了专门优化的挖矿硬件和数据中心。但这部分与主流企业云计算和基础设施的发展路径相对独立，在此不做深入展开。
然而，从这篇2017年的预测文章中，我们可以提炼出几个超越具体技术、至今仍具指导意义的底层逻辑：
6.1 经济性永远是核心驱动力无论是公有云增长的“放缓”，还是HCI的“反击”，或是开放网络的兴起，其根本动力都是企业对于总拥有成本（TCO）和投资回报率（ROI）的极致追求。技术决策越来越像财务决策。当公有云的边际成本高于自建时，回流就会发生；当开源软件+白盒硬件的成本优势大于品牌溢价和运维复杂度时，开放网络就会渗透。
6.2 抽象化与“隐形化”是长期趋势从物理服务器到虚拟机，从虚拟机到容器，从专用存储网络到统一以太网，从命令行配置到意图驱动网络……技术发展的一个清晰脉络是，将底层基础设施的复杂性不断抽象和封装，让开发者和管理员能更专注于业务逻辑本身。预测中“网络变得隐形”正是这一趋势的体现。未来的基础设施会越来越像水电煤，按需使用，无需关心其背后的庞大工程。
6.3 融合与统一是架构主旋律计算、存储、网络的融合（HCI），数据网络与存储网络的融合（NVMe over Ethernet），虚拟机与容器管理的融合（KubeVirt），都指向同一个方向：打破烟囱，构建统一、高效、灵活的资源池。这降低了架构复杂度，提升了资源利用率，也简化了运维管理。
6.4 开源与生态构建护城河Kubernetes的成功不仅是技术的成功，更是开源社区和生态的成功。OpenStack的相对式微，部分原因也在于其复杂的架构和相对封闭的治理模式。在今天，一个基础设施项目能否成功，很大程度上取决于其能否构建一个活跃、开放、共赢的开发者与供应商生态。
7. 从预测到实践：给当前基础设施决策者的建议
回顾这七条预测，再对照我们今天身处的2023年及以后的技术环境，作为一名深度参与者，我有几点强烈的体会和建议，供各位同行在规划未来架构时参考：
7.1 拥抱混合云，但定义要清晰不要再争论“上云还是不上云”，而是规划“哪些上云，怎么上云”。混合云不是简单的“既有本地机房又有公有云”，而是要求应用和数据能够在不同环境间无缝流动。这需要从一开始就在架构上考虑一致性，例如：使用统一的容器编排（K8s）、采用相同的开发运维流程（DevOps）、部署兼容的云原生服务网格（如Istio）。选择支持混合云管理的平台工具，如Google Anthos、Azure Arc、AWS Outposts，它们能帮助你在统一控制面管理跨云资源。
7.2 网络是基石，必须软件定义和自动化无论底层是白盒还是品牌交换机，网络的管理模式必须进化。基于意图的网络（IBN）和网络即代码（Networking as Code）将成为标配。这意味着，你的网络变更应该通过代码仓库（Git）来管理，通过CI/CD流水线进行自动化测试和部署。投资培养团队的网络自动化能力，比单纯购买最贵的硬件更重要。
7.3 存储架构面向云原生和性能重构如果你的应用正在向微服务和容器化转型，那么存储架构也必须跟上。对象存储（如S3兼容接口）已成为非结构化数据的标准。对于有状态容器应用，容器存储接口（CSI）和云原生存储方案（如Rook、Longhorn）提供了动态供给、快照、克隆等能力。对于高性能计算、数据库等关键负载，认真评估NVMe-oF over RoCE的可行性，它很可能是未来高性能统一网络的终极方案。
7.4 安全左移，并贯穿基础设施全栈在融合、统一、软件定义的架构下，安全边界变得模糊。传统的基于边界防火墙的安全模型不再适用。必须采纳零信任（Zero Trust）原则，并实施深度防御：
- 工作负载安全：对VM和容器镜像进行漏洞扫描，运行时安全监控。
- 网络微隔离：在K8s内使用Network Policy，在VM间使用NSX或类似工具的分布式防火墙。
- 身份与访问管理：对所有API调用、管理操作实施严格的身份认证和最小权限授权。
7.5 培养平台工程团队，而不仅仅是运维团队基础设施越来越复杂，但目标却是让开发者感觉越来越简单。这催生了平台工程（Platform Engineering）的角色。这个团队负责将底层复杂的计算、存储、网络、安全能力，封装成一个个自助服务的“内部开发者平台”（IDP），让应用团队可以像使用公有云一样，通过门户或API快速获取所需资源，而无需理解背后的技术细节。这是实现“隐形基础设施”的最后一步，也是最大化技术投资回报的关键。
技术预测的价值，不在于它是否百分百应验，而在于它能否揭示那些驱动变革的底层力量。2017年那篇预测文章，准确地捕捉到了成本、敏捷性、解耦、融合这些核心矛盾。今天，这些力量仍在塑造着我们的数字世界。保持对技术本质的理解，对经济性的敏感，以及对自动化、抽象化趋势的拥抱，或许是我们面对未来无数个“预测”时，最可靠的锚点。
