Architecture & DesignA Cloud Hosting Versus Private Cloud Comparison

A Cloud Hosting Versus Private Cloud Comparison content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

By Irina Kovalyova


In recent times, we have become used to hearing the word cloud a lot, usually coming from the IT crowd, mostly when they discuss web-based projects and services.

Thanks to them, cloud has become a real buzzword! Cloud this, cloud that, and even common folks are using the word cloud without understanding its real significance. It seems almost as if cloud is used to describe any kind of SaaS product or anything Web-related in some way.

But, there’s so much more to cloud technologies than just that.

Cloud technologies have developed rapidly over the last few years. Most of the big players in IT have already developed and published their own cloud platforms, which they are now actively promoting, such as:

  • AmazonWebServices, from Amazon
  • Azure, from Microsoft
  • Google Cloud Platform, from Google
  • RackSpace, from OpenStack
  • Cloud Hosting, from

But, is the whole thing really such a no-brainer? Is a cloud platform really the most scalable and efficient solution for all of your problems?

Being a software engineer, I’ve been using both cloud platforms and dedicated servers in my work. And today, I want to share my knowledge and experience with you. In this article, we will talk about the pros and cons of using a cloud platform versus doing things the traditional way, using a dedicated server. I will also provide a head-to-head cost comparison based on some typical projects.

Let’s get started.

The Impact of Infrastructure

I believe that the project infrastructure has a key role to play in making a decision on the ideal platform for a product. But first things first; let me give you some input about the general approaches that a software development company can take in terms of the infrastructure of a web product.

For example, any Web startup needs four key infrastructure components:

  • Web Server (servlet container, and so forth)
  • Database Server
  • Storage Server
  • Backup Server

These are the logical components. Of course, nobody will stop you from having your storage, database, and Web server running on same machine. And often, this is how it is done, mainly for two reasons:

  • Mirroring of the product infrastructure at the development stage: “Everything works fine and we fear something will break once we change infrastructure.”
  • It is very cheap and efficient in terms of the initial launch, when the server load is relatively low: “We have bad marketing and no one uses our product anyway.”

So, which is the ideal production environment for a project like this? Based on the above, it is quite obvious to choose a dedicated server (or VDS, VPS, and so on) over a cloud platform.

Bu,t is this really the be-all and end-all? Is it really convenient to start out on a small VPS and move on as you grow? Or, will it really pay off to buy space in a cloud, with an established infrastructure, efficient support, and easy scaling? Maybe you could buy machine time from an auction when it’s cheap?

In the end, it all comes down to the approach that is chosen for the development of the product.

The Impact of the Development Approach

I have already said that platform decisions are dictated by the project infrastructure. But, infrastructure choices also are heavily influenced by the approach taken for the actual software development. There are two general development paradigms for startup projects:

  1. Agile development: Time to Productionrules over everything. Flexibility and quick implementation of features overweigh all other aspects. This approach is often used when you need to develop something really quickly, which needs to go live ASAP; for example, to collect feedback and then decide if the product has a future or not.
  2. Careful development: Quality and Planning rule over everything. The Product is marketed and engineered beforehand, contracts have already been signed, and the project has a guaranteed lifespan. This approach is used when the priority is to deliver the most satisfactory solution for your clients.

The more agile approach prioritizes the rapid take-off of a project and enables you to start making money as soon as possible. Any concerns about the infrastructure and the potential growth come second, so everybody just sort of hopes that scaling won’t become a problem in the future. Thinking like that usually leads you to using a VDS/VPS for delivery.

So, what happens with such a product after the initial deployment to a small dedicated server? Well, if a product does not prove popular, it can simply be shut down. But if a growing user base establishes itself, you soon arrive at a point where you need more resources than your server can provide, which obviously should be ignored at your peril. A lack of system resources heavily affects the user experience in the most unpleasant ways. And, a bad user experience can and will kill your new product really fast.

What would be the right thing to do in such a scenario? Well, the next logical step would be vertical scaling. This means purchasing more cores, more RAM, more storage, more bandwidth, more of everything for your own server. You may also want to get yourself a backup server, because no one wants to lose user data.

