The rants and raves of a technogeek
Posts tagged GreenfieldTech
Being a successful Asterisk Consultant (Part 2)
Mar 22nd
Last time, I’ve contemplated upon the various aspects of being an Asterisk consultant, mainly judging these from the Asterisk/Open Source point-of-view. Today, I’d like to contemplate upon a different approach of being a consultant, mainly, the various aspects that are usually not associated with Asterisk consultancy, however, can increase your overall perception by your prospective customer.
Be Targeted, Don’t be Limited
Most Asterisk consultant tend to restrict themselves to the Asterisk arena, at best, they will expand their knowledge into the realms of SIP and networks – but never beyond that point. It is true that telephony makes for over 80% of the Asterisk consultancy world, however, Asterisk isn’t limited to telephony only. More than 40% of the people using Asterisk are utilizing it for something completely different. Ranging from simple IVR to complex Micro Payment systems, Asterisk is there. Surely you can consult about Asterisk, but imagine the benefit your customer will gain if you are able to advise about other issues as well?
You are most probably saying: “I’m an Asterisk expert, I can’t be a **** expert as well!’ – you’re not being asked be one. You are being asked to expand your horizons beyond the Asterisk realm, being asked to be able to answer preliminary questions about various subjects. Over the course of my work I’ve been asked about subjects as: Google Adwords, Business Models, possible business partners, applicability of solutions and many more. Surely, there are people more qualified than myself to answer each of these, however, being able to answer my customer in a short time yielded something interesting, my customer became more at ease consulting with me about other matters as well – sometimes surpassing the realms of VoIP and Networking. When I was unable to answer I always replied with: “I’m not an expert about this, but I can check it out”. If I had an answer I would reply: “Per the information that I have, the answer is ………., however, I do suggest talking to someone more skillful than I on these matters”. This approach yielded an interesting response from my customers, mainly, their appreciation at me being able to supply a form of preliminary answer for a question – while on the other hand admitting at the same time that I’m not the best at this field.
Subjects that are fairly close to Asterisk include: GPL compliance, programmatic approach, platform design, billing considerations, scalability and redundancy and more. Again, always target your knowledge to Asterisk and VoIP, but don’t be limited to these.
Advocate for GPL compliance
As a consultant, you’ll be asked to perform various projects – some of these will most probably clash with the GPL spirit. If you encounter such a request, turn down this project immediately. There is no use or advancement by doing a project that violates the GPL code of conduct. No matter if you’re violating GPL v1, v2, v3 or any other of the Open Source license variants, at the end of the day, it will creep up behind you and bite you in the behind.
An Asterisk consultant who doesn’t advocate for GPL compliance is an outbound liar and a con-man. Consulting for the Asterisk market is prmoting the usage of GPL and Open Source software. Performing projects that violate both put you into the position of being perceived as a consultant without any code of conduct and no personal believes. You will be perceived as only being interested in money, thus, you will attract the type of customers you don’t want to attract.
Business Partners
The business partners you choose tell much about yourself. Sometimes, the big partners, which you really want to put their logo on your website as a partner is the wrong partner for you. Since the Q4 2008, my company had been approach by multiple companies wishing to become partners with my company – many have been declined. They were declined due to a simple reason – they were the wrong partners, even if they were companies generating over 25M$ of income per year. Does it make me sound stuck up and elitist, maybe, but there is no use partnering with a company that may clash with your own business model. Just like customers, partners tend to attract one another. Team up with the wrong partners, you’ll start attracting the wrong partners all over.
Rock Solid Clouded Asterisk
Feb 9th
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.
Virtualizing Asterisk – Digium Asterisk World, Feb 2008
Feb 7th
Well, I just got back from the ITExpo show in Miami, Florida. I have to admit that I really enjoyed the venue, although I didn’t really have time to walk the floor. The main reason that I was unable to walk the floor was due to the fact that I gave a talk, as part of the Digium Asterisk World venue, which was co-located with TMCnet’s ITExpo.
My talk was about the possibilities and incentives for Virtualizing Asterisk using VMWARE and Amazon EC2. Following below is the presentation that I gave.
Virtualizing Asterisk – Presented at Digium Asterisk World, Feb 2008, Miami, Florida
Asterisk 3rd Party API – and their importance
Jan 30th
As some of may know, I spend most of my time working as an Asterisk Developer and Consultant in my own company – called Greenfield Technologies Ltd. - named GreenfieldTech for short. Since the day I started my company I knew a few facts and truths:
- GreenfieldTech starts as a one man operation – thus, spending more than 15% of my day to day tasks on support issues will surely stress me out and drive my business to the ground.
- I don’t really want to deal with PBX installations and various office telephony aspects of using Asterisk – simply because it requires to much of item 1.
- I need a way to be able to provide a fast response to my customers, maintain a low support over head and make sure that what ever I do, it can be accounted for.
Hence the above, I understood that GreenfieldTech‘s products are not really the various services it provides, but actually the products vary completely from what a product looks and feels like. I understood that in order to provide this fast development turn-around I needed my own development framework. Surely PHPAGI, Adhearsion and Asterisk-JAVA can easily provide for a development framework – but it still doesn’t help me one bit – I needed something different.
I then realized that GreenfieldTech‘s products are the one product line that all developers and vendor steer away from: Programmatical API frameworks. The programmatic framework should provide the most basic feature set, allowing it to be extended and continued onwards at ease. Hence, the suite of GTx API frameworks were born. A set of 3 different APIs provide all the facilities required for building any of the below:
- Dynamic IVR structures – driven via web services
- Recording systems
- Pre-Paid/Post-paid solutions
- Inteligent Network (IN) services
- Automatic Dialers – Predictive, Power, Progressive, Preview
- Broadcasting systems
- and more …
The entire API suite is based upon XML-RPC based web services. When I introduced XML-RPC to one of my customers, he immediately indicated: “But, XML-RPC doesn’t really provide for session oriented persistency. Why are you using XML-RPC?” – The reason is simple – we don’t need session persistency in the API – Asterisk can provide all of that internally. Thanks to Asterisk’s channel oriented architecture, we can regard each of Channel thread in Asterisk as a seperated data container, capable of holding all your session information and persistency information at ease.
Recorder API – http://www.greenfieldtech.net/products/gtrapi
IVR API – http://www.greenfieldtech.net/products/gtvapi
Dialer API – http://www.greenfieldtech.net/products/gtdapi
The best thing about the GTx API suite is this – they are all interconnected. For example, call being handled by the Dialer API can be then handed over to the IVR API, operating within the same Asterisk server or a remotely located Asterisk server (via SIP/IAX2).
In the time to come, I’ll be showing you various XML-RPC structures and example of how to use the GTx API suite, and do all sorts of interesting IVR and Dialer structures.
Picasa
Twitter
Facebook
LinkedIn
wikipedia
Youtube
RSS