Cloud

The way we work is evolving. With organizations shifting to hybrid work environments, employees need easy access to business apps and data anytime and anywhere. From a management perspective, this means IT needs to be able to manage their tech stack across various devices and operating systems. 

Chrome Browser Cloud Management gives IT teams a simple and efficient way to manage and secure their browser – all from the cloud. You can manage your deployment across Windows, Linux, macOS and now, Android and iOS too. 

Managing Chrome on Android and iOS

As of our 100th release 🎉, Chrome Browser Cloud Management now supports Chrome-on-Android and Chrome-on-iOS.  We have heard from healthcare, finance, telecom, retail, and even government agencies that it’s extremely important to securely manage Chrome on mobile devices for both frontline workers and knowledge workers.  

That means, from one place, IT teams can:

Configure and set Chrome policies across platforms for a more secure and consistent cross-device user experience 

Get aggregated reports about browsers, versions and device details to make better decisions within their corporate environment 

Use APIs to export information for custom dashboards and workflows

If you’re not using Chrome Browser Cloud Management yet, there are several ways you can get started. For enterprises already managing Chrome from the cloud, here are the steps for extending these capabilities to Android and iOS.

We’ve recently released a ton of other capabilities available through Chrome Browser Cloud Management. Here’s a few highlights: 

More control over extension updates

Extension pinning gives IT the ability to pin the latest version of a Chrome app or extension to control when they are updated to a newer version.  This is useful for organizations with strict change management requirements – especially in highly regulated industries.

Increase access controls with more granular admin privileges 

The team also just introduced a read-only privilege that enhances permission controls available to admins in the Google Admin Console. Admins can grant or restrict access to a subset of other admins. The “Read-only” access will restrict access to Browser Management actions such as moving browsers between organizational units or deleting browsers. This is a great resource for organizations who want to keep their deployment as secure as possible, but want multiple administrators to be able to manage Chrome.

Do more with Chrome Browser Cloud Management reports

This feature allows IT to export data directly into CSV from Chrome Browser Cloud Management reports, so data can be used across their organization or in other reporting tools. It is currently available for Managed Browsers, but will soon be available for Apps & Extension data and Version information. Stay tuned for Q2 when these launch to GA!

Get additional details on applications and extension requests 

Many of our administrators continue to tell us that extensions are critical to business productivity, but they want to have oversight over which ones are being used in their organization.  The App Details API enables IT teams to get detailed information about extensions and the number of extension requests.  We also have a new Github page with examples of how to use other APIs.

Customizing policy ordering

Advanced administrators may have to deploy both Platform (Registry, Group Policy, PLIST, managed preferences) and Cloud policies simultaneously to manage Chrome in complex environments.  Now IT teams can easilychange the order of precedence for Chrome policies to meet their organization’s needs.  

Get 24/7 support from Chrome experts

Did you know that you can get support for your Chrome browsers? Save IT time and keep users connected to the web with 24/7 support from Chrome experts.  Chrome browser support is included for your whole organization if you have any of the following:  >100 Chrome OS CEU licenses, >100 Google Workspace licenses or Google Cloud Platform Enhanced or Premium Support. 

Chrome just had its 100th release last week! To celebrate what we’ve been able to accomplish together and hear from the team on our favorite features and milestones from the past 100 releases, check out our LinkedIn.  To learn more about how you can use Chrome Browser Cloud Management in your organization, visit our website. 

Developers (especially ML engineers) looking to orchestrate BigQuery and BigQuery ML (BQML) operations as part of a Vertex AI Pipeline have previously needed to write their own custom components. Today we are excited to announce the release of new BigQuery and BQML components for Vertex AI Pipelines, that help make it easier to operationalize BigQuery and BQML jobs in a Vertex AI Pipeline. As official components created by Google Cloud, using these components will allow you to more easily include BigQuery and BigQuery ML as part of your Vertex AI Pipelines. For example, with Vertex AI Pipelines, you can automate and monitor the entire model life cycle of your BQML models, from training to serving. In addition, using these components as part of a Vertex AI Pipelines provides extra data and model governance, as each time you run a pipeline, Vertex AI Pipelines tracks any artifacts produced automatically.

For BigQuery, the following components are now available:

BigqueryQueryJobOp

Allows users to submit an arbitrary BQ query which will either write to a temporary or permanent table. Launch a BigQuery query job and wait for it to finish.

For BigQuery ML (BQML), the following components are now available:

BigqueryCreateModelJobOp

Allow users to submit a DDL statement to create a BigQuery ML model.

BigqueryEvaluateModelJobOp

Allows users to evaluate a BigQuery ML model.

BigqueryPredictModelJobOp

