TABLE OF CONTENT
|2. WordPress on Azure Kubernetes Service|
|3. WordPress on AKS with Azure Database for MySQL|
|4. WordPress on Webapp for containers|
|5. Final Verdict|
|6. About CloudThat|
Emerging Cloud Computing technologies are majorly developing advanced applications with modern technologies. Microsoft Azure is at the forefront and provides various cloud services like Azure VM, Azure Storage (blob, fileshare), Azure Function App, Azure Data Factory, and many more.
One of the challenging things for a cloud architect is to make architecture decisions that are optimized, cost-effective and resilient. The goal is to make you aware of the parameters to consider while choosing the right decisions based on different approaches. We will discuss various options by looking at real-life examples of deploying a WordPress application on the Azure cloud, which will be highly available and scalable.
Approach 1: Highly Available and Scalable WordPress on Azure Kubernetes Service
Services to use:
Azure Kubernetes Service, a.k.a. AKS
Azure Kubernetes Service AKS:
AKS is managed Kubernetes service provided by Azure, where they manage the master node for Kubernetes by themselves, which offers benefits such as auto upgrades, self-healing, and patching. This reduces the time-sink for the developers to handle debugging. Other than that more like optimizing resource utilization and scaling massively at speed with ease.
Let us talk about details on Kubernetes, which we can use to deploy our WordPress application.
A Deployment provides details that can update Pods and Replicasets declaratively. You describe the desired state and create a new replica set that removes all the existing configured resources and adopts a new one.
Replicaset is used to maintain a stable set of Pods running at any time and assure the availability of the desired number of identical Pods.
A Service is a way to expose your pods to network service. It resolves the problem of modifying the mechanism for service discovery by giving their IP addresses and DNS name for the set of Pods with load balancing capability.
An API object that helps you to manage access from the external world to services in the cluster such as HTTP, where it also provides features such as SSL termination, Path-based routing, and load balancing.
In simple terms: It will help the service to expose via HTTP and HTTPS to the external world with rules that can be controlled for routing.
A Persistent Volume (PV) is a chunk of storage in a cluster that can be provisioned using storage classes such as node and pod as cluster resources. They are plugins like Volume with lifecycle, which pods use independently using PV. It can be implemented by capturing the configuration of NFS, iSCSI, or a cloud-provider-specific storage system
A Persistent Volume Claim (PVC) is the request of storage by pod, just like Pod use node resources while PVCs use PV resources. Where Pods can have specific CPU and memory and claims can have the exact size and access modes such as ReadWriteOnce, ReadOnlyMany or ReadWriteMany.
Storage options for applications in Azure Kubernetes Service (AKS)
Here we can use Persistent Volume and Persistent Volume Claims to manage our WordPress web data and MySQL data for our storage requirements.
With Azure, we can have two options for Storage Classes:
Can be created as Kubernetes DataDisk resource where
- Azure Premium storage, backed by high-performance SSDs(suitable for production workloads)
- Azure Standard storage, supported by regular HDDs.
The Limitations are that it can be mounted as ReadWriteOnce only available to a single pod.
To avoid this limitation in providing access to multiple Pods, one should use Azure FIles
They are mounted as SMB 3.0 shares backed by an Azure Storage account to pods. It lets you share data across multiple nodes and pods and can use:
- Azure Premium storage, backed by high-performance SSDs, or
- Azure Standard storage backed by regular HDDs.
Approach 2: Highly Available and Scalable WordPress on Azure Kubernetes Service with Azure Database for MySQL
Services to use:
- Azure Kubernetes Service, a.k.a. AKS
- Azure Database for MySQL.
Here, we will use the same components for WordPress(pods) mentioned above. However, Instead of MySQL on Pods, we will use Managed service by Azure, that is, Azure Database for MySQL.
Azure Database for MySQL
It is a fully managed relational database service offered by MS Azure that works on MySQL community edition. In contrast, you can have a single or Flexible server as per your choice, which can handle critical production workloads with optimum performance and dynamic scalability.
Approach 3: Highly Available WordPress on Webapp for containers with Azure Database for MySQL
Web App for Containers
It is served as PAAS offering on App service looking more towards developers who want more control over not just on code with different runtime framework tooling and packages to opt to be installed on containers. Allows forgetting all the worries of managing and maintaining container orchestration which runs. With such advantages, it also provides building CI/CD for packaging code and dependencies for containers using various DevOps tools such as Azure DevOps, Jenkins, or Maven, along with webhooks on App service for automated deployments.
Here we can also leverage the power of Azure managed database service i.e., Azure Databases for MySQL.
Below is an example of simple continuous integration:
Here are the judging criteria for all the three approaches discussed above to select the most suitable Architecture:
Above all the approaches, I think the best suitable architecture would be the 3rd approach, Azure Webapp on containers with Azure Databases for MySQL. It is because it is easier and simpler to deploy and work with than the other two. It may cost you more. However, the features it provides are worthwhile. On the other hand, it does not need to have any Kubernetes expertise, which could be an advantage.
The above three approaches have their own pros and cons. Your decision is based on flexibility, manageability, fault tolerance, and scalability. The 3rd approach, which is Azure Webapp on containers with Azure Databases for MySQL, could be that it is far easier and simpler to deploy and work with than the other two. It may cost you more. In the 2nd approach, you get the power of the Kubernetes engine and Azure Managed Database which will ide resiliency and the 1st approach is more suitable for Kubernetes experts where they can manage stateful states for MySQL databases while providing elasticity and scalability at convenience.
Let me know in the comments which approach you like most and why it is worthy of choice.
I may not have mentioned Azure VM in this blog because of the production workload and more focused on containerization technology which helps us use resources optimally. Still, you can select that using Azure VM Scale Sets and Azure Application Gateway for high availability.
CloudThat is the official Microsoft Gold Partner, AWS (Amazon Web Services) Advanced Consulting Partner, Google Cloud Partner, and Training Partner helping people develop knowledge of the cloud and help their businesses aim for higher goals using best-in-industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.
CloudThat is a house of All-Encompassing IT Services on the cloud offering Multi-cloud Security & Compliance, Cloud Enablement Services, Cloud-Native Application Development, and System Integration Services. Explore our consulting here.