(网经社讯)本文最初写于两年之前，是结合我个人的工作内容以及过往职业生涯中从事企业应用开发的十余年经验写成的；近期做了重新整理和内容补充。文中虽然没有具体讨论软件架构和技术细节，但包含了很多扫盲性质的概念介绍以及我本人对企业 IT 服务和云计算的一些思考。

企业 IT 服务的困局

企业 IT 服务已经不是什么新鲜的业务模式了，从上世纪 80、90 年代开始，随着计算机的广泛应用，企业信息化逐步成为一个被广泛认可的业务领域，专业的企业IT服务商也应运而生。但与国外的企业IT服务商的飞速发展相比，国内的企业 IT 服务业务始终处于不温不火的尴尬境况，这当然与国内企业客户管理层的决策认知以及实操环节的非技术因素有很大关系，但我认为国内企业 IT 服务商自身的技术能力、产品战略、商业模式同样是造成这种困局的不可忽视的重要原因。

时至今日，国内企业 IT 服务领域最主要的商业模式还是外包。

企业 IT 服务的外包时代

这种模式很容易理解。比如，A 公司需要用一套某个具体业务的信息化系统，但 A 公司并不是软件公司，自己也没有专职的开发人员，不能自主开发软件，所以 A 公司将这项开发作为一个项目，外包给有能力做软件开发的 B 公司。

这里边最主要的矛盾在于：A 公司不懂软件开发；B 公司不懂 A 公司的业务。于是，相互沟通中的各种误解、偏差，在开发、测试、部署、验收以及运维、增强的整个软件项目生命周期中不停的发生、叠加，项目的工期越来越长、质量越来越难控制，最后多半就是勉强上线、凑活能用。A 公司受困于无休止的系统问题（可能是功能设计问题，也可能是开发中的程序技术问题）；B 公司受困于无休止的需求变更（可能是真的需求变更，也可能是沟通上的误解或者客户描述的偏差、技术实现的偏差等等）；双方的相关成本都与日俱增（最主要的就是反复沟通、反复修改测试以及一些实操上的手续等等）。

这些现象，在 A 公司、B 公司都没有相关经验时，将变得非常容易发生，也非常影响项目的进展以及双方的实际成本。于是，一种做“IT 咨询”业务的 C 公司就慢慢产生了。C 公司既懂 A 公司的具体业务，也懂软件开发的相关知识。这样，C 公司可以帮助 A 公司做相关的需求、功能设计乃至 IT 规划、IT 管理等等的相关工作；同时，C 公司又可以相对准确、有效的与负责软件开发的 B 公司进行具体的沟通、日常开发管理、验收等工作；这在很大程度上就使这种软件开发外包的模式逐渐专业化、产业化。

实际上，B 公司在进行了若干与 A 公司业务类似的项目之后，自己一般就有了经验，可以直接来做 C 公司的工作；这种能力，对于 B 公司来讲，就可以被称为“具有方案能力”。那么 B 公司与其他仅做软件开发外包的公司相比，就有了一定的竞争优势。

对于技术能力比较强的B公司，多半会在与 A 公司类似的项目中发现大多数代码都是“可复用的”，于是就会基于这些可复用的代码构建出具有具体业务功能的“产品”。之后就可以结合这种产品来给与A公司有类似业务的公司做所谓的“实施”，即针对客户公司的特殊需求做一些定制开发或者模块化的替换、增减来形成一个特定的业务系统。像金蝶、用友，在其发展历程中都经历过这个过程。

同样，C 公司因为有 IT 规划、IT 管理、系统方案的能力，在资金允许的情况下，也可能会自己组建开发团队来做 B 公司的工作。这样，一种既具备 IT 规划、方案能力，又具有软件开发能力的公司就慢慢发展形成了，这就是所谓的“系统集成商”或者叫做“方案商”，它们的核心竞争力主要体现在 IT 规划、方案以及大中企业客户关系上（因为考虑到替换成本，大中企业在 IT 服务商的选择上忠诚度是比较高的），具体的开发工作可能自己做，也可能再外包给仅做软件开发的公司。