Allows users to make predictions using a BigQuery ML model.

BigqueryExportModelJobOp

Allows users to export a BigQuery ML model to a Google Cloud Storage bucket 

Learn how to create a simple Vertex AI Pipeline train a BQML model, and deploy the model to Vertex AI for online predictions:

https://github.com/GoogleCloudPlatform/vertex-ai-samples/blob/main/notebooks/community/ml_ops/stage3/get_started_with_bqml_pipeline_components.ipynb

In addition to the notebook above, check out the end-to-end example of using Dataflow, BigQuery and BigQuery ML components to predict the topic label of text documents using BQML and Dataflow.

End-to-end example using BigQuery and BQML components in a Vertex AI Pipeline

In this section, we’ll show an end-to-end example of using BigQuery and BQML components in a Vertex AI Pipeline. The pipeline predicts the topic of raw text documents by first converting them into embeddings using the pre-trained Swivel TensorFlow model with BQML. Then, it trains a logistic regression model in BQML using the text embeddings to predict the label, which is the topic of the document. For simplification, the model will just predict if the topic is equal to “acq” (1) or not (0), where “acq” means that document is related to the topic of “corporate acquisitions” as defined in the dataset. 

Below you can see a high level picture of the pipeline

From left to right: 

Start with news-related text documents stored in Google Cloud Storage

Create a dataset in BigQuery using BigqueryQueryJobOp

Extract title, content and topic of (HTML) documents using Dataflow and ingest into BigQuery

Using BigQuery ML, apply the Swivel TensorFlow model to generate embeddings for each document’s content

Train a logistic regression model to predict if a document’s embedding is related to a pre-defined topic (1 if related, 0 if not)

Evaluate the model 

Apply the model to a dataset to make predictions

Let’s dive into them. 

ETL with DataflowPythonJobOp component

Imagine that you have raw text documents from Reuters stored in Google Cloud Storage (GCS). You want to preprocess them and import the text into BigQuery to train a classification model using BQML.

First, you will need to create a BQ dataset, which you can do by running the SQL query CREATE SCHEMA IF NOT EXISTS mydataset. In a Vertex AI Pipeline you can execute this query within a BigqueryQueryJobOp.

For the full code, please see this notebook.

Aftering creating the dataset, you will need to prepare the text documents for model training. Importantly, you would need to parse out the relevant sections (“Title”, “Body”, “Topics”) of text from the raw documents. In our case we use a Beam pipeline on Dataflow which uses the Beautiful Soup (bs4) library in Python to extract the following:

Title, the title of the article

Body, the full text content of the article

Topics, one or more categories that the article belongs to

This preprocessing step is based on the ETL pipeline with Apache Beam and can be wrapped in a DataflowPythonJobOp to be used in a Vertex AI Pipeline. DataflowPythonJobOp components enable you to submit Apache Beam jobs written in Python to Dataflow for execution on Google Cloud. In other words, you can use this component to run your data pre-processing step to extract the relevant sections of text via Dataflow.

For the full code, please see this notebook.

To clarify what’s happening in the component above, the requirements_file_path contains the GCS bucket URI to a requirements file, the python_module_path contains the bucket uri to the Apache Beam pipeline python script and args contains a list of arguments that are passed via the Beam Runner to your Apache Beam code. Also notice that WaitGcpResourcesOp is required, which allows the pipeline to wait for the component to finish execution before continuing to the next part of the pipeline.

Feature Engineering with BigqueryQueryJobOp and DataflowPythonJobOp

Once the documents have been pre-processed in Dataflow, the next step is to generate text embeddings from the pre-processed documents. The embeddings can then be used to as training data for the logistic regression model to predict the topic. 

To generate embeddings from text, you can use the Swivel model, which is a pre-trained TensorFlow model publicly available on TensorFlow Hub. How do you use a pre-trained TensorFlow SavedModel on text in BigQuery? You can import it using BQML and apply it to the text of our documents to generate the embeddings. Then you split the dataset to get the training sample you will consume into the text classifier.  

The following shows what the component looks like in the pipeline:

For the full code, please see this notebook.

Where bq_preprocess_query contains the preprocessing query, project and location where the BigQuery job runs. 

For example, within bq_preprocess_query, the first step will be to import the Swivel model using BigQuery ML. And a step thereafter is to retrieve the embeddings, which serves as the training data for the document classifier model in the next section.

For the full code, please see this notebook.

Training a document classifier with BigqueryCreateModelJobOp

