PaaS（Platform as a Service，平台即服务）位于 IaaS 与应用之间，向开发团队提供应用开发、部署、运行和运维所需的平台能力。开发者通常不需要直接管理服务器、操作系统、容器集群等底层基础设施，而是通过平台完成应用交付。
PaaS 的核心是应用运行环境和基础设施管理，解决的是“应用怎么稳定运行、持续交付和弹性扩展”的问题，通常提供：
- 应用部署；
- Runtime；
- CI/CD；
- 服务发现；
- 配置管理；
- 日志；
- 监控；
- 自动扩缩容；
- 网络；
- 资源管理。
需要注意的是，今天的 PaaS 已经不是单一产品形态。传统 PaaS 以 Heroku 为代表；企业级 PaaS 则逐渐与 Kubernetes、容器、微服务、DevOps 和云原生平台融合。
一、国际主流商业 PaaS
1. Heroku
Heroku 是最具代表性的传统 PaaS 之一，也是现代 PaaS 产品形态的重要奠基者。
它的核心理念非常简单：
开发者负责代码，平台负责运行环境。
开发者可以通过 Git 将代码提交到 Heroku，平台自动完成构建、部署、运行和扩缩容。
主要能力包括：
- 应用部署；
- Runtime；
- Buildpack；
- 自动扩缩容；
- 日志；
- 配置管理；
- 数据库和其他托管服务；
- CI/CD 集成。
Heroku 的优势是开发体验非常简单，特别适合 Web 应用、SaaS 和 API 服务。
定位：经典的开发者 PaaS。
2. AWS Elastic Beanstalk
Elastic Beanstalk 是 AWS 提供的应用 PaaS。
它将应用部署进一步抽象化。开发者提交应用后，平台负责创建和管理底层 AWS 资源，例如：
- EC2；
- Elastic Load Balancing；
- Auto Scaling；
- CloudWatch；
- 网络配置。
因此它实际上是：
PaaS 层抽象 + AWS 基础设施。
相比 Heroku，Elastic Beanstalk 给开发者保留了更多 AWS 基础设施控制能力。
定位：AWS 生态中的传统应用 PaaS。
3. Azure App Service
Azure App Service 是 Microsoft Azure 的托管应用平台。
主要用于：
- Web Application；
- REST API；
- 后端服务；
- 企业 Web 应用。
平台负责服务器、操作系统、TLS、部署、扩缩容和监控等基础设施工作。
它尤其适合 .NET、Java、Node.js、Python 等企业应用。
定位：Azure 上的托管应用 PaaS。
4. Google App Engine
Google App Engine 是 Google Cloud 的经典 PaaS 产品。
它强调：
- 自动部署；
- 自动扩缩容；
- 高可用；
- 无需管理服务器；
- 与 Google Cloud 服务深度集成。
开发者主要关注应用代码和运行配置，底层基础设施由 Google Cloud 管理。
定位：高度托管的应用 PaaS。
二、国际企业级 PaaS
5. Red Hat OpenShift
OpenShift 广泛用于大型企业、金融机构、运营商和政府等场景，是目前企业级 PaaS 中非常重要的一类产品。
定位：企业级 Kubernetes PaaS。
它以 Kubernetes 为基础，在其上增加完整的企业应用平台能力：
- 容器管理；
- Kubernetes；
- CI/CD；
- 镜像管理；
- Operator；
- 服务治理；
- 网络；
- 存储；
- 日志；
- 监控；
- 身份与权限；
- 多集群管理；
- 混合云管理。
6. Cloud Foundry
Cloud Foundry 是经典的开源企业 PaaS。
它的设计理念与 Kubernetes 有明显区别。
Kubernetes 更强调：如何管理容器和基础设施。
Cloud Foundry 更强调：开发者如何快速部署和运行应用。
典型操作非常简单：
cf push
之后平台负责应用构建、部署、路由、服务绑定、扩缩容等工作。
Cloud Foundry 曾经是企业 PaaS 的重要技术路线，对后来很多内部开发平台都有影响。
定位：经典企业应用 PaaS。
三、中国主流商业 PaaS
中国市场的 PaaS 与国外传统 PaaS 有明显区别。
国内大型云厂商的 PaaS 通常已经与：
- Kubernetes；
- 微服务；
- 中间件；
- DevOps；
- 数据库；
- 大数据；
- AI；
- 私有云；
- 混合云
深度结合。
因此国产 PaaS 通常比传统 Heroku 类型的平台覆盖范围更大。
7. 阿里云 EDAS
EDAS（Enterprise Distributed Application Service）是阿里云比较典型的应用 PaaS。
主要面向企业应用和微服务，提供：
- 应用部署；
- 应用托管；
- 微服务治理；
- 服务注册与发现；
- 配置管理；
- 应用监控；
- 弹性伸缩；
- DevOps；
- 云服务集成。
EDAS 特别适合 Java / Spring 体系以及微服务应用。
定位：企业应用与微服务 PaaS。
8. 华为云 ServiceStage
ServiceStage 是华为云的应用托管与微服务平台。
主要提供：
- 应用部署；
- 容器化运行；
- 微服务；
- 服务治理；
- 应用生命周期管理；
- 配置管理；
- 监控；
- 自动扩缩容。
它能够连接华为云的基础设施和各种云服务。
定位：企业级应用与云原生 PaaS。
9. 腾讯云 TCS
TCS（Tencent Cloud Native Suite）更加偏向企业级云原生平台。
它的核心基础是 Kubernetes，并进一步提供：
- 容器平台；
- 微服务；
- 中间件；
- DevOps；
- 应用管理；
- 运维管理；
- 多集群；
- 混合云；
- 私有化部署。
与传统云 PaaS 相比，TCS 更强调企业内部建设自己的云原生应用平台。
定位：企业级云原生 PaaS。
10. 腾讯云 TSF
TSF（Tencent Service Framework）更加聚焦微服务。
主要提供：
- 服务注册与发现；
- 配置管理；
- 服务治理；
- 应用部署；
- 服务监控；
- 弹性伸缩；
- 应用生命周期管理。
如果说 TCS 是比较完整的云原生 PaaS，那么 TSF 更接近：
微服务 PaaS。
11. 灵雀云 ACP
灵雀云是国内较早专注 Kubernetes 和云原生平台的厂商之一。
ACP（Alauda Container Platform）以 Kubernetes 为核心，为企业提供：
- 容器平台；
- Kubernetes；
- DevOps；
- 微服务；
- 应用管理；
- 多集群管理；
- 混合云；
- 企业级运维。
它比较典型地体现了国产 PaaS 从传统应用平台向云原生 PaaS演进的路线。
定位：企业级云原生 PaaS。
四、国产开源 PaaS
12. KubeSphere
KubeSphere 是国内最有代表性的开源云原生 PaaS 之一。
它建立在 Kubernetes 之上，在 Kubernetes 基础设施之上进一步提供：
- 多租户；
- 多集群；
- DevOps；
- 应用生命周期管理；
- 日志；
- 监控；
- 网络；
- 存储；
- 应用商店；
- 企业权限管理。
因此它不是 Kubernetes 的简单 Web UI，而是试图构建一个完整的：
Kubernetes + 企业应用平台。
如果希望在企业内部自建 PaaS，KubeSphere 是非常值得研究的项目。
定位：开源 Kubernetes PaaS。
五、轻量级开源 / 自托管 PaaS
这一类产品与 OpenShift、KubeSphere 的定位不同。
它们的目标不是构建大型企业云平台，而是把一台或几台服务器快速变成自己的应用平台。
13. Coolify
Coolify 是近年来比较受关注的开源自托管 PaaS。
它可以部署在自己的 VPS 或服务器上，并通过 Web UI 管理：
- Git 项目；
- Docker；
- Docker Compose；
- Web 应用；
- API；
- 数据库；
- HTTPS；
- 自动部署；
- 多服务器。
它可以看作：
自托管版的 Vercel / Heroku / Railway。
对于个人开发者和小型团队非常实用。
定位：现代开发者自托管 PaaS。
14. CapRover
CapRover 是基于 Docker 的开源 PaaS，它提供：
- Web UI；
- CLI；
- Docker 应用部署；
- 自动 HTTPS；
- 应用管理；
- 数据库部署；
- 一键应用。
它的理念比较接近简单的自托管 Heroku，相比 OpenShift/KubeSphere，它的架构明显更轻量。
定位：轻量级 Docker PaaS。
15. Dokku
Dokku 是一个非常轻量的开源 PaaS，也是 Heroku 的开源替代方案之一。
最典型的使用方式就是：
git push dokku main
之后 Dokku 自动完成构建和部署。
它适合：
- 个人服务器；
- 小型项目；
- 内部工具；
- 简单 SaaS；
- 开发测试环境。
定位：极简 Heroku-like PaaS。
六、如何看待这些 PaaS
如果把这些产品放到一张架构图里，会比较清楚：
PaaS
│
┌─────────────┼─────────────┐
│ │ │
传统应用 PaaS 企业云原生 PaaS 自托管 PaaS
│ │ │
Heroku OpenShift Coolify
Beanstalk KubeSphere CapRover
App Service TCS Dokku
App Engine ACP
│ EDAS
│ ServiceStage
│
└──────────────┬──────────────┘
│
Kubernetes
│
IaaS
VM / Network / Storage
其中存在一个非常明显的行业趋势：
传统 PaaS → 容器化 PaaS → Kubernetes PaaS → 云原生应用平台。
早期 PaaS 的核心是：“我帮你运行应用。”
现代企业 PaaS 的核心则逐渐变成：“我给研发团队提供一套完整的应用交付和运行平台。”
所以今天谈 PaaS，实际上不能只用 Heroku 这种传统模型理解。OpenShift、KubeSphere、TCS、EDAS、ServiceStage 这类产品，已经把 Kubernetes、微服务、DevOps、可观测性、服务治理、多集群和企业安全能力纳入 PaaS 的范畴。
最值得关注的代表产品
如果只选 8 个代表整个 PaaS 生态，我会选：
- Heroku —— 经典 PaaS 的代表；
- AWS Elastic Beanstalk —— 公有云应用 PaaS；
- Red Hat OpenShift —— 企业级 Kubernetes PaaS；
- Cloud Foundry —— 经典开源企业 PaaS；
- 阿里云 EDAS —— 国产应用/微服务 PaaS；
- 华为云 ServiceStage —— 国产企业应用 PaaS；
- KubeSphere —— 国产开源 Kubernetes PaaS；
- Coolify —— 新一代轻量级自托管 PaaS。
这 8 个基本可以覆盖从传统 PaaS → 公有云 PaaS → 企业级 PaaS → Kubernetes PaaS → 开源 PaaS → 自托管 PaaS的主要技术路线。
PaaS 这块没有像 K8s 那样“唯一事实标准”。原因是 PaaS 本身不是一个清晰的技术层，而是一类“把开发到运行的事替你管一部分”的产品形态，所以标准是被拆散在几个子问题里的。
一、经典开源 PaaS：Cloud Foundry 最接近，但已不是当下主流
- Cloud Foundry：曾经是最像“PaaS 标准”的开源项目，
cf push、Service Broker、多租户、应用生命周期管理都很完整，SAP/VMware/IBM 都推过。 - 但 K8s 起来之后，Cloud Foundry 自己也转向 Korifi / Eirini，把应用跑成 K8s Pod。
→ 所以今天再说“Cloud Foundry = PaaS 的 OpenStack”，已经不太准了。
Eirini 是 Cloud Foundry 的调度适配层——开发者照常 cf push，但应用实例不再由 Diego 调度，而是跑成 K8s Pod，属于"换底座"。
Korifi 更彻底，用 K8s CRD 原生重写了 Cloud Foundry 的核心概念（App/Org/Space/Route），Paketo Buildpacks 构建镜像，Envoy 做路由，整套体验跑在标准 K8s 集群上，属于"改架构"。
一句话：Eirini = CF 跑在 K8s 上；Korifi = K8s 原生地提供 CF 体验。Eirini 偏过渡兼容，Korifi 是 CF 在 K8s 时代的主线方向。
Eirini、Korifi 都是 Cloud Foundry 社区项目，核心由 Broadcom/VMware、SAP、IBM 等成员推动，不是单一公司独占。
老架构（BOSH + Diego 的 Classic CF）仍有维护，但重心已转 Korifi/cf-for-k8s；Classic CF 趋于长期稳定维护、不再作为未来主线。
二、现代 PaaS 的实际底座：Kubernetes + 一堆上层抽象
现在企业里“自建 PaaS”几乎都是：
Kubernetes + CI/CD + 镜像构建 + 路由/网关 + 自动扩缩 + 平台工程层
也就是说：
- K8s 不是 PaaS，但是当代 PaaS 的底层事实标准
- 真正的 PaaS 体验由这些拼出来：
- OpenShift（Red Hat）
- Rancher + 自建平台
- Knative（serverless / scale-to-zero / 事件驱动）
- Cloud Native Buildpacks（源码 → OCI 镜像）
- Crossplane / Kratix（平台工程、自助服务）
- Backstage（开发者门户）
三、托管 PaaS 的产品范式：Heroku 是“体验标杆”
- Heroku：
git push就部署，定义了现代 PaaS 的开发者体验 - 后来者：Render、Fly.io、Railway、Vercel、Netlify、AWS Elastic Beanstalk、GCP App Engine、Azure App Service
- 但它们互相不互通，每个都有自己的 CLI / addon / routing / build 机制
→ 所以有“产品范式标准”，没有“跨云开源标准”
四、PaaS 里真正沉淀成标准的是“零件”，不是“整个平台”
更严谨的说法是：
| 能力 | 事实标准 / 趋近标准 |
|---|---|
| 编排 | Kubernetes |
| 镜像格式 | OCI Image |
| 源码构建 | Cloud Native Buildpacks（CNCF graduated） |
| 事件 | CloudEvents |
| Serverless 层 | Knative（CNCF graduated） |
| 身份认证 | OIDC / OAuth2 |
| Git 交付 | GitOps（Argo CD / Flux） |
| 平台工程 | Internal Developer Platform（Backstage 等） |
所以 PaaS 层的标准是“K8s 生态规范集”，不是单个项目。
五、和你前两轮对齐一下
- IaaS/虚拟化：OpenStack（开源侧事实标准）
- 容器编排：Kubernetes（无争议）
- FaaS/serverless：Knative（开源侧）+ Lambda（产品范式）
- PaaS：没有单项目事实标准；
- 经典：Cloud Foundry
- 现代：K8s 上的平台层（OpenShift / Knative / Buildpacks / 平台工程）
- 体验标杆：Heroku
一句人话版：
PaaS 不像 OpenStack/K8s 那样“一个项目吃掉一层”，而是 Heroku 定体验、K8s 定底座、CNCF 把零件标准化。
要不要我帮你画一张“IaaS / CaaS / PaaS / FaaS / 平台工程”的层级图，标出每层谁是关键项目、谁是规范、谁是产品？
