Deploying a Mostly Serverless Website on GCP

• terraform

  501 41,291 9.9 Go

  Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.

  

When exploring options on how to deploy the architecture we briefly considered Google Cloud Deployment Manager. Upon further investigation we were led to use Terraform instead. It was evident that Cloud Deployment Manager did not have the necessary support for the resource types that we were trying to create. Many of the supported resource types were still listed in beta.

• google.cloud

  71 95 6.9 Python

  GCP Ansible Collection https://galaxy.ansible.com/google/cloud

  

With the technology that we have today there are many options for hosting a website. We are particularly interested in Serverless Computing and opted to run our website in that fashion; well mostly. When we chose Google Cloud Platform, we were unable to find a serverless relational database system. Our Java Spring Boot application was constructed to use a relational database so shifting to another database offering wasn’t something we wanted to do at this time. The architecture that we chose to implement consisted of the following GCP services.

• InfluxDB

  www.influxdata.com featured

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• aws-lambda-java-libs

  305 506 6.6 C++

  Official mirror for interface definitions and helper classes for Java code running on the AWS Lambda platform.

  

With our basic application running on GCP for a couple months we have been pleased with the performance and stability of the architecture. Our Cloud Run scaling settings were intentionally set low to meet application expectations as well as to avoid potential bill shock from an autoscaling fiasco. Like AWS App Runner and AWS Lambda we faced cold start delays when scaling up from zero. We could’ve tried to architect around this with something like an automated trigger or always-running instances. Although, the cold start was not a problem for our use-case. We also felt that provisioning always-running instances defeats the purpose of a serverless service. Can a service be considered “serverless” if it can’t scale down to zero so that you’re not paying for idle compute? We said no.

• apprunner-roadmap

  62 289 0.0

  This is the public roadmap for AWS App Runner.

  

With our basic application running on GCP for a couple months we have been pleased with the performance and stability of the architecture. Our Cloud Run scaling settings were intentionally set low to meet application expectations as well as to avoid potential bill shock from an autoscaling fiasco. Like AWS App Runner and AWS Lambda we faced cold start delays when scaling up from zero. We could’ve tried to architect around this with something like an automated trigger or always-running instances. Although, the cold start was not a problem for our use-case. We also felt that provisioning always-running instances defeats the purpose of a serverless service. Can a service be considered “serverless” if it can’t scale down to zero so that you’re not paying for idle compute? We said no.

Suggest a related project