5.2Cloud service models & migration

A system architect designing cloud adoption must choose a service model only after clarifying the division of responsibility—how much is managed in-house and how much is handed to the cloud provider—and must judge the migration strategy for moving an existing system based on the trade-off among operational burden, customization requirements, and the time and cost available for migration. This section covers both of these judgment axes.

5.2.1The IaaS/PaaS/SaaS responsibility split

• IaaS (Infrastructure as a Service) provides the infrastructure layer—virtual servers, storage, and networking—as a service, while the OS, middleware, and application on top of it are managed by the customer. The provider is responsible for the hardware up through the virtualization layer, while the customer handles OS patching, middleware configuration, and application implementation and operation. It suits cases needing OS-level control similar to an existing on-premises setup.
• PaaS (Platform as a Service) has the provider manage the OS, middleware, and runtime environment, letting the customer focus on application code and data. Because the customer does not need to patch the OS or manage middleware configuration, it significantly reduces operational burden, but configuration is limited to the runtime and framework the provider defines, and fine-grained OS-level control or middleware customization is not possible.
• SaaS (Software as a Service) has the provider deliver a complete application feature set, and the customer is responsible only for configuration and data entry (e.g., cloud-based groupware). Operational burden is minimal, but there is almost no room to implement custom logic tailored to business requirements. The basic division of responsibility is "the provider covers infrastructure through the application, while the customer covers data and user-account management."