sipsorcery's blog
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
I was literally in the final stages of development to use Amazon’s SimpleDB as the storage for sipsorcery when an email drops into my inbox announcing a new Amazon Relational Database Service (RDS). The RDS service is basically a hosted MySQL database which is exactly what sipsorcery is using right now.
The problem the SimpleDB implementation was going to overcome is that the sipsorcery MySQL database is a single point of failure and to make it fault tolerant would require a minimum of 6 EC2 instances. With the new RDS service the MySQL single point of failure problem has been solved in one foul swoop. The same swoop has rendered nearly two months of work integrating SimpleDB into sipsorcery redundant. As Ned Kelly would say “such is life”.
Update: After looking into the RDS offering and playing around with it some more it looks like I was a bit hasty assuming it would be a better option than the SimpleDB. I was able to get a MySQL instance up and running and working with sipsorcery in no time at all. The issue though is that the MySQL instance provided by RDS looks to simply be a MySQL server hosted on a dedicated EC2 instance. That deployment model does not overcome the single point of failure limitation that currently exists. In addition the RDS documentation states that the MySQL instances will require a 4 hour window each week for maintenance downtime.
I was naively hoping that the RDS service provided database instances hosted on a MySQL cluster with five nines uptime and no single point of failure. It looks like that option may be coming but I supect the pricing will be high. The SimpleDB already provides a storage option with high uptime and no single point of failure and is cheap. It’s capabilities are less than a relational database but with a bit of wizardry that can be overcome in the sipsorcery server software. So it’s back to the SimpleDB approach.
