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.

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…

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:

1. Cloud Provisioning
2. Configuration Management and Automation
3. Monitoring

Cloud Provisioning

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.

There are many tools available to provision a Linux machine: Cobbler, Kickstart, OpenQRM (includes Windows), Spacewalk, Viper, xCat, Fully Automated Installation (FAI), etc.

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.

Other solutions in this space are: AutomateIT, bcfg2, cfengine, chef,  SmartFrog, etc.

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.

Monitoring

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.

The main solutions in this domain are: Nagios, Zenoss, OpenNMS, Zabbix, etc.

Other thoughts

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…

Ask a Telecom architect how you create a telecom network application, often dubbed as value-added services. He or she will focus on SIP/SS7 standards, service delivery platforms, etc.

The future of cloud-based telecom network apps, let’s call them tapps, is going a totally different direction. For the former telecom architect they probably like open source solutions like Mobicents that allows you to create SIP-based applications on Java. The Asterisks and other types of VoIP application servers are other alternatives.

However for a new generation of Web-based programmers this is all too complex. These are the programmers that like Javascript, Ajax, JSON,  PHP, Ruby, etc.

The majority of them will be fine with whatever Twilio or Tropo offer via easy to use REST APIs or embedded in their favorite scripting language. Which cloud-based application needs more than calling, SMS, answering the phone, getting feedback from the user, telling the use what to do, putting multiple users in a conference, transcribing what the user does, forwarding a call, etc.? 95% of the functionality is covered with a handful of REST APIs.

For business developers that are more used to Java, they can also use Java APIs to access for instance Twilio. To be able to cheaply launch an application and scale it afterwards they could deploy it on Google App Engine. A new alternative has just come around from Amazon: Elastic Beanstalk. A developer can write their app and deploy it on Beanstalk. They no longer have to worry about monitoring, scaling, opening firewalls, etc.

Other alternatives are to extend Cloud-ready telecom applications via plug-ins. An example here could be Twilio’s OpenVBX in which you can easily add new plug-ins.

The conclusion is that 2011 will be the year in which Web 2.0 and the Cloud meet the Telephone 2.0. However the Telephone 2.0 will unlikely pass through Bluevia and other operator initiatives given the fact that they are running about two years late and are very scattered, slow-moving initiatives.

Operators should embrace the new reality and try to help these new applications find new users. The Appstore brought a new eco-system to life. Millions of small and medium-sized Telephone 2.0 applications are waiting to be discovered by Billions of users. Remember that not everybody can pay an expensive mobile with an expensive data plan. However there are billions that can pay for cheap call and SMS-based applications. We need to help the billions find those tapps that are useful to them…

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.

In Telco 1.0, “marketing” decides what customers want and “IT/Network operations” will take 12 months to roll out the new service.

In Telco 2.0, the marketing department no longer decides what customers want and IT/Network operations have 3 months to roll out hundreds of new services.

Impossible?  What is Telco 2.0?

Telco 2.0 is the age where Internet technologies and business ideas meet the telecom world. What are these new ideas?

1. The customer is always right

No group of marketing experts is better able to predict what customers want then the customers themselves. In the dotcom world, customers are in control. They get an avelanche of services and options and via other people’s rating, comments and collective intelligence are able to decide what best suits them. Instead of launching one new release every 6 months, dotcoms launch new incremental features on an hourly, daily or weekly basis. Often several alternatives for the customer to pick from. It is the customer that decides what is right for them and what can be killed quickly due to lack of interest.

2. Give the customer control

If the customer knows what they want then they should be able to get it and if it is not available build it themselves. The explosion of Appstore apps shows that different customers like different things. In the next 12 months we will see VAS stores and build your own VAS designers allowing users to build or configure their own value-added services.

3. Allow the customer to make money

Whoever builds a great VAS should also see an abundant reward for it. High revenue shares for innovative thinkers are becoming the trend. Consumers selling solutions to consumers is no longer an exception.

4. Be the enabler instead of the break

Trying to stop innovation is useless. The Skype’s, Google Voice’s, Twilio´s, Tropo´s, Ribbit’s, etc. are unstoppable. Join the enemy and enable people to use your assets. Otherwise they will find ways around your assets, sooner than later. Think about what happened to location-based services…

5. Think Global and Volume

Local solutions are likely to be copied by others. This is a winner takes it all market. Think global. If you are not global, find a global partner and non-competing other operators and join hands. The money is in the volume. With 1M VAS people are likely to communicate more than before.

