Archive

Archive for February, 2011

The container for long tail post-sales support – part 2

February 25, 2011 1 comment

In a previous post I shared that I was looking for the container for long tail post-sales support.

Today I would like to present a draft proposal. Feedback is very welcome. The idea is to simplify support to a 0 to 5 stars model:

0 stars: No support.
1 star: Best-effort / community support
2 stars: Basic 8×5 SLA with no penalties and web/email support,  daily scheduled maintenance windows possible.
3 stars: Basic 8×5 SLA with limited penalties and phone/web/email support, nightly scheduled maintenance windows possible.
4 stars: Advanced 24×7 SLA with significant penalties, phone/web/email support, and limited off-peak (e.g. weekend nights) scheduled maintenance windows
5 stars: Mission critical 24×7 SLA with high penalties, on-site support and no scheduled maintenance windows

Additionally the operator would be measuring both the availability of the service,  the responsiveness of the support, and the buyer’s satisfaction rates hence not only the “theoretical SLA” is available to potential buyers but the last 12-months of actual performance as well.

By having a simple star system, small and medium enterprises would immediately be able to compare a 1 star with a 5 star support. Afterwards within each star level there might parameters that can differ like the amount of penalties, the 8×5 time zone, the nature and limits of the schedule maintenance windows, etc. So there is still flexibility and potential to differentiate through support.

Having a standard support offering would be one step closer for buyers to be able to understand what they are buying and for operators to be assured that companies offer a standardized high-quality service.

Standardization bodies could even make contract templates, certification programs, etc. to make sure post-sales support is uniform and easily understandable.

Looking for the right hypervisor for my private cloud or IaaS is the wrong question

February 18, 2011 2 comments

If you are trying to find out what the right hypervisor is for your private cloud or IaaS then you might be asking the wrong question…

Do most applications really need an OS and hypervisor is a better question?

One company of the companies that is exploring this area is Joyent. Thier SmartOS is like the mix between a virtual machine and a combined OS + hypervisor. Instead of installing a hypervisor, on top an operating system, on top an application server or database, the Joyent team thought it would be more efficient to try to remove as many layers as possible between the application/data and the hardware.

According to publicly available videos and material, their SmartOS is based on a telecom technology for high-scalable low-latency application operations. Unfortunately Google does not seem to be able to answer which telecom technology it is. So if you know the answer, please leave a comment.

The idea of running applications as close to the hardware as possible and being able to scale an application over multiple servers is the ultimate goal of many cloud architects. Joyent claims that their SmartOS runs directly on the hardware. On top of SmartOS you are able to install virtualization but ideally you run applications and data stores directly.

The next step would be to combine the operating system with the  virtual machine/application server or database server into one.  Removing more layers will greatly improve performance as can be seen by Joyent’s performance tests.

So the real question is: do we need so many extra layers?

A distributed storage system, a virtualized webserver, a virtualized app server, a distributed SQL-accessble database or NoSQL solution that would run straight on hardware with a minimal extension to distribute load over multiple machines would be the ideal IaaS/PaaS architecture. It would give customers what they really need: performance, scalability, low-latency, etc. Why add a large set of OS and hypervisor functions that at the end are not strictly necessary?

How to avoid becoming a bad Amazon-clone when doing IaaS?

February 17, 2011 Leave a comment

In previous posts I already expressed my doubt about telecom operators getting any real benefits from offering virtual servers and other IaaS aspects to their customers. It looks like “a 2000 déjà vu” in which operators started to offer hosted email after Yahoo and other showed them the way…

So if you don’t want to be a bad clone of Amazon AWS what can you do?

Alternative 1: The Mobile IaaS

Operators are all about mobile communication. However creating mobile applications is hard. Testing them is even harder. Let alone testing them on different hand-sets in a continuous automated testing approach.

This is exactly the type of services that a mobile operator can offer:

  1. Mobile hardware virtualization – instead of virtualizing an x86, why not virtualize the phone hardware, e.g. Nvidia Tigra2. A mobile operating system (MOS) developer could choose which hardware to virtualize: the amount of ram, which sensors, which CPU, which graphics card, etc. Afterwards different flavors of operating systems can be ran on this hardware: iOS, Android, Blackberry OS, Symbian, Windows Phone 7, etc.
  2. Mobile operating system virtualization – For less experienced developers they can already pick a pre-configured phone, e.g. iPhone 4. Afterwards a developer can launch applications on the phone.
  3. Automated mobile phone testing – After installing the application on the phone or using the build in browser to access a remote application, a developer should be able to run automated tests. This would allow for a continuous testing approach whereby a new version of a mobile app or an HTML5 application can be automatically tested by a whole set of mobile devices.