国内系统集成商的代表有浪潮、东软、中软、太极、清华同方、神州数码、东华软件和航天信息等公司。它们当中很多都是做计算机硬件起家，因而有了一定的企业客户资源，之后在企业信息化过程中就自然而然的发展出了软件交付、系统集成的能力。就国内环境而言，客户关系在业务发展过程中的作用相对会高于国外的环境（产品本身的技术竞争力有时并不是最重要的），这也是国内这些大的系统集成商的一个共同特色。

外包模式的弊端

对于企业客户来讲，在这种模式之下，除了一次性的项目开发费用或产品实施费用以外，一般还需要花费相当多的软硬件购置、维护费用（例如服务器、数据库产品、中间件、安全软件乃至数据中心的构建等等），以及为专门从事运行维护的人员（负责监控 IT 系统、排除故障乃至一部分技术问题解决等等）所付出的人力成本。而这些成本则会成为企业的一个长期负担。

很多大企业针对外包模式的成本问题，开始自己组建 IT 团队，由自己的IT团队来进行相关的技术方案选型、设计、实施、运维等必要的工作，同时自建数据中心管理自己的软硬件。这当然需要很高的持续投入，然而即使花了很多钱，其人员、设备和实施、运维过程的专业性往往仍然难以令人满意，IT 事故一样层出不穷。对于中小企业客户而言，则受限于可投入的有限成本，而导致它们的IT系统通常都非常简陋和不堪一击。

随着大中型企业自建 IT 团队成为事实，一种从事“人力资源外包”业务的 D 公司也应运而生了。这种商业模式非常简单：D 公司通过长期劳动合同或者项目合同的方式招募技术人员，然后将这些人员外包到有技术人力资源需求的 A 公司去工作。对 A 公司来讲，这只是短期性质的的低廉人力成本，且单价大大低于自己招募同级别全职员工；对 D 公司而言，则可以简单地、相对稳定地赚取人力成本差价，而无需任何额外花销。事实上，除了专门的人力资源公司，很多系统集成商、软件外包公司也都有这种业务；因为理论上讲，这种业务模式只需要客户关系，而基本无需其他技术含量。这种模式的主要弊端则在于其对 A 公司的技术和管理能力要求较高，以及因为人员流动风险而产生的对 A 公司业务、知识管理等方面的影响。

对于服务商来讲，这种外包模式的成本开销同样巨大，因为“需求”永远在变，bug 永远在出，无休止的人力成本和沟通成本投入以及回款问题对其利润空间的不断挤压使很多中小服务商不堪重负。没有一些特定的资源或机会，正常操作的话，想“盈利”是非常困难的。服务商们只能不断压榨内部成本，这也直接导致其自身的专业化、产品化、规模化成为难以企及的空中楼阁。

尽管外包模式对于项目双方都有很多弊端，但在相当长的时间里，它都是非软件企业的信息化建设的唯一选项；直到“云计算”的出现。

云计算的兴起

云计算（Cloud Computing）的提法最早出现在 1996 年，但直到 10 年之后，Amazon 才在 2006 年 8 月发布了世界上第一个真正意义的云计算产品“Elastic Compute Cloud”。随后在 2008 年 4 月，Google 也推出了著名云计算应用引擎的“Google App Engine”；同年 10 月，微软宣布将推出自己的云计算平台Azure（Azure 的实际发布是在 2010 年 2 月）。

又经过了大概 10 年左右，到 2016 年，云计算体系已经相对发展成熟，它也为企业IT服务提供了一种新的可选方案。对服务使用方而言，云计算的主要优点有：

云计算可以使用户方便、快捷的添加、扩展、调整IT基础设施资源（比如服务器的 CPU、内存、硬盘、网络带宽等等）。

使用成本的大幅度降低。因为云计算的模式，是由专业的云计算服务厂商提供软硬件服务，客户所要支付的仅仅是固定的、相对低廉的租赁费用，而不需要再去自己购置软硬件、自己进行运行维护（构建自己的数据中心）。

硬件设备和访问位置的无关性。云计算厂商一般会在各个网络运营商处都有相对优化的接入点；而不像传统的企业自管服务器，会受服务器所在地的网络运营商的线路限制，导致跨地区、跨运营商访问时的性能难以确保。