Now that you have the training data (as a table), you are ready to build a document classifier, using logistic regression to determine if the label of the document is ‘acq’ or not, where ‘acq’ means that the document is related to the topic of “corporate acquisitions”. You can automate this BQML model creation operation within a Vertex AI Pipeline using the BigqueryCreateModelJobOp. This component allows you to pass the BQML training query and, in case you need, parameterize it and the job associated in order to schedule a model training on BigQuery. The component returns a google.BQMLModel which also tracks the BQML model automatically using Vertex ML Metadata which provides extra insight into model and data lineage.

For the full code, please see this notebook.

Evaluate the model using BigqueryEvaluateModelJobOp

Once you train the model, you would probably evaluate it before deploying into production for generating predictions. With the BigqueryEvaluateModelJobOp, you just need to pass the google.BQMLModel output you received from the previous training BigqueryCreateModelJobOp and it will generate various evaluation metrics, based on the type of the model. In our case we get precision, recall, f1_score, log_loss and roc_auc which are available in the lineage of pipeline in the Vertex ML Metadata.

Notice that, thanks to these components, you can implement conditional logic in order to decide what you want to do with the model downstream. For example, if the performance is above a certain threshold, you can have the pipeline proceed to make predictions directly with BigQuery ML, or register your model into a model registry service, or deploy the model to a staging endpoint. This will really depend on the logic you want to implement with your ML pipeline. 

In this example pipeline with document classification, you’ll just be generating batch predictions directly without conditional logic. 

Predict using BigqueryPredictModelJobOp

In order to operationalize BQML model prediction, the bigquery module of google_cloud_pipeline_components library provides you the BigqueryPredictModelJobOp which allows you to launch a BigQuery predict model job by consuming the google.BQMLModel of the training component.

For the full code,  please see this notebook.

In this component,  you also pass in a job_config in order to define the destination table (project ID, dataset ID and table ID) beyond the query statement to format the columns you want to have in the prediction table. 

Below you can see the visualization of the overall pipeline you get in the Vertex AI Pipelines UI.

Conclusion

In this blogpost, we described the new BigQuery and BQML components now available for Vertex AI Pipelines. We also showed an end-to-end example of using the components for document classification involving BigQuery ML and Vertex AI Pipelines. 

What’s Next

Are you ready for running your BQML pipeline with Vertex AI Pipelines? Check out the following resources and let give it a try: 

Documentation

BigQuery ML

Vertex AI Pipelines

BigQuery and BigQuery components for Vertex AI Pipelines

Code Labs

Intro to Vertex Pipelines

Using Vertex ML Metadata with Pipelines

Github samples

Video Series: AI Simplified: Vertex AI

Quick Lab: Build and Deploy Machine Learning Solutions on Vertex AI

References 

https://google-cloud-pipeline-components.readthedocs.io/en/google-cloud-pipeline-components-0.2.2/google_cloud_pipeline_components.experimental.bigquery.html

https://cloud.google.com/architecture/analyzing-text-semantic-similarity-using-tensorflow-and-cloud-dataflow?hl=en

https://towardsdatascience.com/how-to-do-text-similarity-search-and-document-clustering-in-bigquery-75eb8f45ab65 

Special thanks to Bo Yang, Andrew Ferlitsch, Abhinav Khushraj, Ivan Cheung, and Gus Martins for their contributions to this blogpost.

Earning the role as our customers’ most trusted cloud requires commitment to ongoing transparency, collaboration and assurance. Our products regularly undergo independent verification, achieving certifications or attestations of compliance against global regulatory requirements, frameworks, and guidelines. At Google Cloud we work closely with our customers, their regulators, and appointed independent auditors who want to verify the security and privacy of our platform. One example of how the Google Cybersecurity Action Team supports customers’ risk management efforts is our annual audit with the Collaborative Cloud Audit Group (CCAG). In 2020, faced with the global COVID-19 pandemic and the demands for teleworking, Google Cloud swiftly enabled customer audits in completely remote settings. 2021 brought additional challenges for organizations globally with an increased number of cybersecurity threats, data breaches, software supply chain attacks, as well as rapidly evolving data transfer and privacy requirements. These heightened challenges emphasized the importance for customers to rigorously assess the controls that enable them to independently operate and confidently protect their data and applications in the cloud. So, not surprisingly, the scope of the 2021 CCAG pooled audit included, among others, the measures ensuring Google keeps customer data secure and private, effectively manages threats and vulnerabilities, and ensures transparency and accountability across the full software supply chain.

CCAG is an initiative of 39 leading European financial institutions and insurance companies who depend on cloud infrastructure and technologies to deliver innovative solutions and experiences for their customers. For the third year in a row, the CCAG audit of Google Cloud enabled the group members to manage the risks associated with outsourcing material workloads and satisfy strict national and EU regulatory obligations.

