Choosing the Right GCP Compute Platform

When running on a cloud platform such as GCP, there are many ways to build an application. Google offers a comprehensive range of options spanning from fully serverless options, such as Firebase, to dedicated VM hosts, known as sole-tenant nodes. Deciding which level of abstraction is correct depends on the application, the development team, and how you would like to allocate investment to deploy and support the application.

Google’s current compute product continuum, from lowest to highest level, looks like this:

Compute Engine provides raw VMs, so you’ll need to manage most aspects of the system. Firebase and Cloud Functions provide very high levels of abstraction, so you don’t need to manage as many aspects of the system. In order to build an application on a VM, you need to consider more aspects but making your application fit is generally an easy task. To make an application fit into a serverless platform, it will need to match the architectural model of that particular platform. If your application fits the core design tenants of the system, you’ll be in great shape. If it does not fit, then you’ll be fighting the system and it will be painful and frustrating.

This document is meant only to provide a high level overview and call out some of the items we look at when deciding where an application or service might best fit. There are other considerations as well such as the importance of time-to-market, product “roadmap,” expected growth, and maintenance considerations.

As a general rule, you can achieve lower operating costs in terms of compute with lower-level infrastructure. However, you’ll need staff with the expertise and capacity to manage that infrastructure. At very large scales the compute savings can be significant and outweigh the costs of an operations team.

The core value proposition of serverless platforms is allowing you to allocate more resources to your products and less to operations and commodity work. You also benefit from automated operations and 24x7 operations staff the cloud vendor provides. For applications where minimizing compute costs is not the primary goal, serverless platforms offer a great option to allow you to focus more resources on your product. The level of sustained usage and scale where this tradeoff isn’t worth it is unique to each application.

Firebase (BaaS)

Firebase is a development platform that allows you to build mobile and web applications quickly and with minimal server-side code. For example, it provides solutions for aspects such as user authentication and offline data syncing for you. This is often referred to as a “backend as a service” because there is no (or very little) server code. The trade-off is you have less control over the system, but it can be a great fit for quickly prototyping applications or building a proof of concept with minimal investment. Note that some components of Firebase can be used outside of the Firebase platform, such as Cloud Firestore and Firebase Authentication.

The primary advantage is that you can focus most of your development effort on client-side application code and user experience. The primary disadvantage is that you’ll need to fit into the Firebase architectural model and implementing complex server-side logic will be more challenging.

Good Fit Characteristics

• Mobile-first (or ready) applications
• Rapidly prototyping applications
• Applications where most of the logic is (or can be) client-side
• Using Firebase components on other platforms, such as using Cloud Firestore or Firebase Authentication on App Engine, to minimize investment in non-differentiating work

Bad Fit Characteristics

• Applications requiring complex server-side logic or architectures
• Applications which require control over the runtime

Cloud Functions (FaaS)

Cloud Functions are an excellent choice for “plumbing” and connecting services together, especially if those services can consume or react to events. While you can develop basic user-facing APIs, the operational tooling is not sufficient for complex systems. Cloud Functions are highly elastic and have minimal operational overhead since it is a serverless platform, so they work well for applications with bursty or variable traffic patterns.

Cloud Functions are an excellent choice for dynamic, event-driven plumbing such as moving data between services or reacting to log events. They work well for basic APIs, but can rapidly become operationally complex for more than a few endpoints.

Good Fit Characteristics

• Event-driven applications and systems
• “Glueing” systems together
• Deploying simple APIs

Bad Fit Characteristics

• Highly stateful systems
• Deploying large, complex APIs
• Systems that require a high level of control or need custom runtimes or binaries

App Engine (PaaS)

App Engine offers a robust, but opinionated, runtime platform. For stateless applications with quick instance startup times it is often an excellent choice. It offers many of the benefits of Function-as-a-Service platforms, but simplifies operational aspects since larger components are easy to deploy and manage. Google manages nearly all of the low-level operational concerns and the platform is proven to be reliable and highly scalable.

App Engine allows developers to focus most of their efforts on business logic. It is a great fit for green-field applications where server side processing and logic is required. App Engine does best with stateless applications with fast start-up times, so applications built with large frameworks can be challenging to optimize.

Good Fit Characteristics

• Stateless applications
• Rapidly developing CRUD-heavy applications
• Applications composed of a few services
• Deploying complex APIs

Bad Fit Characteristics

• Stateful applications that require lots of in-memory state to meet performance or functional requirements
• Applications built with large or opinionated frameworks or applications that have slow start-up times (this can be okay with Flex)
• Systems that require protocols other than HTTP

Cloud Run (CaaS)

Cloud Run is Google’s managed compute platform for stateless containers. Essentially Google is managing the underlying Kubernetes infrastructure for you. This provides many of the benefits of App Engine with the power of GKE. Cloud Run can also be run on your own GKE cluster if you desire control over the runtime environment.

Cloud Run strikes an appealing balance between higher level serverless products and lower-level infrastructure.

Good Fit Characteristics

• Stateless services that are easily containerized
• Event-driven applications and systems
• Applications that require custom system and language dependencies

Bad Fit Characteristics

• Highly stateful systems or systems that require protocols other than HTTP
• Compliance requirements that demand strict controls over the low-level environment and infrastructure (might be okay with the Knative GKE mode)

Kubernetes Engine (Between IaaS and CaaS)

Kubernetes has rapidly matured and has wide industry support. The pace of development and support across major tech companies has been impressive. In our experience, GKE offers the best managed Kubernetes experience available of any cloud provider. We generally consider it the lowest level most modern systems and applications should target (or require).

Use GKE when you want to provide developers with the most architectural flexibility or you’re looking to minimize operational costs. While GKE is the best managed offering, you’ll need in-house resources to manage your Kubernetes clusters.

Good Fit Characteristics

• Applications that are already or can be easily containerized
• Apps that work well in a multi-tenant environment
• Systems leveraging stateful and stateless services

Bad Fit Characteristics

• Burden of managing underlying infrastructure is still on the team
• Applications that require very low-level access to the underlying hardware (custom kernel/networking etc.)

Compute Engine (IaaS)

Compute Engine is the lowest common denominator generally available in the public clouds. It should be the last choice if all other options have been eliminated. It carries the highest operational overhead. For use-cases requiring custom kernels or other low-level requirements, it might be the only option.

For companies with existing in-hour operations teams, or those moving legacy workloads to the cloud, Compute Engine offers the lowest-friction path. You’ll need to manage all operational aspects, so an operations group will be required.

Good Fit Characteristics

• Need low-level access to, or fine-grained control of, the operating system, network, or other operational characteristics. E.g. custom compiled kernel
• Applications that do not map well into containers, e.g. legacy vendor applications
• Applications with extremely consistent utilization

Bad Fit Characteristics

• Teams who are not experienced managing infrastructure or do not want to invest in managing systems
• Most newer applications

This high level overview summarized some of our key considerations when helping companies decide which compute platform makes the most sense. There are many options and the decision will depend largely on your current skill sets and preferences. Our general advice is to start with higher levels of abstraction and work towards lower levels as the need to clear. We’ve found this offers the best balance of focusing on product development and managing costs and investment.

If you’re currently moving workloads to the cloud or rearchitecting applications to take advantage of serverless platforms, contact us. We help companies ship with confidence.