Google Cloud Architecture Framework : System design

This is the second article in my seven-part series on the Google Cloud Architecture Framework.

Article 1: Google Cloud Architecture Framework Overview

The Google Cloud Architecture Framework’s foundational category is System design. In order to assist you in defining the architecture, components, modules, interfaces, and data on a cloud platform that meet your system requirements, this category offers design recommendations as well as best practices and principles. Additionally, you gain knowledge of system design-supporting Google Cloud features and products.

Core principles of system design

Robust system designs are independent, scalable, secure, and reliable. It helps you reduce possible hazards, increase operational efficiency, and make incremental, reversible changes without upsetting the system. In order to attain a robust system architecture, GCP recommends adhering to four fundamental principles.

A. Document everything
When it comes to accurately visualising the architecture of your current deployments, documentation is very crucial. Cross-functional teams can interact and communicate more successfully when there is a single language and set of standards established by a well specified cloud architecture.

B. Simplify your design and use fully managed services
In system design, simplicity is essential. It will be challenging to implement the design and maintain it over time if your architecture is too complicated to comprehend. Utilise fully managed services whenever possible to reduce the risks, time, and work involved in running and maintaining baseline systems.

C. Decouple your architecture
The process of breaking down your applications and service components into more manageable, standalone components is known as decoupling. For instance, you can divide a monolithic application stack into distinct service components.

D. Use a stateless architecture
Stateless applications can perform tasks without significant local dependencies by using shared storage or cached services. Your applications may scale up quickly with minimal boot dependencies thanks to a stateless architecture. The apps have less downtime, can survive forceful restarts, and provide end users improved performance.

Choose Google Cloud deployment archetypes

This document describes six deployment archetypes zonal, regional, multi-regional, global, hybrid, and multi-cloud. That you can use choose from to build architectures for your cloud workloads based your requirements for availability, cost, performance, and operational efficiency.

A deployment archetype is an abstract, provider-independent model that you use as the foundation to build application-specific deployment architectures that meet your business and technical requirements.
Basic archetypes: zonal, regional, multi-regional and global.
Composite archetypes : hybrid and multi-cloud

You must weigh the pros and disadvantages of several criteria, including cost, operational complexity, and availability, before selecting a deployment archetype for an application. You might select the multi-regional deployment archetype, for instance, if an application needs high availability and serves consumers in several nations. However, if it’s an internal application utilised by staff members in a specific area, you may decide to go with the regional deployment pattern because it’s more affordable than availability.

Zonal Deployment:
Applications that can rely on resources within a particular data centre (zone) and don’t require high availability across several geographic locations are a good fit for zonal deployments.
Examples include facilities for testing and development or apps with a small geographic user base.

Regional Deployment:
By allocating resources among several zones within a single region, regional deployments provide improved availability. It works well for applications that need improved fault tolerance and redundancy within a certain geographic area.
A good example would be websites that cater to people in a certain nation or area, where high availability is essential.

Multi-Regional Deployment:
Applications requiring high availability and worldwide distribution are intended for multi-regional deployments. Resources are dispersed over several zones, enabling disaster recovery and failover over a wider geographical area.
For instance, internationally dispersed web apps, content delivery networks (CDNs), or services that need redundancy across continents.

Global Deployment:
Applications requiring high availability across several continents and low latency access globally are well suited for global deployments. Because resources are dispersed internationally, end users experience the least amount of lag.
Examples include social networking platforms and international e-commerce websites, which are highly spread apps with a global user base.

Hybrid and Multi-cloud Deployment:
These are combination of basic archetypes. Useful if certain parts of your application are deployed in Google Cloud, while other parts run on-premises OR on in other cloud platforms.

Select geographic zones and regions

This document in the Google Cloud Architecture Framework provides best practices to deploy your system based on geographic requirements. You learn how to select optimal geographic zones and regions based on availability and proximity, to support compliance, optimize costs, and implement load balancing.

You take into account factors including service availability, end-user latency, application latency, cost, and regulatory or sustainability requirements when choosing a region or multiple regions for your business applications. Find the best trade-offs by balancing these criteria to support your business aims and policies. The place with the lowest carbon footprint or the highest cost-effectiveness may not always be the most compliant.

Key points to consider while selecting geographic zones and regions:

Manage cloud resources

This document in the Google Cloud Architecture Framework provides best practices to organise and manage your resources in Google Cloud.

Key points to consider while managing cloud resources:

Choose and manage compute

This document provides best practices to deploy your system based on compute requirements. You learn how to choose a compute platform and a migration approach, design and scale workloads, and manage operations and VM migrations.

Many workloads revolve around computing, whether it is applying intricate computational algorithms to datasets or carrying out unique business logic. In one way or another, compute resources are used in most solutions, so choosing the appropriate compute resources is crucial for your application’s requirements.
There are various choices available to Google Cloud for managing compute. Options vary depending on CPU kinds, performance, and usage pricing along with how your code is scheduled to run.

1. Virtual machines (VM) with live migration and other cloud-specific features.
2. Containers are bin-packed on cluster machines with CPU sharing capabilities.
3. Functions and server-less techniques, which let you limit how much CPU time you consume to the amount of work completed in a single HTTP request.

This is a very useful article to help one select a Google Cloud compute option.

Select and implement a storage strategy

This document provides best practices to deploy your system based on storage. You learn how to select a storage strategy and how to manage storage, access patterns, and workloads.

Organisations must select a storage strategy based on workload, input/output operations per second (IOPS), latency, retrieval frequency, location, capacity, and format (block, file, and object) in order to enable data interchange and safely backup and store data.

Key points to consider while deciding the Storage type:

1. Choose a storage strategy:
   – Choose active or archival storage based on storage access needs.
   – Use Cloud CDN to improve static object delivery.
   – Evaluate storage location and data protection needs for Cloud Storage.
2. Storage access pattern and workload type:
   – Use Persistent Disk to support high-performance storage access.
   – Use exponential back-off when implementing retry logic.
3. Storage management:
   – Assign unique names to every bucket.
   – Keep Cloud Storage buckets private.
   – Assign random object names to distribute load evenly.
   – Use public access prevention.

This is a very useful article to help one select a Google Cloud storage option.

Organisations must select a storage strategy based on workload, input/output operations per second (IOPS), latency, retrieval frequency, location, capacity, and format (block, file, and object) in order to enable data interchange and safely backup and store data.

Optimise your database

This document provides best practices to deploy your system based on database design. You learn how to design, migrate, and scale databases, encrypt database information, manage licensing, and monitor your database for events.

Key points to consider while deciding the Database type:

1. Consider using a managed database service.
2. Encryption:
   – Determine encryption requirements.
   – Choose an encryption key strategy.
3. Database design and scaling:
   – Use monitoring metrics to assess scaling needs.
   – Automation and right-sizing.

This is a very useful article to help one select a Google Cloud Database option.

Analyze your data

This document explains some of the core principles and best practices for data analytics in Google Cloud. You learn about some of the key data-analytics services, and how they can help at the various stages of the data lifecycle. These best practices help you to meet your data analytics needs and create your system design.

Companies want to analyse data and draw conclusions from it that are useful. You may get assistance from Google Cloud with a range of services that cover the whole data life-cycle, from data ingestion to reports and visualisation. While some of these services are server-less, the majority are fully managed. Your choice of Google Cloud services to serve your data analytics needs is influenced by your specific focus, team expertise, and strategic view.

Data lifecycle:

You have the option to organise the Google Cloud data analytics services according to the data life-cycle or the general data migration within any system when designing your system. The following phases and sample services are part of the data lifecycle:

1. Ingestion includes services such as Pub/Sub, Storage Transfer Service, Transfer Appliance, and BigQuery.
2. Storage includes services such as Cloud Storage, Bigtable, Memorystore, and BigQuery.
3. Processing and transformation includes services such as Dataflow, Dataproc, Dataprep, Sensitive Data Protection, and BigQuery.
4. Analysis and warehousing includes services such as BigQuery.
5. Reporting and visualisation includes services such as Looker Studio and Looker.

Building reliable, scalable, and effective solutions on Google Cloud Platform requires careful consideration of system design. System design is foundational to building successful applications on GCP. It gives you the ability to fully utilise GCP’s services to develop scalable, dependable, secure, and reasonably priced solutions that are customised to your unique business requirements.

This was the second article in my seven-part series on the Google Cloud Architecture Framework. We will go into more detail about the remaining 5 pillars in my upcoming articles, along with an understanding of some best practices for creating and managing a well-architected framework on GCP.

Thank you for reading this article. Your time is appreciated.
Until next time, stay curious !!