Dazbo's Acme Blogging App on Google Cloud

Acme Blogging App Hosting on Google Cloud Platform

Solution Options and Recommendations

Here I summarise some of the key decision options and options considered.

Sections in this Page

Ghost Application Frontend

These are the hosting options for the Ghost web application itself.

Option Pros Cons Recommendation
GCE instances
  • Standard Ghost stack.
  • Can provide scalability and HA using managed instance group and load balancer.
  • Rolling upgrades possible with managed instance group.
  • Can securely connect to Cloud SQL using Cloud SQL proxy.
  • Would use hardened OS with no external IP address.
  • If we need local persistence, then this will be preferable to Cloud Run. We can provide HA block persistence using a regional persistent disk (though it has limitations), or HA managed NFS using Cloud Filestore.
  • Need to maintain OS. Option to maintain by patching or replacing OS
  • Off-the-shelf Ghost installation not fully automated / scripted. Can be mitigated by deploying as a container.
 Fallback, if Cloud Run proves unworkable.
Cloud Run
  • Fully-managed serverless container runtime environment. No need to manage a cluster.
  • Off-the-shelf community-supported container available
  • Much more lightweight than GCE instances
  • Can still use HTTPS LB, in order to leverage CDN, Cloud Armor, etc
  • Easy to set up CI/CD using Cloud Build
  • Google Container Registry can scan for vulnerabilities
 Default container is SQLite; tricky to configure with Cloud SQL. Recommend
Google Kubernetes Engine (GKE)
  • Managed Kubernetes.
  • Powerfull orchestration and scheduling capabilities.
  • Supports complex multi-service architectures.
  • Supports stateful containers.
  • Significant management overhead, compared to Cloud Run.
  • Higher base cost. Can't scale to 0.
  • Overkill for a single service.
 Reject
App Engine Serverless PaaS, in which we can run nginx and deploy the Ghost application code. Limited support or documentaton for this configuration. Reject

Pruning Application Frontend

These are the hosting options for the application that will allow authorised users to prune all posts in the Ghost database.

Option Pros Cons Recommendation
Cloud Functions
  • The brief strongly hints at wanting a "serverless function".
  • Trivial to implement code to delete records from a database.
  • Easy to implement to respond to an HTTP event
  • Can scale down to 0. Given the low level of expected invocations, this service will effectively be free.
 Not easy to provide a means to authenticate the user. Not ideal, but requested
Cloud Run
  • Fully-managed serverless container runtime environment.
  • Easy to deploy a web application in a container.
  • Highly portable.
  • Still a lightweight serverless approach.
  • Can scale to 0, which is ideal for a service that is rarely invoked.
  • Easy to repackage images in response to source code changes, using Cloud Build.
  • Google Container Registry can scan for vulnerabilities
  • Easy to implement user authentication and authorisation to the service. Since the service will only be accessed by authorised individuals in the organisation, we can use IAP on the load balancer, with an ingress.
 Need to package the application in a container image. Would recommend
App Engine
  • Serverless PaaS.
  • No need to package as a container.
 Less portable than using containers. Reject

Application Persistence / Database

Option Pros Cons Recommendation
Cloud SQL MySQL DB
  • MySQL is an endorsed database for Ghost.
  • Fully-managed relational DB.
  • Supports both intra-region HA, and cross-region replicas for DR.
  • Database engine itself is open source and free.
  • No DB installation, management or patching.
  • No DBA overhead.
 Promotion of cross-region replica to "master" cannot be done using declarative IaC. Some manual steps required in DR process. Recommend
Build your own MySQL DB (install onto GCE instance)
  • (None, over Cloud SQL implementation.)
  • DBA overhead: this is not a managed implementation.
  • Requires installation and management of the DB.
  • OS engineer overhead: Requires installation and management of GCE instances.
 Reject
SQLlite
  • Default off-the-shelf implementation for Ghost.
  • Lightweight.
  • Little or no configuration required.
  • Local (per-instance) persistence only. Won't meet consistency requirement! Nor HA.
  • If we implement within a container, the data would not be persisted.
 Reject
Cloud Spanner Fully cloud-native.
  • Massive overkill for this scale.
  • Very expensive.
  • Unlikely to be supported by the application.
 Reject

Infrastructure-as-Code (IaC)

Option Pros Cons Recommendation
Terraform
  • Declarative.
  • Cloud agnostic and therefore helps avoid cloud vendor lock-in.
  • Extremely lightweight installation. (And installed by default on Google Cloud Shell.)
  • No agents.
  • Open source.
  • Endorsed / certified modules from HashiCorp, and from cloud vendors (including Google)
  • Supports IaC of components across a wide ecosystem.
  • Strong validation capabilities.
 N/A Recommend
Google Cloud Deployment Manager
  • Fully-managed Google Cloud solution, integrated into the Google Cloud ecosystem.
  • No installation or management required.
  • Declarative.
  • No agents.
  • Limited support for products outside of Google Cloud's native offering. (E.g. Kubernetes).
  • Google only.
  • Google are now promoting Terraform over their own Cloud Deployments. Implies deprecation.
 Reject

CI/CD Pipeline

Option Pros Cons Recommendation
Google Cloud Build
  • Fully managed, serverless Google-native CI/CD tooling.
  • Can consume various backends, including GitHub, Google Cloud Source Repositories, and BitBucket.
  • Native container support.
  • Vulnerability scanning and binary authorisation of containers are built-in.
 Not cloud agnostic. Recommend
Jenkins
  • Open source - no license cost.
  • Can integrate with any upstream or downstream components.
  • Cloud agnostic.
  • Very powerful.
  • Requires installation and maintenance. Would typically be deployed on Kubernetes (or GKE in Google Cloud).
  • Whilst Jenkins is free, remember that the run infrastructure is not.
  • With sophistication comes skills overheads.
 Reject
GitLab
  • Very mature CI/CD workflow, integrated with its own Git repos.
  • Basically an all-in-one CI/CD SaaS.
  • Cloud agnostic.
 Not free. Reject
GitHub Actions
  • Embedded with the GitHub ecosystem.
  • Good choice if we already have a lot of GitHub repos.
  • Cloud agnostic.
  • Actions has a market place for consuming workflows.
  • Free up to a point. A lot of free minutes!
  • Relatively new product, so not as mature as others.
  • Dependent on load, may have a cost.
 Second choice.