在这篇文章中，我回顾了我的一位英雄提出的一个想法，并思考了这个想法是如何为今天的集装箱运输计划铺平道路的。

从80年代开始，每个月我都热切期待并经常阅读的期刊之一是Byte杂志。从封面上那些奇思妙想、独具匠心的艺术作品（罗伯特·廷尼的许多作品），到经常出现的专栏，再到时不时出现的专题，我享受着从书页中倾泻而出的开拓精神和绝妙创意，我有幸在2000年初的O'Reilly的开放源码大会（OSCON）上见到了他。

客户机和服务器

Jon写的一篇文章中的想法（还有很多——见他1999-2002年的清单）BYTE.com网站（例如专栏）一直伴随着我，因为我读了它。您必须记住，那时web还很年轻，客户机和服务器之间有着明显的区别。在我们的工作站上，我们运行客户机——网络浏览器，如Netscape Navigator，甚至更早的例子，如Mosaic和Cello。

网络服务器（通常以httpd的形式——Apache的网络服务器软件）运行在服务器上，就是这样。我们的传统思维模式非常倾向于客户机和服务器的概念，尤其是自1992年SAP发布R/3以来，这是一种与我们以前习惯的R/2形成鲜明对比的客户机-服务器体系结构。

本地web服务器

因此当Jon在文中提到直接在本地工作站上运行服务的想法时，基于本地网络服务器，这是一个非常新的东西。将本地web浏览器指向运行在同一主机上的web服务器的概念——这无疑是一个闪光点。在URL地址栏中输入"localhost"会引起一点小小的兴奋，就好像我们在做一件有点未来感的事情。当然，我们以前使用文件方案（file:///）加载本地静态资源，大数据学什么，但是能够与服务交互，特别是基于公共网关接口（CGI）*的服务，我们可以控制和更改，这几乎是神奇的事情。

*我想起了古老的Internet事务服务器（ITS），它一直是主题最近在Twitter上有很多美好的回忆。ITS基本上是两个组成部分，"玛瑙"和"wgate"。根据当时的web服务器api，"wgate"（web网关）有不同的风格。一种是通用的CGI风格，这是我最喜欢的，因为在ITS之前，我已经用CGI和RFCSDK构建了相当长一段时间的基于web的SAP系统接口。但我离题了

离散和可移植服务

本地web服务器的概念是民主化HTTP。当然，人工智能技术发展，网络本身已经相当民主了——任何拥有纯文本编辑器的人都可以用HTML创建内容，并通过查看现有内容的源来学习如何创建内容。但是，任何人都可以在本地运行web服务器，企业管理软件公司，提供小型服务、单一用途用户界面的能力，淘客佣金，更重要的是，这种想法非常有启发性，打破了在工作站上运行的内容和在服务器上运行的内容之间的概念障碍。突然，我们开始考虑在本地运行的服务。我们通过HTTP访问的服务，几乎总是有一个基于web的接口，现在可以在本地运行。一旦你在URL栏中看到"localhost"这个词，你就看不到它了。

于是，至少对我来说，客户机和服务器之间就没有什么区别了。您或其他人构建的服务可以在本地或远程运行。重要的是，你和他们交谈，在某些情况下，通过你的网络浏览器管理他们。唯一的区别是URL中的主机名不同。

此外，在本地运行这样的服务变得更容易，因为越来越多的软件生产商和爱好者提供了易于安装的捆绑包—无论是因为目标操作系统使其更容易安装，还是捆绑包本身是可移植的。不管你喜不喜欢Java语言本身，很难否认Java真正的胜利——Java虚拟机（JVM）所提供的早期代码的可移植性。下载一个Java存档文件，运行它，并通过在浏览器中指定"localhost"和一些端口号*连接到您刚刚实例化的服务。

*端口号通常在1024以上，因为让一个服务侦听低于该端口号的端口号需要根权限。

从便携服务到容器

我被提醒了这一点本周末，我在Kafka和PCF Dev上观看了一段视频，视频中基于web的界面几乎无处不在的便携服务的概念。PCF Dev是一个本地的云铸造安装，用于开发目的——我将把这个想法如何添加到本文主题的概念上的思考留给读者作为练习Kafka服务有一个web界面，显示模式、主题、连接等的统计信息。事实上，我无法确定URL栏中的地址（你可以在视频中看到）是直接在本地还是在容器中（它至少是一个私有地址），这一点让我想到，在这种情况下，离散服务和容器是一回事。

今天我们理所当然地认为容器的概念，这些容器是否是显式的并由本地（或远程）Docker系统管理，或者在SAP云平台上的Cloud Foundry环境中，这些容器是否短暂且实际上是概念性的。但我认为，我们实现企业计算结构的过程受到了几十年前出现的基本思想的影响。