Design decision trade-offs
In this we will learn about Design decision trade-offs.
Geographic zones and regions
Regions are independent geographic areas that consist of multiple zones. A zone is a deployment area for Google Cloud resources within a region. Zones should be considered a single failure domain within a region. However, to deploy fault-tolerant applications with high availability, you deploy your applications across multiple zones in a single region, or in multiple zones in different regions. This is to help protect against expected and unexpected downtimes.
Google Cloud services and resources can be zonal, regional, managed by Google across multiple regions, or global:
Zonal resources
Zonal resources operate within a single zone. If a zone becomes unavailable, all resources in that zone are unavailable until the service is restored.
Regional resources
Regional resources are redundantly deployed across all the zones within a region. However, tThis gives them higher availability than zonal resources.
Multi-regional resources
Google services are redundant and distributed within and across regions. However, these services optimize availability, performance, and resource efficiency. As a result, they require tradeoffs between latency and consistency.
Identity and access management
Identity and access management is a cornerstone of your Google Cloud deployment because it provides the authorization controls to Google Cloud resources. However, using IAM, you manage employee, customer, and other identities and their respective access authorizations. Further, Google Cloud provides you with a set of enterprise-ready IAM services to help you secure access to your data and simplify management through intelligence
In IAM, you grant access to members. Members can be of the following types.
- Firstly, Google account
- Secondly, Service account
- Thirdly, Google group
- Then, Google Workspace domain
- Lastly, Cloud Identity domain
Authorization
When an authenticated member attempts to access a resource, IAM checks the resource’s IAM policy to determine whether the action is allowed.
Resources
You can grant access to users for a Google Cloud resource. Some examples of resources are projects, Compute Engine instances, Cloud Storage buckets, and so on. However, some services, such as Compute Engine and Cloud Storage, support granting IAM permissions at a granularity finer than the project level.
Permissions
Permissions determine what operations have access on a resource. In the IAM world, permissions are represented in the form of service.resource.verb. Here, you don’t assign permissions to users directly. Instead, you assign them a role that contains one or more permissions.
Roles
A role is a collection of permissions. However, when you grant a role to a user, you grant them all the permissions that the role contains. There are three kinds of roles in IAM:
- Firstly, Basic roles. Owner, Editor, and Viewer.
- Secondly, Predefined roles. Predefined roles are IAM roles that give finer-grained access control than basic roles.
- Lastly, Custom roles. Roles that you create to tailor permissions to the needs of your organization when predefined roles don’t meet your needs.
Compute
Most solutions use compute resources in some form, and the selection of compute for your application needs is critical. On Google Cloud, compute refers to Compute Engine, App Engine, Google Kubernetes Engine (GKE), Cloud Functions, and Cloud Run. However, compute Engine provides graphics processing units (GPUs) that you can add to your virtual machine instances.
Generally, App Engine is a great candidate for hosting frontend applications because it lets you focus on application development rather than maintaining infrastructure operation. Further, App Engine also supports container deployment, allowing for easier and quicker migration. App Engine can support hosting microservice architectures with multiple services.
Key services
- Firstly, compute Engine delivers virtual machines running in Google’s innovative data centers and worldwide fiber network. Compute Engine’s tooling enables scaling from single instances to global, load-balanced infrastructure. Moreover, compute Engine VMs boot quickly, come with high-performance persistent and local disk options, and deliver consistent performance.
- Secondly, Google Kubernetes Engine provides a powerful cluster manager and orchestration system for running your Docker containers. GKE schedules your containers into the cluster, keeps them healthy, and manages them automatically based on requirements you define (such as CPU and memory). GKE is based on Kubernetes, the open-source container orchestration system. Further, using a platform based on open source provides you with the flexibility to deploy your containers on GKE, on-premises, or in another public cloud infrastructure.
- Thirdly, App Engine is a platform for building scalable web applications and mobile and IoT backends. App Engine provides you with built-in services and APIs, such as NoSQL datastores, memcache, and a user authentication API, common to most applications.
- Then, Cloud Functions is a serverless execution environment for building and connecting cloud services. With Cloud Functions, you write simple, single-purpose functions that are attached to events emitted from your cloud infrastructure and services.
- Lastly, Cloud Run is a managed compute platform that enables you to run stateless containers that are invocable through web requests or Pub/Sub events. However, Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most—building great applications.
Reference: Google Documentation