The following is a guest post by our friend and fellow publisher, Hubert Nguyen from Ubergizmo.com. -Ed.

Cloud Sites is pitched as a “premium web hosting for serious developers”. It promises to run high-traffic websites reliably and “fast”. It is also a managed hosting, which means that the hosting company is responsible for system updates, server security and system maintenance. The customer is responsible for the application and its security.

Context: among the few things I do at Ubergizmo, I take care of all things related to web infrastructure, hosting and coding. I play with different web hosting options, as part of this.

Many developers and webmasters, would rather focus on their web apps or web site, rather than making sure that the server has the latest security updates, and if the network latency seems within an acceptable range. Also, if the server crashes in the middle of the night, someone else is alerted and has to reboot it.

Cloud Sites customers also get 24/7 technical support, either over the phone, or via a chat interface. More details on that later.

Pricing structure and infrastructure.

Metered pricing

Unlike most other hosting plans, customers don’t pay for a server, but the usage is metered. Customers will for the bandwidth and compute resources they use. The compute resources are measured in a metric called CC. It’s not completely clear how it’s computed, but it seemed to me like being heavily based on the time spent in the PHP engine, and not directly linked to CPU utilization percentage.

The exact formula has not been made public, but if you upload one large (1GB) file, and have someone download it with a slow internet connection, the CC usage shoots up. Weird, since this probably doesn’t use that much resources. In any case, the CC computation seems based on regular PHP usage, so if you’re running a normal website, like WordPress — things will look completely normal. Do

NOT

use Cloud Sites for streaming purposes — use a CDN instead.

Note that there’s a minimum of $150/mo witch comes with a certain amount of CC units (10,000) and bandwidth (~500GB). Once those have been used up, the overage billing kicks in and continues accumulating. You can check on a daily basis where you’re at. If you see something wrong, it’s possible to ask billing support to look into it. I had to do it once, and they did find that something was odd and corrected the billing.

Cloud Sites has never lowered its prices, but instead it does have hardware upgrades from time to time. It’s difficult to quantify the value of one versus the other, but in general, users have been happy if you are to believe the forums (which I agree with).

Opportunity for billing optimizations

Because the usage is metered, users have opportunities to reduce their bills by optimising their content and code. Code that is executed faster uses less CC units, and reduce your bill. Offloading your static files request to a CDN also reduces your bills, so is instantiating a Varnish proxy in the same datacenter (if you can manage it).

Managed platforms that charge you “per visitor” can be hugely expensive, and don’t offer any option to improve your billing situation by making your site less resource-intensive.

With Cloud Sites, you only pay for what you use, but at the same time, there’s plenty of hardware ready to serve content if there’s a spike of traffic, of when you clear all caching.

Server infrastructure: horizontal scalability, powerful MySQL servers

The main page of Cloud Sites doesn’t really say much about how the service is built beyond some generalities, like “it’s fast, it scales…” and other mostly high-level things.

It is actually quite interesting from a technical standpoint. Cloud Sites is divided in a number of load-balanced PHP/NET clusters of maybe a dozen PHP nodes each. It’s not clear how many of those there are, but in general any given site is run on one of those clusters. It’s technically possible that the Cloud Sites team would scale the cluster size if there was a need for it, but I don’t know a site that has outgrown a cluster.

Each PHP node will run a number of Cloud Sites websites, and it’s impossible to know how many, but everyone shares the same set of servers, configuration etc…

All these clusters can access a certain number of MySQL server. Interestingly enough, the MYSQL seem to be very powerful servers that serve many sites at once. It may sound like shared hosting, but the good news is that performance is very good, and you’ll see why shortly.

There’s an HTTPS option for Cloud Sites, but it’s a bit more expensive, and it wasn’t clear how that was still load-balanced, so this is something that I have to try in the future. For now, I’ll assume that most people still use non-encrypted HTTP, although this is changing.

Since we have load-balanced PHP nodes, they need to have some ways to share the app files, and Cloud Sites is using an network-based storage, which I believe is a SAN. Again, Cloud Sites doesn’t make this official, but sources told me that it is a SAN. This kind of networked file storage is highly unusual for web hosting in this price range (SANs are expensive!) and make it super-easy to scale server nodes behind a load-balancer.

Performance
Scalable web node performance (PHP and .NET)

From what you have read about many sites running on the same PHP clusters and MySQL servers, it seems like Cloud Sites is shared hosting. Well, I guess that technically it is “shared”, but we should at least call it premium shared hosting.

Cloud Sites does not run under the “shared hosting spirit”, which is to cram as many customers as possible in the smallest possible hardware (without crashing, if possible). It’s the contrary: Cloud Sites users have ample resource at their disposals, simply because the usage is metered, so there’s no need to constrain resources.

Cloud Sites is like pooling the financial resources of several customers to purchase compute power that most single sites could get by itself. The web node cluster has always felt fast. In fact, when I tested Cloud Sites, I moved a big WordPress site to it, then proceeded to do run Apache Bench (AB) on it, without page caching (WPSC/W3TC) or in-memory object caching. This would make most basic hosting crash (Apache) due to the overwhelming number concurrent requests.

Since the PHP load was distributed across multiple servers (PHP is executed for AB each request and the page wasn’t cached), and the database cached the necessary data in the query_cache (the AB test only floods one page with traffic), Cloud Sites could take the traffic without a hitch.

It is possible to enable page caching if you are using disk storage (WP Supercache). Although it runs on a SAN network storage, Cloud Sites can easily cache files “on disk” without visible performance issues. If you have more than 2000 pages cached on disk, I would advise to reduce the expiration time so that checking their expiration and clearing the cache doesn’t take too long.

Related: All the details about how to install and configure WP Super Cache (WPSC)
MySQL performance

The MySQL servers seem to be really fast too. They feature a large amount of RAM (how much), fast CPUs and they have no limit in database (disk) size. Again, this is something that is expensive to get if you are just hosting one site with your own MySQL servers.

Keep in mind that MySQL is not something that can be easily scaled by “adding more servers”. It’s possible to use sharding, read-only slaves etc, but if you get to that point, it’s unlikely that you would use Cloud Sites. In general, it’s best to have enough RAM to fit your tables and indexes in there, along with a healthy query cache. For mostly read-only content such as news, and articles, the cache is extremely useful.

MySQL issues do happen sometimes

That said, when there had been a few issues (maybe once a year) and most are related to MySQL/Database. In general, the symptom is a database disconnection, but the cause does vary.

The shared nature of Cloud Sites makes it difficult to exactly know what’s going on. For example, it could be that one PHP node lost contact with the database, and you would get disconnected intermittently because other PHP nodes work fine. To debug this, it’s best to output the IP address of the current PHP node in the HTML comment (admin mode) to at least see which nodes do work.

It could be other things, including a bad MySQL neighbor that was abusing the server at the time. Once, we even had a badly configured MySQL setting (max_connections set to 5, instead of 500) which probably happened after an upgrade or a tweak. If you are a WordPress site owner working with tech support on MySQL performance, here are a some slow MySQL debugging tips that could help (you and tech support) when you deal with hosting companies.

I would add that Since Cloud Sites got a hardware upgrade and a move to MariaDB in October 2015, we had no issues at all with either PHP or MySQL.

Load balancer timeout (watch out for slow MySQL queries)

From a performance standpoint, the thing that you have to watch for is long-executing MySQL queries. Sites that have slow queries (~30 seconds) may end up being cut by the load-balancer time out.

What happens is that if the load balancer doesn’t see any data transiting to a client for more than 30 seconds, it will cut the connection to the web server node to free up the connection. For the web browser, it will show up as a 500 error (the 30s value may change without notice, but 30 is probably the minimum).

I have not had this problem personally, but I did read about it on various forums, and it’s officially documented here.

Customer support (very good)

Since we just talked about potential issues, let’s jump onto customer support. At present time, Cloud Sites benefits from 24/7 chat and phone support. This is very important if you don’t want to have a lot of lag in between interactions with the support staff.

I found the staff to be very knowledgable of the PHP stack in general, and a few people were outright brilliant, finding issues buried deep and going through the effort of copying the whole site to a private debugging Cloud Sites cluster for analysis.

Since I have an engineering background, it makes it easier for me to suggest possible issues and I always had a very courteous and productive relationship with the support staff because I felt they really try their best.

If an issue goes too deep, they might bring in the sysOps team, which can investigate network latency issues (another cause of lost connectivity between PHP and Database, when a switch blows up), SAN storage performance etc.

The usual caveat is that the Cloud Sites team’s main role is to support the server stack (LAMP or .NET), and not the application level (WordPress, Drupal etc). This is completely normal for most hosting companies, and it’s important for customers to understand that.

I once helped a publisher friend who had a very deep-rooted issue in corrupted wp_options table data, which was causing the whole site to be extremely slow (~8-20 seconds page generation). It took me many hours (8-12?) in total to reproduce the issue on a test server, and come up with a fix. This is typically something that goes (way) beyond the call of duty for the Cloud Sites support staff, although they did try.

Since Cloud Sites is geared towards developers and agencies, it should be fine. But I know regular web publishers who aren’t as technically savvy using Cloud Sites happily.
Finally, there’s also a Cloud Sites community forum that answers additional questions. People can post any questions or suggestions and the Cloud Sites staff addresses them whenever they can, like recently about Let’s Encrypt SSL.

I try to discuss improvements or answer questions when I can there. Admittedly, other hosting companies have more vibrant communities (like Cloudways’s FB page), but many others have nothing at all.

Caveats

As powerful and exciting that Cloud Sites can be, it does have a number of caveats or tradeoffs that prospect customers need to be aware of.

No command-line or SSH access

For security and isolation reasons, there is no command-line access, so changing file ownership/attributes or for copying/deleting large number of files can quickly turn into a struggle. You can ask tech support to do some of these tasks for you, but it’s a bit of a hassle if you need to do it often. I personally had to ask for a quick favor a couple of times.

It’s also impossible to use a utility like Rsync if you want to reliably copy data to/from another server. This is an annoyance if you want to keep your data synced with a remote location, or if you want to move in/out several GBs of data. Doing this over FTP is not fun to say the least. Most of your files interaction will go through FTP of SFTP (ugh).
No built-in backups

Cloud Sites doesn’t have a built-in backup system. This has been a friction point with many customers for many years, and it is really an odd thing. It seems like the unique nature of Cloud Sites, a backup system has proved too complex to build, for now. Don’t hold your breath on it for now.

Customers were offered a discount to Codeguard, a remote backup system based on FTP and direct MySQL access. It works, but is not ideal if you have to restore a multi gigabyte site via FTP. The Cloud Sites team also came with a free backup script which should work for small sites (big many GB sites may have timeout issues) called ZipitBackup.

There is no such think as a one-click backup/restore, and if you have a huge site that gets corrupted or compromised (at no infrastructure fault), you may have to ask support to either do a whole restore for you, or you would have to request a delete, then restore yourself via FTP…

No copy or staging

For the same reasons that led to the lack of automated backups, there’s no easy way to “copy” all the site’s files elsewhere, nor there is a “staging” feature to create a version for debugging an issue on a real production cluster, with the tech support’s being able to look at it.

As a developer, this kind of thing can be quite important. Talking about debugging, it’s not possible to install New Relic, which can be of tremendous help for issues that only happen on the production (Cloud Sites) hardware.

Since there’s no limit in the number of sites you can create, you could create an additional site at no extra cost and leave it in private mode (you are assigned a test URL). It mostly works, although it’s not anywhere as close as being able to “copy/stage” a site.

Potential left behind / ideas for the future

Cloud Sites is a great piece of technology, and it was well ahead of its time. Even now, there aren’t a lot of comparable services, and even less that would be affordable. Yet, there are many things the Cloud Sites team could do to improve their service, and their profits.

For example, there are no managed services such as Memcached, Redis, MongoDB, Varnish and other contained pieces that aren’t part of the LAMP stack. Arguably, Cloud Sites could charge for these services and greatly improve its profits because they are relatively simple to manage. Most of them *need* to be hosted in the same data center as Cloud Sites to have proper latency.

Note that with single-server hosting, it’s possible to install of all these in a “single box”, but scaling horizontally is not very orthogonal, especially if you don’t want to pay for nodes you don’t need at all times.

The ability to copy/stage sites would get people to use more storage. Again, this would be a great thing for the service’s profit.

And of course… backups. As of today, any issue that would require a full reinstall of a site will cause much bigger downtime and billed hours simply because it’s impossible to script/automate a restore, and doing it over FTP does take a lot of time.

Admin interface

The admin interface of Cloud Site is pretty old, and frankly it’s not the best panel ever. But, it does get the job done, and you can instantiate sites, create databases, create FTP users, CRONs, and manage domains/sub-domains. So yes, it’s not pretty, but it’s reliable and gets the job done.

Conclusion: powerful, but watch for for caveats

Cloud Sites is a very powerful hosting platform. It supports both PHP (multiple versions) and .NET along with MySQL (MariaDB) and Microsoft SQL. That alone makes it a rarity.

It is one of the rare load-balanced, scalable (to the size of a cluster) platform on the market that you can get in for $150 and have a known pricing structure to avoid bad surprises as much as possible. For LAMP, there are other scalable platforms that have much fancier features (like Pantheon.io) but I doubt that they would anywhere near as cost-effective as Cloud Sites.

Other scalable managed hosting pricing structures are also more opaque (charging “per visitor”) and don’t offer an opportunity to reduce your bill by optimizing your consumption.

At the end of the day, Cloud Sites has great potential for small agencies that want reliable web hosting, can deal with the lack of command-line and manage a number of sites in one location, one account. If you are willing to pay 2X or 3X the price, there are other options out there.

Cloud Sites is not a perfect cloud hosting solution, but it’s one that offers horizontal scaling, a powerful MySQL database, and a 24/7 managed support that can handle system security and low level software stack — at a starting price of $150.

A final point: Cloud Sites was recently acquired by Liquid Web (from Rackspace), and although there are no changes to be expected in the near future (~6 months?), things can move for good or bad, or no change at all. But it’s something to be aware of.