Archive
Voxtrot will be stealing calls away from mobile operators!
Voxtrot is built by some of the original Skype team members. Unlike other mobile voip apps, this one has a real potential to change end-user’s behavior. The big difference with Skype and others is that Voxtrot does not assign you yet another username or phone number. You register with your original phone number. When you are calling somebody then Voxtrot will check if the other party is also connected to Voxtrot. If both parties are connected to Voxtrot then the default option will be to use VoIP instead of a mobile call. The Voxtrot call will be ”free” – at least if you are on WiFi or have a large enough data plan – instead of paid. As such Voxtrot will have stolen a call away from the mobile operator…
Although Voxtrot is essentially similar to Skype and others in VoIP technology, the easiness of going VoIP together with the social aspect of inviting all your friends, is really setting it apart from the competition.
Voxtrot is currently only available for Android but plans for an iPhone version were made public.
Operators will have to accelerate their search towards alternative revenue sources or risk becoming bitpipes sooner than later.
What should tomorrow’s mobile cloud offer?
The IT cloud has taken shape. The next step is to offer a mobile cloud. How will it be different and what should a telco offer? For clarity, mobile cloud applications are combinations between mobile apps and cloud computing and telecom backoffice services, not iPhone or Android apps.
Mobile screens of all colours and sizes…
Where the PC worlds only has a handful of web browsers, the mobile world is completely different. Old mobiles live together with the latest smartphones. Applications can be native or web-based. Screens can go up to 11 inches (28cm) on tablets and even if we consider television screens to 50 inches (1.27m). We can even find mobile applications without screens (M2M) or via very limited character entries (SMS).
Although HTML 5 is bringing a good potential stardard, there are still quite some differences between different mobile browsers. So it will probably take some years before a reliable standard is omni-present.
In the mean time operators will have to offer solutions on their mobile cloud. Applications will have to be available on a wide set of platforms. Any help an operator can bring to developers will be highly appreciated.
Mobile testing nightmare
Having to test an html5 application on hundreds of mobiles is a nightmare. Some companies already offer partial solutions. However providing a solution via mobile hardware virtualization and automated testing would help developers bring apps to market quickly. Testing could be paid for by minute (instead of hours in the IT cloud). Mobile makers and testing software companies could get a revenue share for every developer that uses their virtualized solution. This would release the operator from having to do all the mobile OS virtualization and sensor testbeds themselves. It would be similar to having third-parties selling access to their Amazon AMIs but instead they would be for a Nokia Symbian or iPhone 4.
Mobiles have sensors
The latest mobiles have a long list of sensors (GPS, accerelometer, etc.). Mobile clouds should offer developers help in using these sensors and automating testing. You don’t want to physically move a mobile abroad to test if you get a roaming event, would you? Push notifications to the mobile have to be supported in a uniform way accross different platforms.
Latency and network connectivity can be a nightmare
Content caching on the mobile device is key. HTML5 offers an off-line key-value store but unfortunately not all mobiles support it so custom solutions are necessary.
Advertisment support is key
Offering a ready-made integration with major mobile advertisement solutions is important. Some applications can not be charged for, so advertisement is the only means of income. Inline content sales should be supported and hopefully at more competitive rates than the App Store’s 30% revenue cut.
Telecom assets should be the differentiator
All of the above can be offered by IT and dotcoms. Integration with unique telecom assets is a must. Sending an SMS is no longer a unique asset. Neither is location. They have to be real assets: micro-payments via telecom billing, custom numbering plans, zero-cost call forwarding, voice transcription, quality of service, etc.
Become the Elastic Beanstalk of the mobile cloud, not the Google App Engine
The Amazon Elastic Beanstalk is a service that allows java developers to deploy their applications and instantly benefit from auto-scaling, elastic loadbalancing, etc. However in contrast to Google App Engine, there is no one way of doing things. Developers have the liberty to swap out Amazon’s initial configuration by customized configurations.
Mobile to Cloud and Telco connectors
The mobile app, tablet app, TV app, M2M app should be seamingly integrated with cloud applications as well as telecom services. Having single sign-on via OpenID or getting data from the cloud via oAuth are basics. Setting up a conference call, managing call forwarding, voice transcription, etc. are others.
Selling the mobile cloud via a telco marketplace
Mobile cloud applications are combinations between mobile apps/M2M/SMS/Calls/TV Apps/…, cloud computing and telecom backoffice services. Programmers should be able to add them to a telco marketplace and sell them to different customer segments (consumers, soho, small/medium/large enterprises, M2M, etc.). However offen mobile cloud applications should be given away for free and programmers should get a revenue share on telco assets that are used, e.g. calls made, SMS sent, etc.
Mobile Social Networking
Adding social networking concepts are key. Operators know who you call most often. This information can be key when combined with cloud social networks. As long as privacy and opt-in are used, then users should only see benefits.
The long tail mobile cloud is nearby…
The long tail mobile cloud is nearby and operators can be the key players in it. However they will need to suppress their urges to be greedy. Revenue shares should be inline with the dotcom and IT industry. So should individual mobile cloud application pricing.
Cloud speed in time-to-market is necessary. Operators should not try to build things themselves. Instead they should partner with dotcoms and IT/network providers in real partnerships.
Finally the rules are changing. Old rules can no longer apply. Users need to be able to choose between multiple competing mobile cloud apps. No longer can the operator’s marketing department decide what will be a hit. The user community is the only one with this power. Social CRMs and other long tail support solutions can be used to avoid massive call center calls.
When will operators offer visual VAS designing tools?
A long list of startups are making it easier every day to create and customize value-added services. These tools mainly focus on two segments:
- soho and small enterprises with visual PBX, call center as a service, etc.
- consumer oriented with voicemail, mobile apps, etc.
The main players in this new market are small startups. Companies like Twilio with OpenVBX, Invox / PBXPlus, etc. Also some established players offer solutions: e.g. App Inventor and Voice from Google, Yuave from Nokia Siemens Networks, etc.
I am still waiting for the first telecom operator to offer a similar service. Neither of these services is nuclear science. Most are SIP or other VoIP solution based. Via a SaaS marketplace operators could be reselling them if they don’t want to license or build. Additionally the operators have some valuable assets that dotcoms would love to make use off: micro-payments a.k.a. billing/charging; free call forwarding; numbering plan creation; high-available network assets; quality of service; etc.
Scalr, how to simplify cloud operations beyond Puppet and Chef
In previous articles I wrote about automating cloud operations as a key to successfully and quickly launching new services.
You can use Chef or Puppet to automate the deployment of servers. However neither solves some of the other problems with cloud operations: autoscaling and disaster recovery.
Scalr is relatively new and still a bit rough around the edges. However it has great promises to simplify deployment, automate scaling and quickly recover from server outage. Scalr uses the out-of-the-box functionality from Amazon to quickly bootstrap an environment via AMIs. Afterwards it implements an alternative autoscaling that does not rely on Amazon’s. Disaster recovery depends on the type of server but it can automatically recover from master database failure and other elements in a typical scalable web architecture.
Work on extending Scalr towards other providers like Eucalyptus and Rackspace seem to be work in progress.
Scalr is not only a good sample of the 80-20 rule in which they focus on the most common scenarios. However via a plugin mechanism it is very easy to extend. I expect other public cloud providers to contribute plugins in the near future.
At the moment Scalr is still rough around the edges but definitely with the right push of some startups and public cloud providers it should quickly mature. With some custom plugins a telecom operator that is thinking about IaaS and private clouds should definitely look at it and inspire themselves…