Cloud Bigtable

GCP Cloud Bigtable  is a fully managed, scalable NoSQL database service targeted to service large analytical and operational workloads

 The most appropriate data use cases for Cloud Bigtable are next :

• Time-series data, such as CPU and memory usage over time for multiple servers.
• Marketing data, such as purchase histories and customer preferences.
• Financial data, such as transaction histories, stock prices, and currency exchange rates.
• Internet of Things data, such as usage reports from energy meters and home appliances.
• Graph data, such as information about how users are connected to one another.

Cloud Bigtable stores data in  massively scalable but sparsely populated tables.   Each table is a sorted key/value map.  These tables  can scale to billions of rows and thousands of columns, enabling the storing of terabytes or even petabytes of data.   A single value in each row is indexed – this value is known as the row key.     Cloud Bigtable is ideal for storing very large amounts of single-keyed data with very low latency.   It supports high read and write throughput at low latency, and it is an ideal data source for:

• MapReduce operations   
• stream processing/analytics   
• machine learning applications

Each row/column intersection can contain multiple cells, or versions, at different timestamps, providing a record of how the stored data has been altered over time.   Cloud Bigtable tables are sparse – if a cell does not contain any data, it does not take up any space.

Cloud Bigtable is  accessed by applications via multiple client libraries, including a supported extension to the  Apache HBase library for Java . Consequently, it integrates well  with the existing Apache ecosystem of open-source Big Data software.

Cloud Bigtable has a long history with GCP,  and is built on  proven infrastructure that powers a number of Google products,  including  Search & Maps.

The Microsoft equivalent of  GCP’s Cloud Bigtable is  the Azure Cosmos database,

The table below provides a review of specific uses cases/deployment configurations referenced  in the Google Cloud  ‘Architectural Framework & Solution Scenarios’ discussed on this website at  GCP-1 ; 

Cloud Datastore

GCP Cloud Datastore  is a highly scalable NoSQL  database.  Cloud Datastore automatically handles sharding and replication, delivering a  highly available and durable database that scales automatically to handle an application’s expanding load.   Despite being a NoSQL  database, Datastore provides a number of familiar capabilities, including; 

• ACID transactions,
• SQL-like queries,
• indexes

Cloud Datastore utilizes a RESTful interface.  Cloud Datastore can be used  as the integration point for solutions that span across App Engine and Compute Engine.

Given that Cloud Datastore is a schemaless database, less emphasis needs to be placed on managing the underlying data structure as an application evolves.   In addition, the query language is very simple. 

Datastore supports a variety of data types, including:

• integers
• floating-point numbers
• strings
• dates &
• binary data

The  supported programming languages include;

• .Net
• Go
• Java
• JavaScript (Node.js)PHP
• Python
• Ruby

Cloud Datastore users are being encouraged to migrate to Cloud Filestore, which became available on GCP in 2017.

The table below provides a review of specific uses cases/deployment configurations referenced  in the Google Cloud  ‘Architectural Framework & Solution Scenarios’ discussed on this website at  GCP-1 ; 

GCP Cloud Spanner

Cloud Spanner is a fully managed, mission-critical,  relational database service that offers transactional consistency at world-wide scale, and:

• schemas
• ACID transactions
• SQL compatibillity (ANSI 2011 with extensions), &
• automatic, synchronous replication for high availability

Traditionally, when  building cloud applications, dba’s & developers have been mandated to chose either ‘A’ or ‘B’:   

• traditional  relational databases that guarantee transactional  (ACID) consistency, or
• NoSQL databases that offer easy horizontal scaling and data distribution.

Cloud Spanner is very unique, because it offers both of these critical requirements in a single, integrated, fully managed service.  In addition, it functions as a  ‘Database as a Service (DBaaS)’ offering.  

Cloud Spanner keeps application development familiar to traditional  relational DBA’s, by supporting standard tools and languages common to the traditional relational database environment.   It’s an excellent solution for operational workloads supported by traditional relational databases, including;.

• inventory management
• financial transactions &
• e-commerce

Cloud Spanner supports:

