For the better part of the past 15 years, I’ve been a PHP developer. Really, I’ve developed everything in PHP, ranging from server side services, web services, backends – you name it, I’ve probably done it with PHP. Don’t get me wrong, I love PHP and it will always remain my language of choice for doing things really fast.

However, for the past year I’ve been increasingly developing with Python. I’ve always dabbled with Python, but never really had the chance to truly get down and dirty with it. Due to a couple of projects during the past year, specifically ones that involve Google AppEngine, I’ve had to sharpen my Python skills and get to a point where I can develop with the same agility that I have with PHP. Honestly, it wasn’t simple – sometimes I truly wanted to strangle someone with various errors a framework can spit at you. However, once you get around to reading the various cryptic messages Python may spit at you, getting around it and working with it is truly a delight.

So, why do I think Python should be the first language one learns? so here are my thoughts:

I started my coding days with BASIC, to be more accurate GW-BASIC (yes, I am that old). From that I moved to Pascal (Turbo Pascal to be more accurate), then C, then C++, C++ Builder, Visual C++ (yes, I did MFC at some point in my life as well). I then decided that my life is in the open source world – and thus, the track then went to PERL, JAVA and of course PHP. Honestly, somewhere around 2005, the mixture of C, JAVA and PHP truly gave me all the power I needed to do my job – so, I didn’t really find the time to learn a new language.

Then, about a year ago, I decided it’s high time to learn something new – specifically, I became increasingly interested in the Google AppEngine platform. Yes, I’ve been using Google Compute and other cloud platfroms for a few years now, I’ve used most of Amazon’s services, ranging from EC2 up to RedShift and their hosted Hadoop clusters. But when Google AppEngine came out, it only had Python, Java and GO to work with. Java is the least favorite language in my tool box – honestly, I hate it. I’ve never coded in GO, and didn’t really feel like starting out with it. And Python, well, I dabbled with it – but can’t say I’ve done something too serious with it. In 2014, Google added PHP support to Google AppEngine. Damn, that sounds cool – let’s play around with that. So, I built a few applications atop of AppEngine and the PHP SDK. I rapidly realized that while the PHP SDK gives you some power, Python is the more natural choice for AppEngine. So, I more or less sat my ass down for 3 days and decided to teach myself proper Python.

Took me about 3-4 days to get around the quirks of AppEngine and how to get it up and running using PyCharm (if you use Python, by far the best IDE I’ve seen). Then building up my first application, then migrating an existing application (a fairly big one), from PHP to Python on AppEngine. I then rapidly moved along to using easy_install, pip and the other Python tools that make life so easy for developers – honestly, right now, I can’t figure out why use anything else other than Python for shell environment tools. But, regardless of that, I honestly think Python is the first language you should teach students, not C/C++, not JAVA, not Ruby and surely not PHP (and I’m a huge PHP advocate).

Why do I say this? here are my main reasons:

  1. Python is objected oriented from the ground up, which means, that teaching object oriented programming using Python is easy and straight forward for new comers.
  2. Python is strong typed, which means that syntactical issues are dealt harshly – promoting proper usage of syntax, indentation, capitalization, variable handling – all the nice things that make good code – readable code.
  3. Python’s physical typing construct, where blocks of code must be tabulated in specific manner in order to make the code work in specific manner – is GENIUS. I’m very much a “Source Code Nazi” (Imagine that coming from a Jew, right?). For me, indentation, proper loop blocks, proper case blocks, making sure things are wrapped really tight without too many white spaces – this is what makes code look nice.
  4. Python is interpreted, not compiled – but yet, it is strong enough to hold the most complex multi-threaded of tasks.

In other words, if you take the above and teach to a new developer, someone who writes code for the first time in his life – your result will be a developer, that may not dish the best code at first (after all, a beginner), but it will be readable, manageable and maintainable. Python automatically promotes these by its structure, by its rigidness and by its agility at the same time.

As part of my academic studies, I’ve studied education and how to teach computer science to high school students. I’ve learned that you should start with Pascal or C, then move to Object Oriented, then move to more advanced stuff. I have one thing to say: BULLSHIT! Honestly, the first thing you need to teach is Python, after Python, the rest are just syntax. Nothing more, nothing less – pure, simple, straight forward syntax.

Would love to hear your opinion on this one…

During this years’ Asterisk Developers’ Conference, one of the subjects I’ve raised an issue for Asterisk is: “Federating Multiple Asterisk Instances”. Now, for the seasoned Asterisk user/developer, the answer would be simple – use Kamailio/OpenSIPS for that scalability, and use Asterisk as a Media Gateway or application server.

