Cloud

New technologies like integrated artificial intelligence (AI), edge computing, 5G communications, and Internet of Things (IoT) products, as well as the emergence of customers as competitors with in-house chip design capabilities are forcing the semiconductor industry to shift away from a focus on engineering and operations and toward a strong focus on product development, new operating models, and new market penetration. 

According to a 2021 Semiconductor Transformation Study (STS) from Deloitte Consulting and Global Semiconductor Alliance (GSA), 42% of semiconductor companies are experimenting with new go-to-market strategies such as selling integrated solutions and experimenting with nontraditional, cloud-based business models. This is changing the way semiconductor companies go to market, engineer products, and generate revenue. 

Semiconductor Integrated Circuit (IC) design, also commonly known under an umbrella term EDA, encompasses many workflows that are used to design a circuit (or “chip”). These design workloads are compute and storage centric, requiring large quantities of high-performance compute, and scalable Network Attached Storage (NAS) storage systems for the design of chips. Bringing a chip design as a finished product to the market quickly is crucial for EDA companies, and hence, faster and agile compute and storage infrastructure are essential for the design teams. With increasing design densities, moving from seven to three nanometer, the chip designs are becoming more complex and the demand for highly scalable and performant storage and compute capabilities are ever increasing.

Dell PowerScale for Google Cloud

Google and Dell make it easier to run electronic design automation (EDA) workloads in the cloud, providing a foundation for semiconductor companies to scale their clients and jobs easily while still retaining the same shared volume across all clients, with a high performance and low latency service. The solution provides a tightly integrated, self-service, multiprotocol, file service offering in Google Cloud.

Dell PowerScale is tightly integrated with Google Cloud and delivers many benefits including:

Scale-out storage that grows linearly as thousands of EDA simulation jobs (e.g., simulation) are running concurrently

On-demand dedicated capacity to achieve faster aggregate run times, flattening the design curve

Flexible architecture supporting engineers and developers the ability to run workflows in the cloud or on-prem without re-platforming apps or learning new tools 

Architecture Overview; Burst to cloud chip design 

Front-end workflows such as verification and synthesis are compute intensive (some tools are storage I/O intensive too) and the associated jobs tend to be short-lived. Availability of a large number of compute slots for the duration of the job is very valuable to design teams. This requirement is amplified when dealing with larger portions of designs or complex designs to be delivered in tight timelines. This is where the combined capabilities of Google Cloud and PowerScale provide the elasticity for the IC design stakeholders. 

First the user interacts with their primary on-prem resources and launches a job with the scheduler directly into the Google Cloud. 

The necessary compute instances are created on-demand based on the pre-configured or standard images, and once the resources are idle or jobs complete, they can be terminated. The data sets desired for job execution can be replicated ahead of time using built-in PowerScale SyncIQ feature, and this can be orchestrated as well. 

When the instances are terminated, the data persists, and can be reverse-replicated back to on-prem, if needed. This way, there is a bi-directional data-flow that can be orchestrated to be triggered with the jobs or managed separately.

Architecture Overview: Hybrid Model

While the burst to cloud use case entails specific workflows extending into the Google Cloud, a hybrid solution can benefit a broader set of workloads. End users can interact and work directly in Google Cloud, utilizing infrastructure services and accessing datasets with no data egress just as they would for another on-prem location. Figure 2 shows that the license server can be optionally hosted in Google Cloud, or the existing on-prem server can be part of the workflow, depending on licensing requirements for various tools. The PowerScale cluster would host user homes, projects, scratch, tools, repositories and other datasets.

Linear Storage Scalability is Crucial

Selecting a storage solution that scales to meet the demand of compute workers is crucial to a successful EDA run and flattening the design curve. We tested PowerScale using a synthetic EDA benchmark suite. The test suite is used to measure the maximum sustainable throughput that a storage solution can deliver for a specific EDA workload, constructed from Back-End and Front-End subcomponents. We’ve used a Tier_1 all-flash PowerScale solution with 170TB storage capacity and 40 Google Compute Engine instances to run the tests.

The results of the benchmark test show that with PowerScale, as you run more jobs you can deliver more throughput and IOPS. The scale-out architecture allows you to continually manage latency by adding additional nodes. This capability is critical for EDA workloads when they burst to cloud. 