云计算厂商可以提供专业的监控服务，无需自行购置相关的监控软硬件。

按需的自服务资源管理方式和高可伸缩性。就是用户可以按照自己的实际使用量以自服务的方式调整所需的软硬件资源，进一步降低使用成本；同时又可以快速的调整软硬件资源需求。（比如在业务量较低时降低 CPU、内存、带宽等需求以节省成本，在应用压力增大时增加相关资源；或者由服务提供商自动根据应用压力调整所需资源。）

可度量的服务。所有对软硬件资源的使用，都可以由服务提供商进行准确的统计和报告。

云计算的服务模式，从概念上讲，由低到高大概可以分为以下三个层级：

IaaS（Infrastructure as a Service，基础设施即服务），即基于硬件虚拟化技术，为客户提供虚拟化的服务器、数据库及其他相关软件、工具。

PaaS（Platform as a Service，平台即服务），即客户可以使用服务提供商所提供的编程语言、服务接口以及工具在特定的云基础服务上构建自定义的应用程序。

SaaS（Software as a Service，软件即服务），即客户可以直接使用由服务提供商基于云基础服务所构建的特定应用程序。

目前市面上大部分的公有云厂商都是部分或全功能的 IaaS 服务商，即可以为用户提供特定的软硬件虚拟化服务及相关的线上资源管理工具。

PaaS 作为云计算高层抽象的中间层，其具体的界定相对而言是比较暧昧的。它可以是像 AWS（Amazon Web Services）、GCP（Google Cloud Platform）、Azure（微软的云计算平台）这样的，更偏向于IT基础服务的全功能公有云计算平台（这三巨头均同时提供 IaaS 和 PaaS）；也可以是近年来有了迅猛发展的一些类似文件存储、CDN、安全管理、容器服务以及营销、游戏、媒体（直播、视频）这样的特定服务类 PaaS。

而 SaaS 则通常是现成的可用软件，用户只需要支付一定的“租金”就可以通过能接入互联网的浏览器直接使用特定的业务功能，多数 SaaS 都只需要很少的配置就可以在极短的时间内开始为用户提供具体服务。

很明显，SaaS 模式与外包模式相比，其在成本上的优势非常巨大；同时因为其厂商多半对其应用场景有较多、较深的经验，所以其具体业务功能的专业性通常也是比较高的。

针对 SaaS 产品的应用范畴，我们还可以把 SaaS 分为以下两类：

通用 SaaS，旨在解决各种企业中都可能需要的一些功能，比如沟通、安全管理、知识管理、文档管理、考勤、差旅、审批（流程）、资产管理、会议管理之类。

垂直 SaaS，旨在解决一些细分领域或者行业特有的业务问题，比如特定行业的收费业务、电子商务、租赁、医疗（健康管理）、营销、建筑工程、商业零售等等。

总体上说，通用 SaaS 的目标客户范围更大，相对而言竞争也更多；而垂直 SaaS虽然客户范围变小了，但其客户的同质性更强，且因为其细分行业的专业性，从具体功能上看也会更有特点，更容易做深、做精（取决于服务商本身的业务领域能力及个性设计）。这两类 SaaS 从其商业模式上看，并没有本质的区别。

SaaS 还是 PaaS

从实际情况来看，IaaS 和 SaaS 在企业 IT 服务领域的应用是最直接、最自然而然的。

IaaS 模式，是由专业的云计算厂商对基础软硬件（比如服务器、数据库、网络带宽、备份、灾备等等）进行虚拟化来提供的。它与传统的企业 IT 管理方式相似度非常高，但一般而言，即使是大企业，在数据中心构建、网络优化、异地灾备等方面的专业性也很难与专业的公有云计算厂商相比，要得到同级别的服务能力，成本至少要高出一个数量级。所以 IaaS 模式得到客户的认可是很自然的事。但IaaS 模式所解决的仅仅是一些必须的基础IT软硬件的持有和维护问题，用户业务功能的实现，依然还需要通过外包模式来定制开发获得，所以这实际上并不是颠覆性的。

