Cloud Functions, App Engine, Compute Engine, Kubernetes Engine Flashcards
Cloud Function Locations
Cloud Functions is regional
Redundantly available across all the zones within that region.
Select region based on:
1. Latency - close to users
2. Availability - based on location of other GCP services that are used by the app
You can deploy functions to different regions within a project, but once the region has been selected for a function it cannot be changed.
Functions in a given region in a given project must have unique (case insensitive) names, but functions across regions or across projects can share the same name.
Runtimes for Cloud functions
Cloud Functions can be written in Node.js, Python, and Go, and are executed in language-specific runtimes
Cloud function trigger mechanisms
Cloud Functions can be associated with a specific trigger. The trigger type determines how and when your function executes. Cloud Functions supports the following native trigger mechanisms:
HTTP Triggers Cloud Pub/Sub Triggers Cloud Storage Triggers Direct Triggers Cloud Firestore Analytics for Firebase Firebase Realtime Database Firebase Authentication
Cloud function timeout
Function execution time is limited by the timeout duration, which you can specify at function deployment time. By default, a function times out after 1 minute, but you can extend this period up to 9 minutes.
Cloud function pricing
Cloud Functions are priced according to how long your function runs, how many times it’s invoked and how many resources you provision for the function. If your function makes an outbound network request, there are also additional data transfer fees.
Billing interval is 100 milliseconds
Use cases for cloud functions
Microservices architecture
Horizontal scaling
App Engine components
An App Engine app is made up of a single application resource that consists of one or more services. Each service can be configured to use different runtimes and to operate with different performance settings. Within each service, you deploy versions of that service. Each version then runs within one or more instances, depending on how much traffic you configured it to handle.
The App Engine application is a top-level container that includes the service, version, and instance resources that make up your app. When you create your App Engine app, all your resources are created in the region that you choose, including your app code along with a collection of settings, credentials, and your app’s metadata.
Relationship between App Engine Components
Services can have multiple versions. Versions can have multiple instances
App Engine Security services
Access control
In each Cloud project, set up access control to determine who can access the services within the project, including App Engine. You can assign different roles to different accounts to ensure each account has only the permissions it needs to support your app.
App Engine firewall
The App Engine firewall enables you to control access to your App Engine app through a set of rules that can either allow or deny requests from the specified ranges of IP addresses. You are not billed for traffic or bandwidth that is blocked by the firewall.
Security Scanner
App Engine
App Engine is Google Cloud’s platform as a service (PaaS). App Engine is regional
Each GCP project can contain only a single App Engine application, and once created you cannot change the location of your App Engine application
App Engine Single zone failures
Standard environment applications are single-homed, meaning that all instances of the application live in a single availability zone. In the event of a failure in that zone, the application starts new instances in a different zone in the same region and the load balancer routes traffic to the new instances. You will see a latency spike due to loading requests and also a Memcache flush.
Flexible environment applications use Regional Managed Instance Groups, meaning that instances are distributed among multiple availability zones within a region. In the event of a single zone failure, the load balancer stops routing traffic to that zone. If you have set autoscaling to run your instances as hot as possible, then you will see a brief period of overload before autoscaling creates more instances.
Runtimes are provided by the App Engine Standard environment
Node, Java, Python, Go
App Engine Standard Environment
Instance startup time Seconds Maximum request timeout Depends on the runtime and type of scaling. Background processes No Scale to zero Yes Modifying the runtime No Deployment time Seconds Pricing Based on instance hours SSH Debugging No
App Engine Flexible Environment
Instance startup time Minues Maximum request timeout 60 seconds Background processes Yes Scale to zero No, minimum 1 instance Modifying the runtime Yes (through dockerfile) Deployment time Minues Pricing Based on usage of vCPU, memory, and persistent disks One minute minimum charge
Pricing of the App Engine Standard Environment
Free daily quota of compute, storage and requests
Applications are deployed on specific instance class and cost depends on instance class
Initial startup cost of 15 minutes for each instance