Additional information 

Using Dell EMC Cloud Storage Services: PowerScale

Top Reasons to choose Dell EMC PowerScale for Google Cloud for semiconductor design

View webcast: Applying artificial intelligence to design verification 

Read the eBook:  Shaping the future of semiconductor design and manufacturing 

Learn more about Dell EMC PowerScale for semiconductor design and manufacturing

A special thanks to Alec Shnapir and Sean Derrington from Google Cloud and Kami Periman from Dell for their contributions.

We are excited to announce that Google Cloud Managed Service for Prometheus is now generally available! Now you can get all the benefits of open source-compatible monitoring with the ease of use of Google-scale managed services.

The rapid adoption of managed platforms and services across the cloud computing industry has shown that fewer and fewer organizations want to invest developer time into managing infrastructure. Google Cloud was recently recognized as a Leader in The Forrester Wave™: Public Cloud Container Platforms, Q1 2022 and in the report the authors note: “Large firms are seeking enterprise container platforms that accelerate and simplify the development and operations of cloud-native apps with resiliency, manageability, and observability via full-stack cloud-native capabilities.” 

Getting a better picture of the four golden signals of monitoring, as laid out in Google’s SRE book, means you have to capture metrics. In both self-managed Kubernetes and Google Kubernetes Engine (GKE) environments, the de-facto standard monitoring technology is Prometheus, an open source metrics collection and alerting tool. While Prometheus works great out-of-the-box for smaller deployments, running Prometheus at scale creates some uniquely difficult challenges.

Much like you might use GKE because you prefer to not manage your own Kubernetes infrastructure, Managed Service for Prometheus is here for those who prefer to not manage their own Prometheus infrastructure. Focus your developers’ efforts on building features for your customers, as opposed to focusing efforts on operations toil that merely keeps the lights on.

Benefits of using Managed Service for Prometheus  

Two-year retention of all metrics, included in the price: Manually sharding long-term storage is a major pain point of running your own Prometheus-compatible aggregator. Thanks to the global scale and scalability of Monarch, the system that powers not just Cloud Monitoring but all monitoring at Google, long-term storage of Managed Service for Prometheus metrics is easy for us. That benefit gets passed along to you as a two-year retention policy, for all metrics, at no additional charge.

Cost-effective monitoring: Switching from open source to a managed service always brings the fear of increased costs, but the pricing model for this service is straightforward and predictable. Charging on a per-sample basis means you pay only while your containers are alive and sending metrics data, taking the worry out of using features like Horizontal Pod Autoscaling that frequently scale containers up and down. Managed Service for Prometheus also provides other cost control and cost reducing measures such as a reduced charge for sparse histograms, a fee structure that charges less for longer sampling periods, and the ability to only send locally pre-aggregated data.

Easy cost identification and attribution: Within Cloud Monitoring, you can easily separate out your Prometheus ingestion volume by metric name and namespace. This allows you to identify which metrics contribute the most to your bill, determine what team’s namespace is responsible for sending those metrics, and take action to reduce your costs.

No changes needed to existing querying or alerting workflows: You can choose to reuse your existing Prometheus collection deployment or switch to our managed collection. In either case you can keep using the same Grafana dashboards and alert configs you’re using today. PromQL compatibility for dashboarding and alerting means that your existing incident creation and investigation workflows will continue to work as before.  

Viewing Prometheus metrics andGoogle Cloud system metrics together: Many organizations try, but struggle to simplify their operations by building a “single pane of glass” for all their metric sources. Because our service is built on the same technology and backend as Cloud Monitoring, your Prometheus metrics can be used with the dashboarding, alerting, and SLO monitoring available within Cloud Monitoring. Chart your Prometheus metrics right alongside your GKE metrics, your load balancer metrics, and more.

Read more from customers who have used Managed Service for Prometheus on our website.

What’s coming up next

General availability is just the beginning! We have many more great Managed Service for Prometheus features on our roadmap, including:

PromQL querying of free GCP system metrics available in Cloud Monitoring, including GKE, Anthos, and Istio metrics, so you can chart these metrics right alongside your Prometheus metrics in Grafana