当 SaaS 模式发展成熟之后，企业用户在进行 IT 规划时，才有了真正的另一个选项。因为 SaaS 提供的是直接可用的软件，所以其在企业用户的财务报表中仅仅表现为可预测的、低廉的“租赁”成本，而不是外包模式中所必须的、高昂的软件开发费用、软硬件购置费用和维护成本（包含相关的内部人力成本）等等。

从本质上说，外包模式是以较大的投入，换取一定的企业软硬件资产；而 SaaS 模式仅仅是以较小的运营成本支撑企业的运转，并不产生软硬件资产。所以企业的选择，更多的是判断以至少超出一个量级的成本所得到的软硬件资产是否值得去投入的问题。很明显，一般而言，规模越小的企业，使用 SaaS 的意愿会越强，因为这有助于它们聚焦自己的业务，而不用去花费很多成本来创造一些没有实际业务价值的软硬件资产。对于大中型企业而言，SaaS 也并不是就没有吸引力，因为这同样也提供了一种可以使企业把研发、运营成本聚焦在关键业务的选项。

当然，企业用户对 SaaS 模式的担心也是可以理解的。比如，采用 SaaS 模式之后，企业自有 IT 团队势必面临一定程度的边缘化和转型压力；以及最重要的，对业务数据（尤其是敏感商业数据）物理存储位置的担心。但这些问题其实都是企业IT规划、IT 战略转型中的必然，也是可以从技术上、管理上解决的。

与大公司把持 IaaS 市场不同，SaaS 服务商的技术、资金门槛更低，而且作为一种新的产业增长点，SaaS 服务商也是创业公司和传统的系统集成商、方案商乃至软件外包公司的一个巨大的机遇。大概从 2010 年开始，欧美的 SaaS 服务商逐渐得到了广泛的认可和接受，纷纷做大乃至上市。而国内的企业 IT 服务市场还处于转型的初期，大有可为。

SaaS 模式的弊端

SaaS 模式能否取得商业可行性的关键就在于能否快速复制、用户能否在极短的时间内就使用其提供的具体功能服务。这当然要求 SaaS 的功能在不同用户间具有极高的“相似度”，否则就无法快速复制、快速交付用户。

但事实是，对于大中型企业而言，其核心业务的具体功能细节是很难达到“高度相似”的程度的。所以市场上能够得到广泛应用的绝大多数 SaaS 都不是企业的核心业务，而是一些通用型的、非业务功能性的基础功能需求，比如 Slack、钉钉、企业微信所提供的那些功能。

Salesforce 提供的 CRM 功能，当然属于企业的核心业务之一，但它能得到很多大中型企业的采用，是因为它的复杂程度、功能的完整、完善程度实际上已经不是一般意义上的 SaaS 了，它的产品实际上已经做成了本文要安利的终极目标——垂直 PaaS。

对于稍微大一些企业来说，一旦涉及到其重要的具体业务，必然会有很多的定制化需求，包括对本地部署（数据隐私性）的要求，这在国内的老牌 ERP、CRM、财务软件厂商那里已经得到了印证。所以用 SaaS 模式来提供这些业务功能的服务，通常都不是一个可行的好主意，尤其是从国内环境来看。

以我个人实际供职的最后两家公司为例，一家是做企业级金融服务，一家是做智能楼宇管理服务。那么对于这种业务来讲，其客户的体量都不小，所以你要求客户按照你自己设计的 SaaS 软件的流程来走，是根本不现实的。即使能推进，也要根据客户的要求做很多的定制，要适应客户自己的已有系统、已有厂商、已有规程。这在楼宇管理这种业务中体现得尤为明显。绝大多数客户都不可能因为签约了一家管理平台 SaaS 厂商，就把自己已有的所有管理系统全替换掉，就把自己已经使用的所有相关设备厂商全替换掉，所以你的 SaaS 必然要支持客户目前的各种业务系统、各种流程、各种厂商的设备。显然，目前各个厂商的标准化程度是极低的，所以你的 SaaS 里就必然的会出现非常多的定制化逻辑。这会极大增加 SaaS 软件的开发成本和维护成本。SaaS 厂商做到最后会发现实际上 SaaS 已经不是 SaaS 了，而是定制化的项目的集合，变成了费力不讨好的系统集成业务。这对初创公司而言无异于“毒药”，因为你没办法快速复制；换一个客户，又是一堆定制化的需求，那 SaaS 实施的成本优势也就不存在了，整个商业模式也就不成立了。

评判一个 SaaS 软件的标准，最简单的当然就是看它在不同客户企业中实施时所必须的代码改动量。代码零改动当然是所有 SaaS 厂商的目标，但显然并不都能做到。问题就在于这个代码改动量给实施和后期运维所带来的额外成本，能否用订阅模式的“租金”来覆盖；在于客户量逐渐变大之后，总体的“租金”收入能否持续地覆盖这部分额外成本。如果不能，那就要看有多少钱来支撑你的 SaaS 产品达到零代码修改的程度。

采用 PaaS 模式能带来哪些变化

从前文中对 PaaS 的解释可以看到，PaaS，是由服务商提供的一种可以“自定义应用程序”的工具，而不是可以直接使用的软件。我们可以把 PaaS 想象成为乐高积木，用户可以根据自己的需求、设计来自由地组合、拼接出的自己想要的物体。

目前市面上的公有云厂商提供的主要 PaaS 特性，比如应用引擎（例如 Google 的App Engine、AWS 的 Elastic Beanstalk）、云数据库（并不是简单的数据库产品虚拟化，而是可以由 API 控制的、具有动态伸缩性的、高吞吐量的所谓“全托管”数据库产品，例如 AWS 的 Aurora、DynamoDB）、云存储（例如 Amazon 的 S3、阿里云的 OSS）、内容分发（CDN）、网络（VPC）、媒体服务（直播、视频）、监控工具、AI 基础服务工具以及函数计算、无服务器（serverless）计算（例如 AWS Lambda）等等，这些都是更偏向于 IT 基础服务的高级抽象，也就是更接近于 IaaS 的 PaaS。但它们并不能直接用来简单地拼接、搭建可用的业务系统，因为它们并没有对任何具体的业务逻辑进行抽象；当然，这也不是公有云厂商应该做的事，再大的厂商也不可能通吃所有的具体业务场景。

所以，对企业 IT 服务来讲，更接近 SaaS 的 垂直 PaaS 才是企业用户的乐高积木。而这也才是企业 IT 服务商可以有所作为的终极形态！

什么是垂直 PaaS

所谓垂直 PaaS，就是一种针对细分领域、特定业务场景而设计抽象的 PaaS。垂直 PaaS 会提供一套可以实现某项具体业务功能的技术接口（也就是一套原子化的业务功能操作集合），用户可以自由组合、使用这些技术接口，在自己的内部业务系统、产品平台以及各端应用（移动设备 App、浏览器插件等等）中以自定义的方式，简单、直接地实现具体的业务功能。

从概念上，可以把垂直 PaaS 理解为：把某个具体的 SaaS 的前端用户交互逻辑拿掉，把业务处理和一些通用基础服务（比如身份验证、用户权限管理、元数据管理、文件/文档数据服务等等）抽象为原子化的 API 提供出来的一种云计算服务。

SaaS 在大中型企业中应用的一些主要问题（比如，SaaS 一般需要一套单独的用户账户、单独的业务数据；操作界面、操作流程是服务商预设好的，无法整合到已有的业务系统、或者现有的业务流程中等等），在垂直 PaaS 中都可以相对完美地解决：因为垂直 PaaS 提供的是原子化的、解耦的业务操作技术接口，所以可以很容易地集成到现有系统、现有流程中，甚至用户账户、元数据（业务数据）都可以通过技术接口进行方便的初始化（数据定义）、导入导出、格式变换等等。

