Cloud Deployment Models: 3 Helpfully Explained
Reading time 13 minutes
Microservices, Kubernetes, and the cloud are hot topics these days. Many companies are moving to Kubernetes and then to the cloud or the other way around. There are many reasons for that. The cloud gives you many benefits. But what if your company can’t move to the cloud yet? Are you doomed to stay with your ordinary on-prem infrastructure? Do you need to forego all the cloud features? Not at all! When we say “running in the cloud,” we usually mean “running in a public cloud,” which is one cloud deployment model. But there are more. And guess what? You can have a “cloud” in your on-prem data center. You can also combine your on-prem system with the public cloud. In this post, you’ll learn about all these different cloud deployment models.
What Is a Cloud?
Before we dive into explanations of all the possible cloud deployment models, we need to discuss what it actually means to “run on a cloud”. This is because it’s not as simple as you may think. Having that clear will also help you understand how we can have different cloud deployment models. It will also clarify what it means to have a cloud on-prem. Let’s get to it, then!
When we talk about the cloud, you probably picture Google Cloud, Microsoft Azure, or Amazon AWS. These are the three most popular cloud providers, but there are dozens of different companies that host their own cloud. You also may have heard that the cloud is “just someone else’s computer.” These two common cloud associations create a picture of a cloud as resources (like servers, databases, storage) that we only rent and do not own. This is a common misinterpretation of a cloud. It is, however, a valid representation of a public cloud.
But there are also private clouds and hybrid clouds. With the public cloud model, these are the three most popular ways to deploy to the cloud. So what does “the cloud” actually mean if not using Google Cloud, Amazon AWS, Microsoft Azure, or any other public cloud? Wikipedia defines cloud computing as “on-demand availability of computer system resources, especially data storage and computing power, without direct active management by the user.” And that’s a pretty good definition. You see, having “a cloud” means having an abstraction layer on top of physical servers and using self-service systems to request and manage your infrastructure. It doesn’t matter if you own or rent the servers—the only thing that matters is how you manage them.
Say you log in to a web portal or cli and request a virtual machine, which is then automatically provisioned for you. After you finish using the virtual machine, you can delete it yourself too. If this sounds like your setup, you’re on a cloud. But keep in mind that the cloud requires automatic provisioning of virtual machines. Sometimes, you can use a web portal to request a virtual machine—but instead of automatically providing it, the portal creates a ticket for a data center technician to manually create that machine for you. That’s not the cloud! The cloud is all about automation and on-demand provisioning.
The type of cloud you have is defined by whether these provisioned servers are in your data center or somewhere on the internet. For example, if you own the servers, you’re probably on a private cloud. And if the servers are provided to you by another organization, you’re probably on a public cloud. Now that we have that clear, we can discuss different cloud deployment models.
We mentioned before that when people say “the cloud,” they’re usually talking about a public cloud. That’s because a public cloud is the most popular cloud deployment model. So what’s a public cloud, exactly? It’s resources that we can rent from third-party vendors over the internet. When you don’t own any of the servers and everything you use is in the cloud provider’s data centers, not yours, that’s a public cloud.
Take Microsoft Azure’s cloud, for example. Let’s say you want to run an application, which needs a few servers, a load balancer, databases, and storage. You can simply open the Azure portal, add your credit card details, and request all of these resources in a few minutes. They will be provisioned by one of the Microsoft-owned data centers, and you’ll be paying Microsoft for the ability to use these resources. That’s a typical public cloud model. It’s public, meaning everyone can register and use resources in the same way you do.
What are the advantages of using a public cloud? First of all, it’s effortless and quick to provision even dozens of servers and other resources. You don’t need to buy all the servers yourself, then wait for the delivery, and then bother with installing and configuring them somewhere. You also don’t need to worry about hardware failures. Cloud providers have you covered. If something bad happens to the resource you rent, you’ll simply get a different one. Also, since most public clouds offer a pay-per-use model by default, you don’t need to spend thousands of dollars upfront to buy all the hardware you need. You also don’t need to worry about scaling. Your on-prem data center has a limited capacity by design. Once you reach the limit, you’ll have to build the next data center. In the cloud, you are pretty much limitless. And speaking about expanding, the public cloud offers you great flexibility.
In your own data center, you’ll probably waste a lot of resources because you’ll have to keep however many servers it takes to ensure your site stays up during the busiest times of the year. You’ll need to have that capacity all year long, even though your traffic spikes may only last a few weeks, days, or even hours. For example, retail sites see explosive traffic on Black Friday and during the Christmas period. In the cloud, you pay per use. That means that you use only as many servers as your baseline traffic demands, and you can scale up when necessary. Once the spike is over, you can simply delete the extra servers, and you won’t be paying for them anymore.
Sounds great, right? Well, there are some disadvantages too. Ironically, cost is one of them. If you’re not careful, paying for public cloud resources may be more expensive than you would hope. There can be multiple reasons for that: a poorly written query to the pay-per-transaction database, for example, or unlimited autoscaling and a DDoS attack. Also, it’s all too easy for your developers to create resources themselves, so if you don’t apply enough quotas and limitations, you may end up with many more servers than your company needs.
Another thing is that all clouds change. Vendors release new features, API changes, and streamlined services. Therefore, you’ll have to periodically evaluate whether your business needs still align with these changes—and be ready to change providers if they don’t.
Last but not least: Understanding all the cloud services and their limitations is not a piece of cake. Big cloud providers offer dozens of different services, and there is usually more than one way to achieve the same goal in the cloud. It’s more complicated than a typical on-prem environment. Because of that, you’ll have to invest in training.
As you may guess, on the other side of the spectrum, we have a private cloud. If you don’t use any public cloud offering and you have your own data center, you don’t need to run it in a typical, old-fashioned on-prem way. You can transform your data center into your own private cloud. You can do this by installing a private cloud management software that will take all your servers and network devices and manage them in a “cloud way.” In other words, your users will be able to use your data center the same way they would use the public cloud— typically by logging into some web UI where they can create, scale, and destroy resources as they wish.
And as an operator of a data center, cloud management software makes this easier for you too. You no longer need to spend hours planning, installing, and configuring each new server to serve a specific role. You can simply install an operating system on the server and connect it to the network. The private cloud software will take care of the rest. The most significant benefit of a private cloud is that you don’t need to waste all the resources you’ve gathered over the years. You can give them a new life with a private cloud. And your developers can get almost all the benefits of the public cloud. Moreover, even if you plan to move to the public cloud in the future and gradually decommission old hardware, you can create a private cloud to get used to the new way of working in the meantime.
Things to Consider
In theory, a private cloud is a perfect solution for companies that don’t want (or can’t) move to the public cloud. A private cloud does, in fact, bring most of the public cloud benefits to your data center. However, you won’t overcome some of the fundamental limitations of a physical data center. A private cloud will help you utilize your servers more efficiently, but it won’t give you as many scaling possibilities as the public cloud. You will also be limited to simple resources like virtual machines, maybe some container orchestrators, and the storage you own. You won’t get all the new and different public cloud services.
Finally, changing your data center to a private cloud is a tremendous job. You can’t simply redeploy the whole data center as a private cloud because you’ll have to somehow keep your company running in the meantime and then migrate the data. Therefore, implementing a private cloud can take not only months but sometimes even years.
Last but not least, consider the hybrid cloud. As the name suggests, a hybrid cloud is a combination of two management models: a public cloud and traditional on-prem infrastructure. With a hybrid cloud, you’re using both as one system.
In the previous section, we explained the concept of the private cloud. Private clouds are wonderful solutions for many organizations, but implementing a private cloud requires making a lot of changes to your whole infrastructure, which some companies can’t afford. However, they still want to benefit from cloud computing. Therefore, they make a private link between the cloud and their on-prem hardware.
A hybrid cloud also comes with great security and compliance. Due to security requirements, some companies can’t fully move to the public cloud, even if they would like to and have the means to. A hybrid cloud lets them meet their requirements by keeping the most critical data on-prem while the rest of the infrastructure uses a public cloud.
That said, a hybrid cloud is usually a stepping stone for companies who have already decided to move to a public cloud but have too many data centers just to stop using them. No matter your reasons for using a hybrid cloud, the concept stays the same. You keep using your on-prem infrastructure, but you also use the public cloud for some functions. You also create a private connection between your on-prem installation and the public cloud of your choice. Different cloud providers offer various solutions for that. It can be in the form of a simple VPN connection to advanced, totally private links that bypass the public internet and connect directly to the cloud provider network from your data center.
The Dark Side
A hybrid cloud sometimes seems to be a perfect solution for some companies. However, while it does have many advantages, there are also things that you need to be aware of. First of all, you’re not getting any advantages on the on-prem side. You’ll keep using your on-prem servers in the old-fashioned, slow, and probably inefficient way. Some of your application teams may end up in a not-so-nice hybrid situation where their application will have to connect to both on-prem and cloud resources, leading to increased complexity. A little bit of frustration may arise when people start to work in the cloud but still have to deal with old on-prem resources. Once they see the benefits of the cloud, they may find it hard to continue working the old way.
Unfortunately, it’s also really easy to use a hybrid cloud inefficiently. Specifically, managing the public cloud in the same way you managed your old on-prem infrastructure leaves money on the table. Expanding an on-prem resource usually leads to long processes of requesting new networks and firewall rules, which are often very slow. Using the same method for the public cloud nearly defeats its purpose. If your developers will have to wait for days or weeks for the firewall rule to be accepted on the on-prem side, then the ability to quickly create resources in the cloud has little added value.
Double the Infrastructure Work
What’s also specific to the hybrid cloud is the fact that you’ll have to manage two completely different environments—probably using different tools and processes. This means double the infrastructure automation work and a lot of potentially challenging alignment between on-prem and cloud teams.
Fortunately, for this specific problem, there are some tools that can help you. Plutora has a tool that can help you increase the visibility info your hybrid environments and not lose track of what’s where. From the operation teams’ perspective, it may be clear where the on-prem apparatus ends and where the cloud starts. From the developers’ perspective, however, it may not be so obvious. Having different test environments for the application on-prem and in the cloud can lead to some confusion. Plutora can help you avoid that. Centralized environment scheduling and a self-service system can drastically improve developers’ workflow in hybrid cloud environments. Click here to learn more about the Plutora Test Environments Allocation tool.
In this post, we clarified that “the cloud” doesn’t always mean “a public cloud.” We also explained the three main cloud deployment models. If you got this far, we’d bet you’re interested in moving to the cloud. We hope our tips help you pick the model that’s most suitable for you. If you happen to decide to go to the public cloud, like most companies nowadays, you’ll probably end up in a hybrid cloud environment first. If that happens, remember that Plutora can help you navigate the complexity and uncertainty that arises when transitioning to hybrid cloud environments.