Hamidou Dia, VP for Solutions Engineering in Google Cloud, spoke about how critical verifiable transparency is to earning and retaining customer trust: 

“Our customers recognize the need to secure their global workforce, applications, and data across all platforms, which includes understanding cloud service providers’ relevant policies and controls,” said Dia. “Successful enterprise trust partnerships require transparency, along with access to information, premises and experts, all of which help our customers rapidly complete their risk management and due diligence.”

The pooled audit executed by CCAG is a great example of customers working together to efficiently deploy their resources and gain detailed information and assurances of Google Cloud’s trust posture. The annual engagement lasts approximately six months and is a comprehensive assessment of the design and the effectiveness of Google Cloud security and privacy controls.

“This year we primarily focused on testing Google’s infrastructure security, cryptographic and data privacy controls, and supply chain management. An audit of the scale performed by CCAG requires extensive preparation and resources on both sides. To satisfy the participating members’ individual risk assessments, as well as meet regulatory compliance requirements, we reviewed a large number of policies, processes, technical documents, and test samples”, said Christina Hepp, Divisional Head IT, Operations & Sourcing Group Audit, Commerzbank. “Google Cloud teams pulled together subject matter experts across the organization and secured leadership support to help us successfully complete the audit.”

Verifying the security and privacy controls of the platform through pooled audits is one way Google Cloud maintains the commitment to being the industry’s most trusted cloud. We continue to partner with customers to meet their evolving regulatory compliance requirements. To learn more about Google Cloud Trust & Compliance, visit our Compliance resource center.

Cloud Spanner is Google Cloud’s fully managed relational database that offers unlimited scale, strong consistency across regions, and high availability up to 99.999%. Spanner handles more than two billion requests per second. Spanner is trusted by customers in financial services, retail, gaming and many other industries. We are excited to announce that Spanner has doubled the storage capacity for all Cloud Spanner instances to help customers optimize the compute cost of storage intensive workloads.  For example, Cloud Spanner instances with 1 node (1,000 processing units) can now have 4TB storage capacity instead of 2TB (8TB per 2 nodes, 12TB for 3 nodes, and so on)

Customers building applications such as transactional ledger or inventory management on Spanner have higher storage requirements in comparison to compute requirements. As they scale storage, they end up over-provisioning compute to support the storage, incurring additional cost.  We have increased the storage per node so that customers can better align their costs with their usage.

With this launch, current users are automatically upgraded to the increased storage capacity without the need to opt-in or create new instances. This feature does not change storage pricing or the way storage is billed in Spanner. Users still pay for the actual storage their database uses, regardless of the storage capacity Spanner provisions. To view the storage capacity available for your Spanner instance, visit Cloud Console, select Spanner and click on any instance. You should now see the upgraded capacity of 4TB per node.

We’ve doubled the storage capacity for users who are using granular instance sizing (less than 1000 processing unit instances, or 1 node) as well. Each 100 processing units of compute capacity can support 410 GB of storage.

Previously if you had a storage-intensive workload, you had to over-provision compute (e.g. you had to provision at least 50 nodes of compute capacity to get a storage capacity of 100TB). Now, you can get more storage capacity without unnecessary compute (e.g. you can get 100TB of storage capacity with just 25 nodes). This provides an excellent opportunity to reduce your compute costs up to 50% for storage-intensive workloads.  However, be careful not to under-provision compute as per the below guidelines.

To gauge compute requirements, CPU utilization metrics can be used to monitor the present workload. Cloud Spanner uses CPU to serve read-write data requests as well as process background system tasks such as compaction and splitting. We recommend that you leave some head room for system tasks and unexpected bursts in data requests. When scaling down, we recommend you to monitor high priority CPU utilization to make sure it stays within the recommended limits for single or multi-region instances so that the CPU headroom can help in databases continuing to serve data requests even in case of zonal or regional failures. For single region instances, we recommend a high priority CPU utilization threshold of 65% and for multi-region instances, we recommend a high priority CPU utilization threshold of 45%. With the new storage capacity, if you are reducing the number of nodes, reduce it only up to the extent that these CPU utilization thresholds are not exceeded. 

For example, with previous capacity, let us say you had 50 nodes and 100TB storage in your single region Spanner instance with 40% high CPU utilization. With the new limit, if you reduce the number of nodes to 25 from 50, high priority CPU utilization will rise to around 80% (above the recommended threshold of 65%).   So, in this case, you can reduce the number of nodes to 31 instead of reducing to 25, so that the CPU utilization is still below 65%. Please note that it’s recommended to scale down in stages to avoid performance impact.