The business model would be the same as virtual servers: you pay by the hour.

Alternative 2: Telecom Infrastructure as a Service

Why not offer telecom infrastructure as a service instead of pure virtual servers? Admitted, the boundry between IaaS, PaaS and SaaS might be thin but ideas can be the following:

  • Billing as a Service: this can go from offering a complete billing system as a service to MVNOs or other industries that need real-time billing capabilities. To the other extreme whereby you would only offer APIs for partners and developers to charge.
  • Numbering Plan as a Service: more then just offering DIDs, you should be able to create services and associate them to a number formed by shortcode+mobile phone+app id => 12367012345601 => calling this number would forward the call to the application 01 belonging to the mobile subscriber 670123456 and 123 means the owner pays the call. 234 could mean caller pays. 345 could mean caller pays premium call and gives revenue share to owner. This could allow every subscriber to have multiple applications without having to pay €1-€5 for a virtual phone number.

Alternative 3: Mobile Development IaaS

Different from the mobile IaaS in the sense that we focus on facilitating the development and hosting of applications for mobiles. Developers would find tools to develop mobile application interfaces very easily. You write it once and run it on a large set of different mobile devices. Services like mobile push notification, device detection, charging, etc. should also be available. Also the hosting is optimized for mobile applications in which you have very strict low-latency and unreliable connectivity requirements.

Alternative 4: Beat Amazon AWS at Bootstrapping, Configuration Management, and other cloud operation automatization

If you are going to offer virtual servers, focus enormously on the bootstrapping and configuration management. Amazon and others have virtual images that allow a quick deployment of an existing configuration. However that is good if your application is stable and your software stack needs few modifications. Real-life applications and business solutions need a lot more flexibility. Setting up a database cluster, a webserver/proxy/memcache farm, a high-availability loadbalancer, an application server cluster, etc. are very manual tasks on most public clouds. True you can get an image with an apache, tomcat and mysql pre-configured, but you do not get a multi-node cluster image. To solve this you could use software like Chef or Puppet for provisioning and ControlTier or Capistrano for command & control. See my other blog post

Alternative 5: Be the Salesforce for Telecom & Mobile Applications

This is more PaaS then SaaS but being a Telco PaaS in which in a Salesforce.com style you can use Web 2.0 and drag-and-drop to create mobile and telecom applications. Instead of having to code, people can create application via visual designers.

Alternative 6: No.de/Heroku/etc. alternative for quick web & mobile front-ends combined with custom protocols and on-site systems

No.de is PaaS for applications written in Node.js a javascript language that allows for massively scalable applications to be quickly developed.

Heroku is a PaaS for Ruby applications.

These are language specific PaaS that are similar to Google App Engine (GAE).  Where GAE allows Java and Python, No.de has Javascript and Heroku has Ruby. Developers can very easily create applications. However GAE falls short writing front-end applications: Web GUI/Mobile HTML5 quickly. Also integration with non-HTTP protocols is not offered. Although the Internet lets you believe HTTP and FTP are the only protocols out there, there are literally thousands of binary, alternative standards and proprietary systems that large enterprises can not do without. Examples in the telecom industry are RTSP, SS7, etc.  If you can combine the speed of developing modern front-end together with the integration with legacy systems, binary protocols, on-site systems, etc. then you can have a large advantage when corporations want to move their back-office to the cloud.

Alternative 7: The Zoho/37 Signals for Telecom Applications

Zoho and 37 Signals are companies specialized in creating one-purpose mini applications for small and medium enterprises. Instead of a Siebel, Zoho will give you a basic CRM that works out of the box and has virtually no learning curve.

Zoho allows others to build applications on their infrastructure as well and resell them.

The same concept could be applied to telecom. Mini telecom applications like a PBX in the Cloud, SMS marketing, etc. are build on a common infrastructure. Externals can extend the application portfolio and resell them.

Alternative 8: Hosted PaaS

Instead of offering PaaS you offer a hosted PaaS infrastructure for enterprises. Each enterprise gets their own PaaS. Companies like Longjump and WSO2 are in this market. Be sure to add in some telecom assets…

The Long Tail Telco – An Alternative Cloud Strategy

February 11, 2011 2 comments

