User:Shawndouglas/sandbox/sublevel45

You've probably heard terms like "software as a service" and "public cloud," and you may very well be familiar with their significance already. However, let's briefly run through the terminology associated with cloud services and deployments, as that terminology gets used abundantly, and it's best we're all clear on it from the start. Additionally, the cloud computing paradigm is expanding into areas like "hybrid cloud" and "serverless computing," concepts which may be new to many.

Mentioned earlier was NIST's 2011 definition of cloud computing. When that was published, NIST defined three service models and four deployment models (Table 1):

Table 1. The three service models and four deployment models for cloud computing, as defined by the National Institute of Standards and Technology (NIST) in 2011 Service models Model Description Software as a Service (SaaS) "The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings." Platform as a Service (PaaS) "The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment." Infrastructure as a Service (IaaS) "The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls)." Deployment models Model Description Private cloud "The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises." Community cloud "The cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and it may exist on or off premises." Public cloud "The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider." Hybrid cloud "The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds)."

Nearly a decade later, the picture painted in Table 1 is now more nuanced and varied, with slight changes in definitions, as well as additions to the service and deployment models. Cloudflare actually does a splendid job of describing these service and deployment models, so let's paraphrase from them, as seen in Table 2.

Table 2. A more modern look at service models and deployment models for cloud computing, as inspired largely by Cloudflare Service models Model Description Software as a Service (SaaS) This service model allows customers, via an internet connection and a web browser or app, to use software provided by and operated upon a cloud provider and its computing infrastructure. The customer isn't worried about anything hardware-related; from their perspective, they just want the software hosted by the cloud provider to be reliably and effectively operational. If the desired software is tied to strong regulatory or security standards, however, the customer must thoroughly vet the vendor, and even then, there is some risk in taking the word of the vendor that the application is properly secure since customers usually won't be able to test the software's security themselves (e.g., via a penetration test). Platform as a Service (PaaS) This service model allows customers, via an internet connection and a web browser, to use not only the computing infrastructure (e.g., servers, hard drives, networking equipment) of the cloud provider but also development tools, operating systems, database management tools, middleware, etc. required to build web applications. As such, this allows a development team to spread around the world and still productively collaborate using the cloud provider's platform. However, app developers are essentially locked into the vendor's development environment, and additional security challenges may be introduced if the cloud provider has extended its infrastructure to one or more third parties. Finally, PaaS isn't truly "serverless," as applications won't automatically scale unless programmed to do so, and processes must be running most or all the time in order to be immediately available to users. Infrastructure as a Service (IaaS) This service model allows customers to use the computing infrastructure of a cloud provider, via the internet, rather than invest in their own on-premises computing infrastructure. From their internet connection and a web browser, the customer can set up and allocate the resources required (i.e., scalable infrastructure) to build and host web applications, store data, run code, etc. These activities are often facilitated with the help of virtualization and container technologies. Function as a Service (FaaS) This service model allows customers to run isolated or modular bits of code, preferably on local or "edge" cloud servers, when triggered by an element, such as an internet-connected device taking a reading or a user selecting an option in a web application. The customer has the luxury of focusing on writing and fine-tuning the code, and the cloud provider is the one responsible for allocating the necessary server and backend resources to ensure the code is run rapidly and effectively. As such, the customer doesn't have to think about servers at all, making FaaS a "serverless" computing model. Backend as a Service (BaaS) This service model allows customers to focus on front-end application services like client-side logic and user interface (UI), while the cloud provider provides the backend services for user authentication, database management, data storage, etc. The customer uses APIs and software development kits (SDKs) provided by the cloud provider to integrate customer frontend application code with the vendor's backend functionality. As such, the customer doesn't have to think about servers, virtual machines, etc. However, in most cases, BaaS isn't truly serverless like FaaS, as actions aren't usually triggered by an element but rather run continuously (not as scalable as serverless). Additionally, BaaS isn't generally set up to run on the network's edge. Deployment models Model Description Private cloud This deployment model involves the provision of cloud computing infrastructure and services exclusively to one customer. Those infrastructure and service offerings may be hosted locally on-site or be remotely and privately managed and accessed via the internet and a web browser. Those organizations with high security and regulatory requirements may benefit from a private cloud, as they have direct control over how those policies are implemented on the infrastructure and services (i.e., don't have to consider the needs of other users sharing the cloud, as in public cloud). However, private cloud may come with higher costs. Community cloud This deployment model, while not discussed often, still has some relevancy today. This model falls somewhere between private and public cloud, allowing authorized customers who need to work jointly on projects and applications, or require specific computing resources, in an integrated manner. The authorized customers typically have shared interests, policies, and security/regulatory requirements. Like private cloud, the computing infrastructure and services may be hosted locally at one of the customer's locations or be remotely and privately managed, with each customer accessing the community cloud via the internet. Given a set of common interest, policies, and requirements, the community cloud benefits all customers using the community cloud, as does the flexibility, scalability, and availability of cloud computing in general. However, with more users comes more security risk, and more detailed role-based or group-based security levels and enforcement may be required. Additionally, there must be solid communication and agreement among all members of the community to ensure the community cloud operates as efficiently and securely as possible. Public cloud This deployment model is what typically comes to mind when "cloud computing" is discussed, involving a cloud provider that provides computing resources to multiple customers at the same time, though each individual customer's applications, data, and resources remain "hidden" from all other customers not authorized to view and access them. Those provided resources come in many different services model, with SaaS, PaaS, and IaaS being the most common. Traditionally, the public cloud has been touted as being a cost-effective, less complex, relatively secure means of handling computing resources and applications. However, for organizations tied to strong regulatory or security standards, the organizaiton must thoroughly vet the cloud vendor and its approach to security and compliance, as the provider may not be able to meet regulatory needs. There's also the concern of vendor lock-in or even loss of data if the customer becomes too dependent on that one vendor's services. Hybrid cloud This deployment model takes both private cloud and public cloud models and tightly integrates them, along with potentially any existing on-premises computing infrastructure. (Figure 2) The optimal end result is one seamless operating computing infrastructure, e.g., where a private cloud and on-premises infrastructure houses critical operations and a public cloud is used for data and information backup or computing resource scaling. Advantages include great flexibility in deployments, improved backup options, resource scalability, and potential cost savings. Downsides include greater effort required to integrate complex systems and make them sufficiently secure. Note that hybrid cloud is different from multicloud in that it combines both public and private computing components. Multicloud This deployment model takes the concept of public cloud and multiplies it. Instead of the customer relying on a singular public cloud provider, they spread their cloud hosting, data storage, and application stack usage across more than one provider. The advantage to the customer is redundancy protection for data and systems and better value by tapping into different services. Downside comes with increased complexity in managing a multicloud deployment, as well as the potential for increased network latency and a greater cyber-attack surface. Note that multicloud requires multiple public clouds, though a private cloud can also be in the mix. Distributed cloud This up-and-coming deployment model takes public cloud and expands it, such that a provider's public cloud infrastructure can be located in multiple places but be leveraged by a customer wherever they are, from a single control structure. As IBM puts it: "In effect, distributed cloud extends the provider's centralized cloud with geographically distributed micro-cloud satellites. The cloud provider retains central control over the operations, updates, governance, security, and reliability of all distributed infrastructure." Meanwhile, the customer can still access all infrastructure and services as an integrated cloud from a single control structure. The benefit of this model is that, unlike multicloud, latency issues can largely be eliminated, and the risk of failures in infrastructure and services can be further mitigated. Customers in regulated environments may also see benefits as data required to be in a specific geographic location can be better guaranteed with the distributed cloud. However, some challenges to this distributed model involve the allocation of public cloud resources to distributed use and determining who's responsible for bandwidth use.

Figure 2. A representation of hybrid cloud. The cloud on the left represents the public cloud, being fed to the organization's main building. The cloud on the right represents the organization's private cloud, which is spread across all business locations. The main building feeds access to the public cloud to its other locations through its private cloud.

While Table 2 addresses the basic ideas inherent to these service and deployment models, even providing some upside and downside notes, we still need to make further comparisons in order to highlight some fundamental differences in otherwise seemingly similar models. Let's first compare PaaS with serverless computing or FaaS. Then we'll examine the differences among hybrid, multi-, and distributed cloud models.

1.2.1 Platform-as-a-service vs. serverless computing

As a service model, platform as a service or PaaS uses both the infrastructure layer and the platform layer of cloud computing. Hosted on the infrastructure are platform components like development tools, operating systems, database management tools, middleware, and more, which are useful for application design, development, testing, and deployment, as well as web service integration, database integration, state management, application versioning, and application instrumentation. In that regard, the user of the PaaS need not think about the backend processes.

Similarly, serverless computing or FaaS largely abstracts away (think "out of sight, out of mind") the servers running any software or code the user chooses to run on the cloud provider's infrastructure. The user practically doesn't need to know anything about the underlying hardware and operating system, or how that hardware and software handles the computational load of running your software or code, as the cloud provider ends up completely responsible for that. However, this is where the similarities stop.

Let's use Amazon's AWS Lambda serverless computing service as an example for comparison with PaaS. Imagine you have some code you want performed on your website when an internet of things (IoT) device in the field takes a reading for your environmental laboratory. From your AWS Lambda account, you can "stage and invoke" the code you've written (it can be in any programming language) "from within one of the support languages in the AWS Lambda runtime environment." In turn, that runtime environment runs on top of Amazon Linux 2, an Amazon-developed version of Red Hat Enterprise running as a Linux server operating system. This can then be packaged into a container image that runs on Amazon's servers. When a designated event occurs (in this example, the internet-connected device taking a reading), a message is communicated—typically via an API—to the serverless code, which is then triggered, and Amazon Lambda provisions only the necessary resources to see the code to completion. Then the AWS server spins down those resources afterwards. Yes, there are servers still involved, but the critical point is the customer need only to properly package their code up, without any concern whatsoever of how the AWS server manages its use and performance. In that regard, the code is said to be run in a "serverless" fashion, not because the servers aren't involved but because the code developer is effectively abstracted from the servers running and managing the code; the developer is left to only worry about the code itself.

PaaS is not serverless, however. First, a truly serverless model is significantly different in its scalability. The serverless model is meant to instantly provide computing resources based upon a "trigger" or programmed element, and then wind down those resources. This is perfect for the environmental lab wanting to upload remote sensor data to the cloud after each collection time; only the resources required for performing the action to completion are required, minimizing cost. However, this doesn't work well for a PaaS solution, which doesn't scale up automatically unless specifically programmed to. Sure, the developer using PaaS has more control over the development environment, but resources must be scaled up manually and left continuously running, making it less agile than serverless. This makes PaaS more suitable for more prescriptive and deliberate application development, though its usage-based pricing is a bit less precise than serverless. Additionally, serverless models aren't typically offered with development tools, as usually is the case with PaaS, so the serverless code developer must turn to their own development tools.

1.2.2 Hybrid cloud vs. multicloud vs. distributed cloud

At casual glance, one might be led to believe these three deployment models aren't all that different. However, there are some core differences to point out, which may affect an organization's deployment strategy significantly. As Table 2 notes:

• Hybrid cloud takes private cloud and public cloud models (as well as an organization's local infrastructure) and tightly integrates them. This indicates a wide mix of computing services is being used in an integrated fashion to create value.
• Multicloud takes the concept of public cloud and multiplies it. This indicates that two or more public clouds are being used, without a private cloud to muddy the integration.
• Distributed cloud takes public cloud and expands it to multiple edge locations. This indicates that a public cloud service's resources are strategically dispersed in locations as required by the user, while remaining accessible from and complementary to the user's private cloud or on-premises data center.

As such, an organization's existing infrastructure and business demands, combined with its aspirations for moving into the cloud, will dictate their deployment model. But there are also advantages and disadvantages to each which may further dictate an organization's deployment decision. First, all three models provide some level of redundancy. If a failure occurs in one computing core (be it public, private, or local), another core can ideally provide backup services to fill the gap. However, each model does this in a slightly different way. In a similar way, if additional compute resources are required due to a spike in demand, each model can ramp up resources to smooth the demand spike. Hybrid and distributed clouds also have the benefit of making any future transition to a purely public cloud (be it singular or multi-) easier as part of an organization's processes and data are already found in public cloud.

Beyond these benefits, things diverge a bit. While hybrid clouds provide flexibility to maintain sensitive data in a private cloud or on-site, where security can be more tightly controlled, private clouds are resource-intensive to maintain. Additionally, due to the complexity of integrating that private cloud with all other resources, the hybrid cloud reveals a greater attack surface, complicates security protocols, and raises integration costs. Multicloud has the benefit of reducing vendor lock-in (discussed later in this guide) by implementing resource utilization and storage across more than one public cloud provider. Should a need to migrate away from one vendor arrive, it's easier to continue critical services with the other public cloud vendor. This also lends to "shopping around" for public cloud services as costs lower and offerings change. However, this multicloud approach brings with it its own integration challenges, including differences in technologies between vendors, latency complexities between the services, increased points of attack with more integrations, and load balancing issues between the services. A distributed cloud model removes some of that latency and makes it easier to manage integrations and reduce network failure risks from one control center. It also benefits organizations requiring localized data storage due to regulations. However, with multiple servers being involved, it makes it a bit more difficult to troubleshoot integration and network issues across hardware and software. Additionally, implementation costs are likely to be higher, and security for replicated data across multiple locations becomes more complex and risky.