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).
Our current scenario architecture… a bit expanded…
We are building a simplified scenario of an MVP application that depends on the combo of a webserver + MySQL (somehow we to save our state)+ ElasticSearch (you know… for search…). We will create:
- 2 VMs with identical setup and Availability Set
- Load balancing between the two webservers.
- replication for the MySQL and ElasticSearch between the two VMs
Ideally all the traffic should go on one of the servers while being replicated to the second. In case where the first VM fails, the traffic will be redirected automatically to the second. In a more realistic scenario we would require different servers for the MySQL, the ElasticSearch and the web servers.
Keep in mind that we are talking for an MVP where we just want to ensure availability while having limited resources.
We chose to stick with a much simpler scenario with just 2 VMs due to the fact that from the Azure point of view, the process would remain the same anyway.
Having this architecture in mind in order to deploy it on Azure and actually exhibit the desired availability also on the application level we have to follow a number of steps:
- Setup the actuall availability sets, together with load balanced sets of endpoints that will expose our web servers. More info about this part you’ll find here.
- Then we’ll have to figure out how to properly setup a relational database where we can safely store the state of our application, something that can be done using MariaDB using these steps.
- And finally we have to setup ElasticSearch which was a quite fun process, documented also here.
The whole process of setting up such an environment on windows azure was quite fun, and I hope you’ll find summazired some useful information on how to deal with availability. In case of course that you want to skip the guides above, you can go directly to the the final thoughts and conclusions below 😉
Setting up an availability set together with more than one VMs running is essential if we want to guarantee the high availability of our application. But even if creating an availability set is an easy task, it is quite useless if our application is not capable of replicating its state over the multiple nodes that belong to the same set. For this reason we demonstrated how someone can setup mariaDB in a master-master mode with replication and how to install and run ElasticSearch on Azure with cluster auto discovery enabled using the appropriate plugins together with the Azure API. Of course ensuring that the data layer can be replicated over the availability set is not enough; the web application should also work without introducing issues when the load balancer will redirect the traffic from one node to the other, e.g. think for example about sessions management.
Regarding the database, Windows Azure offers “SQL Database” as an out-of-the-box solution for using an SQL database with your application, which also ensures data availability. Now, our problem with that was the cost, unfortunately the cost of running an SQL database on Azure is quite high and as our product is not that storage intensive we decided to follow an approach similar to the one presented in this article. In any case if you have an application that relies heavily on an SQL database and you are deploying on Windows Azure, you should consider using an SQL Database instance, at least it will remove the overhead of replicating your database over the availability set.
ElasticSearch has an excellent support of Windows Azure through the plugin they maintain while, supporting auto discovery through unicast and the Azure API is just awesome; with some initial configuration you can easily add more nodes to the cluster through a script (check the links here). Another good surprise was the quality of the documentation regarding the plugin, if there’s one thing I usually complain about ElasticSearch it’s the documentation they have, but for the case of the discovery plugins their documentation was excellent.
If you have noticed the mariaDB setup there’s no auto-discovery mechanism there but we had to explicitly declare all the nodes in the configuration of the database, I’d love to have something similar to the auto discovery that ElasticSearch has through its plugins also with mariaDB Galera, it would make the managing of the cluster a much better experience.