• distributed transactions
• schemas and DDL statements
• SQL queries &
• JDBC drivers

Cloud Spanner provides client libraries for the most common languages, including:

• Java
• Go
• Python &
• Node.js.

Cloud Spanner provides key benefits to DBAs  already on the Cloud, or seeking to transition to the cloud, as follows;

• Allows DBA’s to focus on application logic, by effectively  abstracting the underlying hardware and software
• Allows the scaling out of  RDBMS solutions without complex sharding or clustering
• Delivers horizontal scaling without migration from relational to NoSQL databases
• Delivers high availability disaster recovery without requiring  a complex replication and failover infrastructure

The rough Microsoft equivalent to Cloud Spanner, is  Cosmos Database.  

The rough AWS equivalent to Cloud Spanner, is  Amazon AWS Dynamo Database.  

The table below provides a review of specific uses cases/deployment configurations referenced  in the Google Cloud  ‘Architectural Framework & Solution Scenarios’ discussed on this website at  GCP-1 ; 

Cloud SQL

GCP Cloud SQL  is a fully managed relational database service for MySQL, PostgreSQL, and SQL Server.  Specifically,  these tradtional relational databases can be seemlessly installed on Cloud SQL.

Also, like Cloud Spanner,  it is also  DbaaS  –  Database as a Service.  

For each of the above traditional relational databases, replication and backups are easily configured  to protect  data.    Automatic failover, to create a  High Availability(HA) solution, is also easily setup .  Cloud SQL data is automatically encrypted, and Cloud SQL is fully compliant for:

• SSAE 16
• ISO 27001
• PCI DSS &
• HIPAA 

Connections to the relational databases running on Cloud SQL, are possible from;

• App Engine
• Compute Engine
• Google Kubernetes Engine, & 
• client workstations.

Lastly, sophisticated analytics can be obtained,  by using BigQuery to directly query Cloud SQL based databases.

The table below provides a summary of the most important use case/deployment configuration for each of these options.

Big Query

GCP Big Query is an updated, modern enterprise data warehousing solution which supports massive datasets.  In order to query these massive datasets cost effectively and expeditiously,  specific hardware and infrastructure must be deployed.   Big Query resolves this issue by being ‘serverless’.  

BigQuery solves this problem by constructing and executing super-fast SQL queries.

BigQuery is fully-managed by GCP.   Activation requires no actions to deploy resources, such as disks and virtual machines.

BigQuery access includes the following options:

• Cloud Console 
• bq command-line tool
• by making calls to BigQuery REST API  

 Client libraries including:

• Java
• .NET  &
• Python.

are useable with the REST API.   Other third-party tools can be used to interact with Biq Query (not listed here).

Four application ‘flavors’ are commonly utilized with Big Query:

•  BigQuery ML
•  BigQuery GIS
•  Big Query BI engine
•  Connected Sheets

Big Query ML (Machine Learning)

The table below provides a summary of the most important use case/deployment configuration for each of these options.

Cloud Dataflow

GCP  Cloud Dataflow is a fully managed service and serverless processing service for executing  Apache  Beam   pipelines within the  GCP  ecosystem.

 When a job executes on Cloud Dataflow, it spins up a cluster of virtual machines, distributes the tasks in the job to the VMs, and dynamically scales the cluster based on how the job is performing.   Routinely,  it changes the order of operations in the processing pipeline to optimize the job.

Apache Beam data processing jobs run on Cloud Dataflow may be either batch and streaming jobs.   Tasks commonly performed to output results include:

• Write a data processing program in Java using Apache Beam
• Use different Beam transforms to map and aggregate data
• Use windows, timestamps, and triggers to process streaming data
• Deploy a Beam pipeline both locally and on Cloud Dataflow
• Output data from Cloud Dataflow to Google BigQuery

The table below provides a summary of the most important use case/ deployment  configuration for each of these options.

GCP Cloud Dataprep,  is an intelligent data preparation tool, used to visually explore, clean  and  prepare both structured and unstructured data for review, reporting, and machine learning.  Given that Cloud Dataprep is serverless, regardless of  the scale of the application, there is never any infrastructure to deploy or manage.  

