Cloud Service Models and Optimization

There are three main cloud service models, IaaS, PaaS and SaaS (Han 2011). Jennings

& Stadler (2015) similarly identify that a public cloud environment typically comprises of the IaaS, PaaS and SaaS service models. Determining the difference between the mod-els depends on the level of abstraction of the offered service (Jennings & Stadler 2015).

In the IaaS service model, the cloud provider manages the underlying physical cloud infrastructure, providing services through virtualization (Han 2011). IaaS provides soft-ware developers access to bare infrastructure for computing, storage and networking (Louridas 2010). Amazon Elastic Compute Cloud (EC2) is an example of an IaaS service (Muhic & Bengtsson 2019).

In the PaaS service model, the cloud provider manages every layer in the service model stack, except the application layer (Han 2011). Software developers are given access to a development platform for designing, building, testing and deploying their own custom applications (Louridas 2010 & Muhic & Bengtsson 2019). Microsoft Azure’s integrated environments (Muhic & Bengtsson 2019) and Microsoft SQL databases as a service are examples of PaaS services (Case Company 2019b).

In the SaaS model, cloud providers manage all the cloud infrastructure including the applications and application logic. This model enables end users to access applications through thin client interfaces i.e. web browsers. (Han 2011, Mell & Grance 2010 & Case Company 2019b) Examples range from standard email and office applications to more complex Enterprise Resource Planning (ERP) systems (Muhic & Bengtsson 2019).

Cloud service models (adapted from Rountree & Castrillo 2014) Consumers must evaluate and understand the complexities of the various service mod-els (Sabharwal & Wali 2013). When planning and designing for migration, Microsoft high-lights the importance of focusing on costs to ensure long-term success (Microsoft Azure 2018). Gartner splits the service models into five separate scenarios (Clayton 2018):

1. Rehost (“lift and shift”) 2. Revise

3. Rearchitect 4. Rebuild 5. Replace

The first and second scenarios, rehost and revise, are typically covered by the IaaS cloud service model. The rehosting (“lift and shift”) scenario entails the migration of virtual ma-chines and data to the cloud IaaS. (Anderson 2018) This scenario avoids alterations to the systems. However, certain modifications are required to adapt to the new hosting environment. This scenario does not support cloud-native features. The revise scenario on the other hand, enables consumers to modify applications so that they can begin to utilize the advantages of cloud capabilities. These include elasticity, minimized resource usage and minimized operational overhead, by capitalizing on managed cloud services, such as database PaaS. In other words, consumers are given the option of optimizing the infrastructure and backing services of the application. This entails making minor changes to the code or leaving the code untouched, while reconfiguring the application, system and application dependencies. (Clayton 2018) Overall, this migration scenario does not yield major cost savings but is a fairly simple form of migration. Optimization is possible and goes hand in hand with resource usage and elasticity. (Anderson 2018)

The case company also suggests optimization activities specific to the IaaS service model (Case Company 2019b):

• Development phase optimization: Rightsizing capacity, autoscaling as a design and automating on-off capabilities for applications that do not require 24/7 uptime.

• Run/ production phase optimization: Monitoring capacity, reacting to and plan-ning possible changes in capacity usage and opting for reserved instances when feasible.

The third and fourth scenarios, rearchitect and rebuild, belong under the PaaS cloud service model. The PaaS scenario entails migrating the application to the cloud middle-ware. (Anderson 2018) If artifacts of the application can be reused, the application is under constant rapid change, the application is either flexible or inflexible portability wise between cloud providers and there is time and an abundance of resources to rearchitect the application, then rearchitecting should be considered. However, if application porta-bility to a cloud platform is considered difficult, existing artifacts cannot be reused, the application cannot be virtualized, there is no pressure time wise to get the application to the market, and resources and time are available to rebuild the application, then rebuild-ing the application may be the best option. (Clayton 2018) The potential cost savrebuild-ings of the PaaS migration scenario are high however, having the ability to implement cloud as a native application capability and leveraging the PaaS components is categorized as a difficult task. Optimization is possible by exploiting the elasticity features of PaaS deploy-ments in cloud. (Anderson 2018) The case company identifies optimization possibilities for PaaS applications (Case Company 2019b):

• Development phase optimization: Designing the solution to scale, eliminating any extra and unnecessary capacity.

• Run/ production phase optimization: Data lifecycle management, identifying and removing orphaned resources and considering commitment possibilities.

The final scenario, replace, covers SaaS cloud service models. This scenario entails replacing a traditional application with a SaaS application. Replacing includes migrating all the users and data to the cloud and shutting down the application from an on-premise environment. (Anderson 2018) If a SaaS offering is available, and there is a possibility in investing in the SaaS option, then replacing should be considered (Clayton 2018). The cost savings potential of SaaS models falls somewhere in between the potential savings of IaaS and PaaS service models (Anderson 2018). The difficulty of a SaaS deployment is low. Optimization possibilities include users, entitlements (Anderson 2018) and data

(Case Company 2019b). The case company also suggest possible optimization activities for SaaS service models (Case Company 2019b):

• Development phase optimization: Sourcing and contracts with optimization re-quirements.

• Run/ production phase optimization: Optimizing users and usage.

Cost savings potential & difficulty of cloud service models (adapted from Case Company 2019b & Clayton 2018)

In the case company, new IT solutions must primarily be considered as cloud-based solutions. Reasons for this include the fact that cloud solutions embody characteristics including fast deployment, evergreen models and scalable capacity and pricing. (Case Company 2019b) The case company (2019b) has a clear prioritization scheme regarding the different cloud service models:

1. The SaaS model must be considered first, as it yields best practice business pro-cesses outside of the core service. This service model may be used i.e. to fulfill a business process within an organization.

2. The PaaS model is suggested as a second choice. This service model enables rapid deployments with the possibility of digital differentiation.

3. Ultimately the IaaS service model should be considered. The IaaS service model enables users to gain elastic computing capacity.

Furthermore, Microsoft highlights that over time a migrated resource may shift to another type of workload. Reasons for this shift include changing business requirements, costs and usage. (Microsoft Azure 2018)