It’s nice to run applications locally, but they provide true value when you run them publicly, in the cloud.

In my previous article “List and detail the articles in a static frontend” I created two pages for listing and detailing our articles posted in WordPress through a static HTML frontend.

In this article I am taking the whole application into the cloud. I’m using Microsoft Azure as that’s the cloud service we have most experience in and is part of in2it’s #azurephp initiative.

Microsoft Azure native services

For the best results with the least of maintenance, I always advice to use native services as much as possible. In this scenario I stick with my advice and use the native services Azure provides.

Does choosing native services create a vendor lock-in situation? If you stick with the PaaS services, you should be fine. You run your own logic on top of provided platforms. Since I started this project with Docker containers on my local development environment, I only needed to change endpoints and use a plugin. Switching vendor will require me to switch endpoint and plugin again.

The same logic, but now running on Microsoft Azure

The architecture is quite simple, though very powerful to scale and to expand:

  • We store data in “Azure Database for MySQL server”, which is a cloud-scale MySQL database cluster on Azure;
  • We have a WordPress site running on a Windows Azure App Service running PHP code natively;
  • We have a static HTML frontend running on Azure Blob Storage as static websites;
  • In the middle of the frontend and WordPress backend, an Azure API Manager is put in place where requests to our exposed endpoints with a given HTTP verb (in our case just GET) are allowed and a Redis Cache for storing responses coming from WordPress API;
  • We store our WordPress images also on the Azure Blob Storage in a separate container and attach an Azure CDN to it;
  • Azure Application Insights will give telemetry and service health information;
  • A VPN Gateway will ensure that only legitimate users have access to the backend;

NOTE: I installed the WordPress plugin “Microsoft Azure Storage for WordPress” to store all images on the Azure Blob Storage. To speed up delivery I use Azure CDN.

Microsoft Azure Storage for WordPress plugin

In the frontend HTML I need to replace the line for the new Azure backend service provided by the Azure API Manager:

var backendUri = "https://in2it-wp-api.azure-api.net/api

I migrate the data and WordPress artefacts to the Azure App Service using the Azure SDK CLI and MySQL client software.

For publishing the WordPress application, I create a ZIP file from my existing WordPress site called build.zip and which I will deploy onto the Azure App Service using Azure CLI.

az webapp deployment source config-zip --resource-group <resource_group> --name <app_service_name> --src ./build.zip

For the frontend less work is required. I push out the frontend code directory straight ontop of the Azure Blob Storage, again using Azure CLI.

az storage blob upload-batch -s './frontend' -d '$web' --account-key <secret_key> --account-name <blob_storage_account_name>

At this point I can go to the Azure Static Website endpoint to see the result of this scalable work.

Still the same listing as before, but now powered by Microsoft Azure cloud.
Even detail pages work, just as before

Direct access to WordPress is now blocked, so the infrastructure is safe and secured while only content can be provided to the public.

No more pesky exploits on your WordPress website

That’s all there is to it (for now). I will dig deeper into the inner workings of REST API endpoints in Magento, Suite CRM and Drupal to see if we can improve on scalability and reduce security risks. More to come soon.


Michelangelo van Dam

Michelangelo van Dam is a senior PHP architect, PHP community leader and international conference speaker with many contributions to PHP projects and community events.