Google Cloud Services for the AWS Expert

Google Cloud services: most cloud platforms have similar concepts. They tend to abstract the concept of data centers, so we as cloud consumers only need to think about them in terms of a “zone.” If you’re already familiar with AWS, then most of the concepts will be the same on the Google Cloud services; they will just have different labels (for example, AWS has Regions and Availability Zones and Google Cloud has Regions and Zones). In this post, we’ll compare and contrast the products and services of Google Cloud services and Amazon Web Services.

Google Cloud Services

In looking at each platform’s services, we can see some general patterns. Both offer compute options: AWS has EC2 for its virtual machines, and Google Cloud has Compute Engine. Overall, they are quite similar. However, in my experience, the instances on Google Cloud services are faster. Also, Compute Engine instances are priced by the minute after the first 10 minutes. It also discounts for sustained use. Regarding the specific features of each, again, they align quite well. Both AWS and Google Cloud services offer snapshots, auto-scaling, predefined machine types, etc.

They both provide platform as a service (PaaS) options to make it easier to deploy web applications. AWS has Elastic Beanstalk, and Google has App Engine. Both give developers managed runtimes, as well as the option to deploy Docker containers. The intent with both is that you can upload your code, and the platform handles the rest. Having used both, I like the flexibility that Beanstalk provides for running OS level commands and installing third-party binaries as needed. This flexibility exists on App Engine only through the use of Docker containers with the Flexible App Engine environment. When it comes to cost, I’ve found App Engine to be less expensive. I’ve been running a small demo web app for a few months, for just a few cents, because it gets very little traffic. Overall, they’re both good PaaS options.


Another common service option is storage. AWS has S3 for blob storage, Glacier for cold storage, as well as EBS and EFS. Google has Cloud Storage and persistent disks. Google’s Cloud Storage provides different storage classes, allowing it to serve in the same role as both S3 and Glacier. The difference is that Cloud Storage has the same millisecond access times for all of the storage classes, including cold storage.

The persistent disks on Google Cloud are similar to Amazon’s EBS. However, Google Cloud doesn’t have anything like EFS, at least not that I’ve seen. Elastic File System (EFS) provides a highly scalable cloud-native file system that you can mount with instances and containers. In addition to being useful for Big Data, I suspect that the increased adoption of containers will make this an essential service.


If you’re going to use any cloud platform, you’ll likely end up needing a database. Both AWS and Google Cloud have similar options. AWS has RDS for relational databases, and Google Cloud has Cloud SQL. RDS may have the upper hand here — depending on your use case — because it offers multiple database engines, including MSQL, Postgres, Oracle, and MySQL. Instead, Cloud SQL is a Google hosted version of MySQL. Cloud SQL offers both first and second generations. The first had some limitations, such as a 500GB size limit. With the second generation, the size limit is now linked to machine type, and even the smallest machine type can go up to something like 3000GB. The second generation option is similar to using RDS Aurora.

Both platforms have a highly scalable NoSQL option. AWS has DynamoDB, and Google has Big Table and Cloud Datastore. If you’ve used DynamoDB, then you know that it’s a great option for many use cases, such as gaming, IoT, web applications, and more. Between Big Table and Datastore, you get the same basic coverage.


When it comes to monitoring, AWS has CloudWatch, which has been used by anyone who has used AWS for even a short period of time. It’s an essential part of AWS since we use it for things such as auto-scaling health checks.

For monitoring, Google Cloud recently bought Stackdriver and started integrating it into their platform. Stackdriver has a lot to offer: It has monitoring and logging tools; it allows you to create your own dashboard to visualize what’s important to you; it can monitor your OS up through your application tier; and, it has an installable client to monitor AWS. While Google works to get Stackdriver fully integrated with their platform, it may feel a bit disjointed at times. However, it’s too good of a service to let that keep you from using it.


These days there is a push toward “serverless” offerings, as a sort of compute as a service. This is an area where AWS is doing quite well and where Google is playing catch-up. Google has a serverless option in alpha called Cloud Functions, and it uses JavaScript and runs on the Node.js runtime. So far, in alpha, you can trigger a function based on Cloud Storage change events, as well as from message in a Cloud Pub/Subtopic. You can also invoke them with an HTTP request. It’s too early to really compare Cloud Functions to Lambda, so we’ll have to wait and see what Google comes up with.

Identity & Access Management

When it comes to identity and access management, AWS allows for some very granular policies to be created with its IAM. This is an area where Google is just now starting to catch up. Not long ago, we used the project-based roles of owner, editor, and viewer to set permissions; though now we also have curated roles. With curated roles, we can assign groups of common permissions, such as an instance admin, which allows a user to administer Compute Engine instances. While it is a work in progress, Google Cloud’s identity and access management are heading in the right direction.


Despite all of the similar services, there is a noticeable difference between the two platforms when it comes to their consoles. The Google Cloud console uses the concept of a project to create individual environments. For example, you may have a project for dev, test, and production for any given application. Because projects are isolated, you can enable services in your dev environment to try them out without impacting other projects.

Another noticeable difference is that the Google Cloud console feels a bit more spartan. However, I slightly prefer the user interface and user experience. 

Favorite Google Cloud features

Since I’m already shifting between objectivity and subjectivity, I’ll share some of the other things that I really like about Google Cloud.

Machine learning services. Google Cloud’s machine learning services are easy to interact with via a REST API as well as higher-level idiomatic abstractions. The Translate API is wonderful, as is the Vision API. If you’re looking for something that allows you to build your own models, Cloud Machine Learning is an option, albeit a beta option.

Big data services. Do I even need to mention Google’s big data services? Google has been solving big data issues for years, and this competency shows in their services. They have services for batch and stream processing, services to ingest massive amounts of data, services for highly scalable analytics, and DataLab to visualize data in a Jupyter notebook format.

Containers. I also really like Container Engine and Container Registry. Container Engine makes it easy to deploy Docker containers. And, it uses Kubernetes for container orchestration, which is great since there is a community of people who are already familiar with it, and who can help with any questions. Containers are gaining in popularity, and learning something like Kubernetes means I can deploy anywhere, including on AWS.

Cloud Shell. One of my favorite features is Cloud Shell, which is a web-based console with pre-loaded programming languages and developer tools, including the Cloud SDK. This makes it easy to open up a shell, pull some code down from a git repo, and test things out. You can even deploy apps. It has a web preview option so you can run a development server in the shell, something like Flask, Rails, or a .NET core web app, and view the results in the browser. And now, they also have a web-based code editor, which is awesome.

Service accounts. A service account allows your Compute Engine virtual machine instances, or App Engine instance, to run under a specific account. You can specify which services the account has access to, allowing any code running under that service account to interact with the different services that it is allowed to use.

And more. Other Google Cloud Platform features that I like include the load balancer, which doesn’t require pre-warming; the ability to set daily spending limits for things like App Engine; the ability to make deployments easier with Deployment Manager, among other cool features.

A few downsides to Google Cloud Services

However, it’s not all rainbows and unicorns. In my experience, there are are some downsides to the Google Cloud services. The community either isn’t there, or it just doesn’t share as much knowledge as the AWS community. Compared to AWS, that means forums and blog posts are few and far between. It can be especially difficult if you’re trying to develop an application on a new platform without that community for answers. As a result, you’re left to search through a lot of documentation.

This leads me to another downside: Documentation. When I first started developing for App Engine, I skimmed over the docs and thought: “This is great, some general info and even hello world apps!” However, once you quickly move past a hello world app and you’re ready to do more, the documentation just doesn’t cut it. It isn’t very well organized, and many of the code samples no longer work. Some of the services or APIs have been superseded, though that’s not always obvious, especially if you came to the docs from a link on a developer forum.

Try it anyway

In my opinion, neither of these are reasons not to try Google Cloud Platform. We’ll never have a community if people don’t test it out. Google Cloud services is a great platform, with a lot to offer, and it gets better all the time.

If you’re a developer or operations engineer and you want to learn more, sign up for a Google Cloud trial. Also, check out our Google Cloud course services to help you get up to speed quickly.

Cloud Academy