Best Drupal Hosting - Choosing the right one

• Introduction
• Reduce friction between on premises and cloud
• Build your software platform agnostic
• The best cloud providers

Introduction

There are many articles out there talking about the advantages and disadvantages of one or another cloud provider. But most of them are sponsored, biased and really none of them poinpointing what really matters. They are distracting, focusing your attention away of what they don't want you to know.

You don't want to wake up one day and find that your infraestructure is taking control of your business, and what is worse, that you can do nothing about it.

But preventing that from happening is very easy!

These are two very important recommendations that will come in handy sooner or later if you deal with big - and long term - projects:

• [1] Reduce friction between on-premises and cloud, ideally making it possible to move from one to another without affecting your processes or your business.
• [2] Try to make everything you build not to critically depend on any specific software stack.

While reducing friction between cloud and on premises is easy, building your software 100% software stack independant is close to impossible.

Of course, for one shot short term projects, you are better off selling off your customer to a specialized cloud provider so you can move on to the next project ASAP. But for big projects with high ongoing investments, real risk management is crucial for long term success.

If anyone wants to trap you into their spider web, your best weapon is to have clear what your priorities are unless you want to end up fighting yourself free from vendor lock-in features.

Reduce friction between on premises and cloud

You wake up one day and you find out that you can cut your hosting bill by more than half by moving from PaaS to Colocated or IaaS. It makes sense to move away. But you realize that you have built everything you are around your cloud provider services. That was an early decision that you overlooked, and now it is going to cost you a lot of money. What can make this change so traumatic? Because everything you do depends on a specific set of tools that your cloud provider is giving you and that only this cloud provider offers.

If any of the following are true you have already bit the bait:

• Your continuous integration procedures depend on tools that are not a market standard, or that you cannot run on premises.
• Your application is designed to consume vendor cloud-only specific infrastructure services, or you have built everything around technologies that are not available on premises.
• Your upscaling/downscaling automation is something you do not control or understand, and would not be confortable managing on your own.
• You think that vanal (I dont mean it is not important) stuff such as monitoring is one of the key features of your cloud provider.

Ideally, you should be able to move from cloud to on premises in a reasonable amount of time and that the shift does not disruptively change the way you do things. 

Next time that you compare the features of a cloud provider do yourself a favor and inmediately discard anything that is provider specific and that will represent a long term tie.

I also deeply recommend to spread services (diversify) as much as possible, and to pick up the service providers that are easier to plug in and out. If your cloud provider is selling you a CDN as well as hosting, usa another CDN. If you ever need to move anything from one provider to another (or from cloud to on permises) it is going to be easier to migrate 1 service instead of 5. Reduce your dependency on a single provider.

We are not going to tear down standard well known Drpual offerings because if any of the above is true, then there is little left to look at with them. And because I do not want to look biased (yes this site is called DrupalOnWindows.com) I will be using Azure to give an example on what things you need to avoid.

Example 1: Azure Document DB

The SQL Server community has been asking for a long time to get JSON support. People are confused as to what is good and in what scenarios regarding RDBM and NOSQL. And MS comes out with a NOSQL storage engine that is only available on azure. Do you know what is going to happen if you build your application around Azure Document DB? That you will never be able to move away from Azure.

Example 2: Blob Storage (Azure, Amazon, etc..)

So it looked like traditional file system approaches were not suited for the cloud, and blob storage was born. But blob storage only exists in the cloud and there is no standard whatsoever as to how you should deal with it. Every provider has it's own API. Instead of consuming your cloud provider specific BLOB API, mount a drive and try to design your application to work on a regular filesystem. You could also use a BLOB API abstraction layer, but still dealing with blob storage will eat away a lot of your time and increase impedance between on-premises and cloud, plus the reality is that blobg storage only makes sense on really huge huge monster applications that have very specific scaling needs.

Example 3: Application specific support

Avoid this like the plague. The only support you must take is for things that are responsibility of your cloud provider, not yours. You want your cloud provider to replace a failing hard drive, but you do not want them to fix your scaling problems on a regular basis. You also do not want them to have all the application-infrastructure binding know how, or else moving away is going to be a tough journey.

Example 4 : Profiling

Zend Z-Ray? Blackfire? I must agree they are great. But is it worth the lock-in? Both of them are things that you cannot run on your own. Blackfire is a cloud service, and Z-Ray can only be installed on Zen Server (this is going to change soon though). For 99% of what profiling is used for, you are perfectly served with XHGUI+UPROFILER, and setting it up takes less than five minutes (or 0 if you make it's deployment part of you automation). Once Z-Ray can be deployed on non Zend Server PHP it will also be a very competitive alternative.

With these examples you have a clear insight on what kind of things you should be looking for before choosing one technology or another to avoid vendor lock-in:

• (1) Can I run it on-premises?
  • If the answer is no, start looking somewhere else.
• (2) Is the licensing scheme and pricing for on premises suitable for my project?
  • So you have chosen to build something on top of MSSQL Server, that you can run on-premises and is free (with a 10GB per database limit). But if you ever happen to exceed that quota the on-premises price might be a little steep (at $3,000 per core). But still that is not *that* expensive considering that you can use that license for quite many years.
• (3) Once (1) and (2) have clearance, now it is time to evaluate features, ease of use and others.

Build your software as platform agnostic as possible

What database engine should you choose? MSSQL, MySQL, MariaDB, Couchbase, Mongo?

Whatever you choose make sure that you are able to switch to another mainstream competitor with 0 application disruption.

It takes a few MSSQL to Oracle migrations to find out that accomplishing this is not as difficult as it looks like, but that it must be done from the begining. Imagine you need to move to Oracle only to find out that the table name limit is of 30 characters. Your application has 100 tables and more than 1,000 columns, and 50% of those columns are more than 30 characters long. That is not fun. You can probably swallow that with ease on a strong typed language. But the effort is many times bigger on loosed type languages such as PHP. And after you are done with that, it turns out that some of the data types you are using are specific to your database engine (such as BIT not being supported on Oracle). You look to God and ask yourself why you picked a BIT instead of an INT, and realize that any argument you held at the time of the decision is vanal and meaningless, and it would have represented little to no difference to development times or application quality.

Build you DAL around an ORM or abstraction layer that ensures database portability to at least MSSQL, MySQL and Oracle. Build your application around one of the big ones, preferably one that encourages good practices such as MSSQL.

The best cloud providers

For us, the most cost effective cloud provider that complies with most of the previously exposed requirements is Rackspace because:

• It is not focused on a specific technology or software stack. Windows or Linux you may have it with first grade support.
• It has the right infrastructure vision. You can mix cloud with dedicated to best suit your needs. You can even spin up a dedicated server with by the hour billing (that you manage as if it was any of your other cloud servers) thanks to their On Metal offering.
• It gives you the tools to build your on platform on industry standards, encouraging that you learn what you do resulting in 0 friction when moving to another provider, dedicated or on premises.
• They give you specialized support - but for infrastructure design - not for your specific application.

But Rackspace is way too expensive - yet suitable for projects that demand strong certification such as SAS70. If you want something cheaper and still extremely good I personaly recommend Vultr.

PaaS providers are on a price and feature war. You must stay away from it.

Image 3 - The mohicans already knew that wars have no winners and no loosers