The problem is that vertical scaling has its own technical and financial limitations, so if your project continues to grow, sooner or later you will have to think about horizontal scaling (for example, one or more additional servers). And, the chances are quite high that your product is not prepared for such a type of deployment as is, and the whole thing is not as easy as just running two or more instances of a product and calling it a day. So, at the same time as pumping up your first server, you have your development team actively refactoring the product, changing its architecture to provide support for horizontal scaling. This in turn means more bugs, more testing, and higher development costs. And, your backup server is not just a black hole where you toss things, but it also needs looking after in the form of upgrades and maintenance.

So, even if such a minimalistic approach pays off at the start, if you then hit a sweet spot with customers and your product becomes really popular, this approach would result in more problems than benefits, to the point when it can harm the popularity of your product.

So, is there a better alternative? Let us take a look at the Careful development approach.

The Careful development approach usually implies that you’ve made sure beforehand that your business model works. The product has already been marketed, so you expect it to be quite popular and obtain a certain market share. The other scenario is when you need to develop a corporate or government solution that will have a guaranteed lifespan. That means that you don’t have the right to mess something up and then fix it after the launch, because the product will already have a pretty large user base from day one. In this scenarios, any issues will severely affect the product’s reputation.

Based on these implications, the Careful development approach prioritizes guaranteed delivery, product quality, and long-term planning. You usually have a fixed release date and feature delivery schedule, which means there is no need to rush to get your product to a wider audience more quickly than potential competitors. And, as there is a set budget, there is no need to cut down development costs that much. You spend additional time and money to deliver the best possible product, you plan ahead to make sure that no feature implementation will become a problem, and you cannot mess anything up. This means that the QA periods will be longer and maybe a beta version of the program will be used for testing.

So, you invest time and money for the sake of the product’s quality, and it all starts with project architecture and infrastructure. You estimate the expected load, plan for upgrades, and project the potential growth of the solution. Here, a cloud platform would be an obvious choice. There is a general infrastructure already built for you, and you don’t have to administrate and maintain individual servers or mechanisms for backups and deployment. It provides easy scaling, and all the trivial stuff is already taken care of for you. It makes things much easier for you, but it costs more from the start.

Each one of the development approaches has, of course, many other pros and cons, but here I focused on the impact on infrastructure decisions and whether it is wiser to use a set of dedicated servers or a cloud platform.

Let us now summarize the pros and cons of each delivery method.

Pros and Cons

No matter which delivery method you choose for your product, in any case you need to estimate the hardware requirements for the initial project deployment.

Should you choose a dedicated server, especially a non-virtual one, it is very important to calculate everything correctly, because such a server can fail pretty quickly under heavy load. On the other hand, you also don’t want to pay tons of money for a server that is idle most of the time. If the popularity of your product fluctuates, you can either kill the growth of your product when resources are scarce, or lose part of your profit due to large maintenance fees of a powerful server. Choosing a virtual dedicated server over a real one makes things far less dramatic, as you can react faster to a changed demand of your product. However, even in this case it can be a never-ending story of expansions and reductions of the system resources, which can be annoying.

With a cloud platform, your resource management becomes far smoother and you can be more efficient in terms of resources and machine time costs without the need to micro-manage everything. Cloud platforms also have established replication mechanisms so you don’t need to fear for hardware failure quite as much. But, as always, this convenience comes at a price.

Following, you will find a summary of the pros and cons of dedicated servers compared to cloud platforms:

The pros of a cloud instance:

  • Pay for used resources only
  • Unlimited number of virtual instances (scaling)
  • Unlimited disk space
  • Dynamic instances scaling depending on load
  • Fast and easy software deployment
  • Fast recovery during hardware fail-over
  • Automated backups

The cons of a cloud instance:

  • Storage is quite expensive
  • SQL storage is expensive
  • Bandwidth is limited and expensive
  • Lower performance versus a dedicated server instance
  • No hardware control
  • No access to servers and data when not paid

The pros of a dedicated server:

  • Cheaper disc space and SQL storage
  • Bandwidth is cheap
  • Great performance
  • Full hardware control

The cons of a dedicated server:

  • Physical instance scaling limit
  • Hardware failures
  • Limited storage space
  • Unused power spent
  • Additional cost for administration

So, some things will always be more expensive, while others are cheaper, depending on the path we chose. But let us look at the numbers, and to the main part of this article—the comparison of costs and maintenance fees.

Thoughts on the Calculation of Costs

Right now, a precise cost analysis for having your product running in the cloud is quite difficult, because competition is very high. Every provider has their own special pricing schemes, promotions, and the like. But, then again, due to this high competition and general drop of the cost of machine time, the overall investment needed for the cloud is becoming less and less.

On the other hand, dedicated servers are part of a well-established market, so here the analysis of the individual providers is quite straightforward. Nevertheless, this should not be a key factor in making a choice between a cloud platform and a dedicated server.

As mentioned above, there are two major problems with dedicated servers:

  1. You can have load fluctuations, which can require a constant resizing of the resources for the product to be efficient.
  2. You cannot scale your server vertically forever. Sooner or later, you will need to scale horizontally; for example, move a database server to a separate machine, set up a load balancer and caching. You will encounter storage problems and at some point need to configure shadowing, performance monitoring, and a reliable back-up routine. The more your project grows, the more problems and additional costs can arise.

With the cloud, it is a completely different story. With AWS or Azure, it is significantly easier to manage your system resources. You easily can get more instances of databases or web instances and set up load balancing with only a couple of clicks. You also have the possibility of automating tasks such as launching and shutting down additional instances based on the current system load.

Keeping the system’s software up-to-date is also a simple process that won’t take up too much of your time. And, there is no such thing as a single point of hardware failure in the cloud. If there is a hardware failure of any sort, the probability of data loss is much lower than with storage based on the dedicated server. And, of course, such important things as replication, backups, and backup management are automated, too. Your users usually won’t even notice it when the system switches to a fallback server.

Clearly, the whole process is a lot less fun with a dedicated server. At least, one that’s “out of the box.” If dedicated servers are set up properly, you can get a comparable experience. The problem is that it takes a really good team to achieve that.

On the other hand, many cloud platforms provide complete migration mechanisms, so if you are unsure how fast your project will grow, it is quite easy to start with a small VPS and make the move to the cloud later.

Okay, so let us now proceed to an actual head-to-head comparison of costs. For this purpose, I have chosen two standard products. The first product is a typical corporate portal and the second one a heavy-load SaaS product.

Comparison of Expenses

In this section, I will take a good, detailed look at the performance, storage, and bandwidth requirements for the two projects described above: a typical corporate portal and a heavy-load SaaS product.

Cloud Expenses

Figure 1: Infographic describing the pros and cons
Please click the image to see a full-size version

Here, we can observe that the pricing changes dramatically for high-load projects. Choosing the cloud path right from the start is much more expensive right now, whereas it is much cheaper to use a bunch of dedicated servers, even considering the additional maintenance and administration costs.

It is therefore reasonable and recommended that you think about building and maintaining your own infrastructure, at least for the start of a project. (You can always migrate to the cloud later, if you feel that the benefits outweigh the price.) On the other hand, if chances of a miscalculation on your side are high and you don’t have much experience in the proper planning of an infrastructure, or if you expect a high load from day one, it is much safer to use a cloud platform, because lower fees won’t compensate for the denial of service in case of a server overload or failure. However, even for a large setup, having your own infrastructure can have many benefits and saves you money, if things are done properly.


Considering my experience and the general nature of the products which we deliver, for now I will side with dedicated servers rather than the cloud.

Having said that, I am aware that cloud platforms are evolving ever so quickly, and that new, convenient features and services are added to them every day, while the fees for those solutions are becoming lower and lower. With machine time getting cheaper and cheaper, I can confidently state that cloud platforms are the future, and that sooner rather than later, most Web projects will be based in the cloud.

I hope that with this article I have managed to help you to understand more about the pros and cons of cloud platforms and dedicated servers. Hopefully, you now better understand the reasons for choosing one over the other, too.

Author Bio

Written by a group of developers from Redwerk Company, who enjoy sharing their knowledge of different software development aspects including Web development, mobile technologies, and others. Redwerk is a team of about 40 developers specializing in different technologies and who are keen on contributing their expertise to specialized media sources.

If you want to connect: Facebook, LinkedIn.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories