This post is somewhat a combination of posts from previous posts, mainly, the posts about virtualization and my latest posts about the utilization of Amazon EC2. As some of you may know, a part of what I do at GreenfieldTech is develop various API’s for the Asterisk Open Source PBX systems. Two of these API’s are the IVR API and the Dialer API. This post if called “Rock Solid Clouded Asterisk” as it will describe the latest production environment that I’ve implemented, using these API’s and Amazon EC2 virtualization framework.

The network diagram

Our implementation consisted of the following general schematic:

Network Diagram

The application logic was based upon a JAVA based web-service, implementing the XML-RPC server side of the IVR API, and a dialer management system that controlled the dialer API located on the remotely located dialers – hosted on Amazon EC2 instances. For simplicity, and we were very much aware this would reduce the overall capacity, we’ve located both the dialer framework and the IVR API execution on each of the servers, while allowing the server s to communicate internally.

Some constraints

As much as we wanted to run many Amazon AMI instances, we were limited to running 5 elastic IPs with a single Amazon AWS account. As a result, we’ve registered 5 accounts, and executed a total of 24 AMI instances with 24 elastic IP’s.

An additional constraint we had realised, but had no way of actually knowing its limitation was the actual number of concurrent calls per server. Initially, we’ve reached the following numbers and configuration on a physical server:

• Intel Quad Core XEON
• 2GB RAM
• 1GB Network Uplink
• CentOS 5.2 64bit
• Total capacity: 120 concurrent calls of Dialer+IVR on a single server

Per our theory, if we managed to reach a similar capacity using amazon c1.medium instances, we would be very happy.

The results

After conducting a test utilizing a single AMI instance, we’ve reached the following results:

• Dual Core instance (c1.medium)
• 180GB Disk Storage
• 8GB of RAM
• Fedora Core 8 32bit
• Total capacity: 80 concurrent calls of Dialer+IVR on a single instance

A decrease of 33% in comparison to the performance observed on a physical server. Ok, so we weren’t all that happy with these results, until we started doing the financial math, realising that using Amazon EC2 with that Dialer+IVR framework would yield a savings of almost 80% in operational costs.

Doing the math

The normal co-located option

Our aim was to reach a capacity of around 2800 concurrent channels. Per the normal physical setup, our hardware requirements would be to use at least 24 servers. At a price of 1500$ per server, that sums up to a total of 36,000$. Adding the time required to install 24 servers, the overall expense for 24 servers would be around the 42,000$ mark. To sustain a total of 2800 concurrent calls, using the g711 codec, we would be required to carry a total of 300Mbps internet uplink – basically talking about 10,000$ of bandwidth.

So, taking all of the above into consideration, we will need a total of 52,000$ just to maintain the hardware installation and operational cost. Taking into consideration that the system would be used at full for no more than a period of 30 hours, we end up with a total of: 1733$ per hour.

The Amazon EC2 option

Now, let’s calculate for Amazon EC2:

2800 concurrent channels translates into 35 instances. Price per c1.medium instance per hour is 0.2$. So, rack that up and you get: 210$ for operating 35 instances for 30 hours.

Elastic IP costs are 0.01$ per hour per server – a total of 10.5$ for 30 hours.

Bandwidth costs are 0.17 per each GB, so according to 300Mbps for 30 hours, with each call duration at 1 minute sums up to be: 5M of data per call. Calculating 2800 concurrent channels for 30 hours gives: 25,200,00 MB, or 25TB of traffic. According to Amazon, first 10TB are at 0.17$ per GB, and then the price goes down. So, let’s take a worst case of 0.17$ per GB. A total of 4284$ for operating 30 hours.

A total of: 4,468 US Dollars, Price per hours calculated at: 148$.

The savings

Per the task at hand, the utilization of Amazon EC2 yielded a savings of 92%

So, is Amazon EC2 good for any usage?

The answer is a definite NO! If your requirement is for a system that works 24×7, like a PBX system or a call center, then your utilization of Amazon EC2 would be identical to leasing a co-located server at any of the world wide co-location providers. If your application is of sporadic nature, or is utilized for short bursts of time, Amazon EC2 is a wonderful tool for lowering your overall expenses. Sure, it will require some work to get running, but the overall savings is more than worth-while.

Like most of the world, I’ve been following the recent market turmoil with a great burden on my shoulder. When you think about it, I’m not a stock broker, nor am I a multi-billionaire that has his funds invested in various stocks and bonds, that a single 0.1% shift in the NASDAQ translates to millions of dollars. I’m a software developer, a freelance one, dealing in the Open Source – and like anybody else, I’m worried about how this crisis immediately affects me.

Today, I came across two items, post on www.themarker.com – Israel’s topmost Internet based financial/business daily. The two items dealt with how three of the better known VC’s in Israel had started instructing their investees to start cutting down costs – mainly, firing people. The three VC’s that I’m talking about are: Carmel Ventures, Benchmark Israel and Sequoia Capital. You are probably wondering why is this interesting? the VC’s in the item had directly instructed their investees to cut down people, costs, operational costs, loose dead weight – in other words, find ways to reduce your costs. Sequoia even out did Carmel and Benchmark, by inviting the investees to a meeting called: “RIP: Good Times”!

Shortly after I finished reading the two items, I got a phone call from a friend working at one of Sequoia’s companies (a well known one in Israel) asking me if he can come work for me. I was surprised, this is the first time I’ve ever read something in the news, and was directly affected by it. As far as I gathered, his company basically took a team of 8 people and reduced it to 2. Now, I completely understand tightening up, but running an operation on a 25% man power is stupid! Running at 50% is manageable, but 25% is down right crazy. For 2 people to do the work of 8, they would need to eat, drink, sleep, live, do everything within the office – I know, I’ve been there. During the year 2003, m-Wise was more or less in the shit. In the year 2002 I had a team that consisted of another SysAdmin and 3 more support techs. In 2003 I was left alone, and I basically did everything myself! – how crazy is that. But again, I decided that I’m not going to have a life for a certain period of time – that is all, not everybody is willing to make that sacrifice.

Now, this case goes hand in hand with my previous post – the migration to Open Source technologies is no longer a myth or a “nice-to-have” issue, it is a matter of business continuity and good expense management. Think about it, the company that fired 75% of their team, could have easily replaced part of their server infrastructure from Windows to Linux, migrate their Oracle database to PostgreSQL and save thousands and thousands of dollars a year, and maybe even save a job or two in the process.

Now, here’s what I think (and I know for fact I’m gonna get slammed here): Hey, VC’s, stop telling the companies to let go people. Sure, get rid of dead weight – no one needs those M$ based shitty, money grabbing, time consuming, hardware intensive environment. Wouldn’t it be better to not pay M$ a few ten’s of thousands of dollars a year, and maybe save a man’s job, or maybe even 2? M$ has enough money of their own, all you are doing is making sure they keep on making money, while the rest are fighting for their lives. Why don’t the VC’s hire Open Source consultants, to help them examine their investees and maybe, just maybe, they will find ways to invest their funds in a wiser way and help these companies to survive the current financial turmoil.