Understand cloud abstraction for your IT needs

SaaS: Use the cloud for services

The highest level of abstraction in the cloud is the software-as-a-service (SaaS) model.

In the SaaS model, the cloud provider packages and delivers an established application to the business user. The application is typically hosted in the cloud and managed by a third-party vendor. Users establish accounts with the provider to gain access to the application. The application is accessed across the internet through a web browser and the user is not required to install or maintain anything. The business is charged a recurring monthly fee based on the number of users and application features.

The principle benefits of SaaS are simplicity and convenience. When a business uses SaaS, it eliminates the need to procure, deploy, manage, maintain and support that application in-house. This removes the costs and logistics of hosting and managing the application, which provides significant savings for busy data centers that support many routine applications. Shifting an application from in-house to SaaS sheds infrastructure and frees IT staff to focus on other projects.

Consider the example of basic business email. A traditional business might build, deploy and maintain a Microsoft Exchange server and infrastructure in the local data center. But the business might opt to employ Office 365 SaaS instead and use both Outlook and Exchange hosted by Microsoft. Countless applications are now available as SaaS offerings. Common examples of SaaS include Salesforce, Dropbox, SAP Concur, Zoom and Microsoft Teams.

Although SaaS is an established, affordable means of accessing software products, there are also a variety of issues to consider with this cloud abstraction model:

• Integration and interoperability support. It can be difficult or impossible to fully integrate SaaS and in-house applications, and SaaS vendor integration support is limited or nonexistent.
• Portability restrictions. The data created and hosted by the SaaS application may not be portable to other SaaS offerings or applications. This can create undesirable vendor lock-in.
• Security and compliance scope. Applications that handle sensitive data may need to remain in-house or rely on SaaS vendor SLAs to support security and compliance certifications.
• Availability and downtime control. Such issues can occur due to the lack of control over the software or its delivery -- all of which is handled by the SaaS provider.
• Customization limitations. SaaS feature sets and customizations may present limitations compared to deploying the same application locally.

PaaS: Use the cloud for platforms

A lower level of abstraction in the public cloud is the platform-as-a-service (PaaS) model.

PaaS is like SaaS in many respects. But rather than having a provider host and deliver a single application, an interrelated set of applications and tools are made available that the user can access across the internet through a web browser. Those tools can be shared by a multitude of users and employed to create a complete, fully functional software development environment, hybrid cloud or other environments.

As with SaaS, PaaS tools are typically hosted in the cloud and managed by a third party. This frees the business and local IT staff from the burden of creating and managing the tool framework themselves. Users establish accounts with the PaaS provider, and the business pays a recurring monthly fee similar to the SaaS model. While SaaS holds all created content on the provider's side, PaaS leaves content -- such as developed applications and data -- on the user's side.

For example, when a software development PaaS creates an application, that app remains the property of the users and they can sell, deploy and use it even without the underlying platform, if desired. The most common expression of PaaS is software development frameworks and toolsets such as Google App Engine, Heroku, Microsoft Power Apps, or Salesforce Force.com, as well as orchestration services such as AWS Elastic Beanstalk or Red Hat OpenShift.

PaaS is a useful way to organize and deliver related groups of applications or tools from the cloud, but organizations should consider some of the limitations associated with PaaS offerings:

• Integration limitations. Interoperability is never a problem between tools within a PaaS toolset, but it may be difficult or impossible to integrate the PaaS and other in-house tools, such as adding an in-house testing tool to the PaaS suite.
• Decreased portability. The data created and hosted within the PaaS framework may not be portable to other PaaS offerings by other providers. For example, code, workflows and test data created in one PaaS is probably not portable to a second PaaS. This can create undesirable vendor lock-in and issues when a user needs additional tools the PaaS provider cannot accommodate.
• Development issues. A PaaS may pose development issues, such as relying on less-preferable languages or testing schema that might not support the types of testing required. Users are limited by the capabilities of the platform and its components and can rarely extend the platform beyond its established capabilities.
• Inconsistency. The PaaS may employ operations and management workflows which are different or inconsistent with the workflows used in-house or with other development platforms. This makes some PaaS platforms difficult to use within the normal business operations.

IaaS: Use the cloud for infrastructure

The lowest level of abstraction in the public cloud is the infrastructure-as-a-service (IaaS) model, which works basically as a virtual data center in the cloud.

