The course is part of these learning pathsSee 6 more
If you’re going to work with modern software systems, then you can escape learning about cloud technologies. And that’s a rather broad umbrella. Across the three major cloud platform providers, we have a lot of different service options, and there’s a lot of value in them all.
However, the area that I think Google Cloud Platform excels in is providing elastic fully managed services. Google Cloud Platform to me, is the optimal cloud platform for developers. It provides so many services for building out highly available - highly scalable web applications and mobile back-ends.
For me personally, Google Cloud Platform has quickly become my personal favorite cloud platform. Now, opinions are subjective, but I’ll share why I like it so much.
I’ve worked as a developer for years, and for much of that time, I was responsible for getting my code into production environments and keeping it running. I worked on a lot of smaller teams where there were no operations engineers.
So, here’s what I like about the Google Cloud Platform, it allows me to think about the code and the features I need to develop, without worrying about the operations side because many of the service offerings are fully managed.
So things such as App Engine allow me to write my code, test it locally, run it through the CI/CD pipeline, and then deploy it. And once it’s deployed, for the most part, unless I’ve introduced some software bug, I don’t have to think about it. Google’s engineers keep it up-and-running, and highly available. And having Google as your ops team is really cool!
Another thing I really like about is the ease of use of things such as BigQuery and their Machine Learning APIs. If you’ve ever worked with large datasets, you know that some queries take forever to run. BigQuery can query massive datasets in just seconds. Which allows me to get the data I need quickly, so I can move on to other things.
And with the machine learning APIs, I can use a REST interface to do things like language translation, or speech to text, with ease. And that allows me the ability to integrate this into my applications, which gives the end-users a better user experience.
So for me personally, I love that I can focus on building out applications and spend my time adding value to the end-users.
If you’re looking to learn the fundamentals about a platform that’s not only developer-friendly but cost-friendly, then this is the right course for you!
By the end of this course, you'll know:
- The purpose and value of each product and service
- How to choose an appropriate deployment environment
- How to deploy an application to App Engine, Kubernetes Engine, and Compute Engine
- The different storage options
- The value of Cloud Firestore
- How to get started with BigQuery
This is an intermediate-level course because it assumes:
- You have at least a basic understanding of the cloud
- You’re at least familiar with building and deploying code
- Anyone who would like to learn how to use Google Cloud Platform
Hello and welcome. In this introduction to App Engine, we're going to explore the features that help developers to build highly scalable web apps and mobile backends. By the end of this lesson, you should be able to: describe the purpose of app engine, explain the difference between standard and flexible environments, explain the current state of the app engine ecosystem, and describe how to deploy a basic application. Alright, there's a lot of information to cover here. So if you're curious to learn more then let's get started.
Let's start with the first learning objective and I'll describe App Engine. App Engine is one of the original platforms as a service. It was released in 2008 which is practically the cloud's very own Stone Age. And it allowed engineers to run Java and Python web applications on a highly scalable, managed platform. Since then, it has continued to evolve while continuing to serve the same purpose which is to help engineers build highly scalable web applications and mobile backends on a fully managed platform.
In the early years of App Engine, Google managed everything in the tech stack, from the runtime down. App Engine started with Java and Python runtimes and started to add more over time. Now eventually Docker came along with its ability to package an application with its dependencies and it changed expectations for app deployment. Engineers started to think about containers as a means of deployment. So Google enhanced the functionality of App Engine by creating the concept of environments. The original managed runtimes became known as the standard environment and a new Docker-based solution became the flexible environment.
Here's what it looks like to run on the standard environment. You run your code using a Google-managed runtime of which there are several. And the runtimes are broken into first and second generation runtimes. Each application runs a container instance based on an instance class which specifies the amount of memory and CPU. It's price based on the number of instance hours, and deployments are measured in seconds. So it's going to deploy your new apps pretty quickly.
Now writing to disk is only supported for some runtimes. And runtimes that do support it are limited to the TMP directory. There's no SSH access, and it is an overall pretty locked-down environment.
The flexible environment, on the other hand, allows you to run code inside of a Docker container using a Google-managed Compute Engine instance. Because you're running in Docker, and to save you some effort, Google provides built-in runtimes which are based on some Google managed Docker container images. It's priced based on the usage of the Compute Engine resources. Deployments are measured more in minutes than seconds. And writing to disk is fully supported. SSH access is also available. And overall, it's a lot less restrictive, though it's going to be slower to scale.
Google created App Engine to facilitate the creation of highly scalable apps. And you can't get there with just compute alone. So you need some other services that are highly scalable to match, such as databases for data storage, task queues, scheduled tasks, etc. So this is where things get complicated because the App Engine ecosystem has been evolving over time and that's left a bit of fragmentation on the family tree.
Some of the older functionality, which still remains in the user interface and is in the documentation, has been made obsolete. For example, in the standard environment, there is functionality called Blobstore which is a less capable version of cloud storage, however, it's really not something that you would use if you're building an app today. Another example is task queues, which were once part of App Engine and now their own standalone product.
One of the larger ecosystem changes, though, has been to the database. App Engine has historically paired with Cloud Datastore, a managed, NoSQL database. Though recently, Google announced that Cloud Firestore would replace Datastore. Firestore being a cross between Cloud Datastore and the acquired Firebase, and it's designed to operate in one of two modes. One they call Native mode and one is Datastore mode.
These sorts of ecosystem changes, in the end, they result in a better product. It's really best for us as customers in the long run, though it can make the learning curve a bit steeper. Documentation is not always up to date, and the same goes for blog posts and tutorials which use obsolete features or services. So, if you're learning about App Engine or you're thinking about using it for your next project, just make sure to double and even triple-check that you're using the most up-to-date functionality.
Alright, that aside, I'm on the App Engine dashboard for a project which does not yet have App Engine enabled which is why you're seeing this landing page here. Let's run through this tutorial together. And the reason is I want you to be able to go back and do this on your own. This tutorial is built right into the product.
So clicking on this start link will present us with a choice of which standard environment to use. And while any of these will work, I'm going to use Go, it's just my preference right now. Here's the overview of what this tutorial covers. So we'll find out, we're about to do it, so we'll click Next. The current project is already selected so I'm going to click Confirm. Alright next, we need to open up Cloud Shell. So clicking this link here shows us how which is by clicking the icon up here.
Now, this can take a moment if you haven't used Cloud Shell recently or at all. Let's expand to cover more of the screen. Alright, that looks about right. And we'll click on this icon here to copy this text into the shell and hit Enter. This is going to take a moment to download the demo code from this repo. Great, with this done we can copy this command here. It's just going to change directories into our newly downloaded code. And clicking Next shows two more commands which display the code and configuration.
The first command here shows the actual Go code. All you need to know about this is that this is going to listen on port 8080 for any HTTP requests and it will return the text Hello, World. You don't have to know Go, just know it's gonna sit there, it's waiting for something to connect with HTTP and it's going to return this text.
The second option here shows the configuration for this app which is in YAML format. And in this case, it's pretty empty. All it has here is the specification for the go111 runtime. So that you can see actually what is really in these files, let's go check out the documentation by clicking this link here. And notice this example shows much more configuration data. The app.yaml file is where you define the configuration of your app. These are settings such as the URL mappings, two request handlers, environment variables, static files, etc.
Alright, let's go back to the tutorial and I'll click Next. Okay, and it wants us to run the code inside of Cloud Shell to make sure it works. If you're not used to using the Go programming language then the first time you're going to run go run is going to take a moment. It's going to download all of the dependencies and get everything ready. So subsequent builds will be faster, but this one takes a little bit longer.
Alright, here it is. Here is our Go code running on port 8080. Now we can use the preview to determine if it's working. And there's our Hello, World text. So it seems like the app actually runs and it does allow us to connect over HTTP. So we're going to stop the process with Control C, and go to the next step. Okay great, this is where we can create and deploy our Hello, World app.
The first command is going to initialize App Engine for our project. So it requires us to specify an app's region. Once you select a region, you cannot change it for this project. If you don't want this app to run in this region, you have to start with a new project. That's the rules. I know, I don't like it either but it's just the way it is. Alright, I'm going to use us-east4 for this demo. Awesome, so with this complete, App Engine is initialized for this project and it's running in us-east4 so we're ready to actually deploy our code.
Running the gcloud app deploy command will find the app.yaml. It's going to find the Go code in the current directory, and it's going to deploy it. Notice it gives a summary of what will happen and prompts for permission to move forward. So type in, Y, and hitting Enter is going to move this along. Okay, being the first deployment this can take a while and here it is.
So clicking Next tells us to inspect the process in the App Engine dashboard. So we'll follow these steps. And let's also collapse this Cloud Shell for now. We may use it in a later video, but we don't need it for the rest of this walkthrough.
So this is the App Engine dashboard. This is your at-a-glance info such as URL, request metrics, resource usage, etc. Clicking on the URL here in the corner is going to open a new tab, it's going to show us our actual running app which says Hello, World. The Service page shows details about the different services in our app.
App Engine, by default, provides the concept of microservices. So while we can split our application into different services, we don't have multiple services. We just have our default, and App Engine automatically created that default for us. Allowing apps to be split into separate services also means they can be versioned independently of each other. So you can have multiple services running at different versions, and that way if you need to roll just the one version of a service back, you can.
The Version page shows details about different service versions. It's throwing an error at the moment, I'm assuming because it's the first deployment, so we'll circle back on that later.
The Instances page shows the details about the instances that are running the app. The Task Queues page tells us that we should go away. It tells us to go to Cloud Tasks because it's its own service now. Though, it was once part of App Engine so it still remains here.
Cron Jobs are where we can create a scheduled task. And Cron jobs on App Engine schedule a get request to a URL. I'll demonstrate creating one in another lesson but for now just know, you can schedule a get request to a URL inside of your app. The Firewall rules allow us to allow or deny traffic to our app from specific IP addresses. And also I'll show that later too. Quotas show information about resource quotas. That's pretty self-explanatory. Blobstore asks us to leave it alone so it can die in peace. It's been replaced by Cloud Storage. Memcache gives standard environment users access to a memory cache. Flexible environments can just use Cloud Redis in its place so you're not missing out if you use flexible environments. The Search functionality is again standard environment stuff only and provides text searching.
The Settings section is where we can disable an App Engine app. And that will stop it from being built. You cannot delete an App Engine app. So once it's created, it's there. All you can do is disable the billing and that will stop you from getting charged for any of its resources. And we can also use the Settings section here to set custom domains, SSL cert, and the approved email senders. Alright, so this is App Engine at a high level.
Let's stop here and review what we've covered so far. The purpose of App Engine is to help engineers build highly available web apps and mobile backends. And the way it accomplishes this has changed over the years, though always towards that purpose. App Engine provides two types of environments, standard and flexible. And standard environments have runtimes controlled by Google. They're fairly restrictive but fast. Flexible environments are based on Docker containers and allow customization of the runtime. They are, however, a bit slower to boot up and deploy.
The App Engine ecosystem contains a lot of obsolete, or ever-evolving functionality, which, as I mentioned, can make it more difficult to get started. So make sure when you're learning or prepared to use a bit of technology from the App Engine ecosystem that it is the latest, greatest.
Alright, after seeing how we just deployed an app, you should be able to describe the process at least at a high level. Maybe something like, pick your environment and runtime, initialize an app in a region which can't be changed, deploy your code with a CLI, and test in the console.
Alright, so that's gonna wrap up this lesson. In the next, I'll demonstrate traffic splitting and migrations. I'll demonstrate creating a cron job and creating a Firewall rule. So if you're interested in learning more, then I will see you in the next lesson.
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.