Post

GCP - Google Cloud Platform Fundamentals - Core Infrastructure


GCP Google Cloud Platform Fundamentals - Core Infrastructure

Screen Shot 2022-08-14 at 23.40.12

Screen Shot 2022-08-28 at 16.36.07


overview

Google

Screen Shot 2021-06-21 at 20.48.32

GCP offers four main kinds of services:

  • compute, storage, big data and machine learning.

Screen Shot 2021-06-21 at 20.50.06

Screenshot 2024-08-07 at 09.45.07


IaaS vs PaaS vs Serverless vs SaaS

  • Infrastructure as a service (IaaS)
    • delivers on-demand infrastructure resources such as compute, storage, and network capabilities, organized virtually into resources similar to physical data centers.
    • Compute Engine
  • Platform as a service (PaaS)
    • offerings bind code to libraries that provide access to the infrastructure application needs.
    • This allows more resources to be focused on application logic.
    • App Engine
  • Serverless
    • further eliminate the need for infrastructure management by allowing developers to concentrate on their code.
    • Cloud Functions and Cloud Run,
  • Software as a Service (SaaS)
    • provides the entire application stack as a cloud-based service that customers can access and use over the internet.
    • Gmail, Docs, and Drive in Google Workspace.

Screen Shot 2021-02-12 at 13.25.46

Screen Shot 2021-02-03 at 14.34.02

Screen Shot 2021-02-09 at 23.26.11

Screen Shot 2021-06-27 at 1.20.06 AM


security

Screen Shot 2021-02-03 at 15.07.14

The security infrastructure of Google Cloud and Google services is designed with multiple layers of protection.

Screenshot 2024-08-07 at 10.06.28

  • The Hardware infrastructure layer

    • custom-designed server boards and networking equipment.

    • Google uses a secure boot stack to ensure that server machines are booting the correct software stack.

    • Premises security is implemented in Google’s data centers, with limited access for Google employees.

Screenshot 2024-08-07 at 10.06.57

  • The Service deployment layer focuses on encryption of inter-service communication.

Screenshot 2024-08-07 at 10.07.24

  • Google’s central identity service
    • goes beyond username and password, employing additional risk-based challenges and secondary factors for user authentication.
    • The service also intelligently challenges users for additional information based on risk factors such as whether they have logged in from the same device or a similar location in the past.
    • Users can also employ secondary factors when signing in, including devices based on the Universal 2nd Factor (U2F) open standard.

Screenshot 2024-08-07 at 10.08.22

  • Encryption at rest
    • applied to storage services, with centrally managed keys and hardware encryption support.

Screenshot 2024-08-07 at 10.09.12

  • The Internet communication layer
    • Google services that are being made available on the internet, register themselves with an infrastructure service called the Google Front End,
      • ensures that all TLS connections are ended using a public-private key pair and an X.509 certificate from a Certified Authority (CA),
      • following best practices such as supporting perfect forward secrecy.
    • The GFE additionally applies protections against Denial of Service attacks.

Screenshot 2024-08-07 at 10.11.34

  • Google’s Operational security layer
    • includes intrusion detection, insider risk reduction, employee U2F use, and stringent software development practices.
    • Google also runs a Vulnerability Rewards Program to incentivize bug discovery in their infrastructure and applications.

pricing

Screen Shot 2021-02-03 at 14.54.20

Screen Shot 2021-02-10 at 21.55.59

Screen Shot 2021-02-10 at 21.58.00

Quota:

Screenshot 2024-08-07 at 10.15.06


The Google Cloud network

global -> multi region -> region -> zone

caching nodes:

  • Google Cloud has more than 100 content caching nodes worldwide, which cache high demand content for quicker access.

  • These caching nodes allow applications to respond to user requests from the location that will provide the quickest response time.

Geographic locations:

  • Google Cloud’s infrastructure is based in five major geographic locations: North America, South America, Europe, Asia, and Australia.

Screen Shot 2022-08-15 at 00.36.25

  • Each location is divided into several different regions and zones.

    • Google Cloud currently supports 121 zones in 40 regions, with the number increasing over time.

    • Screenshot 2024-08-07 at 09.59.45

    • Screen Shot 2021-02-03 at 14.52.03

  • Regions represent independent geographic areas and are composed of zones.

    • Screenshot 2024-08-07 at 10.00.05
  • Zones are areas where Google Cloud resources are deployed.

  • Running resources in different regions and Zones is useful for bringing applications closer to users around the world and for protection in case of issues with an entire region.

    • Some of Google Cloud’s services support placing resources in a multi-region, which allows for replication of data in multiple zones across multiple regions.

    • Screenshot 2024-08-07 at 10.00.49

    • Screenshot 2024-08-07 at 10.00.31

Deploying applications across multiple zones

  • enables fault tolerance and high availability
  • network latencies generally less than 1 millisecond
    • zone and region

The network interconnects with the public Internet and more than 90 Internet exchanges and more than 100 points of presence worldwide.

edge network location

  • When an Internet user sends traffic to a Google resource,
  • Google responds to the user’s request from an edge network location that will provide the lowest latency or delay.
  • Google’s edge casting network places the content close to users to minimize that latency

Screen Shot 2021-02-10 at 21.40.56


Environmental impact

  • Google’s data centers were the first to achieve ISO 14001 certification, which focuses on enhancing environmental performance and resource efficiency.

  • The data center in Hamina, Finland is one of the most advanced and efficient in Google’s fleet.

  • Google aims to operate completely carbon-free by 2030.


Interact with Google Cloud

Screenshot 2024-08-07 at 10.42.12

Screen Shot 2021-02-03 at 15.29.56

4 ways to interact with Google Cloud

  • Google Cloud Console
    • web user interface
    • Screen Shot 2021-02-10 at 22.01.19
  • Cloud SDK and Cloud Shell
    • command-line interface
      • gcloud: Compute Engine, Google Kubernetes Engine (GKE) and many Google Cloud services
      • gsutil: Cloud Storage
      • kubectl: GKE and Kubernetes
      • bq: BigQuery
    • Cloud Shell
      • command-line access to cloud resources directly from browser.
        • Web preview functionality
      • Cloud SDK command-line tools always available, up to date, and fully authenticated.
        • Preinstalled Cloud SDK and other tools
      • ephemeral compute engine virtual machine instance
      • built-in authorization for access to Cloud Console project and resource
      • Temporary Compute Engine VM
        • 5 GB of persistent disk storage ($HOME dir)
      • Language support for Java, Go, Python, Node.js, PHP, and Ruby
    • After 1 hour of inactivity, the Cloud Shell instance is recycled.
      • Only the /home directory persists.
      • Any changes made to the system configuration, including environment variables, are lost between sessions.
  • Cloud Console mobile app
    • For iOS and Android
  • REST-based API
    • for custom application

creating environment variables is a good practice. You can easily and consistently re-use these environment variables, which makes your work less error-prone.


Open APIs

Screen Shot 2021-02-03 at 14.55.17


Cloud Marketplace (formerly Cloud Launcher)


API

Screen Shot 2021-02-09 at 00.38.36

Application Programming Interfaces, APIs

  • A software services implementation can be complex and changeable.
  • to use that service
    • instead other pieces of software had to know internal details about how they worked
    • application developers structure the software, so that it presents a clean, well-defined interface that abstracts away needless details and then they document that interface.
    • That’s an API.
  • The underlying implementation can change as long as the interface doesn’t
    • and other pieces of software that use the API don’t have to know or care.
    • to change an API (add or deprecate a feature)
      • version the APIs.
        • To make the API change cleanly
        • API v2 might contain calls that v1 does not.
      • Programs that consume the API can specify the API version that they want to use in their calls.
  • Supporting API, Google Cloud platform provides two API management tools.
    • Cloud Endpoints
    • Apigee Edge

Cloud Endpoints

  • Suppose
    • you’re developing a software service and one of GCP’s backends.
    • to make it easy to expose this API.
    • an easy way to monitor and log its use.
  • to create and maintain APIs
    • an easy to deploy proxy in front of the software service
  • Distributed API management through an API console
    • provides an API console
    • implements those capabilities in an easy-to-manage interface.
  • expose the API using a RESTful interface

  • supports applications running in GCP's compute platforms

    in the languages and the client technologies.

    • Runtime environment
      • App Engine Flexible environment
      • Kubernetes Engine
      • Compute Engine
    • Clients
      • Android
      • iOS
      • Javascript
  • control access and validate calls with JSON Web Tokens and Google API keys
    • identify web, mobile users with Auth0 and Firebase Authentication
    • to make sure it’s only consumed by other developers whom you trust.
    • for the API to have a single coherent way for it to know which end user is making the call.
  • generate client libraries

Apigee Edge

  • a platform
    • for developing and managing API proxies.
    • for making APIs available to the customers and partners
  • It has a different orientation though.
  • Contains analytics, monetization, and a developer portal
  • focus on business problems
    • like rate limiting, quotas, and analytics.
  • Many users of Apigee Edge are providing a software service to other companies

    and those features come in handy.

    • do business analytics and billing on a customer-facing API
  • Because of the backend services for Apigee Edge need not be in GCP
    • engineers often use it when they are “taking apart” a legacy application.
    • Instead of replacing a monolithic application in one risky move
      • they use Apigee Edge to peel off its services one by one,
      • standing up microservices to implement each in turn,
      • until the legacy application can be finally retired.

.

This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.