associate-cloud-engineer.md

Setting up a cloud solution environment

Example: Cymbal superstore

• Cymbal Superstore plans to migrate three applications to the cloud: its supply chain application, which will run on VMs; its containerized ecommerce application, which will use GKE; and its transportation management application, which will use Cloud Functions to track truck location.

• There are multiple projects under the B2B supply chain app folder, one for each environment related to continuous integration/continuous delivery: a development, staging, and production environment.

• Setting up the cloud environment also involves granting members IAM roles to ensure they have the right access to projects depending on their needs of their job and role at Cymbal Superstore.

• Google Cloud Observability provides metrics and logging services for all your services, resources, and projects in your cloud architecture.

Planning and configuring a cloud solution

1. Cymbal Superstore’s ecommerce application is currently implemented with containers, so you decide to use Google Kubernetes Engine (GKE) for compute.

   • For storage, you select Spanner to house Cymbal Superstore's ecommerce data because it allows for global availability and low latency.

   • Seeing as the ecommerce system is a web-based application, you will need an external http(s) load balancer. With GKE, you can do this by implementing an ingress object with a “gce” ingress class.

2. Logistics’ transportation management system currently uses an on-premise message broker. Together with the cloud architect, you choose Pub/Sub as a solution to collect sensor data from trucks for analysis in the cloud.

   • You will use Cloud Functions to pull data from Pub/Sub and start a Dataflow pipeline.

   • Dataflow will feed data into Bigtable to store your sensor data.

   • You can run federated queries in BigQuery to visualize your data in Looker.

3. Cymbal Superstore’s existing supply chain application is implemented using virtual machines with a Linux operating system and a common Linux, Apache, MySql and PHP (LAMP) development stack.

   • After analyzing this application’s needs, the cloud architect determines that the recommended cloud solution is to migrate this application to Compute Engine virtual instances.

   • The data solution uses a Cloud SQL instance configured with a MySQL database.

   • The recommended network access would be external https access to the region for partners and internal connectivity between the application and the backing database service.

imp notes

Deploying and implementing a Cloud solution

Ensuring successful operation of cloud solution

To implement network load balancing you create a service object with these settings:

• type: LoadBalancer.
• Set External Traffic Policy to cluster or local

Cluster - traffic will be load balanced to any healthy GKE node and then kube-proxy will send it to a node with the pod.

Local - nodes without the pod will be reported as unhealthy. Traffic will only be sent to nodes with the pod. Traffic will be sent directly to pod with source ip header info included.

To implement external http(s) load balancing create an ingress object with the following settings:

• Routing depends on URL path, session affinity, and the balancing mode of backend Network endpoint groups (NEGS)
• The object type is ingress.
• Using ingress.class: “gce” annotation in the metadata deploys an external load balancer.
• External load balancer is deployed at Google Point

To implement an internal http(s) load balancer create an ingress object with the following settings:

• Routing depends on URL path, session affinity, and balancing mode of the backend NEGS.
• The object kind is ingress.
• Metadata requires an Ingress.class: “gce-internal” to spawn an internal load balancer.
• Proxies are deployed in a proxy only subnet in a specific region in your VPC.
• Only NEGs are supported. Use the following annotation in your service metadata:
• cloud.google.com/neg: '{"ingress": true}'
• Forwarding rule is assigned from the GKE node address range.

How does autoscaling work in Cloud Run? Cloud Run automatically scales the number of container instances required for each deployed revision. When no traffic is received, the deployment automatically scales to zero. Other ways you can affect Cloud Run autoscaling:

• CPU utilization, with a default 60% utilization.
• Concurrency settings, with a default of 80 concurrent requests. You can increase it to 1000. You can also lower it if you need to.
• Max number of instances limits total number of instances. It can help you control costs and limit connections to a backing service. Defaults to 1000. Quota increase required if you want more.
• Min number of instances keeps a certain number of instances up. You will incur cost even when no instances are handling requests

Configuring Access and security

• Service accounts are designed to provide permissions for machine-to machine or service-to-service communications in Google Cloud.