6 Comments

Summary:

If you build your company’s software on an external platform as a service, what happens when that platform disappears? PHPFog users are finding out. Here’s a cautionary tale.

paas-tombstone

As of Friday, PHPfog goes away as a supported Platform as a Service.  This is not really a surprise — in November, parent company AppFog alerted affected users that they would have to migrate to the broader, newer AppFog platform as of January 25. And, many have done so, after grumbling, quite happily, according to Lucas Carlson, CEO of Portland, Ore.-based AppFog.

The company started out as PHPfog, which GigaOM’s Derrick Harris characterized two years ago as a sort of Heroku for PHP developers, but changed focus to support multiple languages and multiple public clouds.

appfogThe developers using PHPFog probably already know it’s not  easy to migrate from one software version to another and when the software in question is actually the platform which runs your applications, things get really hairy. One AppFog user acknowledged that the company provided notice and guidance about migrating applications but said any such migration is fraught. “Infrastructure moves are incredibly difficult and risky and the upside is usually fairly slim,” he said via email.

The problem of a defunct PaaS may be rare — Coghead disappeared in 2009, although SAP ended up buying the intellectual property. But given that PaaSes act as platforms for real applications, customers need to go into deployment with their eyes wide open.

Gartner distinguished analyst Yefim Natiz, who studies this topic, recommends that PaaS customers negotiate terms to mitigate risk. “You should put something in your provisions that if the company is acquired or goes away, you can get some money back — even if a company goes bankrupt there are assets left over. The best thing is to get your code in escrow so if the PaaS goes away you can run it on premises if you need to,” he said.

And of course, all companies should always back up their underlying data all the time.

Carlson, who provided the tweetstream below to show how some customers “evolved” their thinking about the transition, said the benefits of moving to AppFog outweigh the headaches of the move itself.

“They get much better service, a choice of infrastructure, new languages, five new database services and can choose whatever version control system they want to manage their code instead of being forced into Git,” he said in an interview.

appfogtweets

  1. Sinclair Schuller Friday, January 25, 2013

    Barb, nice write up. PaaS portability is important for customers to evaluate. One strategy is that PaaS vendors can allow the customer to download the PaaS software layer to run on their own on any infrastructure (e.g. their own datacenter, public IaaS, etc.) This ensures that even if the service were to go down or disappear, the customer could at least get their app back up and running. That’s particularly important in the case where the customer may have API dependencies on the PaaS, making a transition not just a service concern, but also a code change concern.

    Share
  2. Michael Richardson Friday, January 25, 2013

    I’m a lost PHPFog customer, myself, having just done a migration (in the nick of time, as the service shut down an hour ago!) last night – back to a traditional (virtualized) Apache host.

    PHPfog itself represented a serious milestone in hosting, but I think a certain idealism proved to be unsustainable. They created a service that magnetized a common profile in the LAMP-stack development world: using Git; having no interest in or need for complex server management; using phpMyAdmin right away. They also had a dreamy live chat support system, it was affordable and scalable. But not everyone uses Git — and might have to unbuild an existing repository and learn Git. The population of non-PHP developers (or those with apps that include other back-end languages) is significant. And at a certain point, you can’t have your staff chatting with the long tail of issues all day.

    The pivot was a necessary one, but the remainder or “common denominator” has meant: not using Git, letting go of PHP-specific services like phpMyAdmin out of the box. Most critically, having the service level go back to a typical ticketing system.

    Scalability is the main advantage of using “cloud” systems, in that it’s inherently distributed and portable. But there are serious disadvantages. Being distributed also means there are more possible points of failure. AppFog discourages storing large amounts of files; you need to use something like Amazon’s S3; They don’t have a robust MySQL service; rather one would be better off using a 3rd party; They don’t host mail servers; you use Google and services like SendGrid. Now you’re relying on all those companies to stay online and in business. AppFog’s two MySQL partners are startups that may or may not survive the next couple of years.

    All hosting operations will eventually use hybrids of localized-virtualized and distributed (3rd party) cloud systems. The main differentiating factor will be service, and the degree to which you can help developers quickly work out specific issues and crises with a high level of expertise. I think this will be called “Service as a Service” — SaaS.

    Share
    1. thank you for this really thorough and thoughtful comment. I Meant to respond earlier. This thought of PaaSes evolving into SaaSes intrigues me. But doesn’t the problem of lockin remain?

      Share
  3. It is strange to me that cloud adoption in general is happening without the availability of a comprehensive loss and continuity insurance option as part of the service.

    Share
  4. This is a perfect example of the biggest disadvantage of using PaaS products – lockin. This is a problem even with IaaS such as AWS but depending on whether you’re just using provisioning APIs or their more proprietary products, it’s less of an issue. When your entire app is built around proprietary APIs and you’re not able to pull it out and run things yourself, you have a major risk.

    Perhaps this is the reason few (any?) serious apps use platforms like Heroku and Google App Engine – they’re great for small projects, prototyping and internal tools but I don’t think they’re the right place to build a business.

    Share
  5. i do think corproate adoption of PaaS is hindered by these concerns –thanks for the comment David

    Share

Comments have been disabled for this post