A few weeks ago we wrote a post about “How to launch your MVP in a budget with BizSpark” at the Apirise blog. The post briefly explains how someone can build an early MVP with BizSpark and Azure without binding to the Microsoft technologies stack! This post is a sequel of the original post but a bit more technical this time.
What we’ll try to do in this post, is to demonstrate how we can deal with the “availability” of our application (or MVP in the current context) when we build it on a cloud platform like Azure. For this reason we’ll discuss concepts like the “Availability Sets” of the Azure cloud platform and what technologies we can use in order to utilize the availability that the cloud service offers to us. We’ll mess a bit with replication but having the availability in mind and not the scalability of our application, although the same principles more or less apply also when we want to scale our application.
So we’ll proceed by building an environment consisting of an Ubuntu server + Nginx (or apache) web server + MySQL + ElasticSearch on Microsoft Azure. I assume that this stack is quite common for many application and at the end we’ll also be able to identify what difference makes when a piece of software is written from the beginning with replication and in mind (yep I’m refering to the difference between ES and MySQL, in setup terms).
Installing MySQL (actually MariaDB)
If you wonder why we care about availability sets you better read here
By just having two instances of a database on two different VMs, doesn’t offer much even if the VMs are members of an availability zone. In order to make something out of the configuration of our machines we need the data that our application generates to be replicated between the two databases.
Replication is a quite rich and compilcated subject, the most common replication pattern is the simple master-slave replication in which one “master” node takes care of all the application writes while a number of “slave’ nodes are only reading the data, on top of that basic concept it is also possible to have failover configurations and other desirable characteristics on the DB cluster. The issue in this approach is what will happen if the “master” node fails, and although there might be solutions to that, e.g. having more than one “master” node, here we are having a situation with limited resources and thus we cannot really afford to have sets of master and slave nodes. In our case we would like to follow a master-master configuration where each node is able to accept writes and distribute them throughout the cluster. In this way we can redirect all traffic on one of the VMs we have on Azure, the writes will be replicated also on the second VM and in the case where something happens to the first node, automatically the second one will continue serving the application.