Review: Google Cloud flexes flexibility

If one company among all companies is synonymous with cloud-centered computing, it would be Google. From the very beginning, Google built a business located somewhere in the murky depths of the Internet, and its search engine continues to be one of the most formidable engineering marvels of the modern world. When was the last time there was an outage?

It’s only natural that anyone looking to build an information-based business that spans the Internet would turn to Google and leverage all of its experience. As pioneers, if Google needed a technology, Google engineers had to develop it themselves, then deploy it. Now everyone can profit from Google’s skills and build a Google-grade system with Google-grade reliability for pennies per hour or per click.

The simplest path to using the Google Cloud is to start up an instance from the Google Compute Engine. After a few clicks on a Web page or a few calls on an API, you get to be root in your own virtual machine running deep inside Google’s racks.

The basic options include 18 of the standard Linux distros (Ubuntu, Debian, Red Hat, CentOS, and so on) or -- and this may be a bit of a surprise -- two versions of Windows Server (2008 R2 or 2012 R2). Running Windows will add a bit more to the cost: an extra $14.60 per month for a standard, single-vCPU machine. The price on the OS goes up as you add cores.

Machines and containers

Google offers a wide range of hardware options and plenty of predefined configurations with as many as 32 virtual cores and as much as 208GB of RAM. If you don’t like the standard options, the UI includes a couple of sliders that let you choose more arbitrary amounts like 10GB or 34GB of RAM. However, the amount of RAM is connected to the number of cores, and you can’t choose more extreme combinations like one CPU and 180GB of RAM ... not that you might want it.

Useful options for developers are the micro and small instances that have shared CPUs and barely any RAM (0.6GB or 1.7GB). The prices are so low, they’re almost nonexistent. The micro is a mere 0.9 cent per hour, which works out to be $6.57 for a full month.

But the final price could be even lower. Google has started rewarding better customers by giving a “sustained use” discount to people who keep their machines running. The first week of the month is full price, but the next week gets a 20 percent discount. If you leave your machine running for the full month, the last two weeks are discounted 60 and 40 percent respectively. This could average out to be a 30 percent discount off the rack rates for anyone who leaves their machine running.

Note that you don’t need to leave the instance up continually to get the better price. Compute Engine bills by the minute and will adjust the rate accordingly. Google’s VMs boot fairly quickly, so it’s possible to start up instances for a half hour here or an hour there. Shorter times probably aren’t that feasible, and in any case Compute Engine has a minimum 10-minute charge for booting up a VM.

There are other ways to save money. Batch processing and nonessential work can be done with pre-emptible instances that may or may not be there for you, working or not working. When they are running, you can pay up to 70 percent less, a substantial discount. Google’s prices for pre-emptible instances are fixed, unlike Amazon’s rates for spot instances, which are based on an auction market for excess computer cycles. If you want predictability, pre-emptible instances are for you.

It’s worth noting that disk space is billed separately, in part because the disk behaves like it’s independent of the machine itself. You “attach” the persistent disk to your instance, and when the instance dies, the disk lives on. You can attach it to another machine later. If you really don’t need it, you can delete it. You can also juggle the disks by duplicating them with snapshots or even attaching them to multiple machines -- although only in read-only mode.

A newer corner of Google’s cloud is the Container Engine, an option that lets you spin up a cluster of VMs orchestrated by Google’s own Kubernetes, a tool for juggling Docker containers across a collection of machines. The machines, in this case, come from the Compute Engine.

Using the system requires understanding the extra features that Kubernetes brings to the Docker world. You can bundle containers together in pods, which can be useful if the containers are going to share the same resources like a local disk.

The price for all of this depends upon how many Compute Engine instances are running underneath. If you have fewer than five nodes, you pay only for the instances. If you have six nodes or more, it’s an additional 15 cents an hour for the convenience.

Platforms and APIs

The raw instances aren’t the only option. The App Engine is a completely different approach that was radical when it first appeared. Instead of building your server from the OS up, using all of the power of root, the App Engine is like a computing servant. You hand over a relatively thin piece of code and App Engine does the rest. Google handles the load balancers, the servers, the OS, and the databases, then bills you by the compute cycles it takes to answer an HTTP request.

It doesn’t take much to build out an app. The first version of App Engine accepted only Python code. Today you can also upload Java, PHP, or Google’s very own Go. Google’s templates and libraries do much of the work. The standard approach is to take an open source framework like Django (Python) or WordPress (PHP), then add a few extensions.

The tricky part is to rethink your database access. Many of the basic open source frameworks evolved assuming that they could write to a local disk. App Engine wants you to write to Google’s Cloud SQL or Cloud Storage or the NoSQL Datastore. This makes it simpler for App Engine to scale out your app to run on many machines at once because Google doesn’t want to worry about juggling a file system.

App Engine is probably best for apps that end up being relatively thin layers of code between the user and the database. (Snapchat is one of the most famous App Engine success stories.) The big fear is that some app will go off on a tangent -- say, chewing up cycles to compute pi to the millionth decimal. By forcing you to use the cloud storage services, Google retains more control. Google places tight “safety limits” on your code, although these are negotiable -- especially if you’re a big paying customer.

The preferred way to store your data with the Cloud Engine is in BigQuery, a set of append-only tables with an SQL-like interface. BigQuery is built for logs and logs of online data, the kind that people associate with the term "big data." Google is starting to enhance this with more sophisticated tools, like Datalab, which offers a layer of graphics and analysis on top of the BigQuery data storage layer. You store your information in BigQuery, then boot up an App Engine instance running the Datalab code. Datalab is designed to encourage a measure of collaboration between anyone who logs into it through notebooks.

Finally, one of the more interesting options for the Google Cloud user is access to Google infrastructure and specialized services through the many APIs. More than 100 different APIs will let you offload some of your work to Google.

It’s relatively simple, for instance, to let users of your application log in with their Google ID. The Translate API will convert text between any of several dozen languages. The Maps API will let you add location information to your website. There are also prediction APIs and even services aimed at genetic researchers in biology labs. It’s a long list.

It’s probably best to think of these APIs as completely independent of the Compute Engine. You don’t need to run your code locally in a Google data center to use the APIs, although your response time might be a bit faster. But this may only be the case when your server-side code needs to access the API. If your client-side code is pulling down a map, there’s no reason that hosting the server code at Google would result in better performance.

The choice is yours. Google has generally engineered every service to run independently from every other. If you want a Compute Engine machine but your own hardware for something more sensitive, Google is happy to help by renting you many of its powerful services through its APIs. All of the knowledge and expertise that makes the Google cloud run so smoothly is right at your fingertips.