Skip to ContentGo to accessibility pageKeyboard shortcuts menu
OpenStax Logo
Introduction to Computer Science

12.2 Cloud-Based and Cloud-Native Applications Deployment Technologies

Introduction to Computer Science12.2 Cloud-Based and Cloud-Native Applications Deployment Technologies

Learning Objectives

By the end of this section, you will be able to:

  • Understand cloud deployment technology
  • Relate to cloud deployment technology options
  • Explain cloud deployment technology use cases and implementation
  • Select cloud deployment technologies
  • Relate to the future of cloud deployment technologies

Various cloud technologies may be used to deploy cloud-based and cloud-native applications. These technologies differ in their implementation and use. While these technologies span storage, network, and compute services, the emphasis will be on compute options. There are many deployment options available, and there is no right or wrong choice. Only a subset of these options is applicable to the deployment of cloud-native applications. However, all options will be covered because enterprise solutions are typically hybrid solutions that may combine on-premises, cloud-based, and cloud-native components. Many organizations will need to implement more than one option. Accordingly, selecting the best option to support workloads while controlling complexity can be a daunting task.

Introduction to Cloud Deployment Technology

The delivery of computing services, such as databases, software, analytics, and storage over the Internet is called cloud computing. The cloud computing model is composed of three service models—Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS)—and four deployment models—private cloud, community cloud, public cloud, and hybrid cloud. Figure 12.20 describes the relationship between cloud deployment models, service models, and cloud deployment technologies.

A diagram shows the following flow: Cloud computing with arrows to both of the following Deployment Models and Service Models. There is then a line from these to Cloud Deployment Technologies.
Figure 12.20 Cloud deployment models, cloud service models, and cloud deployment technologies are all considered for workload and service deployments. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

When examining workload and service deployments, there are three key architectural considerations. First, the deployment models in the cloud are evaluated, offering choices for where service models are deployed, such as public, hybrid, community, or private cloud environments. Second, the service model options are assessed to determine the level and type of services, including Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). Each of these cloud service models will be discussed in more detail. Finally, workloads and services are actualized in the cloud using various deployment technologies, ranging from bare metal (i.e., high-performance physical servers dedicated to a single customer where the burden of provisioning, maintaining, or scaling applications on these servers falls on the customer) to serverless computing (i.e., where customers deploy applications without the burden of provisioning, maintaining, or scaling these applications as they are provided by the cloud service provider). These technologies serve as the foundation for executing cloud-based and cloud-native applications, allowing organizations to harness the benefits of cloud computing. Understanding these options empowers companies to select the most suitable approach, ensuring performance, deployment speed, scalability, portability, and security align with business requirements while managing costs effectively. Enterprises must consider different factors when deploying various workloads and services in a cloud environment. For instance, high-performance computing (HPC) demands significant compute and memory resources, whereas legacy applications may have lower resource requirements.

Cloud Service Models

The three cloud service models—IaaS, PaaS, and SaaS—define a combination of information technology resources (e.g., compute servers, storage, memory, middleware) offered by a cloud provider and are not mutually exclusive. These service models change the way information technology (IT) resources are consumed. Traditionally, IT resources were purchased, managed, and maintained in a company’s on-premises data center. The cloud computing service models, in contrast, provide a more economical solution where these IT resources are accessed and scaled on-demand from a cloud service provider at a predictable cost. These service models are categorized as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The following sections elaborate on these three cloud service models.

Infrastructure as a Service (IaaS)

Infrastructure as a Service (IaaS) is on-demand access to a cloud-hosted computing infrastructure that includes servers, storage, and network resources. These resources can be provisioned, configured, and used by the customer like on-premises resources are. The difference is the cloud service provider hosts, manages, and maintains these resources in its own data centers, as shown in Figure 12.21.

A diagram shown as a table includes On-Premise: Software Platform Infrastructure and IaaS: Software Platform Infrastructure. There is an arrow going down the left side of the column that reads Customer manages; and an arrow going up the right side of the table that reads Cloud service provider manages.
Figure 12.21 IaaS resources are managed by a cloud provider compared to on-premises resources that are managed by the customer. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

IaaS customers access these resources via the Internet and pay for these services on a subscription or pay-as-you-go basis. Infrastructure consists of three main components: compute for processing tasks, storage, and network. The compute component could, for example, include a general-purpose processing capability or more specific processing capabilities such as a high-speed graphics processor (GPU) or high-performance computing (HPC). The storage component could support different storage needs such as object storage, block storage, or file storage. Finally, the network component allows for the compute and storage components to communicate.

IaaS resources are multitenant and are made available to multiple different customers simultaneously. The cost for the services varies depending on the technologies chosen. IaaS customers make use of these services on-demand where the demanded resources are provisioned and delivered to the customer in a matter of minutes or hours as opposed to days, weeks, or months as is with traditional IT on-premises resources. IaaS also provides the flexibility for customers to scale up or down resources depending on their needs.

Platform as a Service (PaaS)

As discussed previously, IaaS is a set of compute, storage, and networking resources that have been virtualized by a cloud service provider and configured by the customer to suit their needs. PaaS takes advantage of all the virtualized resources from IaaS and adds to this. Platform as a Service (PaaS) is on-demand access to a cloud-hosted platform for developing, running, and managing applications by prepackaging middleware, language runtimes, and tools as containers. The cloud service provider hosts, manages, and maintains all the software included in the platform. This includes the servers, storage, and networking services. It also includes the operating system, middleware, and runtime environment. Figure 12.22 illustrates how PaaS customers can deploy their application and data.

A diagram shown as a table includes On-Premise: Software Platform Infrastructure and PaaS: Software Platform Infrastructure. There is an arrow going down the left side of the column that reads Customer manages; and an arrow going up the right side of the table that reads Cloud service provider manages.
Figure 12.22 PaaS resources are managed by a cloud provider compared to on-premises resources that are managed by the customer. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

PaaS generally makes it easy to get an application up and running quickly. PaaS is cost effective in that customers don’t have to bear the cost to manage the runtime environment for their applications. PaaS cloud providers generally provide tools such as DevOps and collaboration tools, as well as API marketplaces as services that could easily be integrated with applications. PaaS also provides the flexibility for customers to scale resources up or down depending on their needs.

Software as a Service (SaaS)

Software as a Service (SaaS) is a cloud-hosted, ready-to-use software or application that end users access with a client (e.g., web browser, desktop client, mobile app) via a subscription model. SaaS takes advantage of all the resources from PaaS, but also includes the application and data, as shown in Figure 12.23.

A diagram shown as a table includes On-Premise: Software Platform Infrastructure and SaaS: Software Platform Infrastructure. There is an arrow going down the left side of the column that reads Customer manages; and an arrow going up the right side of the table that reads Cloud service provider manages.
Figure 12.23 SaaS resources are managed by a cloud provider, like PaaS resources, but they are subscription based and include application and data. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Unlike IaaS and PaaS, SaaS has the highest level of abstraction where the cloud service provider hosts, manages, and maintains all layers of the stack, including the application as well as all the infrastructure required to provide the application service. This allows for the SaaS application to always be upgraded to the latest version. SaaS applications are scalable at any level of the stack. Additional infrastructure resources such as compute power and platform resources, such as databases, can be added as needed.

SaaS resources are also multitenant where multiple users are all accessing the same pool of resources. Tenants would have access to the same hosted environment; however, they would have their own dedicated space to securely store their data. SaaS applications are cost effective compared to the other cloud service models because the cloud service provider maintains and manages the entire stack. SaaS applications are also cost effective compared to traditional applications hosted on-premises where companies would have to bear the cost of the hardware in addition to continued cost for IT support.

One important benefit of cloud computing is automation. Depending on the service model chosen, organizations can reduce the layers of management of hardware, infrastructure, and applications. This reduces costs and effort of investment into these resources and allows organizations to focus more on innovation. For an organization to choose between the cloud service models and on-premises solutions, it must balance the level of complexity and effort of investment in each solution. These solutions present a spectrum from complex and high effort of investment to simple and low effort of investment, as shown in Figure 12.24.

A diagram shows a comparison of On-Premise, Iaas, Paas, Saas as a table with rows for each of these.
Figure 12.24 Complexity and level of investment effort decrease as level of abstraction from customer increases depending on the solution chosen. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

On-premises and IaaS solutions offer the greatest level of flexibility but are the most complex and require more effort of investment. These solutions also increase costs as they require the hiring of systems personnel as these solutions require a higher level of knowledge and management of infrastructure resources. Moving from left to right, PaaS solutions are less complex with less effort of investment and are generally managed by application developers. Finally, SaaS is the least flexible, but also the least complex, and requires the least effort of investment. SaaS solutions are applications or software that don’t require any installation or manual upgrading, and so the end user can be anyone. Many organizations use a combination of these solutions with the flexibility to change the service models used as their needs change.

Cloud Deployment Models

Cloud deployment models dictate how cloud services are implemented, hosted, and accessed by end users. They revolve around the principle of virtualizing server computing power into segmented, software-driven applications offering processing, storage, and networking capabilities. The following sections elaborate on various cloud deployment models, including private, community, public, and hybrid clouds.

Public Cloud Model

A public cloud is a cloud deployment model where resources are remotely accessible by anyone offered through subscriptions or on-demand pricing plans. A public cloud deployment model is shown in Figure 12.25. This approach allows for the flexibility of provisioning resources on-demand and pay only for what is consumed. Public cloud resources are owned and managed by the cloud service provider. This type of cloud hosting allows cloud service providers to provide various services to a variety of customers. A cloud service provider’s resources are provisioned for any type of customer from individual users to major industry groups.

A diagram shows PCs with lines connecting it to a Cloud service provider and lines to other computers and buildings.
Figure 12.25 A public cloud deployment model consists of resources accessible to all users. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Private Cloud Model

A private cloud is a cloud deployment model where resources are dedicated to one customer such as a single organization for internal use where cloud resources are accessed and managed by an organization. A private cloud deployment model is shown in Figure 12.26. It is not open to the public. Private clouds are isolated and contain the proper security to restrict access to them. They are protected with robust firewalls and a supervised secure environment. Private clouds could run on-premises but can also run on vendor-owned data centers remotely. Private cloud resources are managed either internally by the organization or by a third party. Figure 12.26 shows two private clouds. A cloud service provider’s secured resources are provisioned and dedicated to an organization.

A diagram shows a Cloud service provider including various types of clouds with lines from Private clouds to Dedicated private cloud to organization 1 and Dedicated private cloud to organization 2.
Figure 12.26 A private cloud deployment model consists of dedicated resources with restricted access. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Community Cloud Model

A community cloud is a cloud deployment model where resources are only accessible by a selected group of organizations. The resources of a community cloud are mutually shared between the organizations that belong to a particular community or industry. Examples of community clouds are clouds for banks or governments. The community or industry members generally share similar privacy, performance, and security concerns. A community cloud consists of an infrastructure that integrates the services of different clouds to meet the specific needs of the community or industry. Community cloud resources are managed either by members of the community or industry or by a third party. Figure 12.27 outlines a community cloud deployment model and shows two community clouds. A cloud service provider’s resources are provisioned and dedicated to a community of organizations or government entities.

A diagram shows a Cloud service provider with lines from Community clouds to Dedicated to a group of government members and other lines to Dedicated to a group of organizations.
Figure 12.27 A community cloud deployment model consists of dedicated resources limiting access to a community. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Hybrid Cloud Model

A hybrid cloud is a distributed computing architecture with two or more environments consisting of private and public clouds and on-premises infrastructure. A hybrid cloud deployment model is shown in Figure 12.28. This model provides greater flexibility compared to other cloud deployment models because it provides orchestration and management across all environments that lets customers run workloads wherever they need them increasing workload portability across all cloud environments.

A diagram shows PCs with lines to Cloud service provider. There is another cloud also labeled Cloud service provider. These are connected with a superimposed box labeled Hybrid cloud. Two dedicated private clouds are shown connected to these clouds.
Figure 12.28 A hybrid cloud deployment model combines two or more cloud deployment models. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Cloud Deployment Technology Options

Cloud deployment technologies offered by cloud service providers include bare metal servers, virtual machines (VMs), and containers. The following sections elaborate on each of these deployment technologies. Another deployment technology that is available, however not widely used, are unikernels. Unikernels are also discussed in detail in the following sections. IaaS and PaaS are two service models through which these deployment technologies are provided. There are additional service models through which deployment technologies are provided: Containers as a Service (CaaS) (i.e., a version of IaaS where applications are deployed, managed, and scaled using a container-based virtualization); and serverless computing, also known as Function as a Service (FaaS). Figure 12.29 shows how PaaS and FaaS may leverage CaaS or IaaS for deployment. CaaS is positioned between IaaS and PaaS in the cloud computing stack. CaaS leverages the virtualization of compute, storage, and network resources from the underlying IaaS infrastructure. PaaS allows users to focus on application dependencies and runtime environments while having less control of the operating system and limited portability. CaaS, on the other hand, returns this control as it provides increased portability by facilitating operating system virtualization and customization in containerized deployments.

A diagram shows the following flow: Function as a Service, Platform as a Service – Container as a Service – Infrastructure as a Service.
Figure 12.29 Cloud deployment technology options are available when IaaS is leveraged by other service models, including FaaS, PaaS, and CaaS. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

IaaS Deployment Options

Bare metal servers, VMs, unikernels, and containers are made available in an IaaS cloud service model. These deployment options offer a level of infrastructure control to address specific performance requirements, compliance considerations, and legacy dependencies. Bare metal servers offer the most control and flexibility but with more overhead to maintain them. Moving from bare metal toward containers, the deployment options require less overhead because there is an increased level of automation that makes these options quicker and easier to provision or get up and running. They are also more portable. These four deployment options, in order of more control versus more portability, are illustrated in Figure 12.30.

A diagram with four cells is shown. The labels of these cells are Bare metal, Virtual machines, Unikernels, Containers. Two arrows are below these cells. Under Bare metal and Virtual machines the arrow points left and reads Increase control. Under Unikernels and Containers is an arrow pointed right which reads Increase portability.
Figure 12.30 IaaS deployment options offer either more control or provide more portability. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Bare Metal Server

A bare metal server is a high-performance cloud server that is composed of a single-tenant, nonvirtualized physical server. Customers have complete control over the server’s physical components of hardware, compute, and storage resources to optimize them to accommodate specific workloads. These servers may run any amount of work for the customer, or may have multiple simultaneous users, but they are dedicated entirely to the customer.

Virtual Machines

A virtual machine (VM) is a virtualization of a computer system. The process of creating software-based “virtual” versions of something such as compute, storage, networking, or applications is called virtualization. Virtualization is feasible because of a hypervisor, the software that runs on top of a physical server or a compute host that virtualizes it.

Hypervisors virtualize the resources, such as CPUs, RAM, network, and, in some cases, storage, of the physical server. The hypervisor divides these resources while allocating what is needed for each operating system of a virtual server instance (VSI). The hypervisor, also referred to as a virtual machine monitor (VMM), is a software layer that lies between the physical hardware and the VSIs that run on top of it. The hypervisor allows for the scheduling of multiple VSIs with these divided resources. Thus, multiple virtual servers can run on a single physical server. Hypervisors also provide a level of security between VSIs so that data on one VSI is not accessible from another, maintaining isolation between them, as indicated by the dotted lines between the VSIs in Figure 12.31.

A diagram shows the following flow: VSI1 (OS1), VIS2 (OS2), VIS3 (OS3) – Hypervisor – CPU, RAM, Net, Store.
Figure 12.31 Virtualization of compute resources via hypervisors is used to schedule VSIs. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Virtualization via hypervisors makes multitenancy of VSIs possible. This drives the cost of compute down. Physical servers individually can be quite costly. Virtualization is a cost-effective way to run multiple virtual servers on a single physical computer, thereby maximizing the utilization of resources and reducing cost.

As shown in Figure 12.32, VMs run like a physical server that runs on a hypervisor. They can run their own different operating systems and are completely independent of one another. Running multiple VMs from one physical server also drastically reduces a customer’s physical infrastructure footprint. VMs increase agility and speed because they can be provisioned quickly and easier, with automation, compared to provisioning an entire new physical server and environment. This also lowers downtime in case a VM unexpectedly fails because they are portable as they can be moved from one hypervisor to another on a completely different physical server quickly.

A diagram shows the following: Virtual Machines: APP1: Bins/Libs OS-Win; APP2: Bins/Libs OS-Linux; APP3: Bins/Libs, OS-Unix – Hypervisor, Host OS, Server.
Figure 12.32 Multiple VMs are created and run on a hypervisor. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Unikernels

Originally introduced as MirageOS, a unikernel is a single-purpose machine image that is compile-time specialized into a dedicated stand-alone kernel with only the libraries needed to run the application. Once deployed to a cloud platform, unikernels are protected against any modifications. Unikernels are built by compiling the application source code directly into a customized operating system that includes only the functionality required by the application logic, as shown in Figure 12.33. They are specialized machine images that run directly on a server’s hypervisor or on bare metal. Unikernels are considered more secure, compared to other cloud deployment technology options, due to their smaller attack surface.

A diagram shows the following flow: Configuration files, Application binaries, Language runtime, Kernel threads, User processes, File system, Network stack –Compiles to-> Unikernal, Hypervisor, Host OS.
Figure 12.33 Multiple unikernels are built as specialized images and run on a hypervisor. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Unikernels provide all the advantages of VMs and containers while reducing the server footprint needed to deploy applications, because unikernels offer a significant reduction in image sizes, have a reduced memory footprint, and greatly reduce the need for disk space. The unikernels architecture increases agility and speed. They have minimal overhead, and because they have faster load times with lower latencies, they can start up very quickly, making them faster than containers and VMs. Unikernels are also very portable. Their small size makes it easier and more cost effective to move them from one hypervisor to another.

The adoption of unikernels remains low due to a combination of lack of awareness and low availability of orchestrators. They are becoming more prevalent in single-purpose devices such as network function virtualization (NFV) appliances, however data center adoption remains low.

Containers

Containers are a form of “operating system virtualization” that is more efficient than hardware virtualization because they utilize a full system hardware virtualization. In contrast, containers leverage and run on a single instance of an operating system where the virtualization is managed by the host operating system, as shown in Figure 12.34.

A diagram shows the following: Containers: APP1, APP2, APP3 – Container engine – Host OS – Server.
Figure 12.34 Multiple containers are built and run on a container engine. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

While VMs run as isolated servers on a hypervisor, containers share the same operating system and kernel of the host server. It appears as if each container runs on its own operating system and contains all the required binaries, libraries, and application code that is needed to run the application deployed in it. This is possible because containers run as isolated processes making it possible to run many containers on a single bare metal server or VM without any interference between them. Containers access shared resources of the operating system, but also remain as isolated processes because the shared kernel manages process isolation. Namespaces and control groups (cgroups) also help provide the illusion of process isolation. Namespaces allow for the customization and the appearance that each container instance has its own operating system. Control groups, on the other hand, monitor and manage shared resources controlled by the containers, which helps significantly reduce the number of compute instances needed to run applications.

Container deployment options include building your own container service, utilizing off-the-shelf Containers as a Service platforms, or choosing managed container services, such as managed Kubernetes, provided by large cloud service providers (CSPs). A Container as a Service (CaaS) is a type of IaaS specifically geared toward efficiently deploying, running, scaling, and managing a single application using a container-based virtualization. Container deployment using the build-your-own-service option requires the customer to manage the container technology, container scheduling and orchestration, as well as cluster management. Customers deploy the containers on top of IaaS, either bare metal or VM. The CSP, however, manages the underlying infrastructure.

Container deployment using an off-the-shelf CaaS platform requires the customer to containerize the middleware, libraries, and applications or microservices. Customers deploy the containers on-premises or in a public (or off-premises private) cloud environment. This option has a higher overhead for the customer compared to PaaS because the customer is responsible for creating and updating the container images for each of these components. Container deployment using the managed container services option requires the customer to manage the workload. The CSP manages the container environment as well as the underlying infrastructure.

PaaS Deployment Options

The cloud deployment technologies that are provided through IaaS deployment options are also provided through PaaS deployment options. In addition to the infrastructure provided, PaaS deployment options also provide the operating system, middleware, runtime, and other infrastructural components that also need to be managed with IaaS. PaaS, thus, offers a fully managed solution for developers to quicky deploy and launch their applications, significantly reducing infrastructure and middleware overhead for developers. This allows developers to focus on developing and deploying their applications while the burden of managing the infrastructure, back-end services, and any other system administrative services falls on the cloud service provider.

FaaS Deployment Options

Function as a Service (FaaS) and serverless computing are mostly synonymous. In the cloud-native development model of serverless computing, developers can build and run applications but are not responsible for provisioning, maintaining, and scaling the server infrastructure as this is outsourced to the CSP. The customer is thus focused exclusively on the business logic of the application. As shown in Figure 12.35, navigating up the y-axis toward serverless computing customers focuses more on the business logic and writing the application code abstracting from the underlying infrastructure. Navigating the x-axis toward serverless computing decreases stack implementation and customers have less control of how the application is deployed.

A diagram shows two arrows: one goes up and reads “Increase abstraction/app development focus;” one goes right and reads “Decrease flexibility/stack implementation.” Between these arrows is the following flow: Bare metal -> Virtual machines -> Containers -> Serverless.
Figure 12.35 Serverless computing provides the highest level of abstraction from the infrastructure with a focus on application development. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