In summary, Spanner has doubled the storage capacity for all instances from 2TB storage per node to 4TB storage per node to help reduce the compute cost of storage intensive workloads. For more information on Cloud Spanner, watch this youtube video or visit the Cloud Spanner documentation.

Building new applications is a lot of fun, but troubleshooting and fixing the crashes that can come with app development is not. While many organizations are fast adopting the DevOps model, there are still some legacy frameworks where developers and operations teams are separate. Developers build and submit apps to their ops team, who in turn deploy and maintain the production stack. 

A common issue that arises due to this workflow is the time it takes to find and resolve crashes. To help reduce the time it takes to find crashes, we recently introduced new notification channels for our Alerting product. Building on that release, we’re happy to announce today that you can send Error Reporting notifications through both Slack and Webhooks. 

What is Error Reporting?

Error Reporting can analyze, aggregate, and notify you about crashes in your running cloud services. It can synthesize this information from ingested logs in Cloud Logging and has a dedicated page that displays the details of the errors, including a histogram of occurrences, list of affected versions, request URL, and links to the request log.

What are we launching?

Building on our recent launch of alerting notification channels, today we are announcing an extension of Error Reporting’s notification capabilities to include Slack and Webhooks. 

With this launch, your teams can receive notifications about crashes directly into their configured Slack channel or preferred collaboration platform using webhooks. 

Crash information can then be quickly swarmed, discussed, and resolved.

These new channels  join our existing Error Reporting notification capabilities of email and the Google Cloud Console mobile app.

What do I have to do to enable Error Reporting and these notifications?

Error Reporting is automatically enabled as soon as logs that contain error events like stack traces are ingested into Cloud Logging. Alternatively,  you can self configure Error Reporting for a new project if you won’t be using Cloud Logging.

To configure the new notification channels, see documentation here for Slack and Webhooks, or keep reading below:

Enabling Slack

In Slack: Create a Slack workspace and channel at the Slack site. Record the channel URL.

In the Cloud Console, select Monitoring.

Click Alerting and then click Edit notification channels.

In the Slack section, click Add new to open the Slack sign-in page:

Select your Slack workspace.

Click Allow to enable Cloud Monitoring access to your Slack workspace. This action takes you back to the Monitoring configuration page for your notification channel.

Enter the name of the Slack channel you want to use for notifications.

Enter a display name for the Slack notification channel.

(Optional) To test the connection between Cloud Monitoring and your Slack workspace, click Send test notification. If the connection is successful, then you see a message This is a test alert notification… in the Slack notification channel that you specified. Check the notification channel to confirm receipt.

If the Slack channel you want to use for notifications is a private channel, then you must manually invite the Monitoring app to the channel:

Open Slack.

Go to the channel you specified as your Monitoring notification channel.

Invite the Monitoring app to the channel by entering and sending the following message in the channel:

/invite @Google Cloud Monitoring

Be sure you invite the Monitoring app to the private channel you specified when creating the notification channel in Monitoring. Inviting the Monitoring app to public channels is optional.

Enabling Webhooks

The webhook handler: Identify the public endpoint URL to receive webhook data from Monitoring.

In the Cloud Console, select Monitoring.

Click Alerting and then click Edit notification channels.

In the Webhook section, click Add new.

Complete the dialog.

Click Test Connection to send a test payload to the Webhook endpoint. You can go to the receiving endpoint to verify delivery.

Click Save.

Webhook schema

The Webhook schema structure for Error Reporting, is as follows:

Schema structure, version 1.0

Basic authentication

In addition to the webhook request sent by Cloud Monitoring, basic authentication utilizes the HTTP specification for the username and password. Cloud Monitoring requires your server to return a 401 response with the proper WWW-Authenticate header. For more information about basic authentication, see the following:

RFC Specification

Basic authentication

Token authentication

Token Authentication requires a query string parameter in the endpoint URL and a key that the server expects to be secret between itself and Monitoring. The following is a sample URL that includes a token:

https://www.myserver.com/stackdriver-hook?auth_token=1234-abcd

If Monitoring posts an incident to the endpoint URL, your server can validate the attached token. This method of authentication can be more effective when used with SSL/TLS to encrypt the HTTP request, which can prevent snoopers from learning the token.

For an example server in Python, see this sample server.

Get Started Today

If you haven’t visited your Error Reporting console yet, give it a try today and learn more about it in documentation. When you’re ready to configure your notifications, consider Slack and Webhooks if they fit into your current alerting and notification strategy.

If you have any questions or want to start a discussion with other Error Reporting users, visit the Cloud Operations section of the Google Cloud Community and post a discussion topic.