Recommended default collection configs for commonly-used exporters, such as kube-state-metrics and node-exporter

Optimized network performance for on-prem clusters

Debugging tools, such as a targets discovery and health page

And more!

How to get started

Setting up Managed Service for Prometheus is straightforward. 

For those starting from scratch or for those who want a more fully-managed experience, you can deploy managed collectors in any Kubernetes cluster by using the GKE UI in Cloud Console, the gcloud CLI, or kubectl. 

For those with existing Prometheus deployments, you can keep using your existing configuration by just swapping out your Prometheus binary with the Managed Service for Prometheus binary. 

See Managed Service for Prometheus documentation to get started. You can also check out this video which walks you through a few different ways to set up the service:

Lastly, if you have questions, feature requests, or just want to read topics from other customers who are using Google Cloud Managed Service for Prometheus and Google Cloud’s operations suite, visit our Google Cloud Community site.

PostgreSQL uses transaction IDs (TXIDs, XIDs) to implement Multi-Version Concurrency Control semantics (MVCC). The PostgreSQL documentation explains the role of TXIDs as follows:

PostgreSQL’s MVCC transaction semantics depend on being able to compare transaction ID (XID) numbers: a row version with an insertion XID greater than the current transaction’s XID is “in the future” and should not be visible to the current transaction. But since transaction IDs have limited size (32 bits), a cluster that runs for a long time (more than 4 billion transactions) would suffer transaction ID wraparound: the XID counter wraps around to zero, and all of a sudden transactions that were in the past appear to be in the future – which means their output become invisible. In short, catastrophic data loss.

To overcome the transaction ID wraparound problem, PostgreSQL uses a vacuum mechanism that freezes committed transaction IDs and releases them for further use. You can think of this mechanism as “recycling” of transaction IDs that keeps the database operating despite using a finite number to store the ID. 

Vacuum can operate as a background task called autovacuum (enabled by default), and it can also be invoked manually using the VACUUM command. Autovacuum is designed as a low-priority task that yields to regular workload, so the speed and effectiveness of the process depends on database activity. In some cases, autovacuum might not be able to recycle transaction IDs quickly enough, reaching a point where PostgreSQL initiates a special type of vacuum called “aggressive vacuum” or “anti-wraparound vacuum”.

If TXID utilization continues to increase despite autovacuum’s best efforts, the database stops accepting commands to prevent transaction ID wraparound and consequently data loss. 

This blog post demonstrates ways of accelerating the vacuum process on your Cloud SQL PostgreSQL instance to avoid the problems described above.

Note: This post uses vacuum features introduced in PostgreSQL 12. In order to follow the instructions, your database must be running PostgreSQL version 12 or later.

Autovacuum versus manual vacuum for TXID freezing

The following are the main stages  of a vacuum operation, as shown in the pg_stat_progress_vacuum view:

Scanning heap: Vacuum is scanning the heap. It will prune and defragment each page if required, and possibly perform TXID freezing activity.

Vacuuming indexes: Vacuum is removing the dead row versions from indexes.

Vacuuming heap: Vacuum is removing dead row versions from the heap (table).

Truncating heap: Vacuum is truncating the heap to return empty pages at the end of the table to the operating system.

The task of freezing old transaction IDs requires the “scanning heap” and “vacuuming heap” phases, but not the “vacuuming indexes” and “truncating heap” phases. Consequently, when running a vacuum for the sole purpose of freezing transaction IDs, it can be beneficial to skip the optional phases. Large tables with multiple indexes are particularly susceptible to spending a considerable amount of time in the “vacuuming indexes” stage, and skipping that stage can considerably reduce vacuum time.

The optional phases are not skipped during automatic vacuuming. You can however cancel an autovacuum operation already in progress, and run a customized manual vacuum instead. You can also use the manual vacuum technique proactively to prevent PostgreSQL from initiating an aggressive autovacuum later.

Note: PostgreSQL 14 introduced a vacuum_failsafe_age parameter that provides equivalent functionality as part of autovacuum. PostgreSQL 14 users can still follow the manual procedure to become familiar with vacuum performance concepts, but the built-in functionality might be a better long-term choice.

Manual vacuum guide

Overview

This section will walk you through the following steps:

Check transaction ID utilization in each database.

Identify the autovacuum operations that can be canceled and re-run manually using an optimized VACUUM command.

Run an optimized VACUUM command for each table and monitor its progress.

Optionally, rebuild indexes on each table that was vacuumed manually.

Check database metrics again to verify that transaction ID utilization went down after the manual vacuum.

Note that although vacuum operations do not cause downtime, they do introduce additional load in the database, and their run time is difficult to predict. You may want to use a clone to test and familiarize yourself with the procedure before attempting it on production databases.

Check transaction ID utilization before vacuuming

To determine transaction ID utilization for each database, connect to your Cloud SQL instance as the user postgres and run the following query:

The output will look like this:

A value of >80% in the consumed_txid_pct column indicates that tables in that database are in need of vacuuming to recycle transaction IDs. It is likely that autovacuum is already running on those tables, and it can be sped up as described earlier.

Follow the steps in the next section for each database that needs vacuuming.

Choose tables to vacuum manually

Connect to the database and run the following query to list tables that are currently processed by the autovacuum daemon:

The output will look like this:

Each record in the output corresponds to one autovacuum operation running in the database. Review the output and identify any records where the vacuum is in the “vacuuming indexes” phase as shown in the phase field. This indicates an operation that can potentially be sped up by canceling the autovacuum and performing a manual vacuum instead.

If there are multiple tables eligible for manual vacuuming, focus on the largest ones first. The larger the table, the longer the autovacuum process can take. Therefore, applying this procedure on the largest tables first can produce the biggest gains.

Follow the steps in the next section for each table you identified. Subsequent examples will use information from RECORD 2 highlighted above.

Vacuum a table manually

Ensure that these prerequisites are met before proceeding:

In order to run a VACUUM command on a table, you must be logged in as the table owner.

In order to cancel an ongoing autovacuum, you need permission  to execute the pg_cancel_backend function. The user postgres holds this permission by default, but other users must be granted access explicitly. To grant access, connect to the instance as postgres and run the following command:

Once the prerequisites are met, execute the following commands to cancel the ongoing autovacuum and issue a manual vacuum:

For example:

You can monitor the progress of your manual vacuum using the pg_stat_progress_vacuum view:

After the vacuum completes, you can optionally reindex the table. Our optimized VACUUM command contained the INDEX_CLEANUP false clause, which skips the index optimization stage. Bypassing index optimization doesn’t cause any immediate issues, but if you frequently vacuum the same tables with INDEX_CLEANUP false, it can lead to index bloat in the long term. You may want to REINDEX your table periodically if index bloat becomes a problem. You can read more about index bloat here.

Use the REINDEX command to reindex a table:

For example:

Vacuuming tables proactively

The above procedure focuses on tables that are actively processed by autovacuum. You can also vacuum your tables proactively, based on what you know about their size and the volume of workload they receive.

Even when you vacuum your tables routinely and proactively, continue to monitor transaction ID utilization and try to keep it as low as possible across all databases. For context: by default, Postgres starts an aggressive vacuum when transaction ID utilization reaches 10%. This threshold can be configured using the autovacuum_freeze_max_age setting.

If you find that the default autovacuum behavior is not sufficient for your workload (e.g. it’s routinely unable to reclaim transaction IDs quickly enough), you should consider tuning the autovacuum parameters. Finding optimal configuration can involve some trial and error, but a well-tuned autovacuum can reduce or even eliminate the need for proactive manual vacuuming. Note that a more aggressive autovacuum can potentially impact the performance of regular workloads, so the related settings are best changed and validated in small increments.

Checking transaction ID utilization after vacuuming

After you’ve completed manual vacuuming, check transaction ID utilization again:

You should see that the value in consumed_txid_pct field is now lower than it was before:

If the value is still very high, it might be driven by certain tables that weren’t covered by the prior procedure. You can obtain TXID information at table level to identify tables that still need vacuuming.

For example, this query will show top ten tables ordered by transaction ID utilization:

Learn More

In this blog post, we have demonstrated the ways of accelerating the vacuum process on your Cloud SQL PostgreSQL instance to avoid the transaction ID wraparound. Here is the link that describes what you can do when your database runs into Transaction ID Wraparound protection in PostgreSQL.