Serverless computing offerings typically fall into two groups, Backend as a Service (BaaS) and Function as a Service (FaaS). Backend as a Service (BaaS) is any third-party service that can be integrated with an application where the BaaS code does not need to be managed, and there are no servers. BaaS gives developers access to a variety of third-party services and apps. For instance, a cloud provider may offer authentication services, extra encryption, cloud-accessible databases, and high-fidelity usage data. With BaaS, serverless functions are usually called through APIs.

More commonly, when developers refer to serverless, they are talking about a FaaS service model. Function as a Service (FaaS) is a compute platform for serverless where developers can run functions that are single units of deployment of the code, which is run by events. They are typically invoked via an API gateway. An API gateway translates requests to a single endpoint and then routes it to a FaaS function. FaaS/serverless functions have the following basic characteristics:

  • An event-driven architecture, provided by the cloud service provider, is an architecture where functions are invoked by an event. The function may initiate other events, which could invoke other functions.
  • Functions that are a single unit of deployment of the code and configuration run in a managed environment.
  • Functions are executed in the cloud and run in ephemeral stateless containers.

With FaaS/serverless computing, the cloud service provider manages the infrastructure in its entirety. The FaaS/serverless underlying infrastructure is automatically scaled as demand increases. FaaS/serverless solutions have a faster time to market. Customers are not responsible for the management of any of the underlying infrastructure, making it easier to build and deploy FaaS solutions faster and bring them to market. FaaS/serverless is a polyglot environment. FaaS functions can be written in any language if it is supported by the cloud service providers. FaaS/serverless solutions are inherently highly available. FaaS/serverless solutions can be deployed across multiple availability zones in different geographical regions. Cloud service providers manage fault tolerance and deployment across the available regions making the FaaS/serverless solution highly available.

Serverless offerings are usually metered on-demand through an event-driven execution model. Customers pay for execution only. When a serverless function is idle, there is no cost. Customers must, however, be aware that providers place limits on the resources available to functions, processing time, and concurrency of event processing. These constraints must be assessed to ensure the user experience is not degraded.

PaaS and FaaS Comparison

PaaS provides a platform that allows customers to provision and scale the infrastructure needed as well as develop, run, and manage applications without the complexity of managing the underlying infrastructure required to run the application. FaaS goes a step further in that it provides an environment where developers can focus on running and managing code without having to provision resources or scaling the underlying infrastructure. In summary, both FaaS and PaaS provide an infrastructure managed by the cloud service provider. Both provide scalability options. Both deliver high availability from remote infrastructure managed automatically by the cloud service provider at scale. FaaS/serverless and PaaS, on the surface, appear to be very similar in their implementation and use from a development point of view. In reality, these two cloud deployment services are quite different. Scalability, pricing, start-up time, tooling, and the ability to deploy differ between the two platforms.

Serverless applications offer true auto-scaling capabilities to customers without any additional configurations. PaaS provides scalability options that are more advantageous compared to deployments on bare metal servers. However, developers still must consider how to construct and scale a PaaS platform. They must forecast resource capacity and configure PaaS-hosted applications to scale up and down based on demand. Serverless cost structure is based on usage, and there are no fixed monthly charges for services. With FaaS, customers pay per event-based invocation of the function only. With PaaS, pricing models differ depending on the PaaS provider, and are generally associated with the use of compute, storage, and network resources costs. This means, for PaaS, costs accrue during idle time. In some cases, serverless can be a more cost-effective option for software deployments.

FaaS functions execute in response to events, offering rapid start-up times crucial for event-based processing. Conversely, PaaS applications lack event-triggered start-up capabilities and are tolerant of slower start-up times due to their long-lived nature. FaaS abstracts the application layer, allowing developers to focus solely on function code while cloud service providers manage other aspects. This abstraction, however, reduces flexibility, as developers must adhere to provider-specific frameworks and language limitations. PaaS, on the other hand, offers developers greater control over the development environment, including the choice of programming languages and frameworks.

There are at least three application areas where it makes sense to go serverless:

  1. Unpredictably fluctuating workloads or frequent low usage ideal for the pricing model of FaaS/serverless solutions.
  2. Processing large, distributed data sources because of the feasibility of auto-scaling of FaaS/serverless environments where computing performance can be dramatically boosted.
  3. Building highly modular solutions potentially incorporating external services that can also exploit the pricing model of FaaS/serverless solutions.

More generally, serverless architecture is ideal for asynchronous, stateless applications that can be started instantaneously. Likewise, serverless is a good fit for use cases that see infrequent, unpredictable surges in demand, that are high-volume, and with parallel workloads. An example of an infrequent in-demand task would be a batch processing of incoming image files. This task can be high-volume if a large batch of images to be processed arrives all at once. Serverless is also a good fit for use cases that involve incoming data stream processing for implementing applications such as chat bots, scheduled tasks, or business logic. Some other common serverless use cases are back-end APIs and web apps, business process automation, serverless websites, and integration across multiple systems.

CSPs offer several serverless services. Understanding the minute differences between these services can be overwhelming, making it challenging to select the set of services to develop an optimal serverless architecture. It is expected to invest up-front time to get familiar with these services to understand the runtime expectations and resource consumption associated with a prospective serverless solution. It is also challenging to maintain a serverless architecture in a continuous deployment procedure.

There are many cloud deployment technology options available to customers, which will continue to evolve. The vast possibilities available provide support for a wide host of services. The sections that follow provide insight into common use cases that are associated with the use of these deployment technology options.

Industry Spotlight

CaaS, PaaS, or FaaS?

Deployment technologies are broadly used in the industry today to deploy cloud-native applications. Containers/CaaS, PaaS, and FaaS/serverless deployment technologies are used by Netflix, Uber, and WeChat to deploy cloud-native systems that consist of many independent services. Knowing these systems, can you elaborate on the suitability of Containers/CaaS as compared to PaaS or FaaS/serverless for these particular systems?

Cloud Deployment Technology Use Cases and Implementation

There are various types of situations that prompt the use of cloud deployment technologies. The corresponding use cases and their implementation are covered in the following sections.

Cloud Deployment Technology Use Cases

The most common types of deployments are for enterprise data centers, which will be the focus of these use cases. Typically, multiple cloud deployment technologies are used together to provide the services and deployment requirements to satisfy customer needs. As customers seek to deploy large-scale enterprise applications, they must assess the required infrastructure, middleware, runtime dependencies, and constraints to choose the most appropriate cloud deployment technologies. For cloud-native applications, cloud deployment technologies such as CaaS, PaaS, and FaaS are the most popular.

Bare Metal Deployment Technology

With bare metal servers, there is no virtualization and no hypervisor overhead, thus their resources (CPU, memory, and I/O) are dedicated to the application deployed on it. These resources, along with the hardware, are highly customizable and can be tuned up for maximum performance, making bare metal servers a viable option to support resource-intensive workloads such HPC. This also helps with latency-sensitive applications (e.g., streaming services) and large databases that consume significant resources. A combination of cloud deployment technologies can be used to satisfy the various requirements of a solution architecture. Bare metal servers can be used for the resource-intensive components, whereas VMs, containers, and other cloud deployment technologies deliver application services. Bare metal servers are also an option for legacy applications that may not be virtualized or not well suited for a virtualized environment.

Bare metal servers are also a good fit for security-oriented applications because additional security measures can be easily integrated. Bare metal servers are the best fit for solutions that must comply with regulations or contract agreements that require single-tenant hosting.

VMs Deployment Technology

Legacy applications that can be virtualized but have known and manageable behavioral issues are well suited for cloud deployment using VMs. This also applies to legacy applications that are not well documented but there is basic knowledge of how they run. VMs are a viable option for monolithic and tiered applications that are not mature enough to be migrated to a microservices architecture. Such applications could be migrated to the cloud as cloud-based monoliths.

VMs can also be used to provide enhanced container security, although with additional overhead. The use of a VM can provide an additional layer of isolation when deploying containers eliminating the use of a shared kernel model.

Containers/CaaS Deployment Technology

Containers enable scaling, replicating, and choreographing services in a microservices architecture. Containers are also lightweight, portable, and platform independent. The ability to start containers in a fraction of the time of VMs is critical. With these advantages, cloud customers have developed a plethora of microservices ranging from user interface (UI) front ends to back-end microservices. A microservices architecture is a good use case for using containers.

Legacy applications that depend on out-of-support operating systems or other out-of-support dependencies are candidates for containers. Application dependencies can be containerized to enable execution. However, there are limitations to this approach, and it can be very challenging to get such applications up and running in a container. The application dependencies must be assessed to ensure containerization is a viable option. Legacy applications that can be modernized and migrated to the cloud are also good candidates for containers.

Platform flexibility is the primary use case for CaaS. Containers can consistently run anywhere without the limitations of middleware and platform tools offered by PaaS platforms. CaaS provides the customers with a container-based environment they can control (security, scalability, and availability) without significant effort.

Unikernels Deployment Technology

The need to optimize VMs is the most common use case for unikernels at this time. Unikernels have smaller footprints, in part, because they are built without unnecessary binaries and libraries. Because they have less overhead, unikernels can start up very quickly, faster than VMs and containers. With the smaller footprint and speed comes improve security when it comes to unikernels. Because unikernels are built to include only the libraries needed to run the application, this reduces the cybersecurity attack surface, thereby making them more secure compared to the other cloud deployment technologies.

Mutable server infrastructures are where servers are continually updated and modified in place even after they are deployed. Immutable infrastructures are where servers are never modified after they are deployed. The main difference between mutable and immutable infrastructures is the policy used that determines whether components of the environment are designed to be changed after deployment. Customers may need or expect an immutable infrastructure to preserve the integrity of an environment. Although VMs are not permitted in an immutable environment, unikernels, by design, protect against such modifications because any updates or changes to any components are built from an image and provisioned to replace the old ones. Unikernels, thus, are a good choice for the need of an immutable infrastructure.

PaaS Deployment Technology

PaaS is used to deploy modern, cloud-native application architectures. PaaS provides a complete cloud platform that includes hardware, infrastructure, middleware, and runtime environment. It is most often delivered using a container-based infrastructure, and therefore supports the same use cases as containers.

The most prevalent use case for PaaS is speed to market. PaaS reduces or eliminates the burden of deploying and managing infrastructure, enabling cloud customers to focus instead on customer needs and development of the applications. PaaS can be more affordable, especially for software development houses, which often do not have the budget to hire personnel to build and manage infrastructure, as it offers access to a wider range of services up and down the application stack. PaaS also provides a cost-effective way for customers to scale up and down resources as needed. PaaS also provides a development and CI/CD environment to quickly develop, integrate, build, and deploy applications.

FaaS Deployment Technology

The use case for FaaS/serverless is limited to microservices-based applications, more specifically applications that are short-lived and event-based. Examples of services include data/stream and image processing, reservation handling, and IoT data processing. Other use cases include high-volume and parallel workloads and data aggregation tasks.

FaaS/serverless is used to reduce the customer’s responsibility to manage middleware dependencies, runtime considerations, and the underlying infrastructure. The FaaS/serverless platform takes care of this, leaving the customer with the responsibility to write the function code. The result is increased velocity in delivering highly available, technology capability, and satisfying business demand.

Cloud Deployment Technology Implementation

There are several tools cloud customers must consider when implementing services using the cloud deployment technologies discussed earlier. Cloud customers who adopt automation will increase deployment speeds while lowering costs. With the growth of cloud environments, customers must manage increasingly complex environments. There are several tools that can be used to automate tasks, such as server provisioning and configuration management. Automating these tasks improves the efficiency of DevOps teams and speeds up the deployment of services because they reduce the volume of manual tasks required to manage cloud resources and infrastructure. Tasks that must be automated in the case of each cloud deployment technology include the IaaS tasks of orchestration and provisioning, PaaS tasks include source code management and CI/CD pipelines, and FaaS/serverless tasks include orchestrating the deployment of functions and their dependencies.

Automation tools help customers reduce operational costs and minimize errors. Automation tools can be used to configure and install containers, VMs, or other systems; provision and deprovision resources for auto-scaling; and allocate resources to optimize workload performance. There are several tools that are available to assist with automation of development, delivery, and management of applications, workloads, and infrastructure. Tools such as Ansible, Pulumi, or Terraform can help with automating orchestration. Tools such as Ansible, Chef, Puppet, or Salt can help with automating configuration management. Tools such as BitBucket, GitHub, or GitLab can help with automating source control management. Tools such as Broccoli, CircleCI, Codeship, or Maven can help with automating builds. Tools such as Bamboo, CircleCI, Codeship, and Jenkins can help with automating continuous integration. For automating continuous deployment, additional options include Go, Julu, or Octopus Deploy.

Global Issues in Technology

DevOps Across the Globe

While cloud-native applications are deployed all over the world, they involve the use of DevOps methods and tools that are mostly developed in the United States or Europe. For example, DevOps refers to terms like CI/CD, which relate to terms (i.e., continuous integration/continuous deployment) and tools (e.g., Jenkins, GitLab, Docker) that are respectively used and implemented by companies in the United States. Therefore, it is not certain how well those methods and tools work in other cultural contexts. What is your opinion regarding these concerns?

IaaS Cloud Deployment Implementation

When adopting IaaS, IaC can be used to automate infrastructure management provisioning by using code instead of manually. This includes managing servers, managing operating system installations and updates, kernel modifications, and the management of storage and other infrastructure components needed for the development and deployment of applications.

Orchestration tools (e.g., Kubernetes) can be used on any of the cloud deployment technologies discussed to automate services such as allocating resources and scaling applications as needed. Configuration management tools (e.g., Ansible) can also be used on any of the cloud deployment technologies to automate the process of configuring and managing changes to these resources. Both orchestration and configuration management tools provide support for integrating with IaaS services provided by the major cloud service providers (e.g., Amazon Web Services, Google Cloud Platform, IBM Cloud, and Microsoft Azure).

PaaS Cloud Deployment Implementation

As mentioned, PaaS also provides services for managing the operating system, middleware, and runtime environments for applications. As such, available PaaS tools are used for automating tasks, such as streamlining code integration between systems as well as managing application build and deployment processes.

A tool discussed earlier, Tanzu, provides a major improvement over traditional PaaS deployment options by enabling deployment on any cloud that provides a container orchestration mechanism. It is equivalent to an application server for the cloud that can deploy cloud-based and cloud-native application workloads on any cloud.

FaaS Deployment Technology Implementation

When adopting FaaS, applications are deployed on server infrastructure in response to events without customers having to manage the underlying infrastructure. Although the managing of the infrastructure is not the customer’s concern, there are setup requirements customers must deal with, including setting up the serverless runtime environment, deploying serverless functions, cloud service dependencies (e.g., storage), and the required amount of memory needed. There are tools (e.g., Ansible) that are available to help deploy these cloud services.

Cloud management platforms (CMPs) are used to simplify the deployment and management of cloud services across various cloud service providers. Customers manage several large-scale applications in very complex environments using services from multiple cloud service providers. CMPs can be helpful in simplifying the deployment and management of all these services. Understanding the common use cases as well as the available cloud deployment technologies available help customers to select the appropriate solutions to support their needs.

Selection of Cloud Deployment Technologies

When selecting the most appropriate cloud deployment technologies, customers should both strategically and tactically consider these choices. Strategically, customers should consider their business needs and select the cloud deployment technologies that are relevant to meet these needs. Tactically, customers should consider the application requirements and relevant cloud services needed to support those applications. In summary, the steps to select the appropriate cloud deployment technologies include:

  • Assess how well the cloud deployment technology options meet the business needs.
  • Understand infrastructure and workload/service requirements.
  • Select cloud deployment technologies that satisfy the application requirements and provide the services needed.

Fit to Business Needs

With so many cloud deployment technology options, customers should regularly assess these options with the following considerations in mind:

  • Cost: Understand the different cost models associated with the various cloud deployment technologies.
  • Architectural fit: Understand the application deployment needs and how the different cloud deployment technologies support those needs.
  • Performance: Understand the application performance requirements (e.g., workloads performance requirements, bandwidth requirements, latency requirements) and how the different cloud deployment technologies satisfy these requirements.
  • Compliance: Identify any specific regulatory or contractual requirements that impose limitations that can impact the choices of cloud deployment technologies.
  • Elasticity requirements: Identify the level of elasticity needed to satisfy the possible need to grow or shrink infrastructure resources dynamically as needed.
  • Control requirements: Determine the level of control required to manage the various cloud deployment technologies and at what layers of the infrastructure.
  • Cloud service provider lock-in: For customers who manage diverse, complex environments across multiple cloud service providers, determine the level of portability needed to enable the flexibility to change providers to optimize services utilized.

Although, generally, there is no formal process for selecting cloud deployment technologies, customers can benefit from a more formalized process as it allows customers to implement the appropriate orchestration and management tools and establish processes needed to deliver effective and efficient services.

Understanding Workload/Service Requirements

When selecting cloud deployment technologies, requirements (e.g., latency limitations, industry-dependent data protection controls) related to the types of workloads or services should also be considered.

Selecting Application/Service Cloud Deployment Technology

As the strategic requirements and workload/service constraints discussed previously are defined, customers can then evaluate the cloud deployment technologies that are most appropriate to meet their business needs. The cloud deployment technologies selected must adhere to the service levels required to satisfy business needs. These options may change over time as the range of available cloud deployment technology options continues to evolve. Prudent customers should proactively periodically evaluate these cloud deployment technologies to continuously meet business needs.

Applications Composed of Multiple Cloud Services

A cloud mashup is a technique for seamlessly combining multiple cloud applications from several sources into a single integrated solution. Cloud mashups can be realized in many ways covering different scopes depending on the purpose of the mashup. For example, PaaS services on public clouds can be used to create innovative cloud-based and cloud-native applications as cloud mashups, which enable corporations to undergo digital transformations to provide competitive solutions while differentiating themselves. An example of a cloud mashup that provides a driving route recommendation service is the mashup of AWS EC2, Facebook’s authentication and authorization services, and Google’s MapReduce services.

The selection of cloud deployment technologies is an important factor in the overall quality of cloud mashups measured by quality of service and quality of experience assurances as these metrics specify the desired performance requirements of the cloud mashup. Regarding the previously mentioned driving route example, the recommended driving route and the speed at which the route is calculated are important factors to determine the quality of this service. In addition, the discovery of the best-choice web services and the streamlining of services into a mashup are also impacted by the selection of cloud deployment technologies. The increasing demand for innovative cloud services have led to cloud service providers competing to provide mashup service discovery, automated composition techniques, and reusable cloud component’s APIs as services that support the ability to quickly assemble mashups.

Technology in Everyday Life

Real Life and Technology

How does the use of cloud deployment technologies help people in everyday life? As was mentioned, cloud deployment technologies can be used to create cloud mashups. One example discussed is a driving route recommendation service (the mashup of AWS EC2, Facebook’s authentication and authorization services, and Google’s MapReduce services). Many people depend on a driving route recommendation service in GPS systems today. It was also mentioned that the selection of cloud deployment technologies directly impacts the overall quality of the cloud mashup as the accuracy of the recommended routes and the speed at which routes are calculated are important features of such a service. Can you think of other ways cloud deployment technologies help people in everyday life? Provide a couple of illustrative scenarios to explain your opinion.

Key to Success Summary

There are lots of options when it comes to choosing the most appropriate cloud deployment technologies, and these options will continue to grow. Customers should understand the options that are available and how these cloud deployment technologies can best fit the requirements of deploying their applications to the cloud. To help select the most appropriate options, customers should consider: (1) understand how the currently available cloud deployment technologies and services work and fit in the delivery of cloud services, (2) identify the tools available to automate and support the delivery of these cloud services, and (3) assess the technical factors (e.g., application architecture, data implications, runtime dependencies) of these cloud deployment technologies and select the technologies that provide the “best fit” to their business needs. These steps should be repeated periodically to reassess the available cloud deployment technologies as these technologies evolve and more are added. Customers should keep in mind that the benefits of researching the most appropriate selection of cloud deployment technologies to fit business needs up front can significantly outweigh the costs of taking an ad hoc approach of combining technologies that may end up providing a suboptimal user experience.

Think It Through

Which Solution to Select?

Given the fact that many deployment technologies are available today, is there a process that facilitates the selection of these technologies to deploy cloud-native applications?

Citation/Attribution

This book may not be used in the training of large language models or otherwise be ingested into large language models or generative AI offerings without OpenStax's permission.

Want to cite, share, or modify this book? This book uses the Creative Commons Attribution License and you must attribute OpenStax.

Attribution information
  • If you are redistributing all or part of this book in a print format, then you must include on every physical page the following attribution:
    Access for free at https://openstax.org/books/introduction-computer-science/pages/1-introduction
  • If you are redistributing all or part of this book in a digital format, then you must include on every digital page view the following attribution:
    Access for free at https://openstax.org/books/introduction-computer-science/pages/1-introduction
Citation information

© Oct 29, 2024 OpenStax. Textbook content produced by OpenStax is licensed under a Creative Commons Attribution License . The OpenStax name, OpenStax logo, OpenStax book covers, OpenStax CNX name, and OpenStax CNX logo are not subject to the Creative Commons license and may not be reproduced without the prior and express written consent of Rice University.