PHP Fog is a platform-as-a-service offering that, as its name suggests, targets PHP-based applications. The PHP Fog service, alongside a handful of other new services, fills what has been a gap in the PaaS market, as the best-known PaaS offerings target other languages, chiefly Java, Ruby and Python.
The service, which became publicly available in May, layers caching, load balancing, database scaling and code version control features atop the Amazon Web Services foundation that the service taps for its underlying infrastructure.
The service provides for elasticity by enabling users to spin up multiple Amazon EC2 (Elastic Compute Cloud) instances to serve customer PHP applications from behind a load balancer. This scaling, however, does not occur automatically-users must scale the number of active servers up or down manually, through the PHP Fog Web console.
Each subscriber cloud gets its own set of EC2 instances, with MySQL database service provided from scalable, multitenant MySQL instances. For those who’d prefer dedicated MySQL instances, PHP Fog supports the use of separate Amazon Relational Database Service instances.
Developers interact with PHP Fog using the distributed version control system Git. During my tests, I created and uploaded an ssh key for use with the service. I used the key to authenticate with PHP Fog for pulling and pushing PHP code with Git.
The service includes a handful of “jumpstart” templates for getting up and running with popular applications and frameworks. These templates enable developers to get up and running quickly with WordPress, SugarCRM, Mediawiki, Joomla and Drupal, as well as with CakePHP, Zend Framework and a few other PHP-based frameworks.
PHP Fog’s first service tier, called the silver cloud, is based on micro-sized EC2 server instances, can be used to host up to 10 separate applications and is priced at $29 per server per month. Pricing is prorated per day, so a customer can opt to scale up or down as needed, and pay accordingly.
PHP Fog offers two additional tiers: gold and platinum. The gold tier is based on small-sized EC2 instances, supports 30 applications at a time and is priced at $79 per server per month. The platinum level is based on large-sized EC2 instances, supports 125 applications and is priced at $249 per server per month.
There’s also a free, shared cloud option, which supports one application, offers no additional server scaling and must be upgraded to a paid tier after six months. Still, the free tier is worth checking out for those interested in trying out the service.
Testing PHP Fog
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.