But I ask the following: “What if we could federate Asterisk without the need for an external component? What if we could federate Asterisk in such a way where our users aren’t event aware of the federation process, and it’s fully autonomous? What would actually be required in order to do that?”

I’m normally confronted with these questions on a day to day basis, looking at the problem from different angles – thinking to myself: “Ok, I know the normal box here – but where are the outer limits? what can I do to make it more robust on one hand, without truly making a mess out of it.”

A federated database is defined as: “A federated database system is a type of meta-database management system (DBMS), which transparently maps multiple autonomous database systems into a single federated database. The constituent databases are interconnected via a computer network and may be geographically decentralized. Since the constituent database systems remain autonomous, a federated database system is a contrastable alternative to the (sometimes daunting) task of merging several disparate databases. A federated database, or virtual database, is a composite of all constituent databases in a federated database system. There is no actual data integration in the constituent disparate databases as a result of data federation.” – http://en.wikipedia.org/wiki/Federated_database_system

So, we would like to virtually create a “map-reduce” functionality for Asterisk? can we truly create a map-reduce’ish functionality for Asterisk? should it be internal? should it be external?

In order to accomplish this, we are required to create a federator – a device capable of handling the information regarding each users, device, trunk, provider and other wise SIP/IAX2 entity connected to our system. The federator for all practical purposes is a data store, be it a key-value store, a database, a shared memory environment or some other form of data distribution layer.

Here are some key issues that true federation may be required to tackle:

  1. Geo-Position Agnostic – A truly federated system should render services identically across the board, regardless of where the user is located.
  2. Services Agnostic – A truly federated system doesn’t care if the user is connected to an Asterisk server version 12 or 13, it should behave identically.
  3. Version Agnostic – A truly federated infrastructure can leverage older version and even other software, without changing the underlying federation layer.
  4. Predictable Scalability – A truly federated infrastructure will allow for growth to be planned linearly, with discrete measure methods.

So, you want a tip on how to start federating your systems? here’s step number 1 – there is no central registry, there is no SIP proxy, there is only the cloud and the services it renders. Start thinking from this point and see where you go.

So, Astricon 2014 is over and behind us, so now I’m now sitting at the Holiday Inn in Chicago. I have to admit that moving from the RedRock resort and Casino to the Holiday Inn in Chicago – talk about a mind blowing change. Just to give a general idea, the bath room in Vegas was roughly the size of the entire room here (mental note to self – next time order something better via BA miles).

So, this years’ Astricon was, at least for me personally, one of the best I’ve been to. Various topics that I’ve started talking about years ago, had finally made their way to the public’s ear, and the community and adopters are finally picking up on these. Security, privacy, cloud computing, proper usage of Linux and virtualization – these are now become the predominant subject people are confronted with.

Unlike previous years, I decided to talk about Cloud computing and some tips from the Cloud front line. Cloud computing, specifically cloud based servers are and infrastructure that many want to use – but very few truly understand what it means. What kind of impact does SWAP have over your instances, what is the swapiness value? and why the hell would I choose one cloud over another – aren’t they all the same at the end?

This year, we had the first ever Astrion Hackathon. I’ve participated in several Hackathons in the past, but this was very special to me. While in most Hackathons I’ve participated the participants never knew each other (well, at least 95% of them), here, most participants knew each other – some on a very personal basis. As you know, my latest Open Source passion is my own pet project – phpari. My hack for the contest was a phpari sandbox, imagine it to be a cross between jsfiddle, Asterisk and PHP. A simple use playground, where you can try various parts of ARI in general and the toolkit in particular. Much to my surprise (as there were other strong candidates), the phpari sandbox won the “Asterisk Developer’s Team” Award, for best use of Asterisk during the Hackathon. To me personally, it means a whole lot. I’ve been dealing and working with Asterisk for over 12 years now, in fact, I was joking around with Corey Mc’fadden that we are currently, probably the oldest Asterisk community members around – well, probably oej, joshc and a few others are as old as us. We never had a chance to actually see how we work together, how we think about various problems and challenges. This was the first ever time we’ve got to see each other work, how we work, how we look at things – it was exciting. Looking at Tim Panton as he battles the various concepts of Respoke and he’s application – trying to figure out exactly why “Respoke” didn’t work as he expected (amusing to say the least).

So, after Astricon, we spent the last evening going out to the Vegas Strip. I have one thing to say right now: “I don’t think I like Vegas all that much”. It’s just too much of everything. Too much “Putti’n on the Ritz” facade, too much commercialism of everything and anything, just too much for me. Don’t get me wrong, it’s an interesting place to visit, but I don’t believe that being there more than 2-3 days is required in order to appreciate the place. Be it the lights that are always bright, making you believe it is day light, the hotel that literally had no windows to the outside – so you won’t know if it’s day or night, the entire system gets screwed up totally.