As traditional Moore’s law improvements slow down, we are now turning to custom chips to continue improving performance and efficiency. Innovations like Google’s Tensor Processing Units (TPUs) and Video Coding Units (VCUs) have been incredibly valuable at sustainably meeting the growing demand for machine learning and video distribution services, and we expect to see additional custom chips that meet the emerging needs of our customers and users. 

But building custom chips is a complex and costly endeavor. In particular, the semiconductor industry faces a key challenge. Each successive generation (technology node) is achieving more modest benefits, often surpassed by the high costs of manufacturing the chips (e.g., semiconductor mask costs). As one example, after decades of improvements, the cost-per-bit of SRAM memory on our TPUs started increasing with new technology nodes starting with recent generations. To address these challenges, the industry is shifting away from giant monolithic chips. Instead, chip designers are adopting alternate approaches that combine several small chiplets into a single package. 

Chiplets come with several advantages. Their reduced die size improves yields and costs, but when connected and packaged together, chiplets can still provide the illusion of a large monolithic chip. The opportunity to mix-and-match different “building block” chiplets allows customized solutions to be quickly developed for different usage models. Additionally, different IP blocks can be manufactured in different process technologies best suited for the function: for example, input/output (I/O) blocks can be manufactured in older process technologies while performance-sensitive compute blocks can be built on the latest technology generation. Such heterogeneous technology matching can avoid the long delays associated with migrating the full IP portfolio to the leading technology node.

However, chiplets also come with several challenges: increased complexity and costs for packaging and testing; potential power, area, and performance overheads associated with disaggregating the design over multiple chiplets; and increased supply chain complexity. Additionally, higher levels of the systems stack (e.g., operating system and scheduling subsystems) may need to become “chiplet-aware” to optimize for the added heterogeneity. 

To realize the promise of chiplets and address their challenges, we believe that we need a broader chiplet ecosystem that adheres to a few key principles that we have historically seen to be effective:

The ecosystem needs to be open. Chiplet IPs need to be interoperable across different vendors and foundries, and support multiple process nodes (both mature and leading-edge) and packaging technologies. The ecosystem needs to support diverse customer use-cases, with reduced friction to customization, and support broad industry engagement and contribution.

The ecosystem needs to support complete end-to-end specifications including standardization across interfaces, protocols, packaging, testing, and manufacturing, to meet aggressive customer use-cases. For example, for some accelerator use-cases, the physical layer (the chiplet die-to-die interface) needs to support Tbps/mm bandwidth densities at nanosecond latencies and sub-pJ/bit energy efficiencies. Similarly, advanced cost-effective packaging options need to be supported including 3D integration. Likewise, the protocol stack needs to support PCIe, CXL, Arm® AMBA®, and other extensible custom solutions. 

The ecosystem needs to address system-level aspects such as physical form factors, but also security, manageability, and reliability. Common interfaces are needed for discovery, configuration, monitoring, and out-of-band management. Chiplets need to be established with 100% trust on every boot, with appropriate cryptographic key exchanges with roots-of-trust. In-situ (in-system) testing and repairability is important from a quality and reliability perspective. Standardized physical footprints (standardized die-areas, common naming convention, choice of interposers, compatible power supplies) are important to drive common mechanical dimensions for easy system and package integration. 

Google has a long history with open and standards-based ecosystems, and we are committed to fostering similar open ecosystems for chiplets as well. We have been investing in open standards through our leadership in the Open High Bandwidth Interface (Open HBI) die-to-die interface standard and publishing the OpenChiplet specification to define a layered architecture for interoperable chiplets. Today, we are pleased to come together with other industry leaders to collaborate on Universal Chiplet Interconnect Express (UCIe) in service of a multi-vendor interoperable chiplet marketplace for the industry. 

We are at a critical inflection point in the semiconductor industry, one of the most significant changes since the launch of microprocessors as a building block in the 1970s. Navigating this transition will require leaders across the stack from semiconductor manufacturing, assembly, and test vendors, IP development, silicon engineering, and cloud/infrastructure providers to come together on an end-to-end standard and build a vibrant thriving chiplet ecosystem. We invite the community to join us on this journey as we work together to build the foundation for a new era of specialized and sustainable computing to solve the world’s most challenging problems. 

Thanks to Andy He, Rohit Mittal, Mudasir Ahmad, Igor Arsovski, Amber Huffman, Ben Kerr, David Patterson, Ravi Rajwar, Nick Stevens-Yu, Amin Vahdat, Maruthy Vedam for their input to this blog.

Arm and AMBA are registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

When we talk about reimagining the future of work, one group that’s often left out of the conversation is the frontline workforce. The pandemic, however, has reminded us of the importance of frontline workers. With the exodus of frontline workers in the ongoing Great Resignation, there’s now greater urgency for businesses to rethink the workplace experiences on the frontlines.

From healthcare workers to bus drivers, these employees continue to provide the essential services we’ve needed throughout the pandemic. They’ve stocked our grocery store shelves, shipped our packages, and provided crucial services in areas like healthcare and education. Globally, frontline workers make up80% of the workforce and they are the backbone of many key industries such as manufacturing, healthcare, retail, and transport. 

Yet, as businesses scrambled to adapt to the onset of the pandemic two years ago, 65% of deskless workers didn’t have the right technology to do their jobs. By comparison, knowledge workers managed the transition to remote work relatively smoothly. This digital divide has only become wider and harder to ignore over time. To reimagine the workplace for frontline employees, businesses in Asia Pacific need to find ways to bridge this gap. 

Collaboration equity is key  

Businesses that embrace the idea of collaboration equity can move more quickly to close the digital divide. Collaboration equity is the ability for everyone to contribute equally, regardless of location, role, experience level, language, or even device preference. Within organizations, it fosters the kind of culture that breeds innovation, creates stronger human connections, and enhances productivity. 

From a technology standpoint, it means moving away from old ways of working that are often characterized by hierarchies, information silos, and legacy systems. Collaboration equity calls for new technology that empowers employees in the field to be agile, flexible, and more productive—no matter where they’re working from. 

Frontline workers should be able to engage with their peers and gain equal access to information and training resources to be successful in their roles. They should also be able to suggest a new product or service, provide feedback about internal processes, or exchange insights with colleagues across the company. In short, frontline workers should feel heard and included. And research shows that highly engaged employees are87% less likely to leave their companies than their disengaged counterparts. 

How technology is shaping work on the frontlines in APAC

It’s great to see that some Asian Pacific businesses in industries such as retail, travel, and manufacturing are adopting cloud technologies to empower their frontline workers. At Google, we work with customers in many of these industries—and we see how a cloud-based solution like Google Workspace can transform the frontline work experience.

For one thing, it gives frontline workers everything they need to do their work, all in one place: access to files, seamless collaboration, corporate communication channels, and intuitive search functions. Employees can also work on their mobile devices securely without a VPN, thanks to built-in Mobile Device Management.

Google Workspace can vastly improve how frontline employees connect, create, and collaborate—both with their frontline peers and corporate colleagues.

Pulling down barriers to communication 

Unlike office-based workers, frontline workers often lack access to digital tools to collaborate with their colleagues, and technology needs to do more to fill this gap. With many of our customers in APAC, including large retailers, Google Workspace is keeping thousands of employees connected across stores, offices, and regions. Employees can collaborate with their colleagues company-wide, with access to internal tools like Chat and Spaces.

Providing these engagement tools helps to create a sense of community. People are also kept in the loop on important information, such as a new promotion at a regional store or the latest company news. And because people feel included, it gives them a sense of belonging and nurtures the affinity for the company they work for. 

Lifting the burden of manual, repetitive tasks

Across APAC, we’re continuing to see more mobile apps automating manual tasks for employees. This is good news for frontline workers, since many of them believe that automation will offer them an opportunity to qualify for more highly skilled work. Asia is also making big strides in the area of AI innovation. Using digitization, for example, the person who delivers parcels can easily mark a delivery complete by uploading a photo to a corporate system. And in manufacturing, AI automates tasks such as maintenance and safety reporting for shop floor and field workers. Relieved of repetitive tasks, people can engage in more meaningful work, resulting in improved job satisfaction. Google Workspace will continue to play an important role in this area.