This is the second part of the blog series that covers the migration story of NCR Corporation’s Card Management solution, Authentic Cards, to Google Cloud. This installment describes the Google Cloud solutions used in the architecture to strengthen the functional and technical capabilities of the product.

We start again by reiterating the fact that migrating legacy systems to the cloud can be challenging for large enterprises, but many companies can benefit by deploying them into the cloud for better performance, scalability, and availability. In this blog we will further explore how NCR and Opus Consulting Solutions designed the cloud solution by choosing the right capabilities available in Google Cloud.

If you want to know more about the product and its high level architecture, we encourage you to read part 1 of this blog series.

Why is it important to choose the right component?

A software product is defined by the quality of its features, security, availability, its extensibility in the future along with many other factors. Building the right product using modern technologies is one thing, but choosing the right components while keeping in mind the objectives of key stakeholders when deploying a solution to the cloud is another thing and can be a daunting task. Several factors drive the design decisions while building the right architecture for your product in the cloud. Different teams, from banking lines of business, compliance to IT delivery and operations, have varying needs when it comes to how they leverage and manage the technology day to day. Cloud providers offer a wealth of managed services and hence the balance between choosing these services, their benefits, and the associated costs should be taken into consideration by the key stakeholders when making such decisions. Primarily, cloud components are categorized into hardware, virtualization, storage, and network, and should be chosen carefully when designing solutions.  Some major factors taken into consideration are:

Current industry standards and future trends

Technology and future roadmap of the product

Availability, scalability, and regional independence

Security of the system, modern day threats and mitigations

Data security and governance

Data storage needs

Manageability of the architecture and the system

Contracts, commercials, support, and SLAs

Cloud capabilities

NCR Authentic Cards is built by amalgamating several individual native and custom components in Google Cloud. The entire architecture is designed with a lot of precision keeping in mind the various aspects of the product. The architecture takes a security-first approach and makes use of several managed services provided by Google Cloud for security and better management of resources. Primary infrastructure solutions like Google Kubernetes Engine and Cloud SQL are used to deploy NCR Authentic Card’s business logic and data. Meanwhile, components like Cloud NATand Cloud Armor provide a security shield for the product.

Let us look at all these individual components in detail.

Virtual Private Cloud (VPC)

This is the primary component of the architecture, and it acts as the playground for where the whole product and its constituting components can reside and play. It encompasses the product in a private cloud network spanning across multiple regions helping to ensure security from external elements. The components inside the VPCare configured to have only private IPs which ensures that they can only be accessed from within the VPC and are invisible to the outside world. The data inside the VPC is encrypted while in transit, providing further safety of the data flowing through the product. The security of the VPC is further enhanced by applying a set of firewall rules limiting and restricting communication between the components in the VPC.

Cloud NAT

This Google Cloud managed service is a key part of this architecture, restricting access to components behind the gateway with private IPs. Cloud NAT provides network address translation for subnets in the VPC region with a single gateway. In simple words, it lets the internal resources and its components create outbound internet connections when needed for upgrades and other similar necessities. It was carefully chosen during the design phase as a component of this architecture to ensure security to the internal resources of the system.

Google Kubernetes Engine

Google Kubernetes Engine hosts the service code containing the business logic of the product. The software code along with its dependencies, like runtime environment and libraries required to run the code, are packaged in containers and deployed in pods in Google Kubernetes Engine. The product consists of several microservices, all deployed in pods running in nodes (equivalent of a machine). This allows Google Kubernetes Engine to auto scale a service horizontally by deploying the service into more pods based on demand, supporting the application’s ability to handle unprecedented loads and sudden spikes in traffic. The choice of this component can help yield benefits such as efficient usage of resources, reduced support and infrastructure management overhead, and automated deployments. Google Kubernetes Engine can also support the deployment of the application in a regional cluster using namespaces. The regional cluster helps support higher availability even when an entire zone is down or has issues while namespaces  enable multi-tenant cost optimization. The implementation team at NCR and Opus has built CI/CD pipelines to help build, test, and deploy enhancements and upgrades to the product deployed in the GKE cluster.

Cloud SQL

NCR Authentic Cards uses a relational database, Postgres, to store its data. Cloud SQL gives the choice of picking Postgres while availing the other benefits of a managed service database like applying patches and updates, managing backups, and configuring replications. The database is replicated in two zones making it highly available. The choice of zones and regions are configurable and can be made based on the geographical data norms of the customer. It also adds an additional security layer to the product as the data is encrypted and stored in Cloud SQL. The application code connects to the database using SQL Auth proxy, helping to keep the connection secure between itself and the database.

Cloud Memorystore

