Universities are starting to explore the future of the cloud. This future starts by getting rid of the many layers that separate software from physical hardware or bare metal. Currently you need a hypervisor (e.g. Xen, KVM, VMWare), an operating system (e.g. Linux, Windows, Mac OS), a language virtual machine (e.g. JVM), an application server (e.g. Tomcat, JBoss, etc.) and then the application.
In this article, researchers and academics are arguing that there is too much abstractions going on that could be removed in benefit of unseen performance. Projects like Open Mirage, Exokernel and Apache Mesos are examples.
If telecom operators want to offer IaaS and PaaS then they should focus on having a competitive edge that is not currently offered by established providers like Amazon and Rackspace. This competitive edge could be to build a new Cloud OS that has storage and processing nodes that run as close as possible to the bare metal. Building data storage solutions like Hadoop or Cassandra close to bare metal hardware and using the latest solid state drives would offer unseen performance. The cost per user would be substantially lower then less optimized set-ups. Ideally PaaS platforms can be delivered that allow “cloud application servers” to run on base metal. The model would be Heroku on bare metal instead of on Xen+Linux+JVM+App Server+Java App.
Telecom operators have always focused on two aspects: ARPU and time-to-market. In the latest technology craze – Cloud Computing – a lot of telecom operators are seeing a new golden grail. Those that can see further than SaaS marketplaces and moving their hosting to IaaS are only the happy few. Since Cloud Computing = SaaS + PaaS + IaaS, it is normal that operators start talking about Telco PaaS. However Telco PaaS is a lot more than combining telco assets with an IT PaaS.
IT PaaS are aimed at quickly launching applications. The IT grail is to launch thousands of applications to find the one that everybody likes and become an overnight millionair. Telecom operators might be easily fooled that opening their telecom assets to IT PaaS developers will bring that one application that will turn the telecom sector around: “The Killer App”.
Unfortunately a telecom application is more than an SDK+app server in the Cloud that can do VoIP. The reason why companies pay a plus to telecom operators is “trust”. “Trust” that you can pick up the phone and call somebody. “Trust” that if something is not working that you can call their call center. “Trust” that tomorrow they will offer you the service.
All this “Trust” has to do with the way operators have their backoffice systems and processes set-up. Having thousands of developers creating applications that mix telecom with SaaS might give some nice innovation. However telecom operators are not prepared to handle thousands of end-users that find bugs in a long list of applications and start calling call-centers massively. End-user expectations are different for telecom applications then for IT applications. This definitely has to do with the price they pay for them.
What should a Telco PaaS offer?
More than a fixed feature set, the most important changes for an operator that wants to offer a Telco PaaS might be internal. Operators will need a large shift in thinking to be able to accept some of the new realities:
- Telco PaaS services need to be launched in weeks not years.
- Telco PaaS services will be buggy, unstable and fail.
- Telco PaaS services can not be supported via a call center.
- There are no Telco PaaS standards and there are likely not to be any until it is too late.
- Telecom can not be greedy
Launching in weeks instead of years
If IT PaaS is bringing something then it is speed of development. Telco PaaS needs the same type of speed. In practice this means that REST and JSON should be the operator’s vocabulary, not SIP and CDRs. Telco Assets need to be exposed to non-telco programmers. Developer communities need to be created. Marketplaces that allow developers to sell their creations by the click of a button and not to worry about complex charging and billing.
Unstability, bugs and failure
Not every IT programmer is a genius. There are probably quite a few geniuses. Instead you need to expect that people will do things incorrectly, by error but also on purpose. Application virtualization and sandboxing are key to make sure “mistakes” don’t bring down the whole platform. On the other hand customers need to be segmented. There are customers that can see further than the bugs and see the potential. These are called visionaries or early adopters. It is critical that operators allow these early adopters to play around with buggy services. However it is equally important that the majority of users know that the sandbox might contain buggy apps and that the call center is not the place they can find help.
No support via the call center
All sandbox applications can not be supported via a call center. Agents will not know anything about these thousands of apps but neither should they. The only one that knows is the one that developed the service. He or she should get the right tools to quickly understand which bugs or feature requests are important, e.g. via a social CRM. The operator should monitor those promising apps that are ready to graduate the sandbox. They should be place in an incubation program. Incubation will see if the applications can go mainstream and will professionalize support, availability and reliability.
No Telco PaaS standards
In the dotcom world the first one that creates a solution, creates the standard. In Telco PaaS this will be the same. If we do not know how users will use a Telco PaaS, how can we expect that standardization bodies will define the correct standards. However in disruptive innovation, unlike technology evolution, first movers have an ever lasting advantage.
If you have a monopoly, you can be greedy. No competitor will offer anybody a better deal. However in Cloud Computing, greediness will kill your best innovation. It is better to get a small percentage, signup or usage fee per application when you have thousands of applications then to get nothing at all. Many cents can make billions. Think Adwords…
Telruptive is changing focus…
- Hadoop for Real-Time: Spark, Shark, Spark Streaming, Bagel, etc. will be 2012's new buzzwords
- 10 ways telecom can make money in the future a.k.a. telecom revenue 2.0
- Mesos: Your next highly distributed Cloud architecture framework
- Trident Storm, Real-Time Analytics for Big Data
- Real-Time Hadoop queries will be a reality in 2013
- Build your own 4 G LTE pico cell, GPS receiver, Bluetooth, zig bee, etc.
- NextGen Hadoop, beyond MapReduce
- Try often, kill quickly
- A Big Data-Base that is fast but inaccurate: BlinkDB
- 5 hardware trends to watch...
The Top Blogs
Want to reproduce a Telruptive post?
- MapD - Massively Parallel GPU-based database wp.me/p144kK-fh 1 week ago
- A Big Data-Base that is fast but inaccurate: BlinkDB wp.me/p144kK-eT 1 month ago
- Build your own 4 G LTE pico cell, GPS receiver, Bluetooth, zig bee, etc. wp.me/p144kK-db 2 months ago
- AWS awkward features Amazon should fix and enterprise features to add wp.me/p144kK-d9 2 months ago
- 5 hardware trends to watch... wp.me/p144kK-bA 2 months ago
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
All the contents of the Blog, EXCEPT FOR COMMENTS AND QUOTED MATERIAL, constitute the opinion of the Author, and the Author alone; they do not represent the views and opinions of the Author’s employers, supervisors, nor do they represent the view of organizations, businesses or institutions the Author is a part of.
The Author is not responsible for the content of any comments made by the Commenter(s).
While we have made every attempt to ensure that the information contained in this Blog has been obtained from reliable sources, the Author is not responsible for any errors or omissions, or for the results obtained from the use of this information. All information in this Blog is provided "as is", with no guarantee of completeness, accuracy, timeliness or of the results obtained from the use of this information, and without warranty of any kind.