Cloud Dataprep is provided by a Google partner, Trifacta.  

Cloud Dataprep is unique, given that each UI input by the user triggers a data transformation recommendation.  This abrogates the need to write code.  

Cloud Dataprep automatically detects:

• schemas
• data types
• possible joins, &
• anomalies

such as:

• missing values,
• outliers, &
• duplicates

This real time feedback allows the user to minimize the time-consuming work of assessing data quality, and instead focus on  exploration and analysis.   Specifically,  the feedback generated by Cloud Dataprep is based on a proprietary inference algorithm to interpret the data transformation intent of a user’s data selection.

The user does have major final input into the nature and sequence of data transformations. 

Once the user has defined the nature and sequence of  data transformations, Cloud Dataprep calls Cloud Dataflow behind the scenes, triggering the processing  of structured or unstructured datasets in Cloud Dataflow.  

The table below provides a summary of the most important use case/deployment configuration for each of these options.

GCP Dataproc is a managed Spark and Hadoop service that  provides open source data tools for:

• batch processing
• querying
• streaming, &
• machine learning

Dataproc automation facilitates the quick creation of clusters, and management of them.   Dataproc  saves money by turning clusters off when they are no longer needed. 

Dataproc provides built-in integration with other GCP services, including; 

• BigQuery
• Cloud Storage
• Cloud Bigtable
• Cloud Logging  & 
• Cloud Monitoring

 This integration delivers a complete data platform to support your Spark or Hadoop cluster.   

Dataproc supports the following open source applications; 

• Hadoop
• Spark
• Hive &
• Pig

Dataproc can be accessed in these ways, via:

• REST API 
• Cloud SDK 
• Dataproc UI 
• Cloud Client Libraries 

The table below provides a summary of the most important use case/deployment configurations for each of these options.

The GCP  Cloud IoT Core  utilizes the following concepts to function:

Internet of Things (IoT) : Any physical object  connected to the internet (directly or indirectly) that has the ability to exchange data without user involvement.
Device:Any processing unit that is capable of connecting to the internet and exchanging data with the cloud.  These devices are routinely referred to as  “smart devices” or “connected devices.”  These devices send two types of data:

• telemetry &
• state 

Telemetry:Any and all event data sent from devices to the cloud.  Event data sent commonly provides measurements about the local environment.  Telemetry data can be analyzed by GCP Big Data solutions.  
Device state:  User defined aggregation of data, that describes the current status of the device.  This data can be structured or unstructured, but always only flows from the device to the cloud,  never in reverse.  
Device configuration:   User defined aggregation of data, commonly used to change a device’s settings.  This data can be structured or unstructured,  but always only  flows from the cloud to the device, never in reverse.  
Device registry:    A container of devices with shared properties. A device is “registered” with a service (e.g. Cloud IoT Core) so that it may be managed by it.
Device manager:     Service  used to monitor device health and activity, update device configurations, & manage credentials & authentication.
MQTT(Message Queue Telemetry Transport):      An industry-standard IoT protocol .  MQTT is a publish/subscribe (pub/sub) messaging protocol.
Cloud IoT Core Components:    Device manager & protocol bridges.

Two protocol bridges are available for devices to connect to GCP:

• MQTT  
• HTPP

Cloud IoT Core  is the GCP fully managed service, utilizing all of the above components, to readily and securely connect, manage, and ingest data from globally dispersed devices.

The table below provides a summary of the most important use case/deployment configuration for each of these options.

GCP Pub/Sub is an asynchronous messaging service that decouples production events from  processing events, for all of the services that are involved.  

Pub/Sub offers durable and real time message storage and  delivery with high availability and reliable performance at scale.   Of course, Pub/Sub servers run in of the GCP regions around the world.

Core concepts of Pub/Sub
Topic: A named resource to which messages are sent by publishers.
Subscription: A named resource representing the total stream of messages from a single, specific topic, to be delivered to a subscribing application.
Message: The combination of data and (optional) attributes that a publisher sends to a topic and is eventually delivered to subscribers.
Message attribute: A key-value pair that a publisher can define for a message.
Publisher-subscriber relationships
A publisher application creates and sends messages to a topic. Subscriber applications create a subscription to a topic to receive messages from it. Communication can be;

• one-to-many (fan-out)
• many-to-one (fan-in) &
• many-to-many

Common use cases for Pub/Sub

• Balancing workloads in network clusters
• Implementing asynchronous workflows
• Distributing event notifications
• Refreshing distributed caches
• Logging to multiple systems
• Data streaming from various processes or device
• Reliability improvement

Common GCP services on the ‘send’ side of Pub/Sub include;

• Cloud Logs 
• Cloud  API   
• Cloud Dataflow   
• Cloud  Storage
• Compute Engine

Common GCP services on the ‘receive’ side of Pub/Sub include;

• Cloud Networking   
• Compute Engine 
• Cloud Dataflow 
• App Engine   
• Cloud Monitoring

The table below provides a summary of the most important use case for each of these options.

GCP IAM  allows an administrator to  grant granular access to specific GCP resources and simultaneously prevents access to other resources.    As a baseline, IAM adopts the security principle of least privilege, in which only the minimum and  necessary permissions are granted  to access specific resources.

How IAM functions
Via IAM, the administrator manages access control by defining

• who (identity) has
• what access (role) for
• which resource

The organizations, folders, and projects that used to organize relevant resources are also resources.

Via IAM, permission to access any given resource are never granted directly to the end user. Instead;

• permissions are grouped into roles, &
• roles are granted to authenticated members

An IAM policy defines and enforces:

• what roles are granted to
• which members, &
• this policy is attached to a resource

When an authenticated member attempts to access a resource, IAM checks the resource’s policy to determine whether the action is permitted.

IAM access management has three main parts, Member, Role & Policy, defined as follow;:

*Member. A member can be a:

• Google Account (for end users), a 
• service account (for apps and virtual machines), a 
• Google group, or a 
• Google Workspace or Cloud Identity domain

that can access a resource.

The identity of a member is an email address associated with a

• user,
• service account, or
• Google group; or a
• domain name associated with                                                                      Google Workspace or Cloud Identity domains.

*Role. A role is a collection of permissions. Permissions determine what operations are allowed on a resource. When administrators grant a role to a member, they grant all the permissions that the role contains.

*Policy. An IAM policy binds one or more members to a role. When an administrator seeks to define;

• who (which member) has
• what type of access (role)

on a resource, the administrator creates a:

• policy &
• attaches it to the resource.

The table below provides a summary of the most important use case for each of these options.

GCP Cloud Endpoints  provides a mechanism for an administrator to develop, deploy, protect, and monitor  APIs .   Cloud Endpoints is a distributed API management system, based on OpenAPI v2, defined for Rest API’s.    It comprises:

• services
• runtimes, &
• tools

Cloud Endpoints provides;

• management
• monitoring, &
• authentication,  along with 
• high  performance

The developer effectively ‘offloads’ responsibility for delivering these to this distributed API management system, under the province of GCP.

The components that make up Cloud Endpoints are:

• Extensible Service Proxy (ESP) or Extensible Service Proxy V2 Beta (ESPv2 Beta) – for injecting Cloud Endpoints functionality.
• Service Control – for applying API management rules 
• Service Management – for configuring API management rules
• Cloud SDK – for deploying and management
• Google Cloud Console – for logging, monitoring and sharing.

Cloud Endpoints  is an NGINX-based proxy and distributed architecture, which uses an OpenAPI Specification.  

Cloud Endpoints links with Cloud Monitoring, Cloud Logging, and Cloud Trace to provide operational insights.  Data can, of course, be transferred to  Big Query for further analysis.

API access and validation is accomplished via JSON Web Tokens along with Google API Keys.  The identity of users of  the web or mobile application is obtained via Auth0 and Firebase Authentication.

The table below provides a summary of the most important use case/deployment configuration for each of these options.

A VPC network on GCP, can roughly be viewed  the same way as a physical network, except that it is a virtualized solution within GCP.         A VPC network is a global resource that consists of a:

• list of regional virtual subnetworks (subnets) in data centers,
• all connected by a global wide area network.