The actual product design of NCR Authentic Cards included a Redis component for managing cache. This was revised while designing the architecture in Google Cloud and Cloud Memorystorewas added in the new Authentic Cards realm replacing Redis. Cloud Memorystore is also a managed service and provides caching capabilities to the product, helping to render faster response time on the services.

Cloud Load Balancing

The services of NCR Authentic Cards are exposed to the customers through Cloud Load Balancing which is a fully distributed, software-defined, and highly scalable managed service provided by Google Cloud.  Cloud Load Balancing helped in deploying the entire product behind one anycast external IP which is called by the customers to avail the services. NCR Authentic Cards can be deployed in multiple regions for failover, availability, and geographical needs behind this single IP. Also, the product and its resources can be auto scaled as required without impacting the customers. Cloud Load Balancing also supports SSL offloading, which means that the incoming SSL traffic from the customers is terminated at the load balancer and not sent as-is to the internal servers, providing an additional layer of security.

Cloud Armor

Cloud Armor is a managed WAF (web application firewall) service in Google Cloud and helps provide DDoS defense, enforce security policies, and mitigate key OWASP-identified risks for your system. This component was added to the design of NCR Authentic Cards and provides two main security features to the product which are as follows:

Region based whitelisting which allows only users from a specific geographic region to use the services.

Configuring an Allow/Deny list of IP addresses to help ensure the services are accessed by only allowed IP sources.

Apigee

The architecture of NCR Authentic Cards uses Apigee API managementas the gateway to handle external traffic. Apigee routes traffic through the load balancer as well but independently authorizes each transaction at its layer using OAuth 2.0 API proxy. Apigee provides full API lifecycle management capabilities that support the always evolving and expanding card services integration ecosystem while offering the option to monetize API products. This allows for the solution to constantly offer new endpoints and a wider set of connectors for internal and external systems. The Authentic Card APIs are mapped to API proxies in Apigee which allows policies to be defined at the proxy level for security and other requirements. The default policy applied to the API proxies is VerifyAccessToken, helping to ensure token authentication for all the APIs. The Apigee architecture for Authentic Cards is depicted in the diagram below.

Monitoring components

The support, alert, and monitoring system of NCR Authentic Cards, which is a quintessential component of the product, will be discussed in the final edition of this blog series.

Features enriched by the architecture of NCR Authentic Cards

The cloud components used in the design rendered the following features to NCR Authentic Cards:

Scalability and availability

Security

API lifecycle management with potential monetizing capabilities

Geographical independence

Modernizing a complex system by choosing the right architecture using native and custom cloud solutions can be challenging. The mix of NCR’s product and domain experience, combined with Opus’ specialized cloud development resources helped deliver an improved card management solution on Google Cloud. Today, NCR Authentic Cards is a validated product in Google Cloud and its services are readily accessible to financial institutions upon onboarding.

About Opus Consulting: Backed by years of experience in building highly innovative payment solutions and products for the digital age, Opus Consulting Solutions is at the forefront of shaping the future of the FinTech and Payments Technology landscape. Opus combines its deep technology proficiency with unmatched domain expertise in Payments and FinTech to deliver quality and value in their work. For more information, visit:https://opusconsulting.com/contact/

About NCR: NCR Corporation is a global enterprise technology provider for software, hardware and services needed to deliver exceptional customer experiences. NCR is a trusted partner for financial institutions looking to transform and align their business across mobile, on-line, ATM and branch. Through innovative solutions to run self-directed banking with the ability to power the end-to-end self-directed infrastructure, NCR solutions connect shared services to help simplify and optimize banking experiences for customer and staff alike, and also extend to integrate and innovate with the broader enterprise and fintech ecosystem. NCR helps clients bridge digital and physical operations so that businesses can connect with consumers anytime, anywhere.

Have you ever written a script to transform an image? Did you share the script with others or did you run it on multiple computers? How many times did you need to update the script or the setup instructions? Did you end up making it a service or an online app? If your script is useful, you’ll likely want to make it available to others. Deploying processing services is a recurring need – one that comes with its own set of challenges. Serverless technologies let you solve these challenges easily and efficiently.

In this post, you’ll see how to…

Create an image processing service that generates coloring pages

Make it available online using minimal resources

…and do it all in less than 200 lines of Python and JavaScript!

Tools

To build and deploy a coloring page generator, you’ll need a few tools:

A library to process images

A web application framework

A web server

A serverless solution to make the demo available 24/7

Architecture

Here is one possible architecture for a coloring page generator using Cloud Run:

And here is the workflow:

The user opens the web app: the browser requests the main page.

Cloud Run serves the app HTML code.

The browser requests the additional needed resources.

Cloud Run serves the CSS, JavaScript, and other resources.

