How Google’s Serverless App Engine Work?

App Engine is a fully managed serverless compute service from Google Cloud Platform that makes managing a backend of microservices a lot simpler. It’s built around high scalability without having to manage your own servers.

What Is App Engine?

App Engine is in essence a set of microservices. Traditional applications are usually monolithic, meaning that you run one big runtime service on a server that handles everything. However, what usually happens in the real world is different parts of that application experience differing amounts of traffic, use, and overall load. You end up with bottlenecks, where you’d like to be able to pull out one part of your backend and run more instances of it to keep up with demand.

The design principle of microservices solve this problem. In a microservice-based backend, each service handles only what is required of it. This allows you to deploy multiple copies of the services that you need more of. It also allows you to easily deploy updates to only the services that need updating.

It’s commonplace to use serverless compute services like AWS Lambda Functions or GCP Cloud Functions to easily deploy individual functions as services. App Engine is very similar but is much more powerful as it’s built specifically for microservices backends.

Much like Cloud Functions, you don’t need to manage any underlying servers. You simply upload your code, select a runtime, and let it run. If you’re using the flexible environment, you can deploy your balsamiq kuyhaa application as Docker containers, allowing much more flexibility.

However, unlike Cloud Functions, you do still need to run “Instances” of each service. You’re charges are based on this, and not based on individual function invocations, as there’s nothing like cold start available. (You can downscale to 0 instances on the standard environment, but cold starts will be slow.)

App Engine currently supports the following runtime environments, though if you’re using the flexible environment, you can run custom runtimes in Docker containers.

• Python 2.7, Python 3.7
• Java 8, Java 11
• Node.js 8, Node.js 10
• PHP 5.5, PHP 7.2, PHP 7.3, and PHP 7.4 (beta)
• Ruby 2.5 (beta)
• Go 1.11, Go 1.12, Go 1.13, and Go 1.14 (beta)

For data storage and persistence, there’s a built-in datastore, but it’s being phased out in favor of Firestore, a NoSQL Document database offered as part of the Firebase platform. It has a Datastore mode specifically for compatibility with App Engine’s built in datastore. There’s also a memcache as a service, custom task queues, and cron jobs available from the App Engine console.

If you’d like to get started, Google provides plenty of built in tutorials from the App Engine console.

Standard versus Flexible Environments

App Engine has two different environments you can choose from, both with their pros and cons.

The first, and default environment, is the standard one. This mode operates like compute engine, with predefined instance classes and VM configurations where you will be billed hourly based on usage. Of course, you don’t have to manage these yourself App Engine will handle it, and the environment is sandboxed. This environment has the advantage of quick deployments, and the possibility of zero downscaling, though cold starts can still be slow.

However, with standard you don’t get SSH access, nor do you you get background processes like cron (though Google does provide this as a managed service). There’s a startup and shutdown cost of 15 minutes of instance time, so you’ll want to avoid overly aggressive auto scaling.

The flexible environment uses Docker containers to run everything. Though, if you’re using one of the supported runtimes, you might not need to manage the container yourself. You get SSH access, much more flexibility (it’s in the name), and support for background processes.

However, deployments and startup take a few minutes, and you don’t get access to some built-in App Engine services like memcached.