The course is part of these learning paths
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 lesson, we'll be exploring some of App Engine's functionality from inside the console. By the end of this lesson, you should be able to explain how to split traffic in App Engine, how to migrate traffic, how to create a cron job, and how to create a firewall rule.
This lesson picks up where we left off in Introduction to App Engine, and it's going to be strictly demonstration based. So if you're interested in learning more about App Engine's core functionality then let's get started.
In Intro to App Engine, the versions page was not displaying data properly. Though after a few minutes, it initialized and was ready. So here we are. We have one version which is a basic Hello World app. It's using a standard environment and it's using the Go 1.11 runtime. Each deployment gets its own version number and that makes it easy to select which version of the code we want to serve. Once a service has multiple versions, we may want to split traffic between two or more versions and that could be for let's say A/B testing, canary deployments, or perhaps whatever reason you might imagine.
Let's deploy a modified version of our app and see how this works. Using the Cloud Shell, I'm going to make just a slight change to the code. The file is helloworld.go and I'm going to use nano to make this change. Here at the bottom is the text hello world and this is what I wanna change, we'll change it to hello cloud and I'll save it.
Great, now, running the gcloud app deploy command, we'll again deploy this. The problem is that by default, newly deployed services are promoted so that they receive 100% of the traffic. Well, we want to try traffic splitting so we don't want that. To ensure that our newly deployed app does not get 100% of the traffic or any of the traffic for that matter, we can use the no promote flag. So this will deploy it but it's not going to promote it to be the primary version. And yes we want to continue. And we're done.
Now back on the versions page, there are two versions and the bottom version is our original. It still has 100% of the traffic; that's good. Clicking the new version opens up this version of the service in a tab. And you can see it works, it displays hello cloud.
Alright, so how do we split the traffic? We start by clicking on this link up here which will open up another page where we can determine how to split these requests. There are three options that we can use. We can split by the IP address, we can use a cookie, or at random.
The option for IP address, basically it reduces the IP address to a number between zero and 999 and it uses that to distribute based on our allocation. Now, it makes for almost sticky sessions, but it's not a guarantee, and that's why cookies will give us the most control, however, we have to manage them from inside our application.
The random option, it's just Google's best guess, it tries to randomly distribute them, and I'll use random because it's just easy to demonstrate. So, now we need to determine the traffic allocation. What that means is, how much traffic do we want to go to each version? Both versions are listed here and if we add more, we can optionally include them. I'll use 50% because again it's easy to demonstrate, I'll be able to reload the page and show the different text. So let's save this.
And when we test, we should be presented with roughly half of the responses displaying hello world and half will say hello cloud. And in order to test, we need to use the actual default app URL, not one of these version-specific ones.
So let's head over to the dashboard and click on the primary URL. And I'm going to keep clicking on refresh. Just watch the text change and notice roughly 50% of the time we're seeing one of the two different versions that we have. So it's bouncing between cloud and world so it seems to be working.
Alright, let's route all of the traffic to our new version by splitting traffic again. The version on the bottom is the old version, so we can dial this down to zero and allow 100% of the traffic to go to the new version. So we're saying we want 0% of traffic to be directed to our old version. And heading back to the dash, clicking on the link. All right, all we see now is hello, cloud. So this seems to be working.
Traffic splitting allows us to control how requests are distributed to different versions. That means we can slowly roll out new functionality, though there are occasions where you might want to just immediately cut all traffic to a specific version. Traffic migration does just that, which means it is possible that you end up causing some latency issues for your users if there is a lot of traffic when you switch over.
The version of the service currently running says hello, cloud. So let's change that back. We're going to migrate all of the traffic to hello, world. So we check the box here for version, select migrate and click migrate again. And there it is, all the traffic is now directed back to the old version instantly.
Alright, now having looked at traffic migration and splitting, let's look at cron jobs. Cron jobs are just another name for a scheduled task. So they're useful for cases where we wanna run code on some sort of schedule.
Notice there are no create buttons here in this user interface and let's follow this About link here and see if it tells us why. It takes us to the cron documentation. Though it's taking us to the java docs so let's change that, let's select Go 1.11. And scrolling down, notice this cron.yaml. Remember, we used yaml in the app.yaml file to define our settings for the actual application. So here we have another yaml file for specifying cron jobs. Let's copy one of these jobs here.
Great, and let's go back to the Cloud Shell. And using nano, I'm going to create a file called cron.yaml. And I wanna paste in the text we just copied, though I do wanna make a change here, wanna change the URL. I want it to be just the route URL which is the only URL we have. And I'm going to save this. Alright, awesome.
Now in order to deploy, we use the same gcloud app deploy command that we used previously. However, we have to specify our cron file. We're not just deploying the app, we're deploying our cron job. So this is gonna tell the CLI to deploy our cron job.
Alright, with this complete, we should see our job in the console. So I'll click refresh. And there it is.
Alright, now that you know that you can create cron jobs, if you need to, check out the documentation, look at the cron file, and it's going to show you the types of settings that you can use and the functionality that is supported. So, finally, let's go check out the firewall. This is going to allow us to allow or deny incoming connections from specific IP addresses. Rules have a priority number, an action, an IP address range, and description. And this is the default rule, which we're gonna change to deny. We're gonna say we want basically no one to connect to this app. So in theory, we shouldn't be able to view the running app in production. And browsing to the main URL. And great, it results in a 403 as expected. That's about it, you can allow and deny traffic from IP addresses and ranges.
Alright, with that complete, let's wrap up and see how we did. App Engine allows traffic to be split between two or more versions of a service by setting the desired traffic allocation and a split by method. Traffic migration is similar in that it changes the routing of traffic, however, it performs an immediate switch to the specified version. It's done by selecting the version to migrate to and clicking migrate traffic. To create a cron job we need to create a cron file, which is either xml or yaml based on the runtime. And the way we specify jobs is by providing a URL for which App Engine will send a get request to based on our schedule. To create a firewall rule, you can specify an IP address range, an action, a priority, and Google will do the rest.
Alright, with that let's wrap up here. Thank you so much for watching and I'll 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.