Quality of resource, public cloud versus private cloud

In this second instalment of the PaaS versus Managed Server series we look at "bang for buck".

Photo of Greg Harvey
Tue, 2016-09-13 12:30By greg

Last time I explored the cost per site of some of the Drupal platforms around, when compared against our managed private cloud servers. People often consider our individual VM prices to be on the high side, but when you consider you can host multiple sites on them for no extra fee that changes everything.

However, at this point you might reasonably say: “Hey, hold on! But you’re only selling me one server, whereas the other guys are giving me a container per customer. How does the available resource compare? How will my sites perform if I shove them all on one server? Surely I get more resource in the end from a PaaS product, even if it costs a bit more?”

Well actually, it’s really hard to say but in reality, probably not. But before I explain further, let’s look at actual resource (as best we can tell).






 

Code Enigma

Platform.sh

Pantheon

Acquia

RAM

4GB

4GB

2GB*

3.75GB

CPU

4 vCPU

Unknown

Unknown

2 vCPU (ECU)

Disk

80GB

5GB

20GB

25GB

Network

Private

Public

Public

Public

* this isn’t clear, but we’re assuming 8 “workers” using 256MB each equates to 2GB available.

And let’s apply the same to our “three customer” example and put the money back in (same caveats as before, pricing correct at time of writing):






 

Code Enigma

Platform.sh

Pantheon

Acquia

RAM

4GB

12GB

6GB

11.25GB

CPU

4 vCPU

Unknown

Unknown

6 vCPU (ECU)

Disk

80GB

15GB

60GB

75GB

Network

Private

Public

Public

Public

Cost

£300

£384

£225

£435

When you do that, you can see resource for your money is pretty similar for the most part. You get more in some places and less in others, but on balance it feels like you more or less get what you’re paying for.

You’ve apparently more RAM from the platform providers (apparent being the operative word - more on that in a moment), largely unknowable CPU (with the exception of Acquia where you theoretically have slightly more) and less storage than Code Enigma across the board. Frankly, Pantheon appears to be the best deal at this point, but whether you can even run your site effectively on there when the “PHP workers” are limited to 256MB RAM is questionable. But, before we get too hung up on this table...

The TL;DR for the rest of this section is this: our VMs are backed by private, 100% dedicated, Enterprise infrastructure so they will always perform significantly better than the supposedly equivalent public cloud infrastructure our PaaS competitors are sat upon.

For the longer version, read on:

One of the things you need to understand about cloud hosting is contention is important. That means how many other people am I sharing this resource with?

People are becoming used to contention in the context of, say, their Internet connection. You know you pay more for your ADSL line if you want a lower contention ratio, you want to share it with less people, therefore take a larger share of theoretical maximum performance. Well the same is true in cloud computing, and the important point is this:

All the platform providers are on public cloud services. They have no idea how much of the RAM and CPU they promise you is really available, when push comes to shove. They may have some idea how quick that disk is, but they probably can’t reliably quote IOPS data to you, because even if they measure it, they have no SLA to guarantee it stays like that. And their network is shared across all the other companies using the service of their provider, be it Azure, Rackspace, AWS, doesn’t matter. Shared, all of it.

In stark contrast, we can tell you the exact contention of RAM and CPU because we manage it ourselves. We can tell you the IOPS of your disk, because it’s Enterprise Storage Area Network (SAN) so we know. We can tell you the make, model and serial number! We can tell you our network is private, we manage the addressing. We have an SLA backed 100% uptime guarantee from our routers to the Internet. And we are confident that every aspect of our VMs will out-perform public-cloud platformed containers significantly.

(In fact, we’ve measured it. By StatusCake checking sites about to migrate to us, we have been able to get a picture of their performance before [on a public platform] and their performance after [on our private cloud] and there has always been a marked improvement on our servers. As there should be, we’re backed by uncontended, Enterprise-grade hardware.)

So to re-iterate, when we tell you that you have 4GB of RAM and 4 vCPU available to you, that’s exactly what you have. When a PaaS provider promises you certain resource levels,  all they can do is hope their shared resource provider is able to make that resource available when their customers need it, but they have no control over it. You’re simply out of luck if you need all 3.75 of your AWS ECUs and your host machine is too busy to give them. (You might think the same happens to our VMs, but I’ll touch on that in a later post - essentially it doesn’t, because VMware is very clever.)

So our VMs represent almost as much overall resource as multiple plans from platform providers, but the infrastructure backing our VMs is much more performant and robust.

Which leads nicely on to service resilience, which is the topic of our next post.