The user selects an image and the frontend sends the image to the /api/coloring-page endpoint.

The backend processes the input image and returns an output image, which the user can then visualize, download, or print via the browser.

Software stack

Of course, there are many different software stacks that you could use to implement such an architecture.

Here is a good one based on Python:

It includes:

Gunicorn: A production-grade WSGI HTTP server

Flask: A popular web app framework

scikit-image: An extensive image processing library

Define these app dependencies in a file named requirements.txt:

Image processing

How do you remove colors from an image? One way is by detecting the object edges and removing everything but the edges in the result image. This can be done with a Sobel filter, a convolution filter that detects the regions in which the image intensity changes the most.

Create a Python file named main.py, define an image processing function, and within it use the Sobel filter and other functions from scikit-image:

Note: The NumPy and Pillow libraries are automatically installed as dependencies of scikit-image.

As an example, here is how the Cloud Run logo is processed at each step:

Web app

Backend

To expose both endpoints (GET / and POST /api/coloring-page), add Flask routes in main.py:

Frontend

On the browser side, write a JavaScript function that calls the /api/coloring-page endpoint and receives the processed image:

The base of your app is there. Now you just need to add a mix of HTML + CSS + JS to complete the desired user experience.

Local development

To develop and test the app on your computer, once your environment is set up, make sure you have the needed dependencies:

Add the following block to main.py. It will only execute when you run your app manually:

Run your app:

Flask starts a local web server:

Note: In this mode, you’re using a development web server (one that is not suited for production). You’ll next set up the deployment to serve your app with Gunicorn, a production-grade server.

 You’re all set. Open localhost:8080 in your browser, test, refine, and iterate.

Deployment

Once your app is ready for prime time, you can define how it will be served with this single line in a file named Procfile:

That’s it, you can now deploy your app from the source folder:

Under the hood

The command line output details all the different steps:

Cloud Build is indirectly called to containerize your app. One of its core components is Google Cloud Buildpacks, which automatically builds a production-ready container image from your source code. Here are the main steps:

Cloud Build fetches the source code.

Buildpacks autodetects the app language (Python, in this case) and uses the corresponding secure base image.

Buildpacks installs the app dependencies (defined in requirements.txt for Python).

Buildpacks configures the service entrypoint (defined in Procfile for Python).

Cloud Build pushes the container image to Artifact Registry.

Cloud Run creates a new revision of the service based on this container image.

Cloud Run routes production traffic to it.

Notes:

Buildpacks currently supports the following runtimes: Go, Java, .NET, Node.js, and Python.

The base image is actively maintained by Google, scanned for security vulnerabilities, and patched against known issues. This means that, when you deploy an update, your service is based on an image that is as secure as possible.

If you need to build your own container image, for example with a custom runtime, you can add your own Dockerfile and Buildpacks will use it instead.

Updates

More testing from real-life users shows some issues.

First, the app does not handle pictures taken with digital cameras in non-native orientations. You can fix this using the EXIF orientation data:

In addition, the app is too sensitive to details in the input image. Textures in paintings, or noise in pictures, can generate many edges in the processed image. You can improve the processing algorithm by adding a denoising step upfront:

This additional step makes the coloring page cleaner and reduces the quantity of ink used if you print it:

Redeploy, and the app is automatically updated:

It’s alive

The app is visible as a service in Cloud Run:

The service dashboard gives you an overview of app usage:

That’s it; your image processing app is in production!

It’s serverless

There are many benefits to using Cloud Run in this architecture:

Your app is available 24/7.

The environment is fully managed: you can focus on your code and not worry about the infrastructure.

Your app is automatically available through HTTPS.

You can map your app to a custom domain.

Cloud Run scales the number of instances automatically and the billing includes only the resources used when your code runs.

If your app is not used, Cloud Run scales down to zero.

If your app gets more traffic (imagine it makes the news), Cloud Run scales up to the number of instances needed.

You can control performance and cost by fine-tuning many settings: CPU, memory, concurrency, minimum instances, maximum instances, and more.

Every month, the free tier offers the first 50 vCPU-hours, 100 GiB-hours, and 2 million requests for no cost.

Source code

The project includes just seven files and less than 200 lines of Python + JavaScript code.

You can reuse this demo as a base to build your own image processing app:

Check out the source code on GitHub.

For step-by-step instructions on deploying the app yourself in a few minutes, see “Deploying from scratch”.

More

Try the demo and generate your own coloring pages.

Learn more about Cloud Run.

For more cloud content, follow me on Twitter (@PicardParis) or LinkedIn (in/PicardParis), and feel free to get in touch with any feedback or questions.