A crowd of daffodils and hosted clouds

You might recall the poem by William Wordsworth that begins, "I wandered lonely as a cloud." His poem may have been about 'a host of golden daffodils', but the second verse is more appropriate if we pretend that it's about the advocates of cloud computing.

"Continuous as the stars that shine and twinkle on the Milky Way,
They stretched in never-ending line along the margin of a bay:
Ten thousand saw I at a glance, tossing their heads in sprightly dance."

I'm sure there are at least ten thousand advocates of cloud computing, tossing a few heady paragraphs into their latest blog or preaching to us all from their twittering stance. "The more fool you," if you're not listening, seems to be the message.

You could say there are now two types of businesses, "Those with their heads buried in the sand and those with their heads in the clouds." That phrase would neatly sum up the present situation and, although it's not quite complimentary to the advocates, their devoutness probably means they'd miss the subtlety. Yes, indeed, the 'Cloud' is being hyped at the moment - and rightly so.

However, as with everything, there is always more than one approach. From religion, which we won't go into, to Coke or Pepsi, Google or 'Yah-who?', ..... to ..... (fill in the blanks) - those of independent mind and billions of social lemmings have all been following one trend or another since time immemorial. If open source was the right answer, Microsoft wouldn't exist. If Asterisk was the 'be all and end all', telephony equipment manufacturers would be falling by the wayside or at least ending up with double-barrelled logos (hmnn.... there's a thought). If Skype was the answer to 'life, the universe and everything', there would be more than just 560 million registered users from a global population fast approaching 7 billion.

Nevertheless, there's no denying the attractiveness of operating in the cloud. From data centres and Software-as-a-Service to communications as a service, many benefits emerge, but there is plenty of room in this universe for non-cloud operations. Where, for example, do managed VoIP services sit? They can be described as 'managed dedicated hosted' or 'private cloud' solutions. Whatever the depiction, those providers need service delivery platforms on which to host their applications and that means server-based, IP-centric, software-only enabling technology components. Ideally, those components will include a high-level API in a general purpose programming language. That leaves the application developer free to concentrate on topics such as call flow, database access and back-end processing, rather than on low-level issues involving SIP and RTP usage.

And finally, it shouldn't be forgotten that, somewhere along the silver lining of the telephony cloud, a gateway to the PSTN will always be needed. On the face of it, 'having your head in the clouds' might seem like a nice slogan for the cloud fraternity, but I'm sure they'd prefer something on the lines of 'walking on cloud nine' (or Wolke Sieben).
 
"What indeed are mere words worth?" said William.

Fax communications - the poor relation to voice and video

My previous posts in this Aculab technology blog have been mainly on the subjects of voice or video communications, which correlates well with Aculab's main customer activities where our products support services such as voice conferencing, call centre media processing, and interfacing TDM and IP communications.

An oft forgotten technology, still utilised throughout businesses, though perhaps now less prevalent, is fax. We have all been moving our business communications along with the times - investing in mobile solutions, using voice and video conferencing, getting involved in the VoIP communications space, and finding out how Unified Communications and IM might help with business communication efficiencies. Whilst many have been distracted, chasing the latest and greatest way to communicate with colleagues and customers, the humble fax machine has been there in the corner of the office, performing a key function when the newer approaches of document transfer, such as email, did not work or were not suitable.

Heading in both directions at once

Or, an alternative definition of the 'pushmi-pullyu'

I guess many of you will remember Doctor Dolittle, probably from the Rex Harrision film version, perhaps from the books of Hugh Lofting, maybe from the Eddie Murphy remake, surely not from Lotte Reiniger's silent animation. Whatever your vintage, it's the 'pushmi-pullyu' - that cross between a gazelle and a unicorn with two heads, one at each end - that challenges the imagination. A beast in eternal conflict; when it tries to move, both heads attempt to go in opposite directions. How could it make any progress?

Apply that analogy to the telecommunications market or the computer telephony market or unified communications - any label of your choice - and you might end up thinking, yes, we've got PSTN pulling one way and VoIP, let's say, pulling in the other direction. The one 'head' frantically resisting and the other, frankly irresistible.

What's really happening in the telephony market is definitely a 'pushmi-pullyu', but it's no longer a battle between opposing camps. What we see is that application developers are being asked by the market - their customers - to produce IP-centric voice and video systems. That's market 'pull'. At the same time, those very same developers are falling over themselves to offer IP-based, software-only, applications or service delivery platforms. They are 'pushing' those products onto or into the market place, because they are easier to create, sell, support and maintain. You'll note though, that they are not necessarily cheaper to buy. The end result is one party pushing with the other pulling - a 'pushmi-pullyu' where both 'heads' are going in the same direction. Magic!

Of course, vendors of enabling technology are playing their part, offering IP-based, software-only, media processing platforms with high-level APIs (C# or Python, for example). The media server or telephony engine may be drifting into the 'Cloud', but that is only one deployment option. It's a bit like saying, "premises-based CPE beats hosted delivery any day" - or vice versa. Neither statement is unconditional. Application developers who are focused on a physical, product-based model need a quicker route into the VoIP market. The greatest consumer of their time is coding and debugging so, for those guys, high-level APIs make sense, because they deliver a double bonus. Not only do they lend themselves to more rapid development, they also produce less code, which means a given 'app' is also far easier to debug.

So, who gets the last word? As Red Hot Chili Peppers sing, "Doctor Dolittle, what's your secret? Give it to me Doctor, don't keep it."

If you're looking to build telephony-enabled applications faster and more cost-effectively, give Aculab's new AMS Server a try.

There's more than one way to skin a cat

Musings on the multitude of programming language choices available to todays application developers

Yes, there's more than one way to skin a cat. You could start with the neck or the tail... meeea...oW!  Ok, Ok, I didn't mean to offend. I have, however, seen some nifty looking sporrans made out of pre-deceased, I hasten to add, wildcats from Scotland. Are programmers (application developers) a bit like cats? Cats are known for being independently minded, unlike the typically faithful, devoted, monogamous dog. In the programmer's world, perhaps that stretches to being independent in terms of the choice of their favourite programming language. How many programmers still use Erlang or Lisp, for instance?

Programmers aren't in the business of skinning cats, I trust, but they are into application development, whatever the application might be. In the world of telephony, there are many ways to write - or craft - an application, hence the analogy. So maybe Ruby Tuesday has put a spell on you or you're hooked on Groovy baby or you're a closet snake charmer (a Python in a basket case) or you spell pearl like a German or you've cast your .NET a bit wider and become a C# dresser. Whatever you choose to use, you will be making decisions along the way; from the design approach - what used to be called 'systems analysis' - to the project management approach, which might be the 'Scrum' framework, to the programming language and, ultimately, the telephony hardware.

In these days of 'software-only, IP-based systems' and 'cloud computing' it is often forgotten - or deliberately ignored - that someone, somewhere, even if it is over the rainbow, has to deal with the hardware. Software applications deployed in 'the cloud' are installed and run on hardware, but the benefits stem from someone else being responsible for those server platforms. In the world of telephony, that has lead to a fillip for hosted applications, such as those offering IP PBX or contact centre functionality, particularly when combined with SIP trunking. Of course, the problem with clouds is that they appear in lots of different forms. There are: 'Cumulus' - heaps of clouds; 'Cumulus fractus' - ragged, detached portions of clouds; and 'Accessory clouds' - clouds that develop on the body of the main cloud. The message there, I guess, is that you need to be careful with your cloud. You certainly don't want it to be a 'Nimbus' or a 'Cirrus' and it definitely needs a bit of 'Vertebratus'.

But you do want your programming language to be an 'Alto-stratus'. In terms of developing your telephony application, you should be looking at a high-level API, presented in your favourite programming language and interfacing to the telephony or media server software of your choice. In cat terms, that means you should avoid the 'shabby tabby' and settle for something more 'Alto-ordinus'. I'd recommend using a high-level programming language and API, something like C#, for example, if you're a .NET Microsoft devotee. But, as I said, there's more than one way of skinning that 'Felis'.

To find out how Aculab's latest product makes use of a high-level programming  approach using C# and Python, visit the AMS Server page here.