Coghead post-mortem

March 4, 2009 in CloudViews, Interoperability by hugo.mag | 3 comments

The recent close down of Coghead shows us several problems that cloud players will face, because situations like this will create distrust between current and potential users of the cloud.

This close down is more serious than at it seems at first because Coghead was not just a cloud player that sold its services to end users. Being a PaaS player it also served as a technology base for others partner (developers, ISVs, etc.). Now all their partners will have to move to other platforms that may look the same at first but surely will have their differences.

These PaaS cloud players have all the data, the application building blocks (users configurations, forms builder, etc) and the users application on their side, so cloud users must ask themselves not just what happens to their data if the company closes but also what happens to all the application building blocks and the application itself.

The best way to answer to these questions, for me, is to create at least one of the following functionalities:

  1. Easy migration to other PaaS vendors.
  2. Application backup to desktop application (in Access, OpenOffice Base, FileMaker or others).
  3. Have a local version of the application, so users can use the application no just if the server is down but also if the company goes out of business (using Google Gear for instance). It would be great also (I’m dreaming here) if these local backups allowed users not just to communicate to PaaS servers but also to communicate between local backups (something similar to p2p).

With this potential users (and partners) will be less afraid to move/create their applications in the cloud.

One of the good things we saw after the announcement was that several PaaS players developed (in record time I might add) special offers to former Coghead customers.

Check bellow some opinions for possible reasons for CogHead to have failed:

Share/Save

Tags: , , , , , ,

  1. pcalcada’s avatar

    pcalcada on March 5, 2009 at 10:14 am

    Good catch Hugo, this is exactly why I think that the work done by the UCI working group is fundamental. Without interfaces like the one they are promoting, we are in danger of lock-in inside a Cloud provider..

  2. Eric Novikoff’s avatar

    Eric Novikoff on March 15, 2009 at 4:12 pm

    Lock-in is a problem with all three types of Cloud Computing (Platform-as-a-Service, Software-as-a-Service, and Infrastructure-as-a-Service) however, the problems are different at each level.

    I think Platform-as-a-Service faces the biggest challenges since any platform that offers a service not available by installing open-source software onto a server essentially has no easily migratable alternative, as shown by Coghead. If the service is delivered as a proprietary API or actionable metadata, then moving your code or metadata elsewhere doesn’t enable you to use it. There are few standards in this area, precisely because it is at the forefront of innovation.

    Software-as-a-Service doesn’t present as many problems, since user data and metadata are already exchangeable through XML or even the dreaded CSV, but as I have seen trying to use my NetSuite data in another application, even very simple business data and metadata requires that the receiving system be customized to understand it.

    Infrastructure-as-a-Service presents the least lock-in problems, since the services have to be more or less compatible due to the requirements of the application software and the standards imposed by the underlying hardware. However, even here there can be some issues around differences in services the IaaS vendors offer. For example my company offers automatically scaling cloud services, which are not offered elsewhere and would require additional development effort to realize with another vendor. And we also offer fully hands-off administration of customers’ clouds, which they would have to hire staff for if they went elsewhere.

    These differences between providers are actually seen as advantages by customers, so they will continue to pose lock-in problems. It is the responsibility of the vendors to provide a migration path out, but few seem interested in it at the moment.

    -Eric Novikoff
    ENKI
    http://www.enkiconsulting.net

  3. hugo.mag’s avatar

    hugo.mag on March 17, 2009 at 12:29 pm

    Hello Eric,
    Thanks for your comment.

    I agree with your analysis that the migration path to other platforms is very difficult in the Platform-as-a-Service (PaaS) area, but at this time we already see some common functionalities between the different players and these common functionalities can be used as a basis to improve migration, by allowing not just data but also business rules to be moved from one PaaS to another.

    Migration to other tools is a know problem that all software areas have, from simple documents migration (from Microsoft Word to OpenOffice for example) to traditional software packages (for instance, when you want to change from one ERP to another you normally pay a consulting firm to migrate the data).
    For me a good example how to mitigate migration issues can be seen in the social platforms area. The Open Social effort in this area allowed users to copy data from one platform to another.

    I think that if a OpenSocial like effort appears in the PaaS area could surely mitigate migration issues with the added advantage of avoiding lock-in problems.

    In relation to the migration path out, my opinion is that a company that offers services in the cloud (regardless of its type – PaaS, SaaS, IaaS) should create migration policies that clearly show its users how and when they can export their data (and their building blocks if possible), the same way these companies state their privacy policies.