6. Analog dollars for digital pennies

The “Free economy” is changing more than one existing business model. Don’t think that because in the circuit world you can charge 15 cents/message that in the IP world you can charge the same. The music labels have found out that if you keep on charging a high price, piracy will rule. Does it mean that everything has to be free or losses are guaranteed? No, also not. However history has shown that technology (r)evolutions can destruct a business model without replacing it with an equal lucrative one:  think stamps and emails. The new economic rules dictate that scale and long tail attrack money. Google changed the ad industry from high priced TV ads to low priced adwords. However since they fully automated the process, the scale is enormous and so are the gains. So to be successful in the new telco 2.0 world, you need to offer thousands of services and make money with volume not with individual services. Who better can dominate a world for nano payment then the world leader of micro payments a.k.a. billing and charging.

The new role of marketing

Marketing will no longer be about evaluating which services customers might like and at what price.

Instead the focus will be on finding the right enablers for customers to build and configure the services they want. Afterwards these services can be offered on an open marketplace for others to buy and sell them.

Listen to what customers say on social networks.

Use number crunching on large volumes of data to understand hidden trends.

The new role of IT and operations

A telecom architecture is one of the most complex architectures to explain to non-telecom experts. A new generation of dotcoms are coming up with alternative architectures that separate execution from data and application logic. If you don´t know Google App Engine, take a look how applications are deployed onto a “virtual” application server and data is stored in a “virtual” database. Exactly this concept is what is needed for the next generation of telco services. You deploy telco apps on to a “virtual” service delivery framework, with access to telco assets via APIs and to unified subscriber data in a “virtual” datastore. IT should be the enabler of launching services and not the one that focus on building the services.

Any operator that has not started a project on Cloud Computing is late. The typical data center at an operator is filled with servers that are under utilized e.g. application servers and database servers are running at 30% of memory, disk and CPU. Just by doing step one of getting to Cloud Computing: virtualization, operators are able to save substantially in the cost of hardware, electricity, maintenance, etc. Virtualization means decoupling software from hardware. This allows to run multiple operating systems on one server.

However this would only be focusing on the tip of the iceberg. Cloud Computing is so much more…

Private Clouds

Automatic Scaling

Let´s first focus on the internal systems of an operator. After solutions have been virtualized, then you are able to scale them to more or less servers. The first step is to automate this process. If you have an application server cluster, do you need 8 nodes all the time? You probably only need them the week before Christmas or during some other peak period. So the ideal is to be able to measure the load and to automate the deployment of more or less cluster nodes based on load. The same can be done with the database. During the night you have 2 nodes. In the morning 3. During the day 4. During peak moments 8. In the evening 3 again. You could save massive amounts of money if application servers and databases can be scaled in this way. You ideally also are able to pay licenses based on what you really use and not on your maximum number of nodes during a yearly peak.

Redesigning Applications and Data

Both Amazon and Google found out that if they redesign their applications then they can get even more gains than pure virtualization. Amazon´s S3 service is a clear example. However internally they started with services like Dynamo on which S3 is build. The first step is to build general data stores. Multiple applications should be using a common data store instead of needing a separate database cluster each.

Unlike popular believe in the IT world, the dotcoms are not filling their data centers with Oracle RAC clusters. The dotcoms are designing special purpose data stores. The data volumes any market-leading dotcom has to deal with are so massive that a SQL database can not keep up. SQL databases are very good at running efficient queries on structural data or making sure transactions are consistent. However they fail when data is unstructured, write operations are massive or data volumes grow with terabytes every data.

Relational Data

So for all low-volume applications that need transactional data and read more than they write, you could still use a unified Oracle RAC cluster to serve multiple applications. An alternative approach are the data stores that have been build by Amazon (Relational Database Service or SimpleDB) or Google´s App Engine (Datastore with JDO).

What other alternatives are there?

Read Mostly Data

Data that needs to be read a lot and is not updated frequently can get an enormous performance and scalability boost by using an in-memory data store. The dotcom standard is memcached. Facebook (800 servers and 28TB) and Twitter are addicted to memcached.

Documents, Images & Videos

Binary and media files are best stored outside of a database. In small numbers they are often stored on a file system. However they occupy a lot of disk as well as network bandwidth when moved around. The ideal is a document store with a content-delivery network or CDN as a front-end. Amazon´s S3 and CloudFront are examples. Storing them in a compressed format, e.g. LZO can save valuable space. Also transcoding into different formats, e.g. thumbnails or preview can help save network bandwidth.

Unstructed Realtime Data

Data that is unstructured and needs to be stored and accessed in real-time in high volumes are best stored in special purpose data stores. You can write a book about the latest NoSQL solutions. Write an email to maarten at telruptive dot com if you are interested.

Analytics Data

Twitter has described most extensively how they use all the unstructured data they get from their logs and other sources. They use technology from Facebook to stream it into a high-available file-system from Yahoo. There they run massive parallel map-reduce operations to get to know a lot more about what users are doing and who is influencing who, etc.

Social Graph

The social graph is about who knows who and what kind of relationship you have. This data is best stored in graph data stores.

Collective Intelligence

Again a chapter by itself but dotcoms are also heavy users of collective intelligence which often means dedicate systems.

Accessing Data

Instead of stove pipes with data, the dotcoms are making data accessible to all their applications. Either via search interfaces, web technology to access data (e.g. REST and JSON) or efficient binary interfaces (Thrift and Protocol Buffers).

Messaging and Notification

Amazon is having a simple queue service and a simple notification service to make sure applications communicate in a uniform matter.

Applications

If applications have access to all the above services then the architecture of an application is simplified enormously. Most of the famous dotcoms don´t use middleware. They prefer the SOA principle. However unlike the IT SOA solutions, a dotcom would take an application and make it into a chain of reusable services. Let´s take an IVR application as an example. There would be a service to do voice recognition. Another one for voice transcription. Another one for text-to-speech. A transcoding service to transcode between different media formats (e.g. high-quality voice and low-phone-quality voice). And so on. Each service has independent load-balancing and can be scaled separately. Services can be re-used between applications. An application is very short because it just need to define which services need to work together and how.

Application Deployment

The dotcoms deploy new features on a daily and even hourly basis. This means that all application deployment is fully automated. When a new feature is deployed it does not necessarily overwrite an existing feature. It is possible that a new functionality has been solved in 5 different approaches. Dotcoms would split the total user base and let small parts of users try out the different approaches. Depending on the user´s feedback they would take the preferred approach and slowly scale up from 1% to 100%. If they detect that the feature has a performance problem or a bug then they would be able to roll-back or decrease the load, fix it and deploy gradually again.

The Network, OSS and BSS

There is a substantial effort needed to redesign a network to be cloud-aware. Some components need latencies lower than 10 milli-seconds (e.g. antennas), hence most of this logic will have to be processed locally. However all systems that can live with 100 milli-seconds latencies benefit from a cloud make-over.

Especially in the area of OSS and BSS there is room for optimizing applications and making them cloud-aware. Global services like a network inventory service, a user profile service, a device profile service, etc. would mean simpler applications and less data duplication.

Opening the Cloud

So the network and IT infrastructure is being redesigned to allow for faster innovation and lower costs. However Cloud Computing can also be used to increment revenues.

Being a Cloud Infrastructure Provider

Many IT consultancies and software/hardware vendors will tell an operator that they could be a Cloud infrastructure provider. On slides this really looks nice. However unless an operator is not using the cloud computing principles for their own systems as described in the first part, they are lacking substantial knowledge about how to manage such an infrastructure. Without this knowledge it would be hard to have a very optimized solution and as such be price competitive with the existing players.

Being a Cloud Platform Provider

Although closer to the operator´s core competencies, being a cloud platform provider would still be for those operators that are Cloud experts. A Cloud platform provider would allow others to use the infrastructure services to create applications on top. The complexity lies in the fact that malicious users try to break the platform which could have a very negative effect on the infrastructure if not handled correctly.

Being a Cloud Service Provider

This is the default option most operators should explore first before moving into the other areas. Being a service provider also has a roadmap:

Reselling SaaS

The easiest step is to be the storefront and to resell IT applications from others, e.g. cloud backup storage, security solutions, etc.

Offering Telco SaaS

The next step would be to offer specific telecom applications. Applications that are build for the operator or even better applications that can be build by others based on the operator´s assets. An example would be a PBX in the Cloud.

Open Market for SaaS

Building all telecom applications yourself is hard. Attracting others to do it for you is easier. However just putting a “Net App Store” and an SDK on the web will not get you to dominate the market. Only an open market with a large eco-system of companies and developers can generate large quantities of “Net Apps”. If you are thinking about building an open market, why don´t we talk first. Send an email to maarten at telruptive dot com.