To own, or not to own

Cloud computing is a major buzzword of the decade I think. Now its pretty common to see AWS or GCP experience as a requirement for a job.

Not a surprise, sure — everyone deploys to the cloud these days. Let’s take a closer look on clouds, and start with pros and cons of a public cloud deployments.

Let’s try to be positive, and start with pros for a public cloud offerings. It’s going to be easy, since pros are really huge and can be seen immediately. But let’s name a few.

Quick setup

Once you start a project, it just takes a couple of clicks to setup the infrastructure for it, and that’s just incredible! With Docker or Kubernetes you can deploy your app in less than a minute. That’s definitely a major selling point for public clouds, since if you’re looking to buy own hardware it typically takes up to 4 weeks just to deliver your new shiny server to your DC.

Cheap to start

It doesn’t take a fortune to setup the infrastructure for a proof-of-concept or an MVP. Couple of CPU cores here, couple of gigabytes there — and your application runs in a real distributed environment. All you need to start is a credit card with like $10 available. Pretty impressive if compared to a typical mid-level 1U server price tag of $4500.

No extra staff required

If you don’t own the hardware, you also don’t have to maintain it. So you don’t have to hire all the personnel required to keep the hardware alive. And if your team is really aware of DevOps (and it’s not a someone’s title in your team) you’ll be okay.

Every coin has 2 sides at very least, so do public cloud offerings as well. However there’s a certain asymmetry: if pros can be seen right away, long before you start using them, cons sometimes aren’t that obvious.

Vendor lock-in.

Cheap block storage. Vendor-specific database systems. Container orchestration systems. Machine learning pipelines.

Every time you integrate certain proprietary infrastructure components — you’re also getting another chain attached to your leg. If your project heavily relies on a specific functionality to be feasible, or just amount of efforts required to migrate from a given proprietary component will be too high — you become physically bound to the platform of your choice.

Vendor lock-in is never a good thing, you know that. APIs might change. Legal policies might change. Pricing might change. Everything might change overnight, and if you’re already locked in, you’ll be bound to accept whatever changes they have for you. Or you’ll be pushed out of business.

Performance per dollar.

Major cloud infrastructure vendors often tend to sell virtual CPU cores. Sounds simple enough, but the hard truth is simple too: cores are not made enough. Say, Intel Xeon E5–2650 v4 one vendor offers in its “CPU optimized” VMs is a CPU introduced back in 2016. 5 years ago.

So, you’ll be paying a top dollar for a performance of a 5-years-old machine. That’s going to be a 2x worse performance if compared to the modern machine with modern CPU cores, given 15–25% year-to-year performance improvements Intel and AMD typically announce. Not to mention faster memory used in modern servers. So, if your average compute-bound API request takes 200ms in the public cloud, it can take only 100ms on the private hardware. Or, you can serve 2x more requests with the same number of cores.

Platform limitations.

Clouds only seem to be infinite. In fact it’s just the same boring datacenter filled with the old good rack mounted servers. And there’s finite number of servers in a datacenter. So there are physical limits on how many hardware resources one can rent. There are limits for the hardware options as well. You can easily bring whatever hardware you need in the average DC you own or rent, as long as it fits power and safety requirements, but it’s barely going to work with major cloud platforms.

P.S. Just search the web for the customers feedback for “quota increase _platform name_” to see how bad it can be once your project suddenly takes off and you urgently need additional resources.

There’s no silver bullet when it comes to infrastructure, and neither public or private clouds should be considered as one. Radically different approaches to infrastructure can be beneficial at different stages of your project. I, personally, try to keep mobility as a core requirement for whatever I’m working on. If it makes sense to move some part of the project, or the project as a whole onto private hardware — such a move must be technically possible. Or vice versa — if it’s cheaper to use public cloud — nothing in project design should prevent that. Thanks to Docker and Kubernetes, now it’s way easier to do than it was 10 or 15 years ago.

Plan for a change since day 0: design your systems in a way you’ll be able to stay mobile. Plus, even in a high-margin business costs do matter, and if migration to or from a public cloud can improve your costs structure — think about that in advance.

And another thing to keep in mind: cloud is just someone else’s computer you’re renting.