VPC networks are logically isolated from each other in GCP.

All new GPC  projects start with a default network (an auto mode VPC network) that has one subnetwork (subnet)specified  in each region.

VPC‘s provides networking functionality to:

• Compute Engine virtual machine (VM) instances,  
• Kubernetes Engine (GKE) clusters &
• App Engine flexible environment, &
• all other GCP products built on Compute Engine VM’s

In addition, a VPC network provides the following:

• Native Internal TCP/UDP Load Balancing and proxy systems for Internal HTTP(S) Load Balancing.
• Connections to on-premises networks using Cloud VPN tunnels and Cloud Interconnect attachments.
• Traffic distribution from GCP external load balancers to backends.

Every VPC network implements a distributed virtual firewall that is  configurable.   Firewall rules acontrol which packets are allowed to travel to which destinations.   Every VPC network operates with two  implied firewall rules:

•  block all incoming connections, &
• allow all outgoing connections

Defined routes specify how traffic is sent from an instance to a destination, either inside the network or outside of GCP.   Each VPC network default configuration specifies some  system generated routes  to send traffic:

• among its subnets &
• from eligible instances to the internet

While routes govern traffic departing an instance, forwarding rules direct traffic to a GCP resource located in a VPC network based on:

• IP address
• protocol, &
• port

The destinations for forwarding rules are:

• target instances, 
• load balancer targets (target proxies, pools, & backend svcs), &
• Cloud VPN gateways.

The table below provides a summary of the most important use case for each of these options.

GCP IAP facilitates the construction of a central authorization layer for applications accessed by HTTPS.   This approach replaces traditional reliance on network-level firewalls, with an application-level access control model.

IAP policies are designed to scale across an organization. IAP policies may be defined centrally and then applied across all applications and resources.   By definition, IAP is used to enforce access control policies for all applications and resources.  

When an application or resource is protected by IAP, it can only be accessed through the proxy by:

• members , also known as users, who must have the
• correct  Identity and Access Management (IAM) role 

A user granted access to an application or resource by IAP,  is automatically subjected to the fine-grained access controls implemented by the application, without requiring a VPN. When a user tries to access a IAP-secured resource, IAP performs both

• authentication &
• authorization

checks.

Requests for GCP resources come through

• App Engine or
• Cloud Load Balancing (HTTPS)

 The first step, involving authentication, requires that the serving infrastructure code for these products/applications determines if IAP is enabled for the app/backend service.   If so, information about the protected resource is sent to the IAP authentication server.   The information that may be included covers:

• GCP project number,
• request URL, & any
• IAP credentials in request headers or cookies

For the next step, IAP checks the user’s browser credentials.  If none exist, the user is:

• redirected to an OAuth 2.0 Google Account sign-in flow that
• stores a token in a browser cookie for future sign-ins.

Assuming valid request credentials, these are then used by the authentication server to get the user’s identity (email address & user ID).   The authentication server then uses the identity to check the user’s IAM role and validate that the user is authorized to access the resource.

The next step after authentication is authorization.  During this step, IAP applies the relevant IAM policy to confirm that the user is authorized to access the requested resource.  This user authorization must take the form of  the  IAP-secured Web App User role on the Cloud Console project where the resource exists.  If the user possesses this role, they’re authorized to access the application. Changes to the IAP-secured Web App User role list are executed via the  IAP panel on the Cloud Console .

The table below provides a summary of the most important use case for each of these options.

KMS stands for  ‘Key Management Service’.

 Data stored on GCP  is encrypted at rest.  Use of the Cloud Key Management Service (Cloud KMS) platform provides greater control over how:

• data is encrypted at rest, & how the
• encryption keys are managed.

The Cloud KMS platform allows GCP customers to manage cryptographic keys in a central cloud service for either:

• direct use, or
• use by other cloud resources & apps

There are two types of software based encryption keys:

• customer-managed encryption keys (CMEK)    
• customer-supplied encryption keys (CSEK) 

Cloud KMS provides the following options for key generation:

• Cloud KMS software backend provides the flexibility to encrypt data with either a symmetric or asymmetric key that is directly controlled ( Cloud KMS ).
• Hardware keys, are obtained via validated Hardware Security Modules  (Cloud HSM ‘s) .
• Cloud KMS provides for the import of customer generated cryptographic keys.  
• Another option is to use keys generated by Cloud KMS with other GCP services. These keys are referred to as customer-managed encryption keys (CMEK). This CMEK feature provides for the generation, use, rotation, and destruction of encryption keys  deployed to help protect data in other GCP services.
• Another facility, the Cloud External Key Manager (Cloud EKM) , provides for the creation and management of keys in a key manager located externally  to GCP.   The Cloud KMS platform may then use these external keys to protect data at rest.
• Customer-managed encryption keys may be used with a Cloud EKM key. 

GCP allows for the use of customer-supplied encryption keys (CSEK)  for both:

• Compute Engine &
• Cloud Storage

Under this arrangement, data is decrypted and encrypted using a key that’s provided on an API call.

Cloud KMS provides the following functionality:

• Customer control
• Access control and monitoring
• Regionalization limits & assignment
• Durability  (eleven  9’s)
• Security 

The table below provides a summary of the most important use case for each of these options.

GCP ‘Data Loss Prevention’ (Cloud DLP) is a fully managed service designed to facilitate the:

• discovery
• classification, &
• protection

of an organization’s most sensitive data.

Cloud DLP provides for:

• Inspection of  structured or unstructured data, to facilitate transformation   
• Reduction in data risk through data de-identification via masking and tokenization

Cloud Data Loss Prevention (DLP) API

The Cloud Data Loss Prevention (DLP) API  Provides methods for detection of privacy-sensitive fragments in:

• text
• images, &
• GCP storage repositories

The table below provides a summary of the most important use case for each of these options.

GCP  Cloud ML  has been subsumed by the GCP AI Platform, which provides access to the Cloud ML Engine.  

The GCP  AI End-to-end platform,  targeted at data science and machine learning, facilitates the streamlining of ML workflows constructed by developers, data scientists, and data engineers.  
The advanced AutoML option provides point-and-click workflow construction.  State of the art applications may be developed via additional GCP tools:

• TPUs 
• TensorFlow

The table below provides a summary of the most important use case/deployment configurations for each of these options.

The GCP  Natural Language API has multiple methods for performing analysis and annotation on  text. Each level of analysis provides valuable information for language understanding. These five methods are:

• Sentiment analysis   
• Entity analysis 
• Entity sentiment analysis   
• Syntactic analysis   
• Content classification

An overview of each of these is provided below;

• Sentiment analysis inspects the given text and identifies the prevailing emotional opinion within the text, specifically to determine a writer’s attitude as positive, negative, or neutral. 

• Entity analysis inspects the given text for known entities (Proper nouns such as public figures, landmarks, and so on.  A review of common nouns, such as house, car,  etc, is also executed) . Entity analysis provides information about all of these entities. 

• Entity sentiment analysis inspects the given text for known entities (proper nouns and common nouns), returns information about those entities, and reveals the prevailing emotional opinion of the entity within the text.   This analysis seeks to determine whether  writer’s attitude toward the entity is positive, negative, or neutral. 

• Syntactic analysis extracts linguistic information, and breaks up the given text into a series of sentences and tokens (generally, word boundaries). It also provides further analysis on those tokens. 

• Content classification analyzes text content and generates a content category for the content. 

Each API call also analyzes for, detects and returns the language, in the event a language is not specified by the caller in the initial request

The Natural Language API is a REST API, and consists of JSON requests and response.

The table below provides a summary of the most important use case for each of these options.

GCP Cloud Speech API  deploys 3 main methods to perform speech recognition:

• Synchronous Recognition   
• Asynchronous Recognition   
• Streaming Recognition

Each of these three methods is described briefly below.  A distinction is made with regard to support for different formats of the incoming payload, REST vs qRPC.   qRPC is much more precise.  

Synchronous Recognition (supports both REST and gRPC)

This method sends received audio data to the Speech-to-Text API, which performs recognition on that data.  It then returns results after all audio has been processed.    Synchronous Recognition requests cannot exceed 60 seconds of duration.  