垂直 PaaS，是一种支持“自定义应用程序”的、针对某个具体业务功能的技术平台，要使用它，必然需要有技术能力的“人”来做一定的开发或者集成，而做开发的“人”，既可以是用户、企业自己的开发团队，也可以是系统集成商、方案商、软件外包商乃至个人开发者。所以作为垂直 PaaS 服务商，其发展方向就很明确了：技术上，不断完善平台功能，做深、做精，甚至创造自己的开发语言、开发工具，进而构建开发者社区，建立应用市场、插件市场，逐步完善生态系统；商业模式上，在自主推广的同时，积极寻求有远见的集成商、方案商、外包商合作伙伴，共同扩展客户市场，实现共赢。与 SaaS 模式相比，这显然是更有想象空间的。

只有大公司才能做 PaaS 吗

恰恰相反，“只有做了 PaaS 的公司，才可能成为大公司”。

当然，长期看来，垂直 PaaS 产品的研发成本肯定要高于 SaaS 产品，但在构建初期，其差距并不像想象中那么巨大。目前的大多数 SaaS 产品都应该是前后端分离的了，那么基于这个前提，垂直 PaaS 就可以看作是把某个 SaaS 的后端调用接口开放出来给用户直接使用，以达到灵活的调用、组织和集成这些特性。只是，要把后端接口完全开放，肯定会需要一些额外的设计，以及对业务处理的原子化抽象；因为普通的 SaaS 产品，其后端接口多半是与前端表示逻辑相关的，要开放这些接口，就要把与表示逻辑相关的部分拿掉，这样做的结果有时会产生完全不同的业务处理接口。

所以对于初创公司来说，如果你志在以 SaaS 的方式做企业服务，那么将 SaaS 的后端接口 PaaS 化，就是你应该在最开始就去做的事。这当然会多花费一些成本，但还不至于难以支撑，因为该做的具体功能其实没有多大差别，只需要你有个“会设计 PaaS”的架构师就好了。

这里对垂直 PaaS 和 SaaS 后端设计的区别的描述是概念性的，具体实操时有一些设计原则和技术细节问题需要讨论，但限于文章的篇幅，这里就不再展开了，而且这也已经超出了本文的范畴。

有了 PaaS 化的后端之后，想做一套前端就比较简单了，你甚至可以把前端的开发外包给更有前端经验的公司去做。如果你这么做了，那这个公司就极有可能成为你未来的可选集成商，他的客户就有可能成为你的客户，你的客户也可能成为他的客户；这就是一种共赢的模式。有了 PaaS 化的后端之后，你自己做一套预设好的前端，作为 SaaS 提供给客户直接使用；或者你去帮客户进行集成、给客户定制他们自己的前端也就都是自然而然的可选项了。这也显然是比单纯地提供 SaaS 服务更有竞争力的模式。

对于初创公司而言，你大可采用一些大的公有云厂商的高服务等级、高安全等级的 IaaS 服务（比如 AWS 提供的很多全托管的基础设施服务）去搭建你自己的垂直 PaaS，这对于初创公司而言有很好的灵活性和很高的资金利用率，等到未来有了资金、资源之后再考虑自建相关服务乃至数据中心。

SaaS（垂直 PaaS）是初创公司的机会还是毒药

首先我们来看看两家企业 IT 服务领域最具代表性的垂直 PaaS 厂商的情况。

Salesforce

这个成立于 1999 年的老牌 SaaS 厂商，目前其市值已经超过 1300 亿美元，在企业 IT 服务领域仅次于 Oracle（1700 亿美元） 和 SAP（1400 亿美元），是最大的在线 CRM 厂商。直到现在，它仍然是 SaaS 领域的领导者。

大概从 2003 年左右，Salesforce 就开始构建起生态系统，包括改造后端系统、逐年扩大社区规模。2004 年，Salesforce 在 Nasdaq 上市。2005 年，发布了应用市场 AppExchange，这也被业内称为“商用软件的 eBay”或者“商用软件的 iTunes”。紧跟着在 2006 年，Salesforce 发布了公共开发语言 Apex，允许客户、合作伙伴和开发者使用其创建“企业主导的按需服务”程序。到 2008 年，其 PaaS 产品“Force.com”正式发布，也标志着其生态系统的构建完成。

如果说先入优势是其前 10 年成长壮大的主要因素的话，那么以 PaaS 产品为核心的生态系统，就是其后 10 年飞速发展的坚实基础。

Slack

