新类型的SaaS服务
再考虑另外一种业务场景：2B服务商给客户提供产品和服务。这在国内其实是件不容易的事情。
- 做成SaaS是没人用的，至少
高净值客户是不喜欢SaaS的，他们需要私有化部署的解决方案； - 私有化部署的产品是成本高昂的，特别涉及到定制化和二次开发；
- 私有化部署的产品更为高昂的成本体现在运维上，尤其是客户分布于全国各地时。这与前面介绍的企业面对大量分支机构时的困境异曲同工；
- 唯有降低成本是2B服务获得生存的唯一法门，这是众所周知的秘密了。
Eight为喜欢SaaS的服务提供商和喜欢私有化部署的客户提供了一个两全其美的选择——部署私有化与运维SaaS，并且，Eight提供的强大能力为低成本的运维提供了有力保障。
对于多数高净值客户而言，让他们提供ssh远程登录密码用于系统部署和故障处理都等于天方夜谭。但是，在必要时，通过安全信道（如防火墙、网闸、受控代理等），临时建立一个运维管理通道用于远程在线支持则是一个可以探讨的合同。
又或者，能够将Eight的中央控制平台部署于客户位于一线城市的研发中心的内网之中，这样既能满足客户的安全诉求，也不至于因为运维问题时需要跑遍全国。
总而言之，面向企业提供产品和服务的服务商，如果使用Eight作为基础架构，将获得新的解决方案。这将大大拉近他们与本土企业的距离，大大节省成本，从而在竞争中占据优势。
组件的积累和降低研发成本
上面已经提到，企业应用的开发之所以难以盈利，关键问题在于成本。而成本又分为两部分：研发成本和运维成本。
之前的案例集中展示的是Eight在运维方面的巨大潜力，接下来再来谈谈在研发方面，Eight所拥有的巨大优势。
仔细回顾一下本专题，从一开始的原理部分，谈的就是模块、组件、变化、共识、事物的分解、弱化沟通、并行开发、联系与组件连接等等，一路下来，这一系列哲学理论都指向同一个目标——开发独立而可复用的组件（元件）。
根据我们前一章的实例，我们见到了一个约60MB的底座，其中Eight的核心库只占很小部分，大多是常用的第三方工具库。就这样一个jar包，体积可能比随意一个spring-boot微服务都小，却拥有着千变万化的能力。而根据我们前一章提供的线索，我们一套完整的可供发布的系统，拥有mvc的全部层次和业务逻辑，才仅仅不到400kb，这背后是Eight核心库提供的元件大量的重用。管中窥豹，足以窥见Eight设计哲学的惊人威力。
不仅仅是元件大量的重用，根据我们上一章的实例，我们发现，其实两个一开始并不合适的组件（如userinterface和带dir参数的search组件），在Eight架构下可以轻而易举的粘合在一起使用。而一个service组件，可以在运行时采用不同参数生成多个实例与不同模块对接。无数合适与不合适的组件，如果基于Eight的原则进行开发，是可以意想不到的构建出新的系统的。
说到底，Eight本质上是一种世界观和方法论，切割事物、抽取不变性、归纳共相、构筑内核稳定的组件、实现不断变化联系，最终，高度可复用的软件组件体系才是它的目标，而千变万化的运行时系统和高度可控的远程运维能力，只不过是达成目标过程之中的副产品。Eight优雅的哲学原理，使得Java这样古典的静态语言，拥有了连动态语言都难以企及的威力。
由此，我们可以为企业应用寻找到一条新的道路：
- 2B的企业应用之所以成本高昂，核心问题在于企业业务的独特性带来的定制化需求。定制化导致现有软件不能完全被重用而必须进行二次开发，面向企业的非标准化开发投入的资源巨大而消费方却很狭窄，无法像互联网产品或标准化SaaS产品那样依靠大量用户的复用来摊薄成本；
- 定制化开发缺乏长期大范围复用的考验，质量未必能够保证，其可能导致的运维问题将进一步恶化成本收益；
- 若不以标准化的产品为基本单位，而以标准化的组件为基本单位则能够获取千变万化的能力。即便企业千差万别，业务各不相同，但其中绝大多数的是行业共性，只不过这些共性的组合方式殊异；
- 无论是2B服务商还是企业自身，如果采用Eight体系架构，在行业领域内纵深发展过程中，不断积累共性，积累标准化组件，应对改变，发展出更多新的业务组件，则不仅研发成本随着组件库的积累而不断降低，组件的质量也经历不断的历练而更趋稳定；
- 同一行业的组件库可以在垂直领域内被广泛复用，以更广泛的使用来摊薄单次研发的成本；
- 从这个意义上，2B的企业应用，能突破成本与收益的困局，以低廉的成本获得高质量的应用。
这也许才是未来2B服务的标准样板。