Cloud Deployment Models: Explaining and Comparing the 5 Main Models
What are cloud deployment models?
A cloud deployment model defines where the servers you’re using are and who manages them. It defines what your cloud infrastructure looks like, what you can change yourself, and whether the services are provided to you or you need to build everything yourself. Cloud deployment models also define relationships between the infrastructure and your users (what users are allowed to change or implement).
Whenever you hear about the “cloud” or “cloud computing,” you think about computing resources that someone else manages. But that’s just one of the few cloud deployment models. There are others, too. Typically, when we talk about the cloud, we mean the “public cloud.” That’s one of the cloud deployment models in which a cloud provider owns and manages all the servers (and other hardware resources).
However, say you use a public cloud but also have some physical servers you own, and you wish to use both as one system. Then we’re talking about a “hybrid cloud”—another cloud deployment model. Even if you don’t use the public cloud at all, you could still have “a cloud.” Your own data center could become a “private cloud” if deployed and managed in a specific way.
All of these options are different cloud deployment models. Basically, the way you use and provision your cloud infrastructure defines which cloud deployment model you use. But it’s important to mention that from the user’s perspective, there should be little difference between all models. For example, a “private cloud” in your data center has to provide similar options and features as a public cloud. Similarly, if you use a public cloud and your own data center separately, then it’s not a hybrid cloud.
Why are there different cloud deployment models?
You may ask, why do we have all these different cloud deployment models, and which one is good for me? Well, we have these models because cloud computing is very efficient and has become very popular.
At the same time, companies try to use their existing data centers with the same efficiency and features. Some companies can’t just move to the public cloud for different reasons. For example, compliance and data protection laws may bar them from using the public cloud. Or they may be reluctant to move to the public cloud simply because they previously spent gobs of money on their own servers, and they want to get use out of them. That’s why we have a few cloud deployment models to facilitate all the possible scenarios.
To determine which cloud deployment model could be suitable for you, we need to understand all five models first.
1. Public cloud
The public cloud deployment model is the most popular type of cloud. It’s also the one that people think about when they say “cloud.” The basic principle is that with a public cloud, you don’t own any hardware. All the resources are provided to you by a cloud service provider. So to start using the public cloud, the only thing you need to do is to create an account. “Public” in this model means that such a cloud is available for the general public, and resources are shared between all users.
The biggest advantages of the public cloud are scalability, efficiency, and that you don’t need to purchase your own hardware. Imagine you build a platform that occasionally experiences a high load. Without a cloud, you’d have to make some sacrifices. One option would be to buy enough servers to handle the load at peak. But that would mean that most of the time, all those servers would be underutilized. Another option would be to buy only enough servers to handle the average load, but then your application would be performing poorly with occasional spikes. With the public cloud, you can have both—enough resources for load spikes without significant upfront investments. In addition, you’re billed only for the resources you use, and you can provision resources on an ad-hoc basis when needed and even have load-based autoscaling. Cloud providers also offer many public cloud services besides simple virtual machines and storage.
Amazon Web Services (AWS), Microsoft Azure, IBM Cloud, and Google Cloud are just a few examples of a public cloud.
2. Private cloud
The private cloud deployment model is the opposite of the public cloud. It’s a dedicated environment for one user (customer). You don’t share the hardware with any other users—in fact, most commonly, all the hardware is yours. What’s the difference between a “typical/ordinary” on-premises data center and a private cloud, then? The difference is in the way you manage all the hardware.
A private cloud is when you manage your data center in a similar way as the public cloud providers do. You create an abstraction layer on top of your physical servers. This gives you flexibility similar to a public cloud. If you add new servers to your data center, with a private cloud you won’t have to worry about configuring them—they’ll (semi)automatically become a part of the cluster. You can also get a private cloud from a public cloud provider. This means that a cloud provider will isolate some resources from its cloud and make them available only to you. But no matter if you have your private cloud in your data center or from a cloud provider, the point is that resources are dedicated to a single organization.
Red Hat OpenStack, Rackspace, IBM Bluemix Private Cloud, Microsoft Azure Stack, and VMware Private Cloud are a few examples of a private cloud.
3. Hybrid cloud
As you may have guessed, a hybrid cloud deployment model is the combination of a public and private cloud. It’s the second most popular model since many companies already have some hardware of their own and would like to use it. 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 is a very useful model that 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 having all the rest in the public cloud.
4. Multi-cloud
Another cloud deployment model on our list is multi-cloud. In this model, as the name suggests, we’re talking about using 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. Why would you do that, you ask? Mainly for redundancy. Public cloud providers offer many options to increase the reliability of their services, but accidents still happen. It’s very unlikely you’d have an incident at the same time in two different clouds. Therefore, multi-cloud deployment gives you even better high availability of your services. Another reason for using multi-cloud is when you need a specific service from public cloud X and another specific service from public cloud Y.
5. Community cloud
The last cloud deployment model we’ll discuss is a community cloud. Maybe you haven’t even heard about it before, and there’s a reason for that. This 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.”
Cloud service models
So far, we’ve discussed different cloud deployment models. They define how you provision and manage hardware. But no matter how you do this part, there are different cloud service models available as the next step for your cloud environment.
What does it mean? Imagine that you need, for example, a MySQL server in a cloud environment. You could create a virtual machine and install MySQL on it yourself. You would have to take care of all the configurations and upgrades in the future. Another option would be to request a MySQL server directly from the cloud service provider. A cloud service provider would install, configure, and manage a MySQL server for you. These are two examples of cloud service models.
Simply put, the cloud service model defines which layer of service you manage and which layer the cloud service provider manages. All the models have their pros and cons, so let’s discuss all three so you can decide which one is best for you. Also, we need to mention here that you don’t need to pick one service model for everything. You can pick different models for different components of your cloud infrastructure.
Infrastructure as a Service (IaaS)
IaaS is a cloud service model in which the cloud provider manages the 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 do you have to worry about connecting those servers to the network and attaching any storage to them. Basically, the cloud provider will make sure that the hardware is ready to use. You’ll get a virtual machine with the operating system you pick. You’ll have full access to the machine on the OS 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, Azure, etc., that’s IaaS.
What are the advantages of IaaS? Simplicity and flexibility are the biggest. With one click of a button, you can get a virtual machine ready to be used within a matter of minutes. Do you need to reinstall the operating system? Another few simple clicks or API calls, and your machine is ready again. Another advantage: since you have full control over such a machine, you can configure it as you like or install any custom software you may need. With IaaS you can pretty much clone any existing IT infrastructure, creating, for example, test environments or disaster recovery solutions. Cons? Well, you have to maintain everything yourself. If you only need a MySQL server, you have to secure your operating system, install your MySQL server, and configure it.
Platform as a Service (PaaS)
PaaS is when you don’t manage the operating system and software installed on it. In PaaS, a cloud provider also manages these. 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 can take a few hours. With PaaS, you can get it in a few minutes. Cons? Since a cloud provider manages the platform, you’re a bit limited. It may not be possible to get a very specific, customized configuration for your platform.
Software as a Service (SaaS)
SaaS provides you with an even higher level of abstraction. With SaaS, a cloud provider manages pretty much all layers of cloud infrastructure. For example, consider managed databases. If you use SaaS MySQL, you only need to care about the data in that database. You neither need to create a virtual machine nor install MySQL on it. All of that (together with future upgrade and maintenance) will be done by a cloud provider.
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 from you. You literally can just 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. It only enables you to create something on the platform. With SaaS, you don’t need to do anything else to start using it. The disadvantage is that usually, SaaS offerings are a bit more expensive since the cloud provider needs to do all that work for you.
Deploying to the cloud
Now that you know all the cloud deployment models and cloud service models, let’s talk about software deployment. At the end of the day, that’s what really matters. Picking the right cloud deployment model and service model helps you use the resources optimally. But the business benefits come from effective software deployment. It won’t matter that you can deploy a platform in mere minutes if your deployment process takes an hour.
There are a few ways you can deploy your software. Nowadays, the ability to deploy software quickly and often creates real business value. Companies that can’t deploy new features or bug fixes at least once daily will fall behind the competition. Some companies are afraid to deploy software so often. This is due to possible issues and downtime. They choose the safer option of deploying less often with more testing and preparation upfront.
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 percentage of users first. You test whether everything works correctly, then gradually roll out the change to the rest of the users. This way, if something goes wrong, it affects only a small percentage of 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. The very basic example of the dark launch of a new homepage index.html would be to deploy it with a different name, like index-v2.html. All users would still access index.html while you, and maybe your testing team, would use index-v2.html. 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 changed drastically over the years. At first, it was just an exotic option without many variations. Today it comes in many flavors, and it’s even possible to create your own private cloud in your data center. You learned about different cloud deployment models and cloud service models available. It’s important to remember that, nowadays, 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.
