Google Cloud Overview
GCP is organized into Projects. Projects may belong to some Organization or not.
Different Projects may be used for Testing and Production. Projects have separation of data. If we store data within the same Project (e.g. Firestore), this data is hosted in the same space (instance?).
GCP Projects are a little bit like Resource Groups on Azure.
The command is
gcloud. After the installation, we should run
gcloud init to
Google Cloud Storage uses the
gcloud config allows us to manage the config of the CLI.
Cloud Shell is available from the Web Console interface. Highlights:
- has preinstalled SDKs (e.g. dotnet)
- allows setting up a web server on some port and accessing it from the outside
It’s a GCP’s version of Azure’s App Service.
A single GCP project may have only one App Engine Application. However, an Application may have multiple Services, where each service is a different app (very intuitive (not)).
A Service may have multiple versions, all of them running parallelly. The traffic may be managed for specific versions (e.g., canary deployment). For example, feature braches could be deployed as separate versions of a service.
Each version is scalable horizontally.
Each service version can be reached independently:
Support for .NET seems to be really bad. The provided examples are for .NET Core 2.1. The best option for .NET apps seems to be the “custom” runtime, which is basically containers.
Any app running on App Engine requires the
app.yaml file. Here’s an example of
it for the “custom” runtime:
Here’s a full ASP.NET Core Web API project example: GitHub.
The app can be deployed with
gcloud app deploy app.yaml
We can deploy managed SQL databases:
- Microsoft SQL Server
Service Accounts are identities for applications that need to access GCP. We can managed their access via roles.
In some cases, GCP creates Service Accounts in the background for us. For example, App Engine has its own default Service Account. We can manage it.
Service Accounts are assignable to:
- users - a given user can act as this Service Account
- GCP resources - it works like Managed Identity on Azure
Google Cloud Storage stores files (Objects) in Buckets. Similarly to Azure Storage, we can select a tier (here called Storage Class):
- Standard - cheap retreival, expensive storage
- Archive - cheap storage, expensive retrieval
Access may be managed on the Bucket level, or individually for each Object.
Signed URLs is something similar to Azure Storage SAS Tokens. It allows to generate temporary URLs to read/write Objects.
There’s also a way to manage Objects’ lifetime, similarly to Azure Blog Storage. Objects may change tier after some configured timespan.
It’s similar to Azure Service Bus, or Azure Storage Queue. Cloud Tasks are specifically targetted to be used by App Engine apps.
It’s a CRON-like service that does something on schedule:
- triggers App Engine
- sends pub/sub messages
- invokes some HTTP endpoint
It works like App Insights in Azure.
We can easily write to a log using the CLI:
Structured logging is also supported.
App Engine (and other services, such as Functions) are connected to Cloud Logging, so stdout/stderr goes there automatically.
It’s a web interface that allows us to debug our code. We can see callstack and variables live as the app is being executed in GCP.
I saw how it works with interpreted language such as JS. What about compiled languages such as .NET? Debugger gives us a way to upload the source code, so potentially it is able to synchronize the deployed binary with the source code?
We can even add logs to the running code.
It collects some statistics about our apps (most frequent URLs, latency, etc.). We can also see detailed information about network activity of our apps, similarly to how Azure App Insights displays it. We can see consecutive network calls being executed by our apps.