云计算的3种服务模式分别是：IaaS（基础设施即服务）、PaaS（平台即服务）和SaaS（软件即服务）。理解它们时，抓住一个问题：买到服务以后，哪些工作由供应商完成，哪些仍由自己负责。

购买后，是直接使用软件还是部署自己的应用

SaaS交付的是可直接使用的软件。企业开通在线办公或客户管理系统后，主要处理账号权限和业务配置，不必自己部署软件。若产品现有功能无法满足业务流程，能改到什么程度，要看它开放的配置和接口，不能把“云端软件”理解成任意定制。

IaaS提供云服务器等基础资源。用户能自行安装操作系统和应用，控制空间较大，也要承担相应维护工作。服务器租下来后，应用不会自动完成安装、修补和故障恢复。

PaaS处在两者之间：用户部署自己的应用，平台承担一部分运行环境的管理。开发团队少做一些底层维护，但应用要遵守平台支持的运行方式。它支持什么语言、允许怎样访问系统，会直接影响已有程序能否迁入。

报价单里的费用没有覆盖全部维护工作

比较服务时，先写清准备交给供应商的工作。只想使用成熟软件，却按云服务器价格估算预算，后面还会增加软件采购和部署成本；已有自研应用，则要核对PaaS支持的环境，或确认团队能否维护IaaS上的系统。

IaaS的资源单价之外，还有系统维护的人力投入。PaaS将部分工作纳入平台服务，但不会接管所有应用问题：代码错误仍由开发团队处理，平台维护范围也以具体服务约定为准。

使用SaaS同样要管理数据和权限。员工离职后账号由谁关闭、业务数据能否完整导出，仍是采购方要落实的事项。服务模式描述的是交付层次，并不保证某一种方案一定便宜或安全。

旧应用迁移时，平台支持范围会影响部署

假设有这样一种情况：一个团队准备把已有订单系统迁到云上，希望采用PaaS，减少运行环境维护。试部署时，应用因缺少一个系统级组件而无法启动；核对平台文档后，发现平台不允许用户自行安装该组件。

此时，继续增加计算资源无法解决兼容性问题。团队要核对这个组件在程序中承担什么功能，再判断能否替换为平台支持的实现。如果它与旧代码绑定较深，修改后还要验证订单处理结果，迁移工作就会延伸到应用改造。

转向IaaS能够提供自行安装组件的条件，不过团队要接手操作系统维护。选择范围因此落到两项具体工作上：修改应用以适配平台，或保留原有依赖并承担运行环境维护。

在这一假设情境中，团队暂时保留IaaS部署方案，将组件安装方法和系统更新责任写进交接记录；PaaS适配工作没有立即取消，而是留在测试环境中继续验证。这样的安排保留了原有依赖，也保留了后续维护负担，并非所有应用都适用。

下一次迁移测试，团队先确认该组件的替代方案，再检查订单处理结果。正式采购前，把平台支持范围与实际依赖逐项对照，并写清上线后由谁处理系统更新和应用故障。