The course is part of these learning paths
Building Solutions for Google Cloud Platform with App Engine
As developers, the learning never ends. Just when we get used to a certain technology, it goes and changes. We’re always needing to learn new languages, frameworks, APIs, and platforms.
And if you’re also in charge of deploying your code, then you need to understand how to setup and configure web servers, deal with scaling issues and manage databases. Frankly, it can be exhausting!
So, why invest the time in learning yet another set of technologies? That’s the question I find myself asking whenever some new trend comes along. I want to know how it’ll make my job, and the jobs of my peers better or easier.
Throughout my career I’ve been responsible for deploying my own code. And I think that’s why the Google Cloud Platform resonates with me so well. It’s a platform that understands developers.
So, why take the time to learn something like App Engine? I think the answer is simple. Because you can take all your development experience and apply it to a platform as a service that removes most of the obstacles to getting code running in production.
The value of having Google ensure your app is highly available is worth a lot to me. We get a rich set of tools for developing locally, and simple deployments, with application versioning. All while using the same programming languages and frameworks that we’re used to.
If you’re looking for a native cloud platform for building out highly scalable applications, or mobile back-ends, then you’ve come to the right place. App Engine provides all that and more.
This course focuses on teaching you about the tools App Engine provides to build out highly scalable systems.
We’ll be building out Python web applications using Flask, and using Cloud Datastore as our database. There is a bit of a learning curve to getting started. And that’s what this course is for, to minimize the amount of time spent learning the platform, so you can get back to writing code.
The source code lives on: Github so feel free to download it, and follow along.
We’ll cover a lot of data in this 2 hour course. And by the end of it, you should feel comfortable getting started building out App Engine applications of your own.
And if you’re looking to get your Qualified Solutions Developer certification, this is going help you with that too.
So, if this sounds useful to you, let’s get started!
In this course
- We’ll create an App Engine application, and deploy it
- We’ll be Developing a REST API with Cloud Endpoints
- We’ll learn about the different Authentication and Authorization methods available on App Engine.
- We’ll learn about the monitoring and management tools available.
- We’ll cover the different storage options available.
- We’ll review Cloud Datastore more in depth.
- We’ll look into ways to improve application performance.
- And We’ll learn about Task Queues.
This is a intermediate level course because it assumes:
- You have development experience
What You'll Learn
|Lecture||What you'll learn|
|Intro||What will be covered in this course|
|Getting Started||Creating our first App Engine application|
|Cloud Endpoints||How to create RESTful APIs with Endpoints|
|Services||How to break our applications down into separate services|
|Authentication||How can we authenticate users?|
|Managing Applications||How do we manage App Engine apps?|
|Storage||How do we use the different storage options?|
|Datastore||A more in depth look at datastore|
|App Performance||How can we make our apps more responsive?|
|Task Queues||How can we run tasks outside of a user request?|
|What's next?||Where do we go from here?|
Welcome back to Developing Solutions for Google Cloud Platform. I'm Ben Lambert and I'll be your instructor for this lesson.
In this lesson, we're going to talk about App Engine. We'll go through standard and Flexible Environments. We're gonna talk about some of the different development tools that are available to help us develop our apps faster. And we'll develop a simple web application, test it locally with the development server, and then deploy it to App Engine.
This lesson is going to set the stage for the following lessons. We'll use what we learn here about creating apps for App Engine and how to deploy them throughout the rest of the course. So, we're gonna cover a lot, however, it's going to give us a solid foundation to build on.
Let's talk about the difference between Standard and Flexible Environments before we start writing out code. If you remember from the Fundamentals course, App Engine Standard Environments are the original App Engine environment. It's a sandboxed environment, that allows us to use predefined software runtimes to build out web applications and mobile back-ends. The Standard Environments allow us to use Java 7, Python 2.7, Go, and PHP.
Because these managed runtimes run inside a sandbox, there are a few constraints that we have to work with. First, you can't write to the local file system. Also, there's a 60 second request timeout, and we can't install any third-party binaries. So, if your app can tolerate these sandbox restrictions then I highly recommend the Standard Environments. They start up in just milliseconds and are a fantastic way to have a highly scalable managed platform. With Standard Environments, we develop locally, we test locally, and then, we use the SDK to deploy it to App Engine, and then App Engine handles the rest.
Now, Flexible Environments are the other option. They allow us to use a broader set of standard runtimes including, Java 8, both Python 2.7 and 3.4 Node.JS, Ruby, and Go, and all without the sandbox constraints of the Standard Environment. And, we can SSH into the instances, should we need to. And if these runtimes don't work out, then we can use a Docker file to deploy a Docker container. The Flexible Environments take a bit longer to start up than the Standard Environments and, in some cases, it can take up to minutes.
So, if we need more flexibility than the Standard Environments offer, then Flexible Environments are worth checking out. Flexible Environments used to be called Managed VMs. You may still see some references to that name in the documentation, or on different forums. So, just remember, Managed VMs are now called Flexible Environments.
So we have two environments to choose from, Standard and Flexible, and our application requirements will help us select which one we use. However, we're not limited to using just one. We can use services that allow us to have Standard and Flexible at the same time.
Let's talk about the different tools that are available to help us, as developers, become more efficient while developing for App Engine. First up, let's talk about Cloud SDK. This is a Google-created command-line tool for interacting with some of the Cloud-platform services, and it provides local development versions of some of the services such as Pub/Sub and Cloud Datastore.
Next up, we have Android Studio, which can integrate with App Engine, Cloud Endpoints, and Cloud Messaging. For Java developers, there's a Google Plugin for Eclipse, and, as a hosted Google Cloud service, we have Cloud Source Repositories. This gives us a private Git repo for each project. However, we can create multiple repositories, so we're not locked into having to store everything in just that default repo.
Next up is the Cloud Debugger. If you've ever run into an issue that you can't reproduce on your local environment, then you're gonna find this helpful. Sometimes, there are issues that crop up due to some specific application state, or maybe on account of some data that we didn't account for the format of. Regardless of why, we can use Cloud Debugger to inspect the state of our live application without interfering with anything.
And, we also have Cloud Trace, which is a really cool tool. It allows us to see the latency of our requests. This is something that'll be really useful in identifying bottlenecks and even some of those tough-to-identify application performance issues.
All right, now that we've talked briefly about some of the different tools that will help us as we develop App Engine apps, let's dive into actually building an application. Let's build out a very basic Python application using Flask. Flask is a micro-web framework. It's based on the WSGI standard, which is what Python apps on App Engine use. Because we're using Python, we're going to use virtualenv to create an isolated Python environment. This allows us to keep our Python environment separated, and will allow us to upload any vendor libraries with our app.
Okay, we're gonna start by doing a bit of set-up. We're gonna run virtualenv to create an environment in a directory called venv. All right, now that we have that, we'll use pip, a Python package manager, to install Flask. We're gonna install it into the lib folder with the t-flag, which represents the target folder. So, we'll do that with the pip install tack t lib flask.
Okay, now that we have the set-up out of the way, let's create a main.py file. We'll start by importing the default logging package. App Engine's gonna pick up on the default logging package for Python. And now we're gonna import Flask. And we'll create a Flask app here. All right, and let's set up our default route. We'll use the route decorator to specify that this forward slash, which is our base route, should be bound to the index method here. And we'll have it just return some text. And now, let's set-up an errorhandler, that way if we hit a 500 error, it'll run this server_error method.
Okay, now that we have our basic web application with Flask, we need to create an app.yaml file. The app.yaml file is the way we interact with application-specific settings for App Engine. For runtime environments except Java, we'll use the app.yaml. For Java, it'll be appengine-web.xml. It's roughly the same information, it's just in XML format with Java.
All right. We'll go over some of the different options as we progress through the course, though, for now, let's just cover the things that we need for this demo. So first, we're gonna set the application. This represents our project ID. Not the name or number, but the ID. Next, we'll set the runtime. This is how App Engine knows what software runtime to use when starting up our app. And then, we have the api_version, which allows us to ensure that our code will remain working should Google release a new version, because we're coding against a specific version. Currently for Python, there is only the one version though.
Now we're gonna set threadsafe to true and this will ensure our apps support concurrent requests. And now we're going to set the version. This is our application's version. The value is whatever string we want and it will allow us to deploy distinct versions of our applications, so that we can do things such as AV testing. And now, we start in adding a handler. This is how App Engine is gonna map URLs to our code. In this case, we're gonna listen for all traffic. That's what this pattern here is representing; it's saying, take all traffic and route it to the WSGI application listed in the script field. That's what we're gonna add now. So, add a script field. This is a reference to the Python module we want to look in and a variable that stores our WSGI app. In this case, it's saying, basically, look in the main.py file and find us a variable called app.
Okay. Now, we need to be able to run this and make sure everything works. There are a couple ways that we can do this locally. We can use the App Engine Launcher or the dev_appserver script. Now, we're gonna use both throughout this course. I like to use the command-line tools for when I wanna debug something, because I can jump into an interactive debugger session. And the App Engine Launcher is great for simple apps and it gives us push-button deployments. We're gonna use the Launcher for this demo.
Because we already have an existing app, though, we're gonna wanna click on File and select Existing App and then we're gonna need to browse to the Application. Now that we have that, you can see that we have the ability to set ports, for both our Application and the Admin App. If there were different versions of the Dev Server, we could change that here too.
Now, we'll click on Add and it'll add it to the Launcher for us. Let's try it out. Let's click on Run and, if we Browse, it'll open up in our Web Browser. Let's make a small change. We're gonna add a new route that accepts a parameter. We're gonna call this route /greet and we'll add a name parameter to that. If we have it return a greeting, with a name that we just passed in, and now let's test it out. So, we're gonna browse to /greet/Ben and there it is. Did you notice we didn't have to restart our app? It picked up on the file change and it restarted the Dev Server automatically for us, which is really cool.
All right. It's time to actually get this code running on App Engine. So, what we wanna do is, click this Deploy button on the Launcher and you can see that it's going through the files and uploading them to App Engine. If we click this Dashboard button, it'll take us to the Console with the App Engine Dashboard loaded and here's our app. Now, if we click on this link, the one here on the right-hand side of the screen, we can see that our app is working. Let's check that greeting page. So, let's have it greet Everyone. And there it is. So, with the push of a button, our application is live.
All right, let's recap. App Engine provides Standard and Flexible Environments. The Standard have some constraints, though, they're also the best option if we can deal with those constraints. If we can't work with those constraints, or maybe we need a different runtime, then Flexible Environments make for a great alternative. App Engine offers a lot in the way of supporting tools for us as developers, and we're gonna check out some of these tools more in-depth later on in the course. App Engine is a popular choice for development teams, because it allows us to build out our applications without really focusing on the operation side of things.
One of the common use cases for App Engine is Realtime Stream Processing. This allows us to stream disparate data, maybe from IoT devices, to an App Engine Front End with Autoscaling, and it's that app's job to send the data off to a compute cluster for processing. Then, we'll store that data in some sort of storage mechanisms, such as, Cloud Storage or Cloud SQL.
And then, we can use BigQuery to query that data and visualize it with another App Engine app. Another very common use case is to have App Engine as our web application and mobile back-end. And if we're gonna use it for a web app and mobile back-end, then we'll probably want some way to create APIs. Ideally, they should be easy to create and easy to version. That's what Cloud Endpoints are used for and they're gonna be the topic of our next lesson.
So, if you're ready to keep building on what we've learned here, let's dive in.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.