App Engine
App Engine is a platform for building scalable web applications and mobile and IoT backends. App Engine provides you with built-in services and APIs, such as NoSQL datastores, memcache, and a user authentication API, that are common to most applications. App Engine can scale your application automatically in response to the amount of traffic it receives, so you pay only for the resources you use. Just upload your code and Google will manage your app’s availability—you don’t need to provision or maintain a single server.
- You can split traffic between deployment versions (kind of like blue/green deployments) There are multiple methods to split traffic: by IP address, Cookie, or Random
- You can also migrate traffic between deployment versions, moving traffic from one or more versions to a single new version. For more information, visit this link.
Standard
- Only specific versions of Java, Python, PHP, Node.js, Ruby and Go are supported
- Must conform to sandbox constraints, such as no writing to the local file system, timeouts at 60 seconds, and limited 3rd party software installation
- If you need more flexibility, App Engine probably isn’t the right tool for you
- It is literally an “instance” of your application running in a container on Borg (not a Docker container, but still a container)
- As your application gets more traffic, it will automatically scale and load balance. Scales to 0 instances when not in use – this is very efficient in case studies! However, App Engine takes about 15 minutes to scale down. If you need compute power for less than 15 minutes, consider Cloud Run.
- Because you can’t write to the local file system, you need to store state in a data tier
Flexible
- Takes longer to startup, but you get some benefits. Must have minimum of 1 instance
- Longer request timeout, background processes, SSH into instance, write to local disk, modify the runtime, use websockets, 3rd party binaries
- App Engine Flex is another way to run containers on Google Cloud, but Cloud Run is the future
- Supports .NET Core framework (C#, F#, VB.NET, …), in addition to the languages supported by App Engine Standard
Cloud Functions
Cloud Functions lets you build automation code that lives for a short duration and can perform actions in a scalable fashion. You can use Cloud Functions as a glue to stitch together various pieces of your applications without worrying about infrastructure management.
With Cloud Functions, you write simple, single-purpose functions that are attached to events emitted from your cloud infrastructure and services. Your function is triggered when an event being watched is fired. Your code executes in a fully managed environment. There is no need to provision any infrastructure or worry about managing any servers.
To improve Cloud Functions performance and latency, reduce the amount of imported code, don’t use lazy initializations, and reuse global variables in future invocations. The functions will retry on failure – if your function crashes for any reason (including a bug in your code) it will be retried for up to a week, but it’s not enabled by default!
Cloud Run
Cloud Run is a managed compute platform that enables you to run stateless containers that are invocable through web requests or Pub/Sub events. Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most—building great applications. It is built from Knative, letting you choose to run your containers either fully managed with Cloud Run, or in your GKE cluster with Cloud Run for Anthos on Google Cloud.
A Cloud Run deployment is called a Service. When you create a service, you create a revision. You create a new revision with each deployment (they are immutable) and you can have up to 1,000 past revisions.
Cloud Run supports rollbacks to previous revisions and gradually rolling out to new revisions (like a canary test) using traffic management tools that include splitting and routing.
You can combine Cloud Run with Cloud Build (and triggers) to automatically deploy new revisions of your application. Use cloudbuild.yaml file to tell Cloud Build which steps to take.
By default, Cloud Run is triggered by an HTTPS request and is often publicly referred to with a custom domain name. However, you can also trigger your applications from Pub/Sub topics or scheduled with Cloud Scheduler or Cloud Tasks.
Use Serverless VPC Connector to give Cloud Run access to internal IPs in a VPC. The use case is when your serverless environment needs to access data from your on-premises database through Cloud VPN
Default configuration uses 1 CPU and 256MiB of RAM, and you can use up to 2 CPUs and 2GiB of RAM. Timeout is set to 300 seconds, can be set up to 900 (15 minutes) but Cloud Run isn’t designed for long-running processes. Default concurrency is 80 requests.
