Now that you have a good idea of what services are available in GCP, let’s see how we can put them together to create a more complex solution. Google provides lots of sample architectures in this slide deck. It includes examples for solutions like a mobile game backend and an Internet of Things ingestion and processing system.

Let’s have a look at a more typical solution. One of the most common things people need to set up on GCP is a website. There are many different ways to do this. I already showed you a simple example using App Engine, although I should mention that App Engine is typically used for much more complex applications.

If you only need to set up a static website (that is, one that doesn’t have any server-side code), then believe it or not, you don’t even need to use any sort of compute service. You can just upload your website to Cloud Storage and point the DNS record for your website to it. You don’t even need to use Google’s Cloud DNS service to make this work. If your website domain is already registered with another domain registrar, then you can just update your website’s DNS record there.

Okay, so now you know a couple of really simple ways to create a website on GCP, but what if you need to do something more complicated? This article on Google’s site has a more complex example that uses Compute Engine. There are a lot of services in this diagram, so let’s start from scratch and work our way up to the full architecture.

At the heart of the solution is Compute Engine. Why would you choose this instead of App Engine considering that it takes more work to set up and maintain it? Well, the main reason is that Compute Engine gives you complete flexibility, whereas App Engine has more constraints. For example, suppose you have a web application that runs on Windows. You couldn’t host your application on App Engine because it only supports Linux. That’s not the only reason for choosing Compute Engine. There are many custom Linux configurations that won’t work on App Engine either.

To make sure your app stays up even if one of the zones fails, you’ll want to distribute your instances across multiple zones. If you’re expecting a lot of traffic on your website, then you’ll also want to set up autoscaling so it will add more instances as traffic increases. The way to handle both of these requirements is to put a Global Load Balancer in front of your instances.

Another aspect of making sure your app stays up is to make sure it can deal with Distributed Denial of Service attacks. Fortunately, you can just add Cloud Armor to mitigate DDoS attacks.

Next, you need to put the website’s static files somewhere. This includes things like HTML pages and images. All of the Compute Engine instances should get these static files from the same place, and the logical place to put them is Cloud Storage.

To speed up response time when serving static files, you can cache them in Cloud Content Delivery Network. That way, when a user requests a static file that has been requested by another user recently, they’ll retrieve it from the cache instead of waiting for a Compute Engine instance to retrieve it from Cloud Storage.

That takes care of the web front-end, but now you need to set up the backend. That is, you need to set up the part of the application that handles dynamic content and stores new data. Although you could put the backend on the same instances that serve the front-end, it’s usually better to host it on separate instances, especially for high-traffic applications.

These backend app server instances should also be distributed across zones and configured for autoscaling. However, since these instances will be communicating with the front-end instances rather than with end-users, you need to use an Internal Load Balancer.

The App Server instances also need a central place for their data, but since they’ll deal with dynamic data, Cloud Storage is not the right place for it. There are a few options depending on what type of data you need to store and retrieve. The most commonly used service is probably Cloud SQL because it can handle transaction processing.

Although you could probably use Cloud SQL for all of your backend database needs, you might want to use a NoSQL database to handle some of the simpler types of data that need to be accessed more frequently. Firestore is a NoSQL database, so it’s faster and more scalable than Cloud SQL, but it can only work with certain types of data, such as user profiles and product catalogs.

Finally, you can use Google’s Cloud DNS service to help users find your website, but as I mentioned earlier, it’s not a requirement. If you’re already using a third-party DNS service, you can keep using it. 

There are, of course, lots of other services you could add to this architecture, too. One important consideration is how to manage your application once it’s running. That’ll be the focus of the next video, so if you’re ready, then I’ll see you there.