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."

5.2.2Public / private / hybrid cloud

• Public cloud is where a provider offers a shared infrastructure to an unspecified number of customers. It requires no upfront investment and scales well, but because the infrastructure is shared with other tenants, it can be hard to adopt under strict industry-specific regulations or data-isolation requirements. Private cloud builds and operates infrastructure dedicated to a specific organization, offering more freedom for regulatory compliance and customization, but incurring dedicated capital investment and operational burden. Hybrid cloud combines both, placing, for example, data and processing that regulations require to stay on-premises on the private side and processing that needs scalability on the public side, mixing the two per requirement.

5.2.3Cloud migration strategy: lift and shift vs. re-architecting

• Lift and shift moves an existing system's configuration and architecture largely as-is onto cloud virtual servers (IaaS). Because it requires no application rewrite, it keeps migration time and cost down, but since it carries over the on-premises-era configuration unchanged, it does not fully capture the cloud's scalability or managed-service benefits. It is chosen when the migration deadline is short or the modification budget is limited.
• Re-architecting rebuilds the application's structure on the assumption of the cloud's managed services (PaaS, serverless, managed databases, etc.) and scalable configurations. It maximizes cloud-native benefits such as autoscaling and reduced operational burden from managed services, but requires a commensurate amount of time, cost, and technical validation to modify the application. It is chosen when scalability and operational efficiency matter for the long haul.
• Selecting a migration approach is a matter of weighing "the deadline and budget available for migration" against "the scale of cloud-native benefit desired after migration." In practice, a widely used two-stage migration strategy is also common: complete the migration first via lift and shift, then re-architect the highest-priority components one at a time afterward.

Suppose a system architect is leading a project to migrate an in-house core business system, currently running on-premises, to the cloud. Management set a deadline of "complete the migration within six months," but the system turned out to embed custom-built, specialized middleware integration that did not fit within the runtime constraints of the provider's PaaS offering. At this point, the architect ruled out PaaS and SaaS, since neither allows freely configuring custom middleware, and chose IaaS, where the customer manages everything from the OS up, as the foundation. Next, when considering the migration approach, because of the short six-month deadline and the lack of budget secured for rewriting the application, the architect decided to first complete the migration within the deadline via lift and shift, moving the existing configuration largely as-is onto virtual servers on IaaS. However, because lift and shift alone would leave the on-premises-era lack of scalability intact even after moving to the cloud, the architect presented management with a plan for a phase 2 after the migration completes: re-architecting just the components where access concentration is a known problem (for example, the order-lookup feature) onto a managed-service-based configuration, gradually capturing cloud-native benefits in stages. Additionally, because part of the sensitive customer data this system handles was, under industry regulation, required to be kept in an on-premises-equivalent isolated environment, the architect also decided on a hybrid configuration keeping just that data processing on the private-cloud side, while placing everything else on the public-cloud side. As this shows, weighing multiple constraints together—the responsibility boundary (whether custom middleware can be used), the migration deadline and cost, and the regulatory data-isolation requirement—and designing a staged migration plan rather than a single "correct answer" is the core judgment an architect exercises in cloud migration.

5.2.4Section summary

• IaaS has the customer manage from the OS up, PaaS has the provider manage up through the OS/middleware, and SaaS provides the whole application—each draws the responsibility boundary differently
• A hybrid configuration, keeping data that regulations require to stay on-premises-equivalent on the private cloud side and processing that needs scalability on the public cloud side, is also used in practice
• Lift and shift prioritizes completing migration at low cost/low rework, while re-architecting maximizes cloud-native benefits—the choice depends on requirements, deadline, and budget