Most operators have a mobile portal in which end-users can buy games, applications, ringtones, etc. Several operators have a legacy of server hosting, email hosting, and other business services.  Some operators have a marketplace where small medium enterprises can buy SaaS. Others are thinking or building a private cloud and want to become an infrastructure as a service provider. Often to avoid legacy hosting to disappear.

There can be reasons why a small, medium or large enterprise wants to use the infrastructure from an operator compared to a public cloud: SLAs, quality of network service, security, etc. Price is very likely not going to be one of them. Neither will be innovation or flexibility because here the likes of Amazon, Google and Microsoft are almost impossible to beat.

So why is it that operators think that IaaS is their preferred strategy to enter the cloud? I have no idea but my opinion is that it is easier to start with SaaS and work down to PaaS then to start at IaaS and work upwards. IaaS will have hyper-competition and very small margins as a consequence…

An alternative telco cloud strategy

Operators often have a direct sales channel towards medium-sized enterprises. By offering a SaaS marketplace they could extend the amount of services they are providing towards these medium enterprises. After reaching a tipping point, smaller enterprises will likely follow via direct web-based purchases. However reselling SaaS can never be a long-term strategy.

SaaS should be an initial start of a new customer relationship. Operators should focus on selling complete solutions focused on a specific industry or problem domain. Examples:

* Healthcare – web, mobile, tablet, TV and SMS patient reminder & reservation system, health-care call-center as a service, farmacy locator,web-based medicine reservation system, etc. 
* Restaurant – web, mobile, tablet, TV and SMS table reservation system, online menu web hosting, group-based or community food purchasing service, special deals á la groupon.com, etc.
* Car dealers – web, mobile, tablet, TV and SMS maintenance reminder & reservation system, parts-locator call-center as a service, etc.

The operator should not focus on inventing these services but instead on creating the tools, the eco-system and the community for smaller IT shops and other to come up with scalable niche services.

To fully utilize a SaaS an SME needs help: training, configuration, customization, integration, etc. For this you need a services marketpace closely linked to your SaaS marketplace. As well as a long tail support solution.

The Long Tail Telco PaaS

To be really able to offer long tail services, operators need to have a long tail Telco Paas. A Telco PaaS is like a Google App Engine, combined with Google App Marketplace, combined with Twilio/OpenVBX, combined with charging on your invoice, combined with open standards like OpenID, oAuth,SIP, etc.

Not clear??? A small company knows best what another small company need. However they do not have the infrastructure to reach and help thousands of other small companies in the world that have the same problem. This is where the operator should help both with global communication and IT solutions. A small company should not be focusing on installing a CRM, call center, ERP, etc. if they want to help others configuring and customizing a health care reminder service. They should have specialists in the health care reminder service and should be able to purchase the rest from the Long Tail Telco’s marketplace. They should also be able to auction a request for legal assistance, escrow-service, translation, etc., basically an all-in deal. The operator should focus on business communication in the broad sense, not the telephone service sense…

Finding the Container for Long Tail Post-Sales Support

February 4, 2011 1 comment

There are several long tail sales channels that are currently showing results. Clear examples are Amazon, Netflix, Google, etc. However there is a key area that is currently not resolved: long tail post-sales support.

In the telecom world, operators are not launching long tail applications because they can not offer post-sales support. A lot of small innovative solutions are not meeting the public because the operator can not afford consumers or small businesses to call massively their call centers. Every call-center call costs €1 or more and training call center agents on thousands of niche applications is virtually impossible.

A director in a tier 1 operator told me the other day that what we are missing is the container for long tail post-sales support. His logic was that the second biggest invention after the Internet was the container and the pallet. They allowed goods to be shipped cheaply all over the world. The Internet accelerated the purchases but the container made it possible that China and others produced it and the rest of the world consumed it.

We need to find the container for long tail post-sales support. The simple solution that allows people to understand which services and solutions have a best-effort, basic or top-class support and to get their problems resolved in the shortest and easiest way.

What is the problem? An individual programmer can build a very successful application, launch it on a telecom cloud and get virtually overnight thousands of customers. This programmer would be totally overwhelmed with bug reports, feature requests, integration needs, customization needs, training needs,  etc. from thousands of consumers and small businesses. A business can not afford a critical service not to be available during hours or even minutes or seconds. A single programmer might be a guru in building an innovative application but might lack basic skills in supporting it.

The same would be true if we talk about niche solutions, open source solutions, general solutions with long tail plugins, telecom PaaS platforms,  etc.

So do I know what the container is? Not yet but I am actively reviewing different solutions. If you are interested in participating then drop me a line: maarten at telruptive dot com.

 

 

%d bloggers like this: