Over the last few years, the offer of web hosting services, focused on developers that want to disengage from the infrastructure that supports their app, has been growing and improving.

From the first time with Heroku and its “dynos”, in 2007, various providers have joined the broad offer of Platform as a Service (PaaS). Among them, Google App Engine (GAE) stands out due to its versatility and simplicity. GAE allows developers to deploy their apps in an agile way thanks to its microservices philosophy.

To understand why Google App Engine stands out and understand some of its strengths, we are going to see a practical example of how to deploy an app on Google App Engine and help it evolve.

We will use a simple application developed with Python 2.7, one of the languages supported in Google App Engine’s standard environment. If we needed a different Python version or the app has been developed with a language that is not supported by this environment, we can always use the flexible environment, that allows us to choose almost any runtime environment for our web application.

Desplegar una aplicación con Google App Engine - CAPSiDE

Before deploying an app with Google App Engine, it is necessary to have a Google account and enable Google Cloud Platform (GCP) within it. Once the account is enabled, we can log in to the Google Cloud web console. Then it’s time to create a project to deploy the application. Projects are the base to start using any GCP service.

When you create an account, Google Cloud Platform provides a credit of 300$ that can be used in the first 12 months. In addition, there are selection of services that are always free.

To start working with GAE, the best option is to install Google Cloud’s SDK, which is available for various operating systems. With this SDK we can directly deploy our app with Google App Engine. Also, we will be able to carry-out our development locally. We can install the SDK on a range of servers. For example, the server where you currently work, a virtual server to use as the development environment or even a Google Compute Engine instance used as a development environment that can be switched off when not required. In the example that we are going to use, we installed the SDK in a Linux virtual server.

Once you have the Google Cloud SDK, it is time to install the additional components for the runtime environment. In this case, we will install the App Engine extension for Python. We will do so by running on the server where we have the SDK the following command.

[email protected]:~$>gcloud components install app-engine-python

Now that we have all the necessary tools to deploy on Google App Engine, there is just one thing left: our app. To use in this exercise, we have created a simple app that only shows a picture with a like button. The picture belongs to a new kind of clouds included in the last revision of the Cloud Atlas by the World Meteorological Organization.

Desplegar una aplicación con Google App Engine - CAPSiDE

Deploying the app with Google App Engine

The app that we are going to use can be found here.

To download version 1 of the app, the best you can do is clone the Github repository in your development environment. With the following command, you will clone version 1’s branch in the local directory appv1.

[email protected]:~$>git clone https://github.com/capside/appengine.git -b version1 --single-branch appv1

The first thing to do with this is to test whether the the app works in our local development environment. To do so, you can run the next command:

[email protected]:~>cd appv1
[email protected]:~/appv1$>dev_appserver.py app.yaml --host=

If everything works, the version 1 of our app will run on the development server and we will be able to connect to port 8080 to see the app. Once we try our app in our local environment, we can just deploy the app with Google App Engine using the following command.

[email protected]:~/appv1$>gcloud app deploy -v 1

As you can see, we are using a parameter saying that we want to deploy the app with the version tag “1”.  If we don’t specify this parameter, the version tag that will be deployed will be extracted from the timestamp of the server used for the deployment.

If we deploy successfully, we can see something like the following on the Google Cloud console:

Deploying an app with Google App Engine - CAPSiDE

Google App Engine allows the deployment of different versions in the same way as we did with version 1. As we already have version 2 of the app on another Github branch, we can download it in a different directory of our development server. As an example:

[email protected]:~/appv1$>cd
[email protected]:~$>git clone https://github.com/capside/appengine.git -b version2 --single-branch appv2

Now we can try the second version of our app and, if we are satisfied, we can deploy it on Google App Engine with this command:

[email protected]:~$>cd appv2
[email protected]:~/appv2$>gcloud app deploy -v 2 --no-promote

In this case, the parameter –no-promote tells Google App Engine that we don’t want to use this version in production, we just want to deploy it.

When we have the second version deployed, Google Cloud’s console will show something like this:

Desplegar una aplicación con Google App Engine - CAPSiDE

The links that are shown in the column “version” point to the URLs of each one of the created versions. This means that both versions are active and deployed. Even so,  the main URL of our app in Google App Engine will take us to version 1. This happens because it is the configuration that we decided to deploy.

If we want to use version 2 in production, we can do so by pushing the button “split traffic“, that is shown in the next picture under a red circle.

Desplegar una aplicación con Google App Engine - CAPSiDE

Once we push this button, there is a screen where we can choose the traffic percentage that we want to send to each one of the deployed versions and the criteria we want to use to decide how we want to divide the load between our versions.

In our case, we are going to use both versions in production, even though version 2 will receive only 10% of the traffic. This is a way to do “Canary Testing”. If instead of 10% we decided to use 50% for version 2, it will be a way to do “A/B testing“.

Deploying an app with Google App Engine - CAPSiDE

To verify that our second version is working, we will have to try load our application a few times using different browsers and even with different servers. With a sufficiently large number of tests, we will be able to see that the load distribution complies with what we used on the “Split Traffic” option and that both versions are in production.

We have deployed two versions of our app in an easy way and we can choose how much traffic we want to send to each of them. Also, and due to the fact that both versions can be reached at their own URL, we can also do all the testing before a specific version goes into production.

To understand in more detail which version is more successful, it would be ideal to include logic in our application that could provide metrics to understand which version has more interest. To help us with this task, Google App Engine easily provides most of the services provided by Google Cloud. In the next post, we will talk about how to use some of these services on our app and we will discover which ones have the most benefits.

TAGS: app, google app engine, google cloud, google compute engine, python

speech-bubble-13-icon Created with Sketch.

Leave a Reply

Your email address will not be published. Required fields are marked *