In a recent Gartner assessment of IaaS, only Amazon AWS and Microsoft Azure made it to the magic quadrant. Not surprisingly, among the other IaaS providers, Google was closest to edging its way in.
Like Microsoft Azure and AWS, Google Cloud offers both PaaS and IaaS, as well as a wide range of services. Google’s PaaS, App Engine, is at the heart of its cloud.
App Engine is designed around the idea of small, stateless applications that act as a bridge between Web or mobile endpoints and cloud-hosted data, whether that data is relational SQL data or key-value NoSQL data. You can build apps using Java, PHP, Python, or Go. Google uses Python internally for many projects, so it’s not surprising that App Engine’s Python support is the most mature.
There’s also the option of bringing familiar frameworks and applications to the Google Cloud Platform. With images of many popular software packages in the Cloud Launcher, you can get up and running quickly with a number of modern tools, including WordPress and Hadoop.
As for cost, you can use the online pricing calculator to get a sense of how much an application will cost to run, whether it’s 10 minutes of data analysis on 100 Compute Engine servers running Hadoop, or a dozen instances of a PHP App Engine Web application.
Getting started on App Engine using PHP
PHP is a relatively recent addition to the App Engine family of programming languages, and while it’s currently in beta, it provides a useful introduction to using App Engine for Web application development. You can start with a local instance of the App Engine environment using the App Engine PHP SDK, which enables you to build new apps and test code before uploading it to Google Cloud.
As with other Google dev tools, App Engine’s PHP support is handled by an app.yaml configuration file. The current build uses PHP 5.5, so your configuration needs to explicitly call this runtime version. You use the configuration to define how scripts are called, the URLs used to call your app, and where static files such as images, stylesheets, and templates are stored.
One handy App Engine feature is the ability to maintain multiple versions of an app and switch among them using the developer console. That way you can flip back to a known good version if a problem emerges or use App Engine as an endpoint for a continuous delivery build process. Versioning also lets you test new builds on the App Engine service before making them public.
It’s important to get app.yaml rules right, particularly when you’re handling static content. Defining handlers must be done hand-in-hand with application development and design, so you can define both the URL structure for an application and the regular expressions used to load and deliver static files.
You can also define whether one app can access static content used by another, simplifying resource sharing, and manage how secure SSL connections are used. Google provides tools to ensure users can fire up an application only when logged in, with the ability to limit access to specific folders at the user or user group level.
App Engine strengths and limitations
It’s worth considering the differences between a stateless cloud app and a PHP application running on a Web server. First and foremost, there’s no continuity between calls: Each time an app is run on App Engine, it’s the first (and only) time it will be run.
Other restrictions emerge as a result of App Engine’s closed sandbox model. You don’t have access to the file system and App Engine reserves the right to terminate processes that respond slowly to requests. Plus, you can’t use any PHP system calls. There are workarounds to most of these limitations, including using Google services -- for example, working with Google’s authentication tools.
One option is built in: Web apps need session management, and App Engine provides it through memcache integration. It’s a low-overhead approach that works well -- unless you’re expecting users to have long sessions. As App Engine regularly flushes its memcache store, you’re better off using Google Cloud Storage as a persistent alternative.
Much like running PHP on your own servers, App Engine’s PHP implementation supports PHP extensions -- though only if they’re written in PHP, as there’s no support for C or C++. Libraries and modules can be uploaded with your application code.
Integration with Google services eases some aspects of building a Web application. Instead of building your own authentication tools, you call out to the App Engine user API. If the user object is empty, you simply call a redirect to a Google sign-in page, which then returns an authenticated user object that can be used to display real names and control access to application resources.
Familiar territory
Existing PHP developers should find the App Engine PHP implementation easy to use; at heart, it’s the same old PHP they’ve always worked with. While there are idiosyncrasies resulting from the stateless nature of the App Engine platform, they can be dealt with using Google services or by building the appropriate configuration files.
Google provides a dashboard where you can monitor your application as well as manage uploads and launch current versions. Once running you’re able to see application performance, as well as managing the Google services your apps are using -- including exploring Google’s API library.
With support for familiar tooling like PHP, it’s well worth considering Google’s Cloud Platform. It might not be as comprehensive a platform as Azure or as widely available as AWS, but it offers many of the same features. The new preemptible Compute Engine images are an economical alternative to standard virtual machines, and their drawbacks are relatively easy to work around. You’re also able to bring existing Java and PHP development skills to the App Engine PaaS, so it's an interesting option for existing enterprise development teams that want to shift to the cloud.