2030年，没有人会记得Kubernetes。
当人类发明了容器技术，还没高兴多久，OKR和SCRUM就来了。而现在，一场新的技术变革已经在酝酿之中——WebAssembly（WASM）正在悄悄取代容器，成为下一代开发者的终极武器。
为什么容器已经变得“讨人厌”？
容器技术的出现，曾经解决了许多软件开发的痛点。虚拟机虽然功能强大，但并不够轻量，而容器的出现带来了更快的构建速度、几乎瞬间的启动体验，以及更少的虚拟化开销。
然而，到了今天，容器已经变成了让开发者头疼的东西。DevOps的承诺早已被复杂的工具链和过度绑定所侵蚀，程序-容器-Linux三者的紧耦合让开发体验大打折扣。
大多数开发者的目标是写代码、上线新功能、达成季度KPI，不是研究Docker的构建优化。没人会把“提高Docker构建速度”当成核心目标，除非他是刚刚被重新包装成“PlatformOps”（前DevOps，前Ops）的团队成员。
WASM：真正的“写一次，跑遍全球”
WebAssembly（WASM）正逐步替代容器，甚至在某些场景中已经做到了。
WASM提供了一种真正的跨平台体验——任何能运行V8引擎的环境，都能执行WASM代码，而现在支持V8的地方越来越多。更重要的是，WASM已经支持多种编程语言编译，而对于尚不支持的语言，未来也能通过WASM解释器运行。
目前WASM的最大障碍是系统接口支持不足，比如文件访问、网络通信等。但这些都是时间问题，等到这些功能完善，WASM将彻底释放潜力。
WASM vs JVM：这次真的不一样？
当然，反对WASM的人最喜欢拿Java虚拟机（JVM）来对比。毕竟，JVM早就提出了“写一次，跑遍全球”的口号，而且全球超过30亿台设备在运行Java。
但JVM的最大问题是——它的字节码无法在浏览器中运行（RIP Java Applets）。现代应用需要跨平台共享代码，而JVM在这一点上明显力不从心。更何况，现在市场正逐步从JVM迁移到静态编译的二进制文件，比如GraalVM、Kotlin Native、Scala Native等。
WASM在浏览器端的天然兼容性，才是它真正的杀手锏。
微服务时代，WASM如何颠覆游戏规则？
在微服务架构中，服务之间主要通过HTTP、RPC 或消息队列进行通信。尽管这种解耦方式带来了很多好处，但网络延迟、带宽开销以及系统可靠性问题仍然是摆在开发者面前的挑战。
这正是WASM即将改变游戏规则的地方。
像AWS Lambda这样的无服务器平台已经把微服务拆分到了极致。但Cloudflare Workers的模式更进一步：当一个Worker调用另一个Worker时，它实际上不会发起真正的网络请求，而是直接在同一个V8运行时中执行。
这意味着：
✅ 零网络开销 —— 没有额外的网络延迟，调用就像本地函数一样快。
✅ 不需要容器 —— Cloudflare Workers完全运行在V8沙盒里，直接支持JavaScript、TypeScript，以及编译成WASM的代码。
相比之下，容器无法在同一进程中调用另一个容器，但V8可以。换句话说，WASM+V8沙盒的模式，能够提供微服务的开发体验，同时享受单体架构的运行效率。
Cloudflare并不是唯一在做这件事的公司。Wasmer等项目也在尝试构建类似的WASM解决方案，未来的应用架构可能将发生彻底的变化。
WASM正在加速普及，开发者该如何准备？
WebAssembly仍然是一项年轻的技术，但发展速度惊人，生态系统正在快速扩展。也许现在它还不适合所有应用场景，但不妨关注它的最新进展。想提前体验未来？可以尝试在Cloudflare Workers上开发项目，感受无容器架构的魅力。
如果你目前的主力语言是Python、Ruby 或 PHP，先别着急，这些语言的WASM支持还在完善中。但如果想提前适应潮流，建议把Go或Rust加入你的技术栈，这样当WASM真正成为主流时，你已经站在了风口上。
如果你还在构建Docker镜像，或许是时候重新思考你的开发体验了。