From the local development environment to Google Cloud Platform, where to start? 🌱

From the local development environment to Google Cloud Platform, where to start? 🌱

My thought process of bring an application from a local to a cloud environment.

Hung Vu's photo
Hung Vu
Β·Feb 4, 2022Β·

4 min read

Subscribe to my newsletter and never miss my upcoming articles

Play this article

Table of contents

This is more about describing my personal development and debugging experience, less of a step-by-step tutorial on the topic. Correction to any of the errors is welcome!

Problem statement πŸ€

I have a working full-stack web application. It performs perfectly well in the local environment, but now, I want to make this available on the Internet, on Google Cloud Platform (GCP) to be exact. Where to start? For this example, my stack consists of React for the frontend, NestJS for the backend, and PostgreSQL for the database. React app is statically served.

What will be the criteria for my decision? πŸ€”

There are some goals I want to achieve.

  1. Considering I’m still new to the cloud field, I do not want to configure many things. Limited user management is preferred.
  2. I just want to make an application online for now. Security is prioritized, but there is no need for other aspects like scalability, redundancy, disaster recovery, performance.
  3. My stack requires a NodeJS server to run the NestJS backend codebase and statically serve the React frontend. Meaning both resources must be on one server, and have the same domain.

To run a web application on GCP, which cloud services are required? πŸ€”

We have 3 separate parts of the application here: frontend, backend, and database. That means we need something to handle these three. GCP has hundreds of services and terminologies. That will be confusing, or will it?

Okay, there are frontend and backend, so there must be something to host these two components, right? πŸ€”

As of February 2022, Google Cloud has 5 different options.

  1. Cloud Functions
  2. App Engine
  3. Cloud Run
  4. Kubernetes Engine
  5. Compute Engine

This is like an abstraction stack, the bottom is closer to the physical hardware level. In other words, Cloud Functions will require less configuration (fully managed by Google, serverless) compared to a Compute Engine setup (completely self-managed).

So there are five options. What do they do? Can I have a TLDR of their features? πŸ€”

  • Cloud Functions

    This is a function as a service option. As the name suggests, it is to run singular or multiple functions. Cloud Functions is fully managed by Google. There is no need to initialize an application, declare a listening port, etc. For example, you will only write something like

       exports.yourFunction = (req, res) => {
         res.status(200).send('Result');
       }
    
  • App Engine (GAE)

    This is a platform as a service option, so it resembles other cloud providers such as Heroku. GAE is fully managed by Google. Unlike Cloud Functions, this is where you need to have a fully prepared codebase beforehand. A typical choice when thinking about deploying your application to the cloud.

  • Cloud Run

    This is a container as a service option. Fully managed by Google, scalable to thousands of instances, and pay per CPU and memory usage. That said, you’re responsible for maintaining the containers.

  • Kubernetes Engine (GKE)

    Well, the name says it all, this is a fully-managed Kubernetes service from Google. Kubernetes is essentially used to manage containers on large scales. Cloud Run containers can be used with (GKE). This will require resources and skills to orchestrate the containers, not really set and forget.

  • Compute Engine (GCE)

    The most barebone service, a virtual machine on the cloud. Essentially an empty computer and you need to configure everything from Operating Systems to Network, Storage usage, etc.

Google compute options stack

For a more detailed discussion, these will be great resources

Okay, what will be suitable for my use case then? πŸ€”

Between the five options, Cloud Functions and App Engine are on the side of fully managed by Google, while the other three are more of a hybrid to self-managed options. Only App Engine can be used with my existing codebase, so it will be my choice.

App Engine will be for both frontend and backend. Then, what is for PostgreSQL database? πŸ€”

PostgreSQL is relational, and Google currently has 3 options for this.

  1. Cloud Spanner
  2. Cloud SQL
  3. Bare Metal

Out of the three, Cloud Spanner is fully managed and geared toward enterprises due to its massive scalability, and Bare Metal requires manual configurations (seems like it only supports the Enterprise Oracle database too, correct me if I’m wrong). There can be more options if we consider Compute Engine or Container solutions, but we will skip these for reasons as stated.

Only Cloud SQL is fully managed and suitable for small, personal use, so that will be my choice.

Google Cloud relational database options

Source: Your Google Cloud database options explained.

Wrap up πŸ€

Great, so all three components are covered, now we only need to somehow push the code there then? Not at all, figuring out what to use is one thing, how to use them is another matter. It appears we will need even more cloud services to have a proper and secure deployment.

The chosen services above are fully-managed, but they are only relative to other services in the same category. The upcoming posts will discuss other services necessary for a web application on GCP and matters to consider in a deployment pipeline.

Did you find this article valuable?

Support Hung Vu by becoming a sponsor. Any amount is appreciated!

Learn more about Hashnode Sponsors
Β 
Share this