App Engine is a Platform-as-a-Service (PaaS) offering. It is the fastest way to get your application running with Google Cloud. It is suitable for web, mobile, and IoT applications, takes away the overhead of managing the execution environment, and scales quickly on demand. Multiple languages, such as Node.js, Java, Ruby, C#, Go, Python, and PHP, are supported. This way, the developer can concentrate on solely delivering the code. The applications are versioned, and traffic can be directed to multiple versions, allowing us to perform A/B or canary tests. Applications in App Engine can be secured with firewalls, IAM roles, and SSL certificates, and can be scanned for common vulnerabilities using the Web Security Scanner service.
We will cover the following topics in this chapter:
Exam Tip
Expect a couple of questions on App Engine in the Cloud Architect exam. However, there is another (Cloud Developer) exam that tests your knowledge of App Engine in detail. For this exam, make sure you know how App Engine works, the two types of App Engine environments – namely standard and flexible – the two types of Memcache and use cases for them, versioning, how to split migrate traffic, what cron jobs are for, custom domains, and what SSL certificates can be used.
First, we need to understand that each project can only host one App Engine application.
The application can have multiple services with multiple versions, as shown in the following diagram:
Which version is served to the end user is based on the network traffic's configuration. We decide on the percentage of traffic that should be directed to a particular version. This means that it is very easy to make new rollouts and possibly even rollbacks.
Applications in App Engine are deployed regionally. This means that the infrastructure that's used to host it is spread across the zones within this region for high availability. The main consideration when it comes to choosing the region is where your end users will be connecting from. However, you should also remember that your app might use other GCP resources. This has an impact on delays as well as costs. Consult the documentation to see which regions the App Engine service is available in as this might change.
Important Note
Once the application has been deployed, you cannot change its region.
The deployment itself is fairly easy. We define an app.yaml file that defines the application and develop the code. By using gcloud app deploy, the application will be deployed to App Engine:
The preceding example is very simple, and you can create far more sophisticated applications. The Cloud Architect exam does not require you to have deep knowledge of how to define the app.yaml file or how to write applications. However, we suggest that you have a look at the Further reading section as it might help you understand App Engine concepts better.
App Engine comes with two types of environments, namely standard and flexible. If you don't have any special requirements, such as unsupported languages or need to customize the execution environment, always go for standard. Keep in mind that flexible App Engine will allow you to migrate your workloads more easily as your workload will already be containerized. Let's have a look at these environment types.
The standard environment uses containers running in GCP. These are standardized for each available execution environment. The traffic to your application is distributed using load balancing. The application can scale down to zero if it is not used and can be scaled up within seconds when the demand rises. The following execution environments are supported:
Exam Tip
App Engine standard is often also defined as a sandbox for developers.
We will now look at the flexible environment.
The flexible environment uses GCE virtual machine instances. It also scales up and down automatically and distributes traffic using load balancing. However, it always requires at least a single instance to run. Starting the instances takes minutes, while in standard environments, it takes seconds. The following execution environments are supported:
Note that the runtimes can be customized. You can even create your own runtime. This can be done by supplying a custom Docker image or Dockerfile.
Exam Tip
As you may have noticed, the App Engine standard environment can scale down to zero, while the flexible environment will always run at least one instance. This has an impact on the cost of running your application.
An App Engine flexible environment service allows you to access root accounts on your instances via a secure shell, known as SSH. However, by default, this is disabled. Remember that the instances will be restarted weekly so that the necessary patches are applied.
We have already seen how applications are deployed to App Engine at a high level. Now, let's have a look at the actual steps we need to take. Here, we will provision a Hello World application. This application leverages the Python Flask web server. As you can probably imagine, the application will display static Hello World text on the website. Let's get started:
We have chosen europe-west as our region.
We will open the Cloud Shell as it comes with the SDK already installed and configured. Open the console and run the following command:
gcloud config set project $PROJECT
Here, <project_id> is the ID of the project you used in the Google Cloud Console.
git clone https://github.com/GoogleCloudPlatform/python-docs-samples
cd python-docs-samples/appengine/standard_python3/hello_world
cloudshell edit main.py
gcloud app deploy app.yaml --project $PROJECT
Confirm this action when you are asked in the console. It may take a minute or two to deploy.
gcloud app browse
Next, let's look at versions.
Now, let's imagine that we want to update the application with new content:
gcloud app deploy app.yaml --project <project_id>
Note that all the traffic is directed toward the new version.
Go back to your browser and refresh to see that the new version of the application has been deployed:
In the next section, we will look at splitting traffic.
Now, imagine that we want to test the changes that we've made on a small number of users. We can do that by clicking on Split traffic, which can be found in the top-right corner. This will bring us to a window where we can choose how much traffic is directed to each version of the application. Choose an appropriate percentage and click the Save button:
Important Note
If you don't see the old version, click the Add version button.
Instead of splitting the traffic, we can also migrate the traffic at once. There are also gradual traffic migrating options so that we can gracefully change the version. Follow these steps to do so:
The traffic will now be migrated to the new version.
Exam Tip
Pay special attention to how you switch traffic between different versions. This can be used for both rolling out the new version as well as rolling back to the last stable version.
Here, we can see the old version of the application.
The firewall for App Engine is pretty simple. It contains a list of rules for allowing or denying traffic to your application from a specific IP range. Note that these rules apply to all the resources of the application. The rules are ordered by priority, with a value of 1 being the most important and 2147483647 being the least important:
The default rule, which allows all traffic from all IP ranges, has the lowest priority and is always evaluated at the end.
From the hamburger menu, go to App Engine | Settings. Here, you will find two important settings: Custom domain and SSL certificates. Let's go over these now.
As you already know, when you deploy an application, you are assigned a URL in the form of <project_id>.appspot.com.
However, you can add a custom domain or register a new domain. You do this from the App Engine | Setting | Custom domains menu:
If you choose to register a new domain, you will be able to purchase it from the Google Domains service.
Since the traffic in the App Engine is load-balanced and uses SSL, GCP offers globally distributed SSL endpoints so that you can serve your application users. An application with a custom domain has a managed SSL certificate assigned to it by default. The certificate will be provisioned and renewed before expiration automatically. When you remove the custom domain, the certificate will be revoked:
If you wish to use your own certificate, you are responsible for managing its life cycle.
One of the most important features of App Engine is its ability to scale several instances. We have a choice regarding the level of automation we wish to use. App Engine offers three options, as follows:
Important Note
Scaling is a very important topic for App Engine. We want to make sure that the application can handle the load, but we also want to control the cost. Remember that you pay for the time it takes to run the instances. You can control the scaling behavior using parameters in the YAML that defines your application. Check the Further reading section regarding App Engine scaling to find out more.
With cron jobs, you can schedule tasks that run at a defined time or regular intervals. The use case for cron jobs includes administration tasks that need to reoccur. For example, perhaps you need to send out an email every day that includes a report about the environment.
For each language, cron jobs are configured a little bit differently. See the Further reading section to find detailed configuration information for various languages. The cron jobs are defined in YAML format and placed in the cron.yaml file.
The following is a YAML file that will run the task every 24 hours:
cron:
- description: "daily summary job"
url: /tasks/summary
target: beta
schedule: every 24 hours
gcloud app deploy cron.yaml --project <project_id>
Click on the APP ENGINE CRON JOBS tab:
With that, your newly created job has been created and will run every 24 hours. Note that you might need to enable the Cloud Scheduler API if you have not used it before.
Exam Tip
Remember that cron jobs are a way of triggering jobs periodically and are an alternative to using Compute Engine with native third-party tools.
Caching is a common way of speeding up how we can access frequently accessed data. This includes session data, user preferences, or any other queries that don't change often. If multiple queries are accessing the same data, it is a perfect candidate to be cached. Memcache is a service that's built into App Engine. It allows you to keep key-value pairs in memory that can be accessed much faster than querying a database. There are two service levels for Memcache, as follows:
You can add values to be cached by accessing the App Engine | Memcache menu:
Exam Tip
Make sure you understand that the standard cache is delivered at the best effort and might not fit all use cases. If you want to have predictable performance, use a dedicated cache.
Next, we will look at the IAM roles required for App Engine.
Access to Google App Engine is secured with IAM. Let's have a look at a list of predefined roles, along with a short description of each:
For less granular access, you can also use primitive roles such as Owner, Editor, and Viewer.
Google App Engine comes with predefined quotas. These default quotas can be changed via the hamburger menu, under IAM & Admin | Quotas. From this menu, we can review the current quotas and request an increase to these limits. You should be aware of the limits for each service as this can have an impact on your scalability.
For App Engine, we should be aware of the following quotas:
The price of App Engine consists of multiple factors and differs for standard and flexible environments. For standard environment instances, the manual and basic scaling services are billed at hourly rates based on uptime. For flexible environments, the applications are deployed in virtual machine instances that are billed on a per-second basis with a minimum of 1-minute usage.
On top of that, you need to include the cost of additional resources that are used by your application. To get the most recent prices, take a look at the following link: https://cloud.google.com/appengine/pricing.
In this chapter, we had a look at App Engine, which is a PaaS offering. We distinguished between two types of environments, namely standard and flexible. Then, we looked at how to deploy an App Engine application and how to update it to newer versions. We also learned how to split and migrate traffic between the versions. Finally, we learned about cron jobs, which allow us to run scheduled jobs.
In the next chapter, we will have a look at Cloud Functions, which is a Function-as-a-Service (FaaS) offering.
To find out more about App Engine, check out the following links: