Editor's Note: This post has been recently updated from an earlier version.
What is a cloud deployment model?
A cloud deployment model defines the cloud services you are consuming and the responsibility model for who manages them. It defines your cloud architecture, scalability of your computing resources, what you can change, the services provided to you, and how much of the build you own. Cloud deployment models also define relationships between the cloud infrastructure and your users (what users are allowed to change or implement.)
Whenever you hear about the “cloud,” “cloud computing,” or “cloud service,” you think about computing resources that someone else manages, but that is just one cloud deployment model. Often, when we talk about the cloud, we mean the “public cloud.” That is a model in which a cloud service provider owns and manages all the servers, networking, and hardware. We use cloud services to provide scalability, reliability, resiliency, and relieve ourselves of some of that work and to be more cost-effective and reduce upfront costs.
If you use a public cloud but also have your own physical servers or a datacenter, and you wish to use both as one system. This is a deployment model known as “hybrid cloud.” Even if you don’t use the public cloud at all, you could still have “a cloud.” Your own data center could host a “private cloud” if you provide services that abstract away the concerns of the hardware and physical infrastructure.
Why have various cloud deployment models?
Many companies have a significant investment in their existing data centers while they also have an interest in migrating to cloud computing.
Some companies operate in highly regulated industries and cannot simply move wholesale to the public cloud or they may have applications or systems that aren’t designed to operate in the cloud. For example, compliance and data protection laws may define data residency requirements which aren’t satisfied in the cloud or they may be reluctant to move to the public cloud over concerns with regard to compliance and auditability. For these reasons, there are a variety of models to meet the diverse business needs and use cases of a wide range of organizations.
To determine which model could be suitable for you, we need to understand all five models first and identify a variety of use cases in which these might be the best fit. There is no absolute best cloud, but there is a best cloud solution for your use case, your workflow, and your business needs.
1. Public cloud
A public cloud deployment is best identified by the characteristic that you don’t own any hardware or infrastructure, all your resources are provided to you by a cloud service provider. “Public” in this model means that such a cloud is available for the general public, and resources are shared between all users, also known as “multitenancy.”
The biggest advantage of the cloud services are elastic scalability, resource efficiency, and reducing upfront capital investment. To build a platform that intermittently experiences high load.
Without a cloud provider, you would have to have enough resources to handle the load at peak and have resources enough to handle that load, leaving you with a servers that are underutilized most of the time. In that case, you’ve optimized for performance but this is less cost-effective. You might only provision enough servers to handle the average load, but then your application would either fail under high load or simply perform poorly at peak. Your workloads won’t have the resources they need, but you have cost savings.
With the public cloud deployment model, you can have your cake and eat it too, enough resources for load spikes without significant upfront capital investment, remember you’re buying nothing up front. Additionally, you’re billed only for the resources you use, and you can provision resources on an on-demand basis to scale up for bursts of activity with cloud bursting and scaled down in off-peak times with auto-scaling rules. Cloud providers also offer many higher-order services besides simple virtual machines, networking, and storage. Finally, in many cases your systems can auto-scale (up or down) to meet the load your system is under.
Amazon Web Services (AWS), Microsoft Azure, IBM Cloud, and Google Cloud are all popular public cloud providers.
Advantages:
- Built to support workloads of virtually any scale, large or small
- Ease of provisioning without upfront cost
- Massive catalog of services from bare metal to business services
- Cost-effective with competitive pricing between public cloud providers
Disadvantages:
- Shared tenancy (risk of sensitive data exposure to other tenants, ChaosDB)
- Data residency/privacy regulations might not be satisfied in the public cloud
- Pay for everything you use, almost nothing is free. Your datacenter cost is less variable and more fixed.
2. Private cloud
The private cloud deployment model differs from the public cloud model in that it is a dedicated environment for a single enterprise or organization. Hardware and resources are not shared outside your company. The key difference between a data center and a private cloud is how the resources are managed and provisioned.
Having a private cloud means that consumers of your cloud are able to provision resources much like they would in the public cloud. Individual delivery do not purchase the hardware on which their system runs and they expect a resilience in the cloud such that hardware failures should not disrupt their uptime. With an abstraction layer on top of your physical servers, you gain a flexibility similar to a public cloud. As you add new servers to your data center, with a private cloud you add them to your cluster of servers adding to your scalability as a private cloud and keep those details obscured from your consumers, application delivery teams and their ops teams.
Surprisingly, you can also get a private cloud from a public cloud provider. A cloud provider will isolate resources from its cloud and make them available only to you, you won’t share tenancy with other companies in that private cloud, but you no longer have to host the physical hardware and infrastructure or maintain it. Regardless of how your private cloud is hosted the key takeaway is that resources are dedicated to a single organization.
Some well known private cloud providers are: Red Hat OpenStack, Rackspace, IBM Bluemix Private Cloud, Microsoft Azure Stack, and VMware Private Cloud.
Advantages:
- Less risk of exposing sensitive data as tenancy is limited to your organization
- Greater control over data storage residency and data privacy concerns
- Much more restrictive access, increasing security
- Great alternative to on-premise computing
Disadvantages:
- Considerably more restrictive catalog of service offerings when limited to the private cloud
- Pricing is considerably higher as the initial outlay for the cloud service provider and the consumer are both higher
3. Hybrid cloud
Hybrid cloud model is the combination of a public and private cloud. It’s the second-most-popular model since many companies have made considerable investments in hardware of their own and need to use it as they are in the process of cloud migration.
Creating a hybrid cloud means that a company is using the public cloud but also owns on-premises systems, and there is a connection between the two. They work as one system. This model allows for a smooth transition into the public cloud over a longer period of time.
Due to security requirements or data protection, some companies can’t operate only in the public cloud, so they may choose the hybrid cloud to combine the requirements with the benefits of a public cloud. They run mission-critical applications with sensitive data on-premises while also maintaining a public cloud deployment model. Bandwidth between the two clouds is of critical importance if the two must communicate in real-time.
Advantages:
- Enable migration from on-premise to scalable cloud solutions without losing systems that work today
- Reduce the pain and cost in cloud migration while you run out the cost of your datacenter
- Get access to cloud services from your datacenter
- Keep your sensitive data on premise and greater control over privacy concerns
Disadvantages:
- Infrastructure management is complex and challenging
- Migrating between on-premises and cloud services is not always a one-to-one mapping
- Scalability of on-premise systems is still challenging and can cap the scalability of your system
- Outages may be harder to diagnose and debug as the cloud architecture is more complex
4. Multi-cloud
In the multi-cloud model, we use more than one cloud provider at a time. It’s similar to the hybrid cloud deployment model, where you use both the public and private cloud.
In multi-cloud, however, instead of combining private with public, you’d use more than one public cloud. The motivations for a multi-cloud deployment are for redundancy or to optimize cost for preferred technology choices. For instance, consider running Microsoft SQL Server in the Azure public cloud may be considerably more cost effective and easier than running Microsoft SQL Server on compute instances in another public cloud provider.
Public cloud providers have invested considerably in increasing the reliability and resiliency of their services, but no system is immune to defects or outages. Given the resiliency and reliability of a single public cloud provider, multi-cloud deployment could provide even higher availability for your system as it would have extra redundancy. However, the most common reason for deploying multi-cloud is when you need a specific service from one public cloud provider and another service from another public cloud provider.
Advantages:
- Reduce vendor stickiness and lock-in
- Potential increase in redundancy depending on your cloud architecture
- Reduced limits in the catalog of cloud solutions available to you
Disadvantages:
- Moving data in the cloud costs you as you consume cloud service providers bandwidth (AWS Data Transfer costs)
- Requires cultivation of multiple deployment/pipeline strategies for delivering to multiple cloud service providers
- Considerably more complex cloud architecture leads to difficult to observe and troubleshoot systems
- Very challenging to optimize and find cost savings because of the distribution of costs and resources
5. Community cloud
Community cloud is dedicated to a few organizations from the same “community.” Thus, it’s not a public cloud because it’s not open for everyone, but it’s also not a private cloud because there is more than one user/organization using it.
An example of a community cloud could be a cloud that a few different banks use. The biggest advantage of a community cloud is the fact that it can be tailored to requirements for a specific “community.” In fact, you might even think of this as a gated community, it’s not private, but within that community are generally a group of similarly interested or invested consumers.
Advantages:
- Much of the control of a private cloud without all the burden of owning the cloud infrastructure yourself
- Optimize cloud architecture and resourcing for the cloud computing workloads of the community
Disadvantages:
- Still has multi-tenant risks present in the public cloud, but with a smaller blast radius
Cloud service models
Cloud deployment types define how you provision and manage your cloud resources, effectively the different type of cloud offerings. The choice in deployment model is largely influenced by a variety of key factors: pricing or cost savings, privacy concerns, end user needs, data storage and residency, and most importantly your business needs.
No matter how you manage your cloud deployment, there are a variety of cloud service models you consume in the cloud. The offerings and tooling vary considerably between cloud providers but all major cloud providers offer a variety of means of managing your cloud architecture, cloud computing services, and tools supporting your infrastructure management.
For example, imagine you need MySQL server in a cloud environment. You could provision a server, a virtual machine, and install MySQL on it yourself. You’ll be responsible for managing all upgrades, resource allocation, and support of the MySQL server instance. Also, you’ll need to manage the backups, replication for redundancy, and the routing of your requests across instances if you want to ensure greater resiliency.
Alternatively, you could provision MySQL server as a service directly from the cloud service provider where you administer the internals of the server, define resource allocation, but only for your server, not on the underlying hardware or VM. The cloud service provider would own installation, configuration, and upgrades of MySQL server. These are only two examples of cloud service models, there are more and next we’ll dive into those.
At its core, the cloud service model defines which layer of service you manage and which layer the cloud service provider manages. AWS refers to this as the shared responsibility model. As with the cloud deployment models, there is no one size fits all, let’s unpack all three so you can decide which one is best for you. In all likelihood, the answer will be like a buffet—a little bit everything. You can pick different models for different components of your cloud infrastructure so that you can take advantage of higher-order cloud solutions, those services that combine a number of services under the hood, or sometimes you need to be as close as possible to the bare metal and deeply control and manage your resources.
Infrastructure as a Service (IaaS)
IaaS is a cloud service model in which the cloud provider manages the physical hardware (servers, storage, and networking), and you manage the rest. It means that you don’t have to worry about placing servers in the data center, nor connecting those servers to the network, or attaching any storage to them. The cloud provider ensures the hardware is ready to use, reliable, and resiliently configured. You select your operating system and you have full access to the machine on the operating system level and full control over what software to install on it. When you create computing resources, for example, on AWS, Oracle Cloud Infrastructure, Google Cloud, Microsoft Azure, etc., that’s IaaS.
The most important advantages of IaaS are flexibility and virtualization. You can provision a virtual machine ready to use in minutes without concern for upfront capital expense. You get absolute control over the virtual machine and many public cloud providers offer straightforward ways to install a new operating system with just a few clicks. Since you have full control over the machine, you can configure it to meet your workload’s needs or install any software your use case demands. With IaaS you can virtually clone any existing IT infrastructure, creating test environments, disaster recovery solutions, or a redundant replica of your entire entire infrastructure.
Advantages:
- Immense flexibility, you have a machine, network, and storage, do anything you want to meet your business needs
- Almost anything you can do on premise, you can do with IaaS
Disadvantages:
- Significant work involved in managing the IaaS resources - installs, updates, configuration, you own it all
- Challenging to optimize for cost, performance, and security simultaneously
- Risk of noisy neighbors varies based on your cloud architecture
Platform as a Service (PaaS)
As we give some ownership back to the cloud service provider, we move up to the PaaS service model where the cloud service provider manages the operating system and software installed on the machine.
Imagine you’re getting ready to use a cloud platform—for example, managed Kubernetes or Kafka. In this model, you’re not limited to one specific application (for example, if you get PaaS Kubernetes, you can deploy anything you want on it), but you are limited to one specific platform.
The biggest advantage of the PaaS model is that you don’t have to handle all the installation and maintenance efforts of the cloud platform. Installing and configuring a Kubernetes or Kafka cluster optimally can take considerable technical expertise and experience to setup and to maintain.
Advantages:
- Ease of provisioning and resourcing, many platforms can be provisioned for you in minutes
- Cost savings is typical because the cloud service provider benefits from economies of scale
- Reduced complexity in configuration and setup, less expertise required
Disadvantages:
- The cloud service provider manages the platform so you have less control over the platform’s configuration than if you ran it yourself in IaaS
- Platform errors may be concealed from you and make it harder to debug or troubleshoot because you can’t see “inside”
Software as a Service (SaaS)
As we move toward higher levels of abstraction away from infrastructure management, away from operating system management, shifting more responsibility to the cloud service provider, we come to SaaS, where the cloud service provider manages all layers cloud infrastructure.
Consider managed databases, if you use SaaS MySQL, you only concern yourself with your data, access controls, scale, and redundancy as defined by your business needs, use case, and end users. The cloud service provider manages the cloud infrastructure, scalability of underlying hardware, the operating system, the database management system version, and the resiliency of systems to ensure that failures don’t affect your consumption of the DBaaS (database as a service).
The difference between PaaS and SaaS is that SaaS limits you to one specific application (as mentioned, MySQL). The advantage of SaaS is that it offloads most of the engineering effort of a cloud service from you. You can simply deploy a MySQL database and start writing data to it in a matter of minutes. With PaaS, you get a platform that does nothing on its own, but provides a foundation on which you can create something. With SaaS, you don’t need to do anything else to start using it.
Advantages:
- Reduced risk of outages
- The highest order of virtualization
- Cloud service offerings vary by cloud service provider (not easy to migrate)
Disadvantages:
- Optimize for operational efficiency, the cloud service provider owns the cloud infrastructure and the redundancy concerns
- Not applicable for all use cases, less flexible than IaaS and PaaS
- Data residency restrictions may be prohibitive here depending on data privacy concerns since you don’t own where the data lives
Deploying to the cloud
The end goal of all cloud deployment models and cloud service models is ultimately to enable software deployment. Picking the best cloud deployment model and service model ensures the optimal balance between cost, security, compliance, and scalability.
There are so many ways to ship your software now. The ability to release software on-demand, with the same flexibility, scalability, and control as you can with your cloud computing resources is absolutely essential. If you can have new servers, new platforms, or new services under your control in minutes, your end users can’t wait hours to see your software evolve.
The idea of shipping software more frequently is often met with resistance because we lack confidence that our changes our safe to release and we believe that we need more time spent testing. The truth is that code doesn’t age well. Features sitting on a shelf waiting to be tested are already paid for upfront, but aren’t improving your end user experience or adding to your bottomline and may be incompatible with your platform as it evolves if they’re not actively being used or developed.
But avoiding downtime and unexpected problems doesn’t mean you won’t be able to deploy often. There are ways of deploying software often and safely. Both canary launches and dark launches let you limit the risk of the new deployment. The canary launch means that you deploy new software to only a small sampling of users first. You test whether things work as expected, then progressively roll out the change to the rest of the users. This way, if something goes wrong, it affects only a portion of your users.
A canary launch is a type of a dark launch. But a dark launch can also include deploying a feature to production for internal testers while hiding the feature from users. As you can see, the risk of deploying software can be greatly minimized.
LaunchDarkly’s feature management platform allows teams to use feature flags to perform dark launches and canary launches on a large scale and with a great deal of sophistication.
Summary
The cloud has evolved dramatically in recent years. Initially, it was an exotic option without many variations. Today it comes in many flavors from the public to the private and everywhere in-between.
In this post, you learned about different cloud deployment models and cloud service models available. It’s important to remember that, the public cloud isn’t the only option. In fact, for some, running a private cloud in your own data center is probably the best way to manage your IT infrastructure.
No matter what cloud deployment model will suit you best, you still need to pick the right software deployment method. To make good decisions here, learn how to deploy software to the cloud fast and fearlessly via canary launches and dark launches (enabled by LaunchDarkly.) Also, learn how to use LaunchDarkly feature flags to perform smooth, uneventful database migrations to the cloud.
.webp)
.webp)
