Archive

Posts Tagged ‘google app engine’

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…

Puppets on the wire – Automatic Cloud Operations

January 29, 2011 2 comments

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, chefSmartFrog, 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…

Creating Telecom Network Apps the Cloud Way: Telephone 2.0!

January 21, 2011 Leave a comment

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…

Virtual Telecom Applications and an innovation architecture

December 22, 2010 Leave a comment

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.

Marketing’s and IT’s loss of power

November 4, 2010 Leave a comment

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.

%d bloggers like this: