Is is possible to be in the managed website hosting business, without having to deal with all the technically challenging chores of managing web servers? The answer, in 2021, is a qualified (but enthusiastic) YES! This year I am just beginning to dip a toe into the murky waters of “serverless website hosting” — that is, hosting websites without the responsibility or overhead of web servers. Technically, servers will continue to be required for the long-term hosting of websites. Websites need to be always available 24/7, so a server needs to be ready at all times to serve up pages when visitors request them. But servers are changing. Here’s what your webmaster is learning about this new “serverless” paradigm in website hosting.

From Hardware Web Servers, to Virtual Web Servers, to Serverless

For over four years, Oakley Studio has been providing it’s website hosting on “virtual servers,” cloud-based server “instances” which we lease from Amazon Web Services (AWS). Yes — that Amazon, the one with a global online shopping presence, who’s servers never go down. You’ve probably bought a book from them at some point since the dawn of the internet.

Amazon built a rock-solid hosting infrastructure for their own global network of online stores. And having done so, they turned that awesome infrastructure into a new technology business — offering “in the cloud” computing services to many other businesses big and small. Oakley Studio is one of them. We began using Amazon’s Elastic Cloud Computing (EC2) service in 2016 to build out a small secure data farm of “virtual computers” for our managed website hosting business. Unlike real web servers, these virtual servers have no physical hardware per se. As far as we are concerned, virtual servers exist as configurations only.

Of course there is some actual heavy-duty hardware operating behind the scenes, but a webmaster like me doesn’t need to deal with any of that physical stuff. Not any more. Amazon slices up its big iron into compartmentalized chunks based on configurable variables like Operating System type, CPU processor power, network capacity, and storage volume. I can start up a new web server within minutes by specifying these variables and hitting the “Launch” button. Over the past four years, I’ve spun up and terminated quite a few servers in the process of discovering how to “tune” them to best advantage for my clients and my business.

The “Elastic” in EC2 describes the ability to increase storage, or easily swap one virtual computer for another, or to attach existing storage to bigger faster better computing power and greater network bandwidth. This has always been challenging to do with actual real computers, and involved considerable expense to purchase and maintain the hardware.

Being able to make adjustments to my available hosting infrastructure simply by modifying server configurations in a web-based console is a huge advance for my business, and has made me a webmaster superhero in the eyes of some clients. And yet it still involves quite a bit of research, testing, development, and implementation to get those server configurations just right, and maintain them as my client list grows, and each client business attracts more and more visitors. As my business grows, I still need to increase “virtual” storage capacity a couple times per year. I still need to upgrade my virtual servers for faster CPUs. And I am having to pay for unused capacity which needs to be there just in case a few client sites get crazy levels of traffic. These configuration tasks still require some downtime — and entail offline time for my client websites — whenever server modifications are required.

The real promise of “serverless hosting” is that, for a webmaster like me, these periodic configuration tasks go away! Serverless computing suggests that the elasticity I enjoy now will become even more automatic. Server power, storage, and networking will automatically scale up or down as needed. That means if a few clients are running big marketing efforts, their websites may be replicated across additional server instances, without me having to manage those changes myself. Computing availability will scale up or scale back down as needed. It will happen on a moment-by-moment basis.

My First Serverless WordPress Website

Happily, I now have first-hand experience with creating this kind of truly elastic website hosting infrastructure, and am using it for a test WordPress website that you can go visit right now*. On that website you’ll learn more about what’s required to orchestrate all the parts and pieces necessary to build Serverless Website Hosting, so that it is secure, scalable, and high-performance. It uses a handful of AWS services that I had not previously used up until now.

I don’t expect to be hosting Live client websites on my “serverless” platform until I am certain it is secure and capable of replacing my current cohort of virtual servers. But OH am I eager to see how this can scale!

I’ll use the rest of this blog post to diagram it out for those readers who wish to try their hand at it. I followed a very detailed tutorial to implement my serverless website. It took one very long day to get WordPress up and running on this new platform. And then another day to go back and fix a few mistakes I made along the way. Yes, it’s complicated, but it makes for a challenging and fun weekend project if you’re up for it.

