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…
In the past automatic deployment of software was something that a handfull of data center specialists dominated. However the cloud is changing this needs. If you need to deploy a battery of web servers, application servers, database clusters, nosql farm, etc. then you need to think of automatic software deployment from day one. Additionally you might have to deploy applications on Google App Engine, Azure, Amazon EC2/S3/etc., Rackspace, GoGrid, etc.
The three core areas to automate are:
- Cloud Provisioning
- Configuration Management and Automation
The main advantage of the Cloud is its capability to autoscale. If you get more requests during the day, you turn up more machines. If you get less during the night then you switch some off. You can even do autoscaling by the hour or less. Since you pay by the hour, your costs will match your revenues.
These installers can be handy when we are talking about a private cloud. However in case a public cloud is used, we are more likely to want to use the public APIs offered by public Cloud providers to provision machines. Unfortunately there are no standard APIs in public Cloud land yet. The best option is to use tools or APIs that can handle multiple clouds: e.g. Openstack, JClouds, Fog, Deltacloud, etc. Using one API to deploy on multiple clouds is key to avoid vendor lock-in.
The truth to be said, there is no clear winner in this space yet because most solutions have limitations and customization will be required. However expect very active development to happen in the coming months.
Configuration Management and Automation
The clear marketleader in this area is Puppet, which becomes even better when combined with mCollective. Puppet is a client/server configuration management solution that allows you to describe what you want to install and configure in a abstraction language. mCollective adds real-time notification. The whole solution is very powerful, although some learning will be required before you are up and running.
Additionally there are tools whose focus is not on the software installation but instead on the deployment of applications once the main software stack is installed. Examples are: ControlTier, Capistrano, Fabric, etc.
With multiple servers, solutions and applications spread over multiple cloud providers, you need to monitor. Monitor to see if they are available, but also monitor to see if you need to switch on extra capacity or if it is safe to switch off some capacity.
Creating an automatec stack of tools to provision, deploy and monitor is an initial investment that will pay itself back very quickly. Other systems could be added to the stack like inventory and asset tracking, software version control, build automation, etc. In general there is no easy solution that gives you everything and this is where open source communities should focus their attention: bringing it all together and simplifying so we do not need experts…
I have been looking into virtualization but what I find are mainly operation system based virtualizations. What I am looking for are application, integration and datastore virtualization solutions. Google’s App Engine and Oracle’s JRocket Virtual come closed to what I am looking for application virtualization. Why do you need an operating system if you could virtualize your application directly? It would save resources and would be more secure. My ideal solution allows developers to write applications and run them on a virtual application server. This virtual app server can scale applications horizontally over multiple machines. Each application is running in a sandbox hence badly written or unsecure applications will run out of resources and are not able to impact other applications. We would need a similar solution for integration solutions. Both would need out of the box support for multi-tenancy in which either a tenant gets a separate instance or multiple tenants can share one instance if supported by the software. Integration should be separated from the application logic and so should data storage.
Integration is key because the virtual applications could be running on a public cloud but would have to be able to interact with on-site systems. Enormous high-throughput, security, multi-tenancy and resistance to failure are key. One API can be linked to multiple back-office systems or different versions. Different versions of an API can be link to the same back-office system to prepare applications before a major back-office upgrade.
A distributed multi-tenant data store should hold all the end-user and application data. Ideally in a schema-less manner that avoids having to migrate data for data schema changes.
All these virtual elements should be managed by an automated scaling and highly distributed administration that can let applications grow or shrink based on demand, assure integration links are always up and get re-established if they fail, store data in a limitless way, etc. But there is more. The administration should allow to deploy different versions of the same application or integration and allow for step-wise migration to new versions and fast roll-backs.
Why do we need all this?
The first company that will have such elements at its disposal will have enormous competitive advantages in delivering innovative services quickly. They can launch new applications quickly and scale them to millions of users in hours. They can integrate diverse sources and make them universally available to be re-used by multiple applications. They can store data without having an army of DBAs for every application. They can try out new features and quickly scale them up or kill them. In short they can innovate on a daily basis.
The Google’s of this world understood years ago that a good architecture is a very powerful competitive weapon. There is a valid trend to offshore technical work. However technical work should be separated in extremely high-value and routine. Never off-shore high-value work. Also never assume that because the resources are expensive, it must be high-value. Defining and implementing this innovation architecture is extremely high-value. Writing applications on top of it is routine at least starting from number 5.