Asynchronous Recognition (supports both REST and gRPC)              Like the Streaming Recogniton method, this method sends audio data to the Speech-to-Text API.   However, instead  it initiates a Long Running Operation.  This approach supports period polling for recognition results.  Also, durations up to 28,800 seconds are supported.  

Streaming Recognition (supports gRPC only) Executes perecognition on audio data provided within a  gRPC bi-directional stream .    This approach is designed primarily for real-time recognition purposes- e.g., capturing live audio from a microphone. Streaming recognition provides near real-time results while audio is being captured.  This  allows result to appear, for example, while a user is still speaking.     

Recognition requests contain:

• configuration parameters, along with 
• audio data

We will  now review the simplest method for performing recognition on speech audio data – Speech-to-Text API recognition.

Speech-to-Text API recognition
Speech-to-Text can process up to 60 seconds of speech audio data sent in a synchronous request. Once Speech-to-Text processes and recognizes all of the audio, it returns a response.

 Speech-to-Text usually processes audio faster than real-time.  For example, 30 seconds of audio input will usually be processed  in less than 15 seconds on average.   However, a  recognition request can take much longer  if the audio quality is poor.

The table below provides a summary of the most important use case for each of these options.

GCP Cloud Vision API  provides two computer vision products that use machine learning to provide insight into images, with industry-leading prediction accuracy.  These two products are:

• Cloud Vision API       
• AutoML Vision Edge

GCP Cloud Vision API offers powerful pre-trained machine learning models through REST and RPC APIs.     Labels are assigned to images in order to quickly classify them into millions of predefined categories.    Tasks performed include;

• Detection of  objects and faces,
• reading of  printed and handwritten text, &
• construction of  metadata into an image catalog

This application also supports detection and classification of multiple objects including the location of each object within the image. 

Vision API  uses OCR to  detect text  within images in more than 50  languages  and various file types. It’s also a subcomponet  of  Document Understanding AI , which lets you process millions of documents quickly and automate business workflows.

Vision API’s  vision product search capabiity allows retailers to create an sophisticated mobile experience that enables   a customers to upload a photo of an item and immediately see a list of related items for purchase from the vendor.

Vision API can  can allow a vendor to review  images using  Safe Search , which provides real time insight into  the likelihood that any given image includes adult content, violence, or other objectionable content.

AutoML Vision Edge is used to build and deploy fast, high-accuracy models to classify images or detect objects at the edge.  It also triggers real-time actions based on local data. AutoML Vision Edge supports a variety of edge devices where resources are constrained and latency is critical.

AutoML Vision  vs  Vision API :  What they both can do

These two applicatons provide similar capabilities in these areas:

:

The table below provides a summary of the most important use case for each of these options.

The GCP Cloud Translate API   facilitates  dynamic translation between languages using GCP’s pre-trained or custom machine learning models.       We will investigate three different  capability levels associated with the Cloud Translate API;

• AutoML Translation   
• Translation API Basic
• Translation API Advanced

AutoML Translation

Users can upload translated image pairs, and the AutoML Translation  application  will train a custom model that can be adapted to meet domain-specific needs.    This built-in training capability allow developers and translators, who are unfamiliar with machine learning solutions, to construct high quality, production-ready models.

AutoML Translation outputs custom model results in more than fifty language pairs.

Translation API Basic
This application automatically and immediately  translates texts into more than one hundred languages for recipient website and apps.

Translation API Advanced

This application offers the same instantaneous results provided with Basic, but provides additional customization features. Customization is especially relevant for domain- and context-specific terms or phrases.

Both versions of the Translation API  pre-trained model supports more than one hundred languages, from Armenian to Zulu.   

Translation API provides an  easy-to-use Google REST API , that makes unecessary the extraction of text from the document.  The source HTML can be inputted to the application, and the translated text automatically returned.    

In the even the  source language is unknown— for instance, in user-generated content that doesn’t include a language code —both  translation products automatically identify languages with high accuracy.

The table below provides a summary of the most important use case for each of these options.