Testing PHP Fog

By Jason Brooks  |  Posted 2011-07-01 Print this article Print


Testing PHP Fog

I evaluated PHP Fog as a potential home for our Labs blog, which we currently run on WordPress and host on an Amazon EC2 instance. We've been eyeing a shift from the infrastructure as a service of Amazon to a more PaaS-like option to offload some system administration chores, and PHP Fog appeared to fit the bill.

I started out on the free shared cloud by opting for the WordPress jumpstart template. I entered the user name and password for the admin WordPress user and the password for the root database user, and after a minute or two of waiting, I had a vanilla WordPress 3.0 site up and running.

From the admin console of this WordPress instance, I could update to the latest WordPress release (3.1.4) and begin adding plug-ins to the site. However, file changes made through an application aren't synced up with an application's Git repository-PHP Fog suggests using one file modification method or the other-so I turned instead to Git on my local workstation to pull down the site's files, and modify and add to them from there.

I was able to upload multiple SSH keys to my account, and specify whether particular keys had read/write or read-only access to the Git repositories associated with my cloud. There was no option, however, to specify which applications or which clouds a particular key pertained to.

Alongside application file and directory access through Git, PHP Fog enables users to access the MySQL database associated with their application through phpMyAdmin, the popular Web-based MySQL administration tool.
The service provides for application stats and diagnostic information through a partnership with SaaS (software-as-a-service)-based application performance management vendor New Relic. For each application I created on my cloud, I was provided with access to an application monitoring dashboard at New Relic, with breakdowns of the Web and database transactions associated with my application.

One area of the service that could stand improvement is PHP Fog's handling of application URLs. I could associate my application either with an address at one of my own domains or at *.phpfogapp.com-but not both. With other services, such as Google's App Engine, it's possible to access an application from both an App Engine address at appspot.com and from a custom domain.

In the case of our blog, I would have to specify labs.eweek.com as my desired address for the PHP Fog application, point the nameserver for that address at PHP Fog's servers, and then go without accessing the application (other than through Git or phpMyAdmin) while the DNS changes propagated. In contrast, with plain Amazon EC2 hosting, our site was accessible directly from its IP address during DNS propagation.

What's more, for the time being, SSL (Secure Sockets Layer) encryption is available only for *.phpfogapp.com addresses, not for custom addresses, although PHP Fog has said that it is working to resolve this issue.

Jason Brooks is editor in chief of eWEEK Labs. Follow Jason on Twitter at jasonbrooks, or reach him by email at jbrooks@eweek.com.


As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. JasonÔÇÖs coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at jbrooks@eweek.com.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel