In this article, we will jump into the Google Cloud Platform (GCP) from the perspective that you’re already familiar with Amazon Web Services (AWS). We will be tackling how to build Serverless/cloud-native web applications on GCP and AWS. Along with a breakdown of related services and how they compare when held up next to each other.

• Google Cloud Platform
• Serverless Web Applications

Google Cloud Platform

The Google Cloud Platform or GCP is one of the major cloud providers that developers can leverage to build applications that are optimized, scalable, and secure. With GCP you get the powerful integrations that only Google can offer such as GSuite. Google also runs its own applications at the scale of hundreds of millions, meaning the services that GCP is releasing are battle tested and most of them were born out of Google products such as Youtube or Gmail.

GCP has services that cover the entire surface area of modern applications and have poured a lot of time and energy into making their services easy to understand and use.

At Serverless Guru, we use GCP to host our website, Serverlessguru.com, using the Firebase suite of services. Which made it extremely easy to set up local development and deployments by leveraging Firebase Hosting. We also use Cloud Build to create simple CI/CD pipelines for our website as well as client projects where the majority of application related services are on AWS.

Serverless Web Applications

Application development on GCP and AWS doesn’t actually look too much different. There is a combination of the same ingredients which makes it easy to transfer concepts between the two.

Static Website Hosting

We are big proponents of utilizing static website hosting over the notion of running a “web server”. Static web hosting can easily be done on both AWS and GCP. However, we found GCP was much easier to get up and running quickly while AWS has more functionality as the supporting services are more mature.

On GCP we would leverage a suite of services known as Firebase. Specifically, to achieve web hosting, we would use Firebase Hosting which is how we actually run the Serverless Guru website as we mentioned above. We enjoy using Firebase hosting because it’s simple to configure, does a ton of abstraction, and makes it easy to focus solely on the application code.

On AWS we would use AWS S3 to do static hosting. AWS S3 requires much more setup on our end as we have to manage the infrastructure deployment as well as turning a series of knobs to even get an HTTP version of our website up. Compared to Firebase Hosting which automatically comes with HTTPS.

NoSQL Databases

When it comes to choosing a database we would lean towards leveraging another fully managed service. There is no need to become Sysadmins or Database Admins when we want to simply put data into a box and pull data out of that box.

On GCP, we would lean towards Cloud Firestore 🔥. Firestore was born from the knowledge GCP gained from releasing the Realtime Database and Cloud Datastore. For all future applications on GCP, we would always go towards Firestore over the Realtime Database or Cloud Datastore due to GCP framing Firestore as the “next generation of Cloud Datastore”.

On AWS we would go with DynamoDB. There aren’t as many NoSQL options on AWS as there are on GCP, making the decision much more straight forward. DynamoDB is a mature NoSQL product offering that has been constantly updated and tweaked since it’s inception. For example, AWS recently released On Demand pricing for DynamoDB making it an even more attractive database.

The structure of Firestore and DynamoDB are worlds apart and should not be taken as if they were one of the same. Firestore leverages the same concepts and verbiage as MongoDB, another NoSQL database, such as the use of collections and documents. DynamoDB has a structure which swings more into a category of its own.

At Serverless Guru, we typically use DynamoDB for applications that were partly or wholly built on AWS. However, if we are building an application for GCP/Firebase we would opt instead to use Firestore. The decision mostly comes down to the additional service support/integrations to maximize our ability to develop effectively.

Cloud Functions

When we need to extend the functionality of our web application past the point of simply showing static content. We need to introduce the concept of cloud functions. Cloud functions allow you to replace your traditional backend server with a lightweight alternative which is usually less than a few hundred lines of code and does a very specific task.

For example, we could have a cloud function which has a single purpose job of sending emails. You can provide the function an email and it sends the email. Simple and we didn’t need to spin up a container or virtual machine to handle this.

Cloud functions fall under the umbrella of FaaS (Functions as a Service) and are a core component of Serverless Event Driven Architecture. Modern web applications which follow this paradigm are comprised of tens to hundreds of these cloud functions which are responding to events across our application. Events could be a user uploading a document or image to blob storage, a user registering for an account, and a record in our database being created or updated.

On GCP we would be using, Cloud Functions. Cloud Functions on GCP are less mature than AWS. Meaning you’re going to find gaps in automation, deployment, language support, available triggers to connect too, and so on.

On AWS we would be using, Lambda. Lambda is the gold standard at the moment for cloud functions. AWS has been dominating the space since the inception of Lambda in 2014. Lambda is mature and a solid choice whenever you’re thinking about using Serverless Event Driven Architecture.

At Serverless Guru, we always go with Lambda over Cloud Functions on GCP because the functionality and integrations on AWS are just not present at the moment on GCP. Based on this fact, the web applications we build are mostly on AWS and then we will leverage single services on GCP where it makes sense.

APIs

Building REST APIs for our frontend to consume is a normal part of making a web application dynamic. We will combine the API with a cloud function to handle

On GCP we would be using, Cloud Functions with an HTTP trigger. Basically, we are using the Cloud Function to handle any backend operations such as storing a document in blob storage or hitting our database.

On AWS we would be using, API Gateway and Lambda. API Gateway allows developers to easily create REST APIs and it’s a core component of practically all web applications that are built on AWS. Lambda acts similar to Cloud Functions on GCP and handles any backend operations.

Blob Storage

We normally use blob storage to store documents, images, videos, binaries, and so on which our web applications collect from users and provide to users. Both GCP and AWS have options to handle this type of simple storage and the differences are minimal.

On GCP the service is called, Cloud Storage.

On AWS the service is called, S3.

Both providers allow you to hook into events that take place on your blob storage such as create, update, and delete. You can configure an event to be fired to a cloud function immediately and then do additional post-processing.

For example, a user uploads a profile image. You store that image in S3 or Cloud Storage. An event is fired off, triggering your cloud function and the user's profile image is resized. Once the cloud function finishes resizing the image, the image is stored under a separate directory called, thumbnail.

CI/CD Pipelines

When it comes to deploying web applications we want to utilize the power of a CI/CD (Continous Integration/Continous Delivery) pipeline. If you’re unfamiliar with CI/CD pipelines, check out our introduction to CI/CD article.

A CI/CD can be kicked off by a trigger on a specific git branch in your GitHub or BitBucket repository which will automatically run a series of scripts that do common tasks:

• Clone source code
• Install dependencies
• Run test suite
• Build distribution files
• Deploy to live environment

On GCP we would be using, Cloud Build. Cloud Build is a simple CI/CD solution which has a ton of built-in features that makes it easy to create complex pipelines. If you want to dive deeper into Cloud Build, check out our Serverless CI/CD — Cloud Build article.

On AWS we would be using, Code Pipeline. Code Pipeline wraps over Code Build and Code Deploy. Similar to Cloud Build we can handle all the different aspects of a normal CI/CD as we listed out above. The main difference between Code Pipeline and Cloud Build would be in the level of involvement you need.

At Serverless Guru, we lean towards Cloud Build over Code Pipeline because of the simplicity we’ve found in creating new CI/CD triggers and the ability to leverage Cloud Builds preconfigured docker containers to get all the functionality of a hand-rolled container without any of the engineering effort.

Conclusion

There are some differences between GCP and AWS around how to build web applications. Yet, there are a lot of similarities. From my experience working as a cloud-native developer in entirely Serverless architectures over the past two years, I’ve been thrilled with the new services coming out of both AWS and GCP. We as developers are in the golden age and it’s only going to get better as Serverless matures. All of the services in this article if you hadn’t noticed are fully managed.

Meaning the barrier of entry to do all of the things mentioned above is at it’s the lowest point in history. Armed with that knowledge I wish everyone reading this article the best of luck on your Serverless journey and please don’t hesitate to reach out. 🏁