作者：舒乐之 Immux
软件开发，本不应该如此复杂；系统维护，本不需要如履薄冰。
今天通行的互联网软件开发体系，是数十年来，成百上千个组织与个人共同构建的。
比方说云服务器–Linux操作系统–SQL数据库–Java后端–React前端这个常见的技术栈，每一层都由不同的人设计，这些人各有专攻，大多并不相识，时间上横跨十年二十年三十年。于是，计算体系是成了一件百衲衣，确实能大致满足我们的需求，但是体系里有大量偶然复杂度，冗余无处不在，结构难以理解。
我们称这种现象为「计算体系的碎片化」。
1. 碎片化的来源
在服务器领域，占主导地位的操作系统是Linux，Linux的设计承袭自Unix，Unix的设计则是在60年代就开始了。Windows一开始是MS-DOS的图形界面，MS-DOS又承袭自CP/M，这也是70年代开始的设计。
当时，电脑还是科研机构里的珍贵器材，内存是以KB计算的。这些操作系统早期处理的问题是，如果我只有一台电脑、一个处理器，但是有很多人想用，我要怎么分计算资源？
后来，我们对计算机系统的需求迅速膨胀，计算硬件的性能也高速增长，但是早期做出的设计决定却不容易修改，于是我们就旧有基础上不断新增抽象。
操作系统的文件系统满足不了我们对数据存储的需求，我们开发了各种数据库软件。
为了提高数据库性能，我们又开发了内存数据库（比如Redis），以充当「主数据库」的缓存。
我们嫌现有操作系统部署不够方便，又开发出了「容器」（如Docker），然后容器还需要专门的「编排」工具（如Kubernetes）。
这些扩展和改进，往往缺乏协调。新增机制叠床架屋，有时候互相倾轧，有时候顾此失彼。
例如，Linux和Windows都有「用户」系统，可是数据库（比如MySQL）也有「用户」系统，应用层可能还有「用户」系统。这些用户系统之间，并没有明确的逻辑关系。你只有数据库的「读」权限，是不是代表你写不了东西进数据库？不一定，如果你能拿到数据库文件的写权限，也可以绕过数据库软件直接操作数据库文件。
又如，不同程序之间，通常是不能读写别的程序的内存的，隔离进程权限。但是，在硬盘上，不同程序却可以读别的程序存储的文件（只要是同一个用户创建的）。如果一个程序不应该读别的程序的内存，为什么又可以读别的程序的文件？
还有，编程语言提供多种数据类型，数据库也有数据类型，这些数据类型，有时候可以通用，有时候又不行。比如，JavaScript有个null，SQL也有个NULL，JavaScript的null当成SQL的NULL存取，却会出问题。
2. 我们的理想
我们是一网网络。
我们希望重建一个计算体系，吸取现在现有体系设计的经验，合并重复、冲突的机制，针对21世纪高性能计算机硬件设计，构建一个统一、协调、安全、容易理解的计算体系。
我们的计划如下。
第一步：数据层
我们认为，计算体系的基础是数据体系，所以我们的起点是一个不可变（Immutable）的存储引擎。这个存储引擎会保留所有的数据修改，随时可以回溯至过去任何一个状态。
此时，文件系统和内存管理，它将仍然依赖于现有的操作系统。
第二步：计算层
然后，我们为各个编程语言设计连接到数据存储引擎的接口，接口对于每种编程语言应该是自然的。比如，如果编程语言是面向对象的，访问数据层就应该像访问「对象」 一样。
如果技术能力允许，或者现有方案不能满足我们对接口的需求，我们或许会需要构建新的编程语言虚拟机/编译器。
第三步：操作系统层
然后，我们使我们的系统需要独立于现有的操作系统体系，不再受现有操作系统对任务调度、磁盘存取的限制。
第四步：硬件层
当前的通用计算和存储芯片是为存储可变数据设计的，我们对数据不可变的要求，有一天会迫使我们开发特制的芯片，针对不可变计算、函数式编程做专门优化。
3. 昨天、今天与明天
我们在2018年11月成立，2019年获得一轮种子融资。我们在广州有办公室，但是全员远程工作。
我们在数据层有ImmuxDB，现在的版本已经是重写过一次的第二版，从一开始依赖RocksDB到自己实现键值引擎。ImmuxDB已经有多个应用案例。
在计算层，我们正在开发第一版的ImmuxCompute，提供一个统一的函数运行接口，目前可以托管运行JavaScript函数。
在ImmuxCompute基础上，我们在开发「函数市场」功能，让广大程序员分享、出租各种重复的业余逻辑与函数。
对我们团队、产品有兴趣吗？欢迎来我们网站https://immux.cn/zh/ 。
技术方面，欢迎来我们的GitHub看看：https://github.com/immux/immux，我们博客也会定期更新技术分享，比如我们写过一篇LevelDB的分析：https://immux.cn/zh/blog/level-db-reading-notes/。
