PHPFog is Coming to an End – But Don’t Panic!
Have you heard PHPFog is coming to an end? No, well – it is. That’s right, in a recent announcement on their mailing list, the company has said that PHPFog will be no more by the end of January, 2013. But if you’re on their platform, don’t panic! The new, combined platform may be even better than what you’re accustomed to with them now.
Cloud is all the rage these days so it’s likely a lot of us have applications deployed with one or more cloud providers, whether they’re our pet projects, professional projects, or projects for our employers. And as AppFog is one of the larger vendors, with venture funding of around $9.8 million, this announcement should not go unnoticed because you might be affected either directly or indirectly.
To ensure that you’re not caught out by this transition, I’ve written this article to do two things:
- If you want to stay with them, I’ll help you ensure that you’re fully up to speed on the changes and what you need to do to migrate
- If you want to migrate away, I’ll help you get that process successfully under way
What is AppFog – How is it Different?
If you’re not familiar with either PHPFog or AppFog, here’s a quick introduction.
PHPFog was a high-quality Cloud PaaS (Platform as a Service) that, in a nutshell, allowed developers to focus on the core stuff that gets us excited – developing wicked, fast, highly-scaleable, high-performance applications.
Like the wealth of other cloud platforms, such as cloudControl, Joyent, Rackspace, and EngineYard, PHPFog alleviated the need for us to set up and manage the backend servers that power our applications, along with all the related services, such as databases, caching servers, reverse proxy servers, firewalls, and so on. We were able to design our application, with all the components on which it depends, such as MongoDB, MySQL, Memcache, NewRelic and Blitz, test it, profile and improve its performance, and then deploy it, knowing that these same components were available and professionally supported.
However, on November 13, the company announced that PHPFog was reaching end of life and was being replaced by AppFog. So if you’re going to stay with them, you’re going to need to know what you’re in for.
AppFog is pretty much the same as PHPFog (even referred to by the company as PHPFog 2.0), yet in some respects it’s more and in some it’s less. From a practical perspective, you’re not likely to see an effective difference; you can still create and deploy great applications there. But one of the best things about AppFog will be the increased scope of technologies that it offers.
Whereas PHPFog was just for PHP, AppFog is a multi-technology platform, providing support for PHP, Java, Scala, Python, Node, Ruby, and Erlang. Now I don’t know about you, but to me, this is exciting. Not just from a technology perspective, but from the larger overall developer community that naturally comes along with it.
It’s not just the new technologies that make AppFog better, there are also more addons. With it you get a range of options, including PostgreSQL, Redis, RabbitMQ, and Memcachier. In addition to these, the company has indicated that the list will continue to grow.
New Deployment Process
Whereas deployment on PHPFog was done only with Git, the new platform provides the three key version control tools that we use today: Git, Subversion (SVN), and Mercurial. To make it simple, they provide a custom tool,
af, which allows you to manage the deployment process irrespective of which version control system your project is controlled by. For a complete understanding of af, check out the online documentation.
What’s the Cut Off Date
The cut off date will be different depending on whether your plan is free or paid. If you’re on a free plan, then you’ve got until December 21st of this year. Otherwise, with a paid plan, you have until January 25th of next year. Depending on the complexity of your application, you’d best get started sooner rather than later.
Other Points to Note
In addition to these four areas, there’s a few other things that you should be aware of if you’re staying on board with them. For the sakes of simplicity, they are these:
- Databases are limited to 100Mb in size
- There is no persistent filesystem (though it’s said to be in the pipeline)
- You need to use
afto view the error logs
- There is no dedicated database support, only shared
But the key point is that it’s not just technology that’s important to us, right? As the announcement email said, the company is focusing on one platform, not two. If done right, this can only be a good thing for us as consumers and developers. Instead of splitting their efforts across multiple projects requiring multiple resources, whether human, financial, or otherwise, they’re focusing on one and consequently able to give us the best tools and platform on which to base our projects.
I Want to Make the Transition
Ok, you’ve decided to stay. The two things that you’re going to need to consider are database connection and migration. In the migration guide, two points are covered. For the sakes of time, I’ll include them here.
They’ve said that under AppFog there will be a new environment variable,
VCAP_SERVICES, which will store connection information. The sample that they’ve provided is as follows:
<?php $services_json = json_decode(getenv("VCAP_SERVICES"),true); $mysql_config = $services_json["mysql-5.1"]["credentials"]; $username = $mysql_config["username"]; $password = $mysql_config["password"]; $hostname = $mysql_config["hostname"]; $port = $mysql_config["port"]; $db = $mysql_config["name"]; $link = mysql_connect("$hostname:$port", $username, $password); $db_selected = mysql_select_db($db, $link);
They’ve then listed four steps for migrating your database over. These are:
- Export your existing database from PHP Fog using phpMyAdmin from your app console.
- Download and install the af gem and caldecott:
$ gem install af $ gem install caldecott
- Create a MySQL service to connect to:
$ af login $ af create-service
- Connect to your database service:
$ af import-service <service> <url>
service is the name of the service you want to import to.
url is the URL where your database lives.
I Want to Change Vendors
If you’re not keen to stay with them after hearing all of this, their official recommendation is to open a support ticket which should, hopefully, allow you to retrieve everything you need to change vendors. Obviously they want you to stay with them, but if the change isn’t for you, don’t feel any obligation to continue. Always do what you believe is best for you, your application, and your organization.
Is There Further Information?
There most certainly is. As well as the online documentation, the company has indicated that they’ll be publishing a series of blog posts and further documentation over the coming days and weeks on exactly what to do to migrate your application.
I take heart that in their official email, they mention “some of the edge-case differences between the platforms”. This would indicate that they are taking the process seriously and are genuine about making the process as smooth and painless for us as possible. So if you’re worried that there may be something particular you’re going to need help with, then it’s likely that this information will answer your questions.
Whether you’re a PHPFog customer and want to make the transition to AppFog or you feel AppFog is not the future for your application, you now have the key information and related links that you need to press ahead, with peace of mind.
I hope that this article has given you all that you need to make an informed decision and leaves no questions unanswered. However, if it has, then have a read of the official migration guide that the company put out or get in touch with their support team.
So which one are you? Are you going to stay or is it time for you to move on? Share your thoughts in the comments below.