sipsorcery's blog
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Because of the sipsorcery.com outage last week as a result of the Amazon EC2 instance losing it’s network connection I got motivated to look around at the other cloud computing environments and while I didn’t find anything that matches Amazon’s flexibility one thing I did look into i depth was Microsoft’s SQL Azure offering.
SQL Azure is a hosted instance of Microsoft’s SQL 2008 database with all the really difficult issues like clustering, replication, load balancing supposedly taken care of. That means from an application point of view the database can be treated as a nice big bucket to get things to and from. Compared to Amazon’s Relational Database Service SQL Azure is far superior because the Amzon RDS is simply a single instance of a relational database with none of the afore mentioned clustering, replication and load balancing. The Amazon RDS would not offer a lot above the sipsorcery’s current database approach where a MySQL instance is running on the sipsorcery.com server.
I have discussed this problem in the past and in fact have spent quite a lot of time over the last 3 months working on a way to allow Amazon’s SimpleDB to be used as sipsorcery’s data store. While I did acheive that goal there are just enough shortcomings of the SimpleDB offering to keep me a bit hesitant about switching over to it. Its querying capability is very limited compared to a relational database but the biggest worry is that all communications with it are HTTPS which introduce quite a bit of latency. Now it’s probably not enough to be a showstopper, in my initial testing I observed a delay of between 500 and 800ms when making a call above the current situation, but enough to be slightly concerned about.
Out of interest I decided to try and use SQL Azure as the data store for a sipsorcery instance and see what additional latency that would introduce given that the database communications would now need to travel between Amazon’s and Microsoft’s data centres. The results were very heartening and were in the order of 100 to 200ms for call set up which is only just percetible for a user making the call. That coupled with the fact that SQL Azure would still provide the powerful querying capability of a relational database has placed it firmly in place as the favoured sipsorcery data store option. The development work to use SQL Azure wass less than a day which was because all data access in the sipsorcery servers now uses LINQ and Microsoft include Linq-to-SQL as a core library in the .Net framework, another big advantage.
Now that the SSH console is largely complete the next job I am going to tackle is to try and get two sipsorcery servers running side by side in a redundant mode so that if an incident like last week’s does occur and an instance becomes inaccessible the other one will still be available. Up until last week I was going to do that by using Amazon’s SimpleDB but if things continue to go smoothly with SQL Azure it will eventually become the new sipsorcery data store.