IaaS hosts applications and data. IT teams use IaaS to assemble a virtual infrastructure of cloud resources and services capable of operating an application and available to employees, business partners and users. The primary benefit of IaaS is convenience that enables businesses to shed costly local data center infrastructure in favor of flexible cloud resources that are available and paid for only as needed.

Infrastructure in the cloud serves the same purpose as infrastructure within a local data center. It offers the underlying resources and services needed to deploy and support an application. With IaaS, businesses have a large degree of control over the resources and services provisioned to the resulting infrastructure. It may be a simple matter of provisioning a virtual machine instance and connecting that instance to a storage bucket in order to run a basic application. 

At the other extreme, users can configure cloud infrastructure to include myriad different compute instances, storage elements, load balancers, database services and more to build a robust and highly available environment for demanding applications.

Every public cloud provider offers a comprehensive array of infrastructure services including AWS, Microsoft Azure and Google Cloud. Other IaaS providers include Rackspace and DigitalOcean.

IaaS is the quintessential use case for the public cloud and has been in constant development for decades. However, several issues and limitations remain:

• Security. While the cloud provider is responsible for the security of the cloud, the user is responsible for security in the cloud. IaaS users must handle security elements such as resource configurations, authentication and authorization.
• Cost. Public cloud infrastructure can include a bewildering array of resources and services -- each involving an assortment of monthly and per-use costs. This can make IaaS deployment costs difficult to predict and control, especially when autoscaling services make unplanned adjustments to resource provisioning.
• Monitoring and management. Provisioning a cloud infrastructure is relatively easy; monitoring and managing that infrastructure to deliver value to the business is challenging. Organizations must monitor resources and services and adjust or eliminate unneeded capacity or instances to limit costs and optimize performance.
• Multi-cloud complexities. The idea of multi-cloud capabilities -- deploying and migrating workloads from one cloud to another -- remains difficult to achieve. Organizations that rely on IaaS often face vendor lock-in and may need to implement different sets of infrastructure resources and services to deploy the same application to different cloud providers.

VMs vs. containers vs. serverless

Within the IaaS model, there are three more layers of abstraction to consider. Each one relies on virtualization, which decouples software from the underlying hardware.

1. Virtual machines (VMs). These are the classic virtual instance, using hypervisors to provision and maintain highly isolated logical instances. Each logical instance acts as an independent, full-featured server and receives its own operating system, drivers and application. VMs are the largest type of virtual instance, and they demand the largest commitment of computing resources, such as processors and memory. VMs are ideal for traditional software intended to run continuously.
2. Containers. Containers use a hypervisor such as Docker or Apache Mesos to create and manage instances on top of a common operating system kernel. Containers are isolated -- except for the common OS -- but can be significantly smaller and more efficient than VMs. Containers are most often used to host application components that can be combined to construct complete and highly scalable applications -- also known as microservices. Containers can be created and destroyed much faster than VMs and are often used for temporary or short-lived instances.
3. Serverless computing. Serverless is offered as a service -- like AWS Lambda -- that runs code only on-demand, through event-driven computing. Users define the code and trigger conditions, then the code is loaded and executed based on those conditions. When trigger conditions are absent, the code and its associated resources do not run. Cloud providers provision and manage the underlying instances on the back end.

Choose the right cloud abstraction level

When choosing between cloud abstraction models, base the decision on the availability of resources and services, as well as the level of control you require.

SaaS

SaaS is often the best choice when a business wants to use an existing application but doesn't want to purchase, install and manage that application in-house. For example, a business may opt to use Zoom as a virtual meeting and collaboration service. The SaaS provider supplies and manages the service. However, a business with concerns about data security, application performance and availability may need to consider SaaS choices carefully before making a commitment.

PaaS

PaaS is a better choice when a specific platform or set of tools needs to support business tasks or initiatives. For example, software developers may use a development PaaS so many different developers can share code, run tests, enforce version control and collaborate on a project. Like SaaS, outside providers manage and maintain PaaS, so developers do not need to install or managed the tools in-house. The users only save and control the work they create, such as a software product. This enhances data security, but availability can still be an issue.

IaaS

IaaS is the ideal choice for organizations that require granular control over a deployment environment.  This is the traditional cloud model where users provision compute, storage, network and other services to create an infrastructure where an enterprise application can be deployed, operated and maintained successfully within the public cloud. A business should use IaaS environments when it needs to host and control its own applications.

Fortunately, these are not mutually exclusive choices. All three levels of abstraction can exist together, and organizations frequently use a mix of SaaS, PaaS and IaaS deployments from one or more providers.