Enabling smoother collaboration and teamwork

In a recent global hybrid work survey commissioned by Google Workspace, nearly 60% of people in APAC say that limited ability to collaborate leaves them frustrated. But it’s a workplace frustration businesses can easily address. When Korean Air moved its work processes to the cloud in 2019, it made collaboration easier and smoother for its cabin crew and ground staff. Its cabin crew started using Drive, allowing them to easily share flight details about in-flight meals and galley management with each other. Flight attendants no longer had to compile weekly meeting memos. Instead, they started working from a shared document on Docs that stayed updated in real time. These new tools have improved workplace communication, creating a smoother experience for Korean Air’s staff. 

We’re at a turning point as we figure out what the future of work will look like. And it’s not too late for businesses to rethink the workplace for their own frontline workforce. With the chance to hit reset, businesses can now prioritize what matters most: the happiness and job satisfaction of frontline employees as they serve customers. All frontline workers want to feel included, to be able to contribute effectively from anywhere, and to collaborate more easily with their co-workers. And the crucial first step to making this happen is empowering frontline employees with the digital tools to improve their workplace experience.

On November 30th, 2021, Google submitted Knative to be considered as an incubating project, which began the process for handing over the project to be managed by the Cloud Native Computing Foundation (CNCF). Today we are pleased to acknowledge the completion of this process, allowing the next phase of community-driven innovation in Knative to begin. 

In 2018, the Knative project was founded and released by Google and subsequently developed in close partnership with IBM, Red Hat, VMware, and SAP. Over the last three years, Knative has become the most widely-installed serverless layer on Kubernetes. We built Knative to provide the essential components you need to build, deploy and manage modern serverless workloads anywhere you choose, and open sourcing this technology provided the industry with an open Serverless platform to help drive innovation. 

Google remains one of the top contributors over the lifetime of the project to date, helping Knative to deliver on its key objectives of portability and ease of use. Moving forward, we plan to continue to fund the project with credits towards Knative infrastructure to support the project’s growth in its new home. We worked with other major contributors to set up a governance structure and conformance certification process geared to provide longevity for Knative.

Acceptance into the CNCF marks a milestone for Knative. Google endeavors to continue supporting the project with a diverse set of maintainers as members of the Knative community, and to  offer compatible services to customers. At Google, we build managed services based on open source technologies directly into Google Cloud so developers don’t have to be experts, and can seamlessly port and deploy their applications to the cloud when ready. 

We believe that using open source comes with a responsibility to contribute, sustain, and improve open source, which we are committed to doing through our work with partners, foundations, and maintaining and growing critical cloud native projects on behalf of our customers and the community at large. This is a significant milestone for the project and we are excited to see what’s next. Be sure to keep up to date with everything Google is doing to support Knative and drive serverless innovation. We plan to host Knative Day at KubeCon EU, and offer access to learning from the top Google minds in Open Source through our Innovators program, to help our customers grow, innovate and keep building.

Business leaders see much in Artificial Intelligence, including new ways to save money, serve customers, and figure out what to build. What’s often tougher is deciding how to engage. That’s understandable, since getting into AI often raises questions about costs, data integrity, project length, and similar issues of planning and execution.

For CIOs concerned with the deployment and use of IT at their companies, these are critical issues. Here is one way to think about this complexity, by breaking it down into three different areas; Early Automation, Learning and working, and System Views. 

First, a bit of good news and myth dispelling for readers who think AI is some far off promise, still in the labs and not safe for work. The reality is that AI is very much here, and almost everyone in your workplace is using it every day. People work with AI when they use Google Search, Photos, the autocomplete feature in Docs, live translation in Pixel phones, and many other areas. It is in the products of many other companies too. 

“IDC reports that the market for AI software, hardware and services is expected to break the $500 billion mark in 2023.”

Additionally, it’s increasingly clear that AI can be adapted as a virtuous process, not just a one-off purchase (though there is much to recommend that.) During a recent Alphabet earnings call, CEO Sundar Pichai noted that “investments in AI will be key” to its near-term strategy, with new techniques that make it faster and easier to train and build AI for a number of uses. Additionally, the company is offering AI-driven “insights, new tools, and automation” to its advertising clients. The striking thing in this was the way that developing AI in one area could lead to growth in many others.  

So, how does an IT leader foster a growth process like this for their stakeholders? By leading people through the well-established stages of Awareness, Learning, and Extension. Here’s what I mean.

Awareness: Early Automation

Consumer-facing AI is particularly strong in communications functions like voice recognition, translation, and writing tips. It’s similar in business uses: One of the most effective early instances of AI in the workplace has been Contact Center AI (CCAI), which manages basic customer communications, automatically answering common questions and prioritizing calls that require human assistance. It is doing what automation has always done best, automating the rote stuff and leaving the higher-value imaginative activity to people. It has been used by governments, retailers, telecommunications companies, and others, in a wide variety of use cases.

These and similar language-centric products, like DocAI for extracting information from things like invoices, receipts, or AI that extracts information from business contracts, have a number of benefits. For one, the investment is relatively easy to control, unlike with a research project leading to a formal launch. The payoff is also clearer. In the case of contact centers, in particular, the automation relieves stress, wins loyalty and slows disaffection in a high-turnover area. In both cases, successful results build allies in the business, who can testify to the earlier benefits when it’s time to take on something more complex. 

Perhaps best of all, creating interest in basic AI services for business, right now, means people become engaged in learning more, since they see the early benefits and wonder what else might be done.

Learning: The Human Factor

The Natural Language Processing (NLP) that goes into these ready made, “out of the box” AI products can, not surprisingly, be used on much more sophisticated levels. Twitter, for example, processes 400 billion different events in real time, and its staff queries this trove using advanced NLP, answering questions and improving customer experiences.

There is clearly an enormous gap between Call Center AI and processing Twitter’s 400 billion events per day, but it’s not noticed enough how quickly that gap is closing. Look at how many products, partners, and training resources have emerged in the past few years. The gap makes sense, insofar as both the means of AI (like large data sets, good algorithms, and sufficient computing) and the value of AI, are new. 

Increasingly, as AI is incorporated into standard enterprise tools like spreadsheets and analytic tools, easier to use AI becomes a skill within reach for many (even as the advanced end becomes more complex, meaning this ease of use process will continue for some time.) 

It’s so new that AI skills demand isn’t met by conventional education means, creating lots of good opportunities for both nonstandard skills training, and in-house learning in the workforce. Companies offering AI skills training could well gain a competitive advantage and retain staff better. 

Extension: Building System Views

When a new technology lands and gains in popularity, people seek to find new uses for it, or build connections among its different uses. Networked computing is one example, but think also of the way cars were soon followed by trucks and fire engines, or the way the data services on wireless phones soon morphed into the App Economy. If something is useful, people look for ways to grow it.

How will AI grow? My colleague Dominik Wee recently wrote about ways that AI will soon change supply chains, change product design, and improve sustainability. Most interestingly, he talked about how customers in manufacturing were realizing savings and gaining insights when once separate quality control data was combined with system wide views of the quality process.

There are several reasons to think AI will promote many such system views. For one thing, successful AI promotes the collection of data from more places, at greater frequency, since that leads to insight (and the cost of data collection is dropping.) Additionally, AI is good at spotting patterns and interactions that are not currently known. As well, AI is used in prediction and scenario planning, which leads to better understanding of how large-scale systems interact. 

This comes at a time when we have more ways of seeing the world, from satellites, sensors, social media, and much more. We have more awareness of interactions, and a demand to understand them, in everything from the supply chain crisis, to human rights and sourcing regulations, or in the business realities of partnering, and serving customers in all sorts of ways, online and in the physical world.

Whether by coincidence or design, the Age of AI is also an age when organizations see themselves more accurately with a rich web of connections, with their choices and actions having more resonance than ever. That awareness is both a competitive tool, and a call to greater responsibility, potentially affording more customer loyalty and a more satisfied workforce for those who get it right. 

That transformation won’t happen everywhere overnight, but it seems to be happening at all sorts of companies. And the trend for AI to assist, to be studied and grown, and to provide a richer understanding of the world, is happening every time someone touches this technology, at whatever level they need.