Slack 是一款团队协作工具和服务平台，于 2013 年 8 月发布了 beta 版本，在其前两年的发展中饱受 bug 和频繁更新的困扰，但其优秀的用户体验、人性化的细节设计也迅速征服了用户。仅仅用了 3 年时间，Slack 就登上了福布斯 Cloud100榜单（还未上市的云计算厂商热度排名）的头名。2017 年，Slack 在 Cloud100 中名列第三（其估值已经超过50亿美元），前两名是 Stripe 和 Dropbox。

Slack 是目前最好的协作和工具集成平台（工具类垂直 PaaS），其主要特性包括：在线沟通（参考 QQ 或 TIM 中的群、讨论组、即时消息、个人状态等等）、内容搜索（Slack 内的所有资源都是可直接搜索的，包括文档、话题、消息历史、用户等等）、流式的集成消息工作区（一种将所有集成工具、服务的内容“流”化而成的信息流工作区，可以集成包括 Google Drive、Dropbox、Github、Jira、Salesforce、Zendesk、Twitter 在内的数百种第三方在线服务，并且可以自定义开发，由其提供的 App Directory 进行发布和管理）。

Slack 的流式消息工作区，其后端实际上是一种定制化的垂直 PaaS，可以与同样提供了 PaaS 接口的第三方 SaaS/垂直 PaaS 进行简单的技术集成，从而在 Slack预设的界面中用统一的形式展示给用户。

垂直 PaaS 是企业 IT 服务的银弹么

我想系统集成、SaaS、垂直 PaaS 依然将是中长期会并存的解决方案，因为它们的实际目标客户并没有太多冲突。而且技术方案从来都不是最重要的因素。

别的公司都做 PaaS 了，我们要不要做？这个问题就像是：别的公司都做微服务了，我们要不要做？别的公司都搞中台了，我们要不要搞？其实所有的架构、技术都是为业务服务的，都是为了解决某些具体问题的，本质上都是组织的演进和变革。如果你都不知道自己的企业/组织有什么问题，不知道瓶颈在哪里，那你怎么改也都是东施效颦，只是多浪费一些钱或者死的更快而已。

所以最重要的，就是搞明白一个产品的业务目标，搞清楚你是想解决什么问题。如果你要推动其他企业的组织形式、管理方式的变革，那你就要考虑自己的产品如何适应那些千奇百怪的定制化需求，就要考虑你能否将复杂的功能需求抽象为可实现的数据模型和控制模型以便能够快速地复制或定制；那么你的产品形态也就自然地应该成为垂直 PaaS。如果你的目标只是去解决某个具体的、与业务无关或低相关的问题，比如沟通、协作、共享、具体工作内容支持等等，那做 SaaS 就够了。

产品形态影响的是内部效率和中长期的成本，你的义务闭环能否成立还是要看商业模式和财务模型。在软件工程或架构设计层面，当然不存在“银弹”这种东西。

初创公司的失败有很多原因，对业务目标定位不清或者频繁摇摆将是直接致命的，因为这将直接影响你的技术决策。虽然软件重构、再设计的成本和可行性远低于实体工程，但对于初创公司而言，依然是难以承受的，除非你有巨额的或者持续的资金支持去不断试错；即便如此，这也是对研发/实操团队和投资人耐心的巨大考验。比如你把 SaaS 产品做成了实施项目的集合、到处是定制化功能、到处 hard code，这在扩展和后期维护上带来的隐形成本必将使你无以为继；客户越多，死的越快。没有产品平台支撑的快速扩张无异于自杀。即使不马上死，也会陷入系统集成商们的窘境，变成软件劳动力输出，难以做大做强。

企业 IT 服务这个市场没有问题，因为大多数企业的信息化、规范化都存在提升的空间和意愿；问题在于初创公司如何选择合适的切入点，如何确定对自己最有利的产品形态。但这个问题的答案就只能靠创业者自己去探索找寻了。

垂直 PaaS 的设计和实现当然不简单，对研发团队人员的要求也是很高的；但这方面的话题已经超出了本文的范畴，未来有机会我们再另行撰文讨论。（来源：倚杖听江声 文/杨镇 编选：网经社）