Serverless Solutions Insights

Cloud Deployment Options for an Application

Written by Admin | Jan 7, 2026 5:12:03 PM

A Simple Example of Deploying a WordPress Site Via PaaS, Containers, IaaS, and SaaS

Clients frequently ask what cloud services they should use for different applications.  Lift and shift to IaaS, true modernization with containers and PaaS, or reach for the appealing benefits of FaaS or SaaS?  Unfortunately the optimal path and destination is not always a simple answer.  It depends on the application(s) we’re talking about and what’s most important to you regarding how it is used, managed, and valued.

In this blog, we describe an educational journey we took as we deployed and configured WordPress in four different fashions, using this as a real world example.  This one focuses on WordPress, but the decision points here could apply to any application you are considering using in the cloud.

We outline four ways we have deployed WordPress and highlight the benefits and challenges for each.  Don’t worry if you are unfamiliar with the acronyms or terms; we’ll try to explain a bit along the way.

tl;dr

WordPress

Globally Dominant CMS with Great Deployment and Scaling Options

MARKET SHARE

As of 2019, WordPress has a 60% market share for CMS. Global usage has skyrocketed for a reason!

Google Cloud

Top Tier Full Services Cloud Platform

GOOGLE CLOUD MARKET SHARE

Google trails AWS and Azure with roughly 8% if the market share in early 2019.  The market is growing very rapidly and the big three are battling it out to continue astronomical growth.

GCP Revenue

Dramatic Revenue Growth

GCP REVENUE GROWTH

Google Cloud Revenue grew by roughly 83% in Q1/2019.  Continued growth at this rate will position Google to challenge the market dominance of AWS and Azure.

Exercise 1 – Going Serverless with App Engine

Given the focus of our company (Serverless Solutions), we decided to wade into the PaaS pool first.  App Engine is Google’s Platform as a Service (PaaS) offering.  It is appealing because this serverless model allows us to focus on the application and not the underlying infrastructure, operating system, database, scaling, or consumption of resources.  This model is very appealing for custom applications and sometimes for portions of applications (e.g. data tier), but can be challenging for 3rd party applications that limit our control of the code or configuration.

Overview of Deployment and Configuration for WordPress on App Engine

Google’s tutorial outlines the process fairly well.  We had to change a parameter a couple of times and install the newer version of php.

  • Setup the database

    • Setup a new Cloud SQL Second Gen instance
    • Updated the password
    • Created the Cloud SQL Proxy
    • Created a new WordPress database and user

  • Setup the WordPress Project

    • Clone the sample repository (git clone https://github.com/GoogleCloudPlatform/php-docs-samples.git)
    • Install php 7
    • Install the dependencies (composer install)
    • Run the helper script (php wordpress.php create -n –dir=./wordpress-project –db_instance=INSTANCE –db_name=NAME –db_user=USER –project_id=PROJECT –db_password=PASSWORD

  • Deploy the WordPress Project

    • Deploy the project (gcloud app deploy –promote app.yaml cron.yaml)
    • Access the site by going to https://[project id].appspot.com
    • Go through the WordPress installation process in the browser

  • Update WordPress, Plugins, and Themes

    • Update WordPress itself (vendor/bin/wp core update –path=wordpress)
    • Update the plugins (vendor/bin/wp plugin update –all –path=wordpress)
    • Copy any of the updated dropin files from the plugin directory to wp-content
    • Update the themes (vendor/bin/wp theme update –all –path=wordpress)
    • Deploy the project again (gcloud app deploy –promote –stop-previous-version app.yaml cron.yaml)

  • Installing Plugins or Themes requires you to download and redeploy your application

The Good

  • Simple ability to scale to meet usage needs
  • Theoretically less cost in this pay for consumption model
  • No database to manage, just Cloud SQL
  • Not much concerns with maintenance (e.g. database, file storage, etc.)

The Not So Good

  • A little tedious to configure with storage bucket for typical filesystem
  • More difficult to use some of the WordPress theme and plugin download features due to the above
  • Cost in our example was surprisingly high- over $40/month

Exercise 2 – Deploying WordPress in GKE

Google Kubernetes Engine has gained tremendous momentum among Google Cloud customers.  GKE is Google’s focus for providing containerization in the cloud.  Containerization is a form of virtualization that allows us to deploy applications or portions of applications in smaller containers without including the full virtual machine and operating system in each.  This model allows for better horizontal scaling and simplified management than traditional Virtual Machines/Infrastructure as a Service (IaaS).  In many ways it is an option between IaaS and PaaS, taking some benefits from each depending on our design decisions.

Overview of Deployment and Configuration for WordPress on Google Kubernetes Engine (GKE)

Google has a tutorial that outlines the process of defining persistent disks for WordPress and MySQL here.  Steps outlined below generally map to the Google version, but we also tested this one that uses Helm/Tiller/Nginx.  We had issues with downloading WordPress plugins and themes on the Google tutorial version and had namespace issues and load balancer configuration problems with the stcox one.  After some tweaking we could get them to work, but it was a bit tedious.

  • Create a GKE cluster.  This creates the compute instance to run the kubernetes instances.

  • Create a PersistentVolume and PersistentVolumeClaim.  This is the persistent disk that WordPress will use for file and MySQL storage.

  • Set up MySQL

    • kubectl create secret generic mysql –from-literal=password=YourPassword
    • Setup your MySQL yaml file and deploy (kubectl create -f mysql.yaml)
    • Verify that the pod is running (kubectl get pod -l app=mysql)
    • Create MySQL service (kubectl create -f mysql-service.yaml)
    • Check to see if the service is running (kubectl get service mysql)

  • Set up WordPress

    • Deploy the yaml file (kubectl create -f wordpress.yaml)
    • Verify it is running (kubectl get pod -l app=wordpress)
    • Expose the service (kubectl create -f wordpress-service.yaml)

  • Install and Configure WordPress

    • After setting up the service, verify it is running (kubectl get svc -l app=wordpress) and note the external IP address
    • Browse to the external IP and you should see the WordPress installation instructions
    • Configure load balancer and SSL

The Good

  • If configured correctly, this model can be extremely scalable
  • Option to use Cloud SQL or MySQL depending on your needs
  • Ability to leverage a hybrid on-premises and cloud deployment model
  • Horizontal scaling is seamless

The Not So Good

  • A little tedious to configure- a ton of options makes it difficult if you don’t have a lot of experience and can make the right decisions
  • Depending on the decisions, it might limit some WordPress features and impact how you configure load balancing and SSL
  • Cost in our example was higher than anticipated- roughly $35/month with a three node cluster

Exercise 3 – Let’s try a Click to Run WordPress VM

Click to Run is the “Easy Button” for leveraging prebuilt solutions in GCP.

Overview of Deployment and Configuration for WordPress on Google Compute Engine (GCE)

Google has a number of ‘click to run’ options to install WordPress on GCE.  We’ve installed the Bitnami single instance version and had it up and running in minutes.

  • Log into the Cloud Console and find the best option in the marketplace.  We used the Bitnami single instance version.

  • We expanded the disk size in the VM from 10GB to 20GB.

  • Setup a static IP via VPC Networks / External IP.

  • Install and Configure WordPress

    • Browse to the external IP and you should see the WordPress installation instructions
    • Configure load balancer and SSL

The Good

  • Extremely simple setup.
  • Easy to go into the VM and change WordPress setting/files.
  • Everything in WordPress just works as expected.
  • About $12/month with the g1-small instance.  We also tried the Micro instance and while only a few dollars a month, performance wasn’t great.
  • Ability to scale up to a larger instance very easily

The Not So Good

  • Horizontal scaling will require some reconfiguration (e.g. a separate database and file system)
  •  Availability isn’t as solid as Kubernetes or App Engine options

Exercise 4 – Let’s try a managed solution

This is closest aligned to SaaS option.

With out naming names we tried to deploy a website on one of the most popular managed wordpress sites. There really is no checklist of activities to go through in this scenario. You go the the SaaS provider, pick your options and they deploy the site for you. You simply login to a configured wordpress site and start setting up your content.

The Good

  • Simplest set-up of all options
  • Inexpensive (with caveats)
  • Managed – no need to do patching

The Not So Good

  • Best pricing requires multi-year commitment
  • Nickle-and-Dime options. You want to use a theme? You want to use a plug-in? That cost extra. This was kind of a nasty surprise after signing up for a year
  • Available “free” themes, etc are not very good

Summary and Takeaways

This exercise was very similar to what we see companies going through for sets of their applications.  Fortunately for us there is an optimal cloud deployment path for any application.

  • SaaS – this option works great for WordPress if you don’t want to worry about touching anything outside of the actual WordPress configuration and content. You may have to pay a bit more and sacrifice some ability to customize things, but the tradeoff works for a lot of people.

  • Compute Engine – GCE makes the most sense for WordPress if you don’t need tremendous scaling or high availability, are looking for a cheap option, and don’t mind managing the VM.

  • Kubernetes Engine – GKE is a perfect solution for a more advanced deployment with HA and horizontal scaling capabilities. This comes at a bit more cost and effort, but this is likely the best option for a mature organization concerned about response times and high availability.

  • App Engine (or Functions) – WordPress works on App Engine but the challenges getting it to work and keeping it updated in that environment didn’t seem worth the effort.

Hopefully this all makes sense for WordPress, but what do we takeaway from this exercise to apply these lessons to other applications?  First, there is at least one right answer for every application.

  • SaaS availability – is SaaS even an option?  If so, that should be the default unless it doesn’t meet your needs.

  • 3rd Party Applications – we don’t have control over some of the inner workings, so this often makes it difficult to fit into a PaaS model.  And often the benefits of PaaS are muted because we have to work around the application to make it work.

  • How critical is the application to your organization?  Containerized apps are generally easy to make redundant and scale horizontally when the architecture is designed correctly.  Unfortunately, not all 3rd party apps are easy to containerize, but the landscape is improving rapidly.

  • Custom developed applications or components- this is a topic too wide to cover here, but the preference generally for custom is PaaS and functions.  It really depends on what your starting point is.  For example, legacy applications may be difficult to modernize for serverless, but there are a lot of options available to us.  In short, the criticality and architectural characteristics of the application have to be taken into account to define the optimal modernization approach.

  • Hybrid on-premises benefits – GKE allows for an application to scale from on-premises to the cloud.  This may be a very compelling option for many situations- performance or cost driven.

For www.serverless-solutions.com we chose to deploy in Google Compute Engine for the time being.  The tradeoff of performance/scalability/HA of GKE wasn’t worth the cost at this point and the SaaS option was not appealing because we are more than capable of managing the environment.  We plan to move to GKE in the near future though when our blogs start getting more hits!

Regardless of where you are in your decision process, we can help you map out a path and successfully leverage cloud computing. Contact us for a free session to help you understand your cloud deployment options.
View full post