Google puts flash storage, HTTP load balancing to work in Compute Engine

Google puts flash storage, HTTP load balancing to work in Compute Engine

Summary: Google launches flash storage and a new load balancing option on its Cloud Platform.

TOPICS: Storage, Cloud, Google

Google has launched solid state drive persistent disks and cross-region HTTP load balancing on its Google Cloud Platform.

Ahead of Google's I/O developer conference later this month, the company has announced two new features and prices that once again throw down the gauntlet to Amazon Web Services.

Applications running on Google's Cloud Platform that need higher performance can now tap its new SSD persistent disks, which cost $0.325 a month per GB. Each unit of storage supports up to 30 IOPS (input/output operations per second), so one terabyte would offer 30,000 IOPS at a cost of $325 per month.

While SSD disk costs much more than the $0.04 per GB each month for persistent standard hard disk (HDD) drives previously available, SSD delivers 100 times faster read rates and 20 times faster write rates.

Google has also distinguished its pricing from AWS elastic block storage. Tom Kershaw, Google Cloud Platform product management lead, said in a blogpost that Google's SSD persistent disk "includes IOPS in the base price with no extra charges or fees" where as rivals count and charge for extra IOPS.

As Hacker News user Aaron Friel notes, AWS charges for both the amount of storage and a separate charge for IOPS, while Microsoft charges per GB for Azure storage and offers 500 IOPS per disk with a maximum of 16 disks. As Friel's analysis shows, which provider is cheaper depends on requirements and uses. In some cases, Google is significantly cheaper, while for others Amazon and Microsoft come up trumps.

Google also announced a HTTP load balancing in limited preview, offering developers another way to deal with heavy traffic or optimising their application by using its different regions.

The new service provides globe load balancing for HTTP requests, allowing developers to serve traffic to users from a region near the user and balance loads across instances within that region. Developers can also create content-aware load balancing to route HTTP requests to instances that optimised for a type of load.

"HTTP load balancing can easily scale to support more than one million requests per second with no 'warm up'," Kershaw sais. "It also supports content-based routing and allows you to capture the benefits of Google’s global network infrastructure."

Since HTTP load balancing is a preview release, Google recommends not putting it in to production use. It's also worth noting that HTTP load balancing doesn't support the SSL protocol yet.

Read more on storage

Topics: Storage, Cloud, Google

Liam Tung

About Liam Tung

Liam Tung is an Australian business technology journalist living a few too many Swedish miles north of Stockholm for his liking. He gained a bachelors degree in economics and arts (cultural studies) at Sydney's Macquarie University, but hacked (without Norse or malicious code for that matter) his way into a career as an enterprise tech, security and telecommunications journalist with ZDNet Australia. These days Liam is a full time freelance technology journalist who writes for several publications.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


1 comment
Log in or register to join the discussion
  • Price will still drop

    The premium on these services in the article omit the existing trend of continued price drops. As an example: AWS announced it's 42nd price drop (Effective April 1, 2014) The reason why I posted this is that any integrator/developer who is not looking at building right off of the load balancer, versioning off of the load balancer is simply missing the new way of doing things. It is to say that you can roll out a newer version of a build and roll between the two instances. If it is elastic you can even run in parallel which is convenient for financial systems to verify that the two systems are closing ledger and meeting any auditing requirements. My big takeaway on the offering and availability is that you should be building this way today to leverage the ROI asap.