Building a fully Serverless app on Google Cloud

Back in the days of yonder (circa the 90s), we had to buy servers to run our company websites. Then Amazon came along with their quirky AWS idea and told us that we didn't need to buy anything anymore. We could just spin up servers virtually in their data centers on demand. It was incredible. We said, take our money!

The rub, of course, was that you still had to know how to setup the server. All of that Linux kungfu was still left to the developers. So we fumbled along, trying to figure out what the difference between Ubuntu and CentOs really is. We got through it and setup our servers, but sometimes (a lot of the times) they had big security holes because lets be real: We didn't really know what we were doing with all those Linux commands we found on StackOverflow.

Then AWS said forget the servers, just write functions. Lambdas and serverless were born. The idea is incredible: Rather than worrying about all that devops-y stuff of firewalls and NGINX and ports, just write your functions that actually respond to a REST request or do something in the background. Then upload just the function code to AWS, and they will execute it for you on demand as HTTP requests come in--or you trigger the functions to run through some other means (Pubsub events, database events, direct triggers, scheduled tasks, etc). Best of all, you get charged only for the time the functions are running--making compute a rounding error for most SMBs.

Google to the Serverless (and Cloud) Party

‍While AWS should get all the credit in the world for developing and popularizing the ideas behind serverless, HiOperator runs its infrastructure on Google Cloud. We used to be on AWS and made a move over a year ago (and haven't looked back!). The WHY we changed is another post. What I want to focus on here is what services we use to make it happen.

First thing to know is that there are two UIs and feature sets to be mindful of: Google Cloud and Firebase. They are both really Google Cloud and overlap in some features (e.g., cloud functions, storage), but have two distinct UIs and some unique services we will need to use.

We found that the best way to build the app is to use mostly the Firebase services with a sprinkle of Google Cloud services for a few specific things (like a mySQL database). So without further preamble, here's mostly what you need.

For static files (HTML, CSS, JS), use Firebase Hosting: All of that wonderful frontend code that we write can be served to clients from Firebase's cloud storage bucket. This assumes you have a micro-services architecture (so your frontend makes API calls to your backend to get data) and you don't need to do any server-side rendering. If those assumptions are fair, going the cloud storage bucket route is amazing! It's super easy to deploy and version. And Firebase does HTTPS out the box for you for free. They make the certificate and ensure all traffic goes over HTTPS. Pretty nice, right?

For authentication and user management, use Firebase Authentication: Firebase gives this product away for free. You can use their pre-build UI components or the super simple API to use your own. The service handles all the federation stuff too (e.g., letting people sign in with Facebook or Google into your app).

For the API endpoints, use Firebase Cloud Functions: This is the Google equivalent of Lambdas. Just write the functions that handle the logic you want to execute for different endpoints and deploy to Firebase. They will auto-scale for you and charge you for only the time the functions are executing. One note here is that technically Google Cloud also has this service, but you can only put the API behind your custom domain by using the Firebase version of cloud functions (weird, I know!). So you probably want to go the Firebase route.

For functions you execute in the background or on a schedule, use Firebase Cloud Functions: Cloud functions can be triggered through Pubsub events or through a cron scheduler. The maximum duration for these functions is 9 minutes.

For storing files (e.g., images), use Firebase Storage: This is the Google equivalent of S3 buckets. Firebase frontend tools have a neat easy upload directly to storage from the frontend feature.

For database, use CloudSQL or Firestore: CloudSQL is in Google Cloud and it is a fully managed mySQL or Postgres database. It's not actually serverless--you are going to get an instance running. But Google doesn't really have a serverless relational DB offering :(. Firestore is a NoSQL fully serverless database from Firebase. It does realtime super well, but there are gotchas (which I cover in another post).

That's it! You should be able to get even a pretty complex app running through just the usage of the above services.