Archive

Posts Tagged ‘cloud app server’

Creating an amazing fast IaaS and PaaS platform, the Cloud OS

January 23, 2012 Leave a comment

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.

 

Telco PaaS is not Telco Assets and PaaS

April 11, 2011 2 comments

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:

  1. Telco PaaS services need to be launched in weeks not years.
  2. Telco PaaS services will be buggy, unstable and fail.
  3. Telco PaaS services can not be supported via a call center.
  4. There are no Telco PaaS standards and there are likely not to be any until it is too late.
  5. 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.

Telecom Greediness

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…

Follow

Get every new post delivered to your Inbox.

Join 301 other followers

%d bloggers like this: