Understanding Cloud Models for Adoption Strategy

When moving your applications to Cloud is not only a matter of selecting the provider that most fit your needs, but also choosing between the multiple options of available solutions.

Before opening the panel of your preferred cloud provider, register and fill out your credit card to start “paying for what you use” is important to trace and define a solid strategy to move to the cloud.

Part of this strategy consists of creating an assessment of your current environment, understand the motivation and define the goals and achievements expected with the use of the cloud.

Understanding the cloud models and their capabilities is the first step to support your decision and strategy for this movement, as each option offers different models of shared responsibility with the cloud provider.

The cloud services are divided into 3 main “as a Service” categories: IaaS, PaaS and SaaS.

IaaS — Infrastructure as a Service

This model refers to the offering of the infrastructure of hardware to provide a virtualized environment. A very common example of this model is the Virtual Machine (VM).

In this case, the customer is responsible to manage the VM as he would do with a server on-premises. It means that the customer must manage the operating system, software installation, web server, patches, configuration and so on.

Compare this model as leasing a car on a dealer. The car is handled to you with the wheels, engine, seats, commands and everything else. But you are still responsible to make sure that the car is locked when you’re alway, that you keep the keys with you, that you operate according to the manual, refuel, and take it the car shop when maintenance is needed.

This is the easier model for a lift and shift migration because it only requires to virtualize your physical servers or use your current virtual machines if you already use virtualization, and send it to the cloud to work exactly as it does today.

The downside of the lift and shift approach is that you will not make use of a few cloud capabilities and most certainly will have idle resources and paying for that.

For instance, you have a dedicated server for a specific application where it constantly uses 30% of capacity, but on specific period of the month you need to process a huge amount of data on this application for consolidation and the peak of capacity is registered at 90%. So you provide the same server configuration on the cloud, but most of the time you will pay for 70% of capacity without using it.

Instead, you could review your server configuration and optimize it on a small instance and configure it to automatically scale your environment when there is a need for additional capacity.

However, your application must be ready for this type of approach, handling aspects like session persistence and server affinity.

Pricing for this model is usually calculated based on the uptime of the allocated resources. Long term commitment usually offer better deals.

Examples of IaaS are:

• Microsoft Azure: Virtual Machine
• Amazon AWS: EC2 (Elastic Compute Cloud)
• Google GCP: Compute Engine

PaaS — Platform as a Service

This model refers to the offering where the customer, besides the hardware, doesn’t need to care about the platform to run the application. The management of the operating system and any component required to run the application are managed by the cloud provider.

Compare this model as an application to order food from different restaurants. You don’t need to care about getting a car to go to the restaurant to get your food. You might not even need to care about which restaurant you will get your food if you only select your double pepperoni pizza.

The offerings on this model are often referred to as serverless, once you don’t need to have the burden of configuring the server. You only care about the code.

Every cloud provider has its own set of offerings on this model and as there is no standard on the nomenclature, they might have different names but work pretty similar.

For instance, if you want to run a .NET Core application but you don’t want to manage Windows nor Internet Information Services, you can deploy it on a Web App on Azure. The same service is available on AWS, under the name of AWS Serverless Application Model. And the GCP version is App Engine.

On the other hand, if you have a specific and isolated function, to generate a thumbnail from a full-size image, for example, you can use Azure Functions, where you configure what types of trigger and pay per execution. For AWS this functionality can be found under the name Lambda Functions and the same can be found as Cloud Functions on CGP.

Pricing for this model is usually metered per execution.

SaaS — Software as a Service

This model refers to the offering of software that is ready to use where you have a specific subscription and handles only your data and the configuration of the space provided to you.

A license is assigned to every customer and the infrastructure for operating the software is centralized but transparent to the customer.

Compare this model as a building of apartments. When you contract this model, one of the apartments is assigned to you and the whole structure is there to attend all the tenants of this building. However, every tenant only has access to their apartment and you don’t necessarily know your neighbor.

Applications of this type include productivity suites like Office 365, by Microsoft and GSuite, by Google.

Another example is Salesforce that provides a complete web-based CRM solution.

Pricing for this model is usually metered per license, based on the number of users.

Shared Responsibility Model Matrix

It’s not uncommon to hear a classic misconception about running applications on cloud environment:

It’s on the cloud, the cloud provider guarantee that it’s secure.

Well, more or less. Running applications on the cloud involves a shared responsibility model between the customer and the cloud provider.

The following image illustrates the responsibility model matrix, pointing what relies on the cloud provider and what relies on the customer for each of model scenarios:

Note that on every cloud model the cloud provider is fully responsible for physical security. Other factors will depend on the model selected.

What Should I Choose?

Well, I hate to use my default consultant answer, but… It Depends! Several factors impact this decision and no single solution fits all scenarios, quite the opposite.

Once I was on a meetup where the presenter was doing an introduction to Azure Functions. One of the questions from the audience was “Great, so how do I move all the code of my applications to Azure Functions?”. Short answer, you don’t. Simply because this solution does not fit all the scenarios.

The main point is to have options, know the tools and when to apply the specific solution for a specific scenario.

After all, you don’t use a screwdriver when you want to put a nail on the wall.