Bluemix now has multiple region (US and UK) to host applications. So user has choice of selecting regions depending on network connectivity. I was wondering that because Bluemix is based on open platform called Cloud Foundry, it should be able to support the same application on each Cloud Foundry instances via DNS round robin.
This is a preliminary experiment for hosting the same application on both region using the same URL. Bluemix can bring your own domain. For example, I can have “example.com” domain for my applications. I noticed that I can set up the same domain for each region in US and UK.
$cf domains name status mybluemix.net shared ng.bluemix.net shared example.com owned
$cf domains name status eu-gb.mybluemix.net shared eu-gb.bluemix.net shared example.com owned
I have setup DNS server locally, and setup it to do round robin for each host. For example, dnstest.example.com has IP address, and the same host has another IP address.
And created an alias dnsapp for the host (dnstest). If I run “nslookup” command to search for dnsapp.example.com, it surely returns IP address via round robin.
$ nslookup dnsapp.example.com Name: dnstest.example.com Addresses: 188.8.131.52 184.108.40.206 Aliases: dnsapp.example.com
$ nslookup dnsapp.example.com Name: dnstest.example.com Addresses: 220.127.116.11 18.104.22.168 Aliases: dnsapp.example.com
Then, I pushed the same application with slight modification to show the region (i.e. US or UK).
# Push the application to US region $cf login -a https://api.ng.bluemix.net $cf push dnsapp -d example.com
# Push the application to UK region $cf login -a https://api.eu-gb.bluemix.net $cf push dnsapp -d example.com
The result was not that I expected one. I always got the same result. It seems either computer or browser seems to cache the IP address. So I need to bring two PCs. And open the http://dnsapp.example.com. Here is a result. I now see the same application with the same URL runs on both Bluemix regions.
If this works, I think this can become yet another solution for redundancy. For example, we might get some disruption in the region due to security update (e.g. Shell Shock). But if we have the same application with the same URL in the different region, it is likely that the application will be able to serve to end-user without significant impact.
I also think this can be used on another Cloud Foundry instances, such as NTT’s Cloudn PaaS, Pivotal’s one, or your own. This means the same application with the same URL should be able to run on various Cloud Foundry instances. Our application scales beyond just one cloud vendor. This is the power of Cloud Foundry openness. By the way, this blog is still experimental state, but surely good to start about scalability beyond region.