Examining Technical Processes for GCP

In your role as an architect, you'll be involved in numerous technical procedures, some of which were covered in earlier chapters, like continuous integration/continuous delivery (CI/CD) and post-mortem analysis. This chapter will delve deeper into these and other processes like software development lifecycle management, testing and validation, and business continuity and disaster recovery planning. Our aim is to present a comprehensive understanding of these technical processes, with an emphasis on their connection to business goals. For a more technical exploration, including the use of tools like Jenkins in CI/CD, please refer to the subsequent discussions.

Analyzing Technical Processes for GCP

Architects are involved in many different types of technical processes:

• Continuos Deployment
• Continuous Delivery
• Post-mortem Analysis
• Development Lifecycle Planning
• Testing
• Validation
• Business continuity
• Disaster Recovery(DR)

Architecting for Reliability

A reliable system is one people can get to now. Reliability is the probability a system can be reached and used without failure and Availability is a measure of how available a system is to be used within a given period of time.

Cloud Operations Suite

Architecting GCP Solutions for Security and Legal Compliance

Identity and Access Management

Identity and Access Management or IAM is a service which lets you specify which users can perform which actions in the cloud. IAM includes the following objects:

• Identities and Groups
• Resources
• Permissions
• Roles
• Policies

Architecting GCP Network Solutions

OSI Model Layers

1. Physical, the actual metal, wires, electrons and plastic ethernet plugs. You'll find wifi's radio frequency here because radio is physical phenomenon. In Quantum networking this layer are the entangled particles and the equipment uses to read and write to them plus the equipment used to connect to that. Voltage is sometimes the physical layer in Ethernet Over Power. With tin cans on a string, this layer is the cans, string and the vocal vibrations traveling through them.
2. Data Link, ARP, Mac Addresses, Collision avoidance. This is broken into two mini-layers, the first is media access control(MAC) and the second is Logical Link Control(LLC). The second acts as a negotiator between the MAC layer and the third 'Network' layer.
3. Network, this is where IP Addresses live. Keep in mind these network layers are the layers of a packet sent over the network. This is the base layer for packets. A packet is data encapsulated in a route with source and destination addresses.
4. Transport. The protocol that makes this process work known by all networking devices speak is Transmission Control Protocol(TCP) or User Datagram Protocol(UDP). The Protocol identifier stored in a packet lives in this layer.
5. Session, this layer manages handshakes. An SMTP connection timeout would exist on this layer. TLS handshakes happen here. An https packet is fully encrypted, so a request to a server asking for a url cannot be understood unless it is decrypted, then it can be seen. Inside layer 4 lives an encrypted layer 5 envelope in the case oF HTTPS connections. Layer 5 is the encrypted data, while layer 6 is the decrypted data.
6. Presentation, A GET / request is in this layer. Mappings of network resources to application resources in the OS kernel happen at layer 6.
7. Application, This is the later applications connect to in order to do networking. A webbrowser fetches web pages from this layer. This layer one might consider a data format. A TXT file vs a Json file. Mime types exist at this Layer. Layer 7 in the packet is the raw data unenveloped by network dressing that tells the network about it.

Architecting Storage Solutions in Google Cloud Storage

Object Storage

Object Storage is common to all cloud systems and has its roots way back in 2006 with Amazon S3 and Rackspace Files/OpenStack Swift and Google Cloud Storage in 2010. These systems are for storing files or documents as objects as opposed to a directory filesystem. Instead of hierarchical the particulate nature of object storage treats everything atomically. You can't seek and read parts of the file, you can't tail off of object storage. You can get, put, delete objects. Their organization depends on the system.

Architecting Compute Engine Solutions in GCP

Compute Engine Services

Each of these services have different use cases. You'll have to know how to select the right one for your requirements.

Service	Use Case	Fancy Buzzword
Compute Engine	If you need root access and are running multiple processes in the same operating system instance.	Infrastructure as a Service (IaaS)
App Engine	You need to run a nodeJS, Java, Ruby, C#, Go, Python or PHP application quickly with no configuration or management.	Platform as a service (PaaS)
Cloud Functions	You need to run a serverless routine.	Executions as a Service (EaaS)
Cloud Run	Run individual containers.	PaaS
Kubernetes Engine	Run several docker containers in group.	Containers as a Service (CaaS)
Anthos	Run containers in a hybrid or multi-cloud environment.	Hybrid CaaS

List of Site Reliability Engineering Practices

Penetration Testing

Container or virtual machine policy enforcement

Binary Authorization

Official Resources

• Load Balancing and Autoscaling Compute Engine
• Cluster Autoscaling Kubernetes Engine
• The Official Google Certified Professional Cloud Architect Exam
  Guide
• Exam FAQ
• Sample Questions
• GCP Documentation

Desiging Solutions for Technical Requirements

High Availability

High availability is a key characteristic of any reliable system, and is typically measured by what is known as the "99999" rule. This rule states that a system must be operational 99.9999% of the time in order to be considered highly available. This equates to a maximum downtime of just over 5 minutes per year. In order to achieve such a high level of availability, a system must be designed and implemented with care, and must be constantly monitored and maintained. Additionally, a high availability system must have a robust service-level agreement (SLA) in place in order to ensure that the system meets the required availability levels.

Designing and Planning GCP Solutions for Business Requirements

Key Considerations

• Business Use Case & Product Strategy
• Cost Optimization
• Dovetail with Application Design
• Integration with External Systems
• Movement of Data
• Security
• Measuring Success
• Compliance and Observability