Another false battle - On-prem and the public cloud

What costs coming from your infrastructure choices are not visible to you?

The “public cloud versus on-premise infrastructure” debate has picked up steam again. While the topic itself is worth discussing, the conversation so far has been skewed towards the public cloud. Businesses tend to aim towards simplifications and a general recommendation for the best solution – even when such a solution does not exist. In this outline, I offer several reasons why, and I try to provide guidance for your organization to determine which path to take.

In the last couple of months, we have seen a backlash. There are many new articles and messages circulating that are questioning the public cloud. The central concept is that when you use the public cloud, you rent someone else’s computing power and networking devices. The writers assume that renting is much more expensive than buying and installing your computers in some room. Suddenly opinion-makers think it's a good idea for companies to ditch the public cloud and return to having their server rooms so they can enjoy cheap computing power in a blink of an eye.

Many new infrastructure tools are said to help you achieve a unique on-premise private cloud that you can use for good and cheap. Is this assumption correct? I am still trying to figure that out.

It's going to look like the microservices and monolith debate. Companies that enjoy the benefits of microservices have particular needs. If you don't have those needs or the personnel for maintenance, the change might hurt you more than you can imagine. On the other hand, the monolithic architecture has its limitations too. But what's best for you? Only you or someone who would put much effort into understanding your needs can know. Only some companies need to deploy as often as Google, and most companies can't, even if they would need to.

Before I go forward: I am not writing this article to say “Please stay in the public cloud”, but to ask for something else. I advocate for people to think and define their needs by themselves and be critical of their constraints – whether they are architectural, technological, or cultural. In our business, one size only fits some, and sometimes many sizes only match some.

As a personal example, I have worked in IT and software development for over 20 years. I worked mainly as a QA engineer and system administrator. In most of my roles, I was one of the few people responsible for the data center or server room. Sometimes, I volunteered for that work. Having long days alone in a room with many servers and an intense air conditioner is excellent when you live in the Middle East and you are an introvert.

However, I remember how hard it was to maintain all those servers, to update their operating systems and the software they run. In those days, we used bash scripts, which worked fine until something did not work. A few years later, we had configuration management tools like Puppet that shifted our time into maintaining the modules we used to write so we could make the software run. We had to move offices once, and it took us two weeks to get everything working. Nowadays, we have better tools to make our on-prem environments much more efficient and reliable, but they demand colossal efforts to manage and maintain. What kind of hardware should we buy? Would all the machines be from the same supplier, or should we diversify? Which one is better or cheaper?

Another thing we need to remember is all the peripherals we need around the servers: KVMs and networking devices (switches and routers). I did not like fixing those, mainly because networking is an art. It demands people who are experts to understand why certain routers do not do what you want them to do. I could use even more examples, but you get my point. You must pay for the computing power, regardless of your chosen direction. The real question you need to ask yourself is: Is this the most appropriate option I can get for the investment I will put in? 

My problem with the “let's get ourselves a private cloud” argument is that someone is taking their particular success story and making it a general best-case scenario. I have worked for a DevOps consultancy firm for the last four years. The benefit of being a consultant is that you become neutral to most opinions in your field of expertise.

For example, many people thought that Kubernetes would improve their stack and solve many problems. Still, we explained to some of them that Kubernetes would fit specific needs, and for the rest, it is an overblown monster of a solution. One can get a much better return on investment by using on-demand functions, VMs, or simple containers.

One more thing: if your team went deep into proprietary usage of certain features from a cloud provider, for example, Lambda functions on AWS. Have you considered how your team would migrate your software to a different technology if you had to for some reason (for example, costs)?

Also, consider the sustainability aspect of going into the hardware path seriously. Each device you buy has a specific lifecycle, and over time, they would require new parts, which will need to be maintained or even replaced. Adding to the energy costs, the whole concept of having your data center looks less appealing.

Another area for improvement is security, and it's a lot of work to secure your private data center. The security of the cloud vs. on-premises is a critical consideration in this debate. Cloud security controls have historically been considered less robust than on-prem ones, but cloud computing is a familiar technology. More and more businesses are trusting the cloud for their security needs. 

A company running its servers on-premise retains complete control over security. They are responsible for setting appropriate user access policies, installing firewalls and all the relevant software, installing security patches promptly, and guarding against cyberattacks. This degree of control is a double-edged sword. Again, the organization would need to hire security specialists and ensure their data center is hardened against attacks.

The cloud can be cheap if you design your infra and stack in a way that is suitable for your needs. Before you build your own on-premise data center, take a step back and think about what you have and what you need. Determine your bottlenecks, where you spend a lot of money, and if your technology stack requires your current infrastructure model. You need to have better observability to understand what your actual needs are. Otherwise, you are mainly doing guesstimates, which can be right or wrong. They are half-guesses anyway. 

Something to think about is your utilization levels; as you get closer to 100% usage for extended periods, owning some of the hardware you will use would make more sense. Another critical aspect is scalability; if you need to scale fast in any direction, the public cloud is your best bet.

Think about your workforce and their base knowledge; it takes time to learn new tools and hardware, and this is not something to be taken lightly. You might have a strong team that knows Azure Cloud, but doing all the server maintenance work on-premise is a different ball game.

Ultimately, each company should understand the business and technical needs and juxtapose them with the budget and workforce they have to create something that would fit your budget, business needs, and plans. 

Do you have any more questions? We can help you! Polar Squad is a DevOps consultancy. Based in Helsinki, Berlin, Málaga, and Tampere, Polar Squad’s 50+ specialized senior professionals enable software development companies to focus on what matters. We are experts in DevOps, SRE, and cloud native.