Your Own Private Cloud Network

I started by creating a new Private Cloud Network (PCS) in AWS. This experiment was to be entirely separate from my existing PCS. That contains my Production and Staging EC2 web servers for my ongoing managed website hosting business. If anything went bad with my serverless experiment, I wanted to be sure it did not touch my existing production service!

With my new PCS up and running, I added Amazon’s Aurora Relational Database Service (RDS) which would contain my WordPress database. And I added Amazon’s Elastic File System (EFS) to store my WordPress file system. Then I added Amazon’s Elastic Container Service (ECS) as the source for spinning up my experimental WordPress site. Next, I created “Security Groups” to control in/out access to these computing resources. I actually duplicated these Security Groups so that my “serverless” WordPress site could be hosted in two different “Accessibility Zones.” Amazon’s Accessibility Zones (AZs) are geographically separated computing centers, which provides additional redundancy and reliability. This is how Amazon ensures against any kind of “catastrophic” outage. (And this is why Amazon’s online stores never go down.) And lastly I added an Amazon Automatic Load Balancer (ALB) to manage traffic to multiple instances of my site. So if my website got a sudden burst of traffic, the site would automatically be replicated to additional server instances.

Here is what all these parts look like in diagram form.

AWS Serverless Fargate Configuration

All these services together comprise Amazon’s “Fargate” Service. Fargate is their proprietary system that replicates websites across multiple AZs, and automatically scales up or down the computing resources for the RDS database and EFS file system used by a serverless containerized ECS WordPress instance. That all happens invisibly in the background.

Final Takeaways

My serverless experiment has ended for the time being, so when you visit my “serverless” WordPress site you are actually viewing it on one of our Oakley Studio Staging servers, running on an EC2 virtual server. What have I learned from this experiment in serverless WordPress hosting?

  1. For a single website, serverless is more expensive! This was a bit of a surprise. There are initial base costs for RDS, EFS, and ECS that make it expensive for running a single WordPress site on this serverless platform. In the two months that my serverless website experiment was up and running, the cost averaged $2.75 per day. That’s profitable for hosting a “Professional” or “Enterprise” or “Destination” (Levels 7 thru Level 9, see Pricing page) website, but not suitable for the majority of Startup or Intermediate websites that are the core focus of my managed hosting business. Any of those low-traffic sites can become internet stars, of course, and I love it when that happens. We expect the cost to be amortized across multiple websites in a production setting, but the startup costs make it an expensive proposition.
  2. This was technically challenging! All these services were new to me, and they each have their own configuration panels and terminology. I’d say the most difficult piece was the ECS, which used a Docker instance of WordPress from a git repository to containerize and spin up my WordPress instance. So many components to the configuration, and if just one is not right, the container service does not run, or does not launch a workable WordPress, or can’t connect to it’s database…
  3. But once my serverless WordPress site was up and running, it was a thrill! I was able to connect it to my ManageWP dashboard, which I use for keeping all client sites updated, backed up, and for cloning from Live to Staging. I was able to backup and clone the site. (That’s how I created a permanent Staging site for it.)
  4. For secure connections, I was able to use AWS Certificate Service (CS) for the website, created an SSL Digital Certificate for the “serverless.oakleystudio.com” subdomain, and assigned the certificate to my ALB, so that all connnections to the site were HTTPS encrypted.
  5. The one significant downside is that there is no server to log into! I could not SSH in or SFTP because there is no server for me to log into. It’s serverless, right? And this means that I would not be able to go into the file system and tinker with Plugins or Themes, or configure a wp-config.php file or a .htaccess file. It is hard to conceive how to manage a WordPress website without this file-level access. How might we solve this in the future? Will WordPress eventually provide the means to do such file-level configurations all from within the Dashboard? I don’t think we’re close to that yet.

So those were my initial learnings from this “serverless WordPress” experiment. If you are a WordPress webmaster tinkering with these things yourself, I’d love to hear your experience. And especially if you are using serverless for production website hosting, I’d be very interested in knowing how it’s going, and how you’ve addressed point #5 above, as well as your experience with costs and technical challenges. If you have comments or questions, please reply below.