What's the difference between Cloud-based and on-premise solutions, and which should you choose?

Cloud solutions align with the trend of simplifying everything on the internet.

In the past, when you wanted to deploy an app, you had to have your own server somewhere, and you had to be able to set it up from the ground up and maintain it. Today, at least to some extent, you don't need to know anything about configuring or maintaining a server because everything can be handled by a Cloud provider, such as AWS, Azure, or Google Cloud.

Does this mean, however, that Cloud is clearly better than on-premise solutions? Not necessarily. In this article, I will describe the essential features of both approaches.

Yet, if you want a tl;dr answer to the question stated in the topic: it depends, but you should probably use Cloud-based solutions or at least give them a try.

Cloud is usually easier to manage

In the beginning, let's note that Cloud and serverless solutions don't mean the lack of a machine because somewhere at the end of the rainbow, there is always a physical server. However, the most significant difference between AWS or Azure advanced hosting services, and a dedicated server is the approach to development.

As a rule, you are relieved of many administrative issues with Cloud-based solutions. For example, if you don't want to, you don't have to be interested in how many physical machines you have, what kind, and how to maintain them. Likewise, you don't have to worry about installing the database service, scaling the server manually, or doing backups.

With Cloud-based solutions, you get access to an admin panel and console utilities with multiple ready-to-use services that can make your work easier. Lambda, a tool for building serverless microservices, is a great example. Even if you know little about AWS, with Lambda, you can run code for any app with minimal configuration overhead.

Suppose you wanted to do it on an on-premise server. In that case, you'd have to configure all the required services and infrastructure, where some operations like scaling might be significantly challenging to implement correctly.

Lamda is just one example, which presents the benefits of using Cloud-based services since it's one of the closest to the 'serverless' approach, but there are many more. In AWS (the Cloud platform we use most often in OG), you can choose from several services to run a database (relational or NoSQL), a service for user authorization, multiple utilities for video streaming, or a CDN for serving files and caching your web applications.

You don't have to worry about many standard administration routines related to doing these things on your own. And since you have all these services within one architecture, you get minimum latency times, too (at least, that's what we want to believe in).

You have to learn Cloud solutions constantly

Considering everything I wrote above, if you want to put a very advanced architecture on AWS, it's crucial to be very familiar with this solution and be up to date with its services. You must know which ones to choose and how to combine them. And it's not that easy because new solutions come out very often, and some require a rather complex configuration to be efficient.

While how you deploy apps to on-premise servers has stayed mostly the same for several years (well, maybe apart from introducing Docker in the mix), Cloud providers regularly release new solutions. Many of them, in theory, do the same thing, and you have to consider whether it's beneficial for you to move or stick to the ones you used before.

For example: if I now google how to deploy Django to AWS, top results may point me to do it manually using an EC2 machine (the least optimal way btw.) and suggest many different ways of doing so. Which is best for my specific case? I will only know if I stay up to date with AWS services and, ideally, have experience with most of the valuable options to choose from.

On-premise is cheaper, but…

Setting up and maintaining your own server long-term is often cheaper than Cloud-based solutions. However, there is a 'but' – this usually only applies if we try to mirror the computing power and other resources into counterpart services of a Cloud provider.

If we skip that assumption, this can easily be false. A great example is a situation where our application has variable traffic that we can predict or scale fast enough to handle without degrading user performance. Using Cloud-based services optimized for fast scaling, we can keep the resources on a lower level and either periodically spin up more instances in the time of expected peaks or scale dynamically depending on our custom-defined metrics.

This will often significantly lower our costs compared to keeping a beefy dedicated server running the whole time while not utilizing its resources. And that's not all there is to it.

With many computing-focused services, we can also use spot instances, which cost up to 70-80 percent less, with the caveat that they might be decommissioned at any time, and our application will have to be migrated to different instances. If that's not a problem, we can lower the cost of the additional computing power even further.

Cloud solutions make you dependent on one supplier

The biggest disadvantage and potential threat associated with the Cloud is the commitment to one provider. Once you bet on AWS or Azure, with each subsequent change, you dive deeper into the network of services of this provider. Theoretically, you can lift and shift most services to dedicated or hybrid servers or a different Cloud provider. Still, in practice, it may be a long and not exactly painless process.

So once you go Cloud, you (probably) never go back.

On-premise may be less safe, but...

Theoretically, due to the popularity and availability of Cloud servers, if you choose this hosting solution, you decide to depend on the safety of their infrastructure. And since they are as big as they are, they are often chosen as prioritized targets for multiple attacks.

Also, sometimes a tiny misconfiguration error on their end might also break it. It has happened several times, effectively rendering many online web services inaccessible to the world.

In practice, however, for on-premises to be secure, you need to know how to do the heavy lifting on the system and network since your machine may be connected directly to the internet.

It doesn't mean that this is never the case for Cloud-based solutions. However, they usually allow us to rely on some built-in solutions that put the responsibility on the provider and give us tools to build a highly-secured isolated architecture e.g., by designing our application inside a VPC (Virtual Private Cloud) and explicitly defining the access policies for all our services.

Therefore, keeping your information in the Cloud will be safer if you are unfamiliar with server security and don't have a dedicated security specialist or team. Just make sure to follow the provider's precautions, such as AWS Well-Architected Framework.

I should also mention that running applications and services in the Cloud doesn't exclude the risk of potential hardware failure and data loss. However, most providers allow us to design our infrastructure to run redundant instances ready to take over in the case of failure, with minimum reaction time.

Of course, this can be done on on-premise solutions as well, but configuring is usually much more complex and requires specific skills and experience. In the case of the Cloud, it can be as easy as enabling some options in the provider console.

So what's the better choice in the end?

Cloud is usually easier to manage and scale and provides a range of services that simplify the lives of developers and administrators. However, with complex architectures, it's no longer so easy to use, but not to the advantage of on-premise solutions.

Advanced IT architectures are complex tasks to execute in both ways. Still, it’s also easier to build teams with Dev-ops skills in AWS, Azure, or GCP than in a self-managed approach.

Cloud solutions may have a steep learning curve for beginners, but it's definitely worth a try. Also, we believe it's essential to utilize the Infrastructure as Code approach and to manage your infrastructure with tools like Terraform.

Even if the Cloud is a bit more expensive, we still choose its reliability and scalability in most commercial implementations. The most common situation in which we don't go with this approach is when the project has to fulfill a specific requirement to be self-hosted (for instance, because of law regulations).