So, during the night of the “geeks take over Vegas”, the following group of people decided to head to the strip:

  • Allison Smith
  • Peter – Aka: Mr Allison (hey, what do you want, you’re married to the voice of Asterisk)
  • Ben Klang (Adhearsion/Mojo-Lingo)
  • Evan (sorry, can’t recall the rest)
  • Steve (Mojo-Lingo)
  • Dan Jenkins (Respoke)
  • Eric Klein (My partner in crime)
  • Correy McFadden (Venoto)
  • Beth – Correy’s Wife
  • Steve (From South Africa)

So, here we are sitting at the cosmopolitan waiting for our table to the STK. Once we got it (at 10:45PM), we sat down at the stools waiting for our table. At the table next to us, a man and two young ladies were definitely getting it on. To be more descriptive, apart from actually going at it in front of us all, they were all over the place. As they say, what happens in Vegas – stays in Vegas. But what happens at a public restaurant, don’t be surprised to find it on Twitter. Coming to think about, we should have videoed the entire thing. Now, don’t get me wrong, I’m as much a man as the other guy, and I admit that the display was interesting (so say the least) – but comm’on, we’re a public place – get a bloody room. The funny bit was that Peter came back from the rest rooms, saying that he was delayed due it being occupied. When the door opened, two girls walked out of the same compartment – and I’ll let your imagination continue from here. So, as Eric commented on Trip Avisor – the music was loud, the service was slow – but the Steak WAS PERFECT. In deed, one of the finest steaks I’ve had in a long time.

One more thing I need to mention in our dinner (Eric and Myself) with John Draper – aka: Capation Crunch, but that’s a whole different story all together.

Ok All, this is my official Astricon Countdown – start your engines, as Eric Klein and myself will be attending Astricon this year, Vegas here we come.

So, what are we going to talk about: Security and Cloud computing. Yes, over the past year, I’ve been returning to my old stomping ground, the various cloud infrastructure that is publicly available – and how to exploit it to the max. I will be talking about the various methods of speeding up your clouded Asterisk server, and most importantly, I’ll share some of the methodologies and logic behind building these instances, maintaining them and the various do’s and don’ts I’ve learned along the way.

I’m planning a few surprises and giveaways for my talk, so make sure you stay updated on this page 🙂

 

*** This post was originally posted at http://www.greenfieldtech.net

Here’s a challenging question for the Asterisk technical savvy of you… What is the top performance you can squeeze out of an Asterisk box, running on Amazon EC2 – or to that extent, a cloud infrastructure? If you scout the Internet, you may find various answers – however, most of them aren’t backed up by real numbers or real information,made accessible in a normal readable form.
Recently, we’ve become heavily involved in a project requiring massive usage of cloud based infrastructure. I won’t go into details as to what the project is or what we are doing, however, I felt that some interesting facts about Asterisk 11.0.1 and Cloud infrastructure can be shared with the rest of you.

Before we dig deep into the actual results, let’s talk about the various measurements usually associated with performance assessments of an Asterisk box, mainly, the machines load average. In order to continue, we must first understand what the Linux Load Average actually is. Most of you know load average as the below:

Load Average Example

Most people know the load average as those 3 numbers, ranging from 0 to anything higher, and if the numbers reach a certain level – it’s bad. But the question is: “What is a good number? and what makes a number bad?” First, let’s understand what the number represents. Load average is an exponential average of all your machines processes. Running processes, sleeping processes, waiting processes and on Linux, also processes currently waiting for I/O access. Now, these number are directly correlated to the number of processors/cores your server has. In general terms, a machine with a single core, any number higher than 1 is considered bad – where 1 represents 100% of the resources being consumed. So, if your machine has 4 cores, the number 4 is your top most number – and from there it’s linear. Now, can we calculate HyperThreading into the equation, multiple CPU pipelines, SSD access – in Linux, all these come into play into that equation. In other words, we’ll never know what is the actual top limit, but working with a rule of thumb based upon the number of cores is a good practice – specifically if your operational environment is a virtualized one.

Now, there are 3 numbers in there – a 1 minute average, a 5 minute average and a 15 minute average. Technically speaking, the 1 minute average isn’t really interesting – as it is highly affected by context switches and process bootstrapping, thus, there is a good chande that its number will be higher than the “advised” number. The numbers that are more interesting are the 5 minute and 15 minute average. Technically speaking, if your machine’s load average is considerably higher than the advised at these, something is definitely wrong.