Cloud

In our previous post, we discussed various cost optimization strategies that we here at Wayfair identified to use on a render platform that we had recently moved to Google Cloud using a lift-and-shift migration strategy. In this post, we’ll shift our focus to how we applied those strategies to plan and execute the initiatives, and share what we learned.

Plan and execute

Once we identified the key cost and usage levers, our workgroup partnered with engineers, analytics, and Google Cloud to come up with a plan and execution framework. We set up high-level objectives and key results with a baseline and target to align the team and get stakeholders’ buy-in.

Objective: Render each asset most efficiently without compromising on quality
KR1: Reduce Render Core Cost Per Hour by 30%
KR2: Reduce Avg Render Time Per Image Request by 35%

Initiatives and prioritization

We identified our key initiatives and pushed teams to come up with efforts and ROI calculations for each of them, and placed them on a quadrant of savings and efforts. Using this quadrant we identified low-effort initiatives that will yield mid-to-high savings. We also identified other high-cost high savings initiatives, and saved them for later. You can find other examples of balancing effort with spend in the following diagram.

Using the framework above we executed the following initiatives in the order outlined:

Jun 2022

Implement cost dashboards: We created a deep-dive Render cost dashboard using Cloudability to track every aspect of the spend on the Render Farm by providing daily, weekly and monthly trends on each bucket of cost on the Google Cloud project for Rendering, providing engineers and leaders a clear view of spend on Google Cloud.

Schedule shutdowns: One of the first things we did was shut down a high percentage of farm capacity on the weekend; this was a no-brainer after looking at the render-hour usage data on weekends. 

Optimize render settings: We adjusted Global Illumination, Max Subdivision, and Radiance for scenes used in modeling to reduce the number of hours needed to produce images with similar quality.

Rightsize Automated farm: We also cut the Automated farm size by 30% to improve the overall farm utilization based on the usage models.

Jul 2022

Deploy multiple MIGs with Instance Types: For our on-prem render nodes, we initially optimized them for the top 10th percentile workload with the Google C2D-Standard-30 instance type. Based on recommendations from Google we benchmarked the new TAU instances and found their T2D-Standard-16 performs better for 90% of our use cases with a savings of more than 50%.

Reduce images per round: We noticed that some images rendered on the farm did  not add any value, and in certain cases were never utilized at all. We removed certain class-specific images from rendered requests to reduce the wasted renders per round of work, and hence reduce workload requirements further.

Implement self-service render usage dashboard: We worked closely with our partners in Data Engineering to create real-time visibility into render-hours usage along with the ability to slice data around various dimensions to allow them to identify any waste as early as possible and address it the same.

Aug 2022

Autoscaling: In close partnership with Google Cloud and the analytics team, we created a custom scaling algorithm that looks into current farm usage, submission volume and patterns to control the deployed nodes on the farm at regular intervals; this helped us achieve a target utilization of 90%+ on the render farm.

In a period of 5 months from May 2022 to Sep 2022, our monthly costs went down by approximately 85%. We achieved all this without any impact on core business objectives around imagery quality or speed of delivery. And we’re not done yet: we’re planning to drive further savings of ~25%+ by eliminating license costs over the next few months. In addition, we will be exploring Spot instances and optimizing Artist pools further to drive further savings on the cloud.

Gaining knowledge through experience 

Throughout the cost optimization process, we learned a lot. Here are some highlights. 

Work collaboratively

The speed and level of optimization we saw were possible due to a very tight collaboration between engineering, business, infrastructure, and Google teams. The business played an instrumental role in identifying opportunities to optimize and rightsizing the quality and throughput of the pipeline. Google Cloud team jumped in multiple times during design phases to point us in the right direction when selecting machine types or building algorithms to auto-scale within constraints, helping us save more. They even helped for cost modeling. The  Google teams were tremendously insightful.

Plan and execute

Going in, we set clear rules for ourselves: Design and pressure-test initiatives. . Whiteboard before keyboard to validate each initiative. And prioritize initiatives ruthlessly during deep dives. There are so many ways to achieve the end goal, but sequencing them using Google’s FinOps and Cost optimization framework helped us plug the leaks immediately with low-effort, high-savings initiatives. Once we identified the initiatives, we delivered them in small increments every couple of weeks, driving immediate impact on our spend.

Measure and iterate

Finally, we created realistic objectives and measurable key results for the team and provided complete transparency to every member of the team through weekly metric reporting. To drive accountability and ownership on an ongoing basis, we created reports and dashboards along with proactive monitors to provide teams with deep-dive data on render-farm usage, and daily costs. Best of all, we’re just getting started: Thanks to the visibility provided by these data points, we continue to identify opportunities to fine-tune both cost per hour and render hour usage. To learn more about how to identify and implement cost savings in your environment, we highly recommend Google Cloud’s whitepaper, Understand the principles of cloud cost optimization. 

Googler Hasan Khan, Lead Principal Architect, Retail Global, contributed to this post.

At Wayfair, we have content creation pipelines that automate some portions of 3D model and 3D scene creation, and render images from those models/scenes. At a high level, suppliers provide us with product images and information about dimensions, materials, etc., and we use them to create photorealistic 3D models and generate proprietary imagery. But creating these 3D renders requires significant computation (rendering) capabilities. Last year, we performed a lift-and-shift migration to the cloud, but because we hadn’t optimized our workloads for the cloud, our costs bubbled up substantially. We worked closely with Google Cloud to optimize our render platform, driving an estimated ~$9M of savings on an annualized basis. 

Let’s take a look at how we did it.

Lift and shift to Google Cloud

We’ve been working with the Google Cloud team to complete the transition from a hybrid cloud to a Unified Public Cloud strategy. We have two different “farms” that we use, one primarily for automation tasks and the other for rendering tasks with: 

The Automation farm is managed using OpenCue to dispatch jobs to the nodes 

The Render Farm uses Deadline to dispatch jobs to the nodes; we completed migrating it from on-premises to the cloud In Q2 2022.

Here’s our lift-and-shift deployed architecture on Google Cloud:

During the migration, our goal was to provide as-is SLAs to our customers without compromising the quality of the pipelines. Post-migration, we recognized inefficiencies in the deployed architecture, which was not well suited for the economics of the pay-as-you-go cloud model. In particular, the architecture had:

Poor infrastructure optimization with fixed farm size and one-size-fits-all machines

Missed opportunities for automation and consolidation

Minimal visibility into cost and render-hour usage across the farm

Wasted usage on rendering due to non-optimized workflows and cost controls

We realized that we could do better than a one-size-fits-all model. With a variety of compute available from Google Cloud, we decided to take advantage of it for the farm. This would help us not only optimize but also provide better visibility and the render-hour usage across the rendering farm, for greater savings.

Cost optimization strategy

We followed the three Cloud FinOps principles — inform, optimize and operate — to create a holistic strategy to optimize our spending and drive sustained governance going forward.

Simplified view

To create an execution plan, the first step was to thoroughly understand what was driving our cloud spending. When on-prem, we didn’t have a lot of insight into our usage and infrastructure costs, as those were managed by a centralized Infrastructure team. During deep dives, we realized that due to a lack of visibility into usage in our current state, , we had many inefficiencies with our deployed infrastructure footprint and how the farm is used by artists and modelers. 

We formed a focused team of engineers, business stakeholders, infrastructure experts, and Google Cloud to drive discussions. To optimize rendering costs we needed to not only drive down the cost of the rendering platform but also optimize the workflows to reduce the render hours usage per asset. We developed a simplified formula of all-inclusive render cost per core hour and time needed for each asset, making it easier for each team to drive objectives with focus and transparency. On Google Cloud, we were shifting the focus from an owned asset to pay-per-usage model.

Identifying cost levers

One of our goals was to optimize all-inclusive cost to render per hour. We categorized the overall spend on the farm into various funnels, and assigned weights to the impact each lever can drive. At a high level, we looked into the following key areas:

Nodes – Are we using the right machine size and configurations on the farm? The current deployment had a single pool which forced the machine size to be optimized for worst-case usage, leading to waste for 90% of our use cases. Can we use GPU acceleration to optimize render times? What about leveraging instance types like Spot?

Utilization – How is the per node and overall farm utilization over 24X7X365? We looked at usage and submission patterns on the farm along with utilization to find out ways to drive efficiency. 

Licenses – Because of the change from Enterprise License on-prem to Data Center license on Google Cloud, we were seeing license costs around 45% of the overall spend on the farm. What are the software license fees leveraged on the farm? What constraints do they enforce on scaling needs?

Other – We looked at storage, network transfers, and other miscellaneous costs on the farm. Together, they only accounted for 8% of the overall spend, so we deemed them insignificant to optimize initially.

Levers for optimizing usage

As part of our holistic strategy, we also set goals for improving workflow efficiency to optimize rendering hours. We realized during cost modeling that we could unlock large benefits by reducing the hours needed for the same unit of work. At a high level, we looked into the following areas:

Render quality – Can we optimize render settings like Irradiance, Noise, Threshold, and Resolution to reduce the render hours needed for each request without substantially impacting the quality of final renders?

Work unit – Can we reduce the number of render frames, render rounds, and angles for each request to reduce the number of renders needed per request and reduce waste in the pipeline?

Complexity – Can we look into optimizing specific materials or lightning settings and frames to reduce render complexity? Can we look at render requests at p90 based on render hours and create a feedback loop? 

Artist experience – Can we improve the artist workflow by providing them with cloud workstations with local rendering and storage management to reduce the indirect invisible costs associated with rendering?

In our next article, we discuss how we applied the above strategies to plan and execute these initiatives, and share what we learned.

Googler Hasan Khan, Lead Principal Architect, Retail Global, contributed to this post.

For years, Google Cloud has been driving business transformation across the financial services industry with native and partner solutions. These solutions help customers drive top line growth, improve efficiency, and better manage risk. Among these are a growing number of tools for improving how financial services organizations solve for increasingly complex regulatory requirements. Collectively known as RegTech, these solutions not only make it easier to manage regulatory requirements, but they also represent an opportunity for organizations to become more agile and efficient in an increasingly digitized marketplace. RegTech can also simplify the work of the regulators themselves and provide better industry-wide insights. 

The driver behind RegTech is the same as it is for FinTech: digital transformation. Banks, insurance companies, and other financial services organizations are now leveraging Google Cloud across the board for a number of strategic use cases, including anti-financial crime and risk modeling. 

Google Cloud’s role is to support customers where they are in their modernization journeys with our own technology fortified by a robust ecosystem of partners. As a platform provider, Google Cloud supports these efforts in three ways: 

Offering ways for vendors to modernize their legacy reporting applications 

Supporting organizations in building net-new cloud-native solutions

Providing our own technology with which financial services organizations can streamline and automate the regulatory reporting process

Robust infrastructure and security for modernizing legacy reporting applications

Google Cloud’s robust, highly scalable global infrastructure provides a secure-by-design foundation with a shared-fate model for risk management supported by products, services, frameworks, best practices, controls, and capabilities to help meet digital sovereignty requirements. This infrastructure creates an opportunity for established software providers with a wide on-premises user base to modernize their tech stacks so they can leverage cloud capabilities either as a managed service or a SaaS solution. 

For example, Regnology, a provider of regulatory reporting solutions, has partnered with Google Cloud to bolster its regulatory reporting offering with a fully-fledged cloud service known as Rcloud. The platform uses Google Cloud infrastructure to enhance Regnology’s regulatory reporting offering across its complete set of cloud-native solutions and managed services, with vertical and horizontal scaling for better performance and greater efficiency. Underpinned by Google Cloud, Rcloud benefits from improved deployment and infrastructure-as-code services, run and change management automation, high scalability, and future-proofed architecture for additional services and products. Furthermore, Regnology Rcloud’s integration with BigQuery allows organizations to build a granular and cohesive finance and risk warehouse, which can be leveraged to improve the efficiency of the end to end data supply chain.

“We are excited to be partnering with Google Cloud to develop an enhanced platform for our customers, presenting a seamless delivery of service as part of a one-stop shop offering,” says Rob Mackay, Chief Executive Officer at Regnology. “Our mission is to connect regulators and the industry to drive financial stability, and as such it is important to us to build the future of regulatory reporting on energy efficient and scalable architecture.”

Powering cloud-native RegTech solutions with data and AI

Google Cloud’s advanced data and AI capabilities, such as BigQuery, Vertex AI, and Apigee API management, have attracted newer RegTech players as well. Google Cloud partner Quantexa, for example, offers a Decision Intelligence platform powered by Google Kubernetes Engine (GKE) and tools such as Dataproc. The solution gives customers the ability to understand their data by connecting siloed systems and visualizing complex networks. The result is a single view of data that becomes their most trusted and reusable resource across the organization. Quantexa provides an intelligent “model-based” system that probes networks and behavior patterns to uncover financial crime, allowing customers to better comply with anti-money laundering (AML) regulations. Quantexa helps customers establish a culture of confident decision making at strategic, operational, and tactical levels to mitigate risk and seize opportunities.

Google Cloud is key to Quantexa’s ability to generate real-time, AI-driven financial crime alerts, according to Quantexa CTO Jamie Hutton. In particular, GKE provides Quantexa the scaling power to effectively deploy Elasticsearch, an enterprise search engine for data querying that’s central to Quantexa’s entity resolution and network analytics. “We deploy Elasticsearch in Google Kubernetes Engine, which gives us the ability to scale as required on a granular process level,” says Hutton. “And because Google is the architect of Kubernetes, we know that we always have the latest updates and features available with Google Kubernetes Engine, ahead of any other provider.”

Google Cloud tools to facilitate regulatory reporting 

Google Cloud powers out-of-the-box solutions, such as Google Cloud Regulatory Reporting Platform, a scalable, on-demand serverless solution with data controls built into the architecture at each step to maximize performance and reliability while minimizing operational effort. You can store and query large, granular datasets in BigQuery as a consistent (and cost-effective) source of high-quality data to power multiple report types (e.g. across risk, financial and regulatory reporting). 

Google Kx for CAT is an enterprise-grade application designed to accommodate the sophisticated and complex reporting transformations required by The Consolidated Audit Trail (CAT). CAT is a regulatory reporting obligation for U.S. broker-dealer firms and demands the kind of intensive compute power and storage requirements historically associated with bespoke implementations.

Google Cloud Analytics Hub is a data exchange that allows you to efficiently and securely exchange data assets across organizations to address challenges of data reliability and cost. Analytics Hub enables data providers like Dun & Bradstreet to publish their data sets for analysis in BigQuery. Regulators, for example, can access this information to see how individual banks and financial services institutions are being compliant.

Where will the RegTech journey take us?

RegTech is a rapidly growing and maturing area with tremendous potential not only to make it easier for financial services organizations to meet their regulatory obligations, but also to deliver real business value. Google Cloud’s goal is to enable customers to maximize that value, whether the solutions are native to Google Cloud or offered by one of our many partners. As the field progresses, it’s likely to bring new capabilities and insights that go beyond compliance to manage risk, support growth and improve customer experience.

Learn more about how Google Cloud’s RegTech capabilities are making it easier for organizations to meet their regulatory responsibilities and more.

Cloud Bigtable is a scalable, distributed, high-performance NoSQL database that processes more than 6 billion requests per second at peak and has more than 10 Exabytes of data under management. Operating at this scale, Bigtable is highly optimized for high-throughput and low-latency reads and writes. Even so, our performance engineering team continually explores new areas to optimize. In this article, we share details of recent projects that helped us push Bigtable’s performance envelope forward, improving single-row read throughput by 20-50% while maintaining the same low latency.

Below is an example of the impact we delivered to one of our customers, Snap. The compute cost for this small-point read-heavy workload reduced by 25% while maintaining the previous level of performance.

Performance research

We use a suite of benchmarks to continuously evaluate Bigtable’s performance. These represent a broad spectrum of workloads, access patterns and data volumes that we see across the fleet. Benchmark results give us a high-level view of performance opportunities, which we then enhance using sampling profilers and pprof for analysis. This analysis plus several iterations of prototyping confirmed feasibility of improvements in the following areas: Bloom filters, prefetching, and a new post-link-time optimization framework, Propeller.

Bloom filters

Bigtable stores its data in a log-structured merge tree. Data is organized into row ranges and each row range is represented by a set of SSTables. Each SSTable is a file that contains sorted key-value pairs. During a point-read operation, Bigtable searches across the set of SSTables to find data blocks that contain values relevant to the row-key. This is where the Bloom filter comes into play. A Bloom filter is a space-efficient probabilistic data structure that can tell whether an item is in a set, if it has a small number of false positives (item may be in the set), but no false negatives (item is definitely not in the set). In Bigtable’s case, Bloom filters reduce the search area to a subset of SSTables that may contain data for a given row-key, reducing costly disk access.

We identified two major opportunities with the existing implementation: improving utilization and reducing CPU overhead.

First, our statistics indicated that we were using Bloom filters in a lower than expected percentage of requests. This was due to our Bloom filter implementation expecting both the “column family” and the “column” in the read filter, while a high percentage of customers filter by “column family” only — which means the Bloom filter can’t be used. We increased utilization by implementing a hybrid Bloom filter that was applicable in both cases, resulting in a 4x increase in utilization. While this change made the Bloom filters larger, the overall disk footprint increased by only a fraction of a percent, as Bloom filters are typically two orders of magnitude smaller than the data they represent.

Second, the CPU cost of accessing the Bloom filters was high, so we made enhancements to Bloom filters that optimize runtime performance: 

Local cache for individual reads: When queries select multiple column families and columns in a single row, it is common that the query will use the same Bloom filter. We take advantage of this by storing a local cache of the Bloom filters used for the query being executed.

Bloom filter index cache: Since Bloom filters are stored as data, accessing them for the first time involves fetching three blocks — two index blocks and a data block — then performing a binary search on all three. To avoid this overhead we built a custom in-memory index for just the Bloom filters. This cache tracks which Bloom filters we have in our block cache and provides direct access to them.

Overall these changes decreased the CPU cost of accessing Bloom filters by 60-70%.

Prefetching

In the previous section we noted that data for a single row may be stored in multiple SSTables. Row data from these SSTables is merged into a final result set, and because blocks can either be in memory or on disk, there’s a risk of introducing additional latency from filesystem access. Bigtable’s prefetcher was designed to read ahead of the merge logic and pull in data from disk for all SSTables in parallel.

Prefetching has an associated CPU cost due to the additional threading and synchronization overhead. We reduced these costs by optimizing the prefetch threads through improved coordination with the block cache. Overall this reduced the prefetching CPU costs by almost 50%.

Post-link-time optimization

Bigtable uses profile guided optimizations (PGO) and link-time optimizations (ThinLTO). Propeller is a new post-link optimization framework released by Google that improves CPU utilization by 2-6% on top of existing optimizations.

Propeller requires additional build stages to optimize the binary. We start by building a fully optimized and annotated binary that holds additional profile mapping metadata. Then, using this annotated binary, we collected hardware profiles by running a set of training workloads that exercise critical code paths. Finally, using these profiles as input, Propeller builds a new binary with an optimized and improved code layout. Here is an example of the improved code locality.

The new build process used our existing performance benchmark suite as a training workload for profile collection. The Propeller optimized binary showed promising results in our tests, showing up to 10% improvement in QPS over baseline. 

However, when we released this binary to our pilot production clusters, the results were mixed. It turned out that there was overfitting for the benchmarks. We investigated sources of regression by quantifying profile overlap, inspecting hardware performance counter metrics and applied statistical analysis for noisy scenarios. To reduce overfitting, we extended our training workloads to cover a larger and more representative set of use cases. 

The result was a significant improvement in CPU efficiency — reducing fleetwide utilization by 3% with an even more pronounced reduction in read-heavy workloads, where we saw up to a 10% reduction in CPU usage.

Conclusion

Overall, single-row read throughput increased by 20-50% whilst maintaining the same latency profile. We are excited about these performance gains, and continue to work on improving the performance of Bigtable. Click here to learn more about Bigtable performance and tips for testing and troubleshooting any performance issues you may encounter.

Insurance management has come a long way in recent years, with new technologies and tools emerging to streamline processes and improve customer experiences. However, many insurance companies are still using legacy systems that are slow, inflexible, and difficult to integrate across different channels.

One of the biggest problems with legacy insurance management systems is their lack of agility. These systems are often built around specific channels or products, and are not designed to adapt to new technologies or changing customer needs. When companies want to introduce new products or channels, they need to go through a new development cycle, which results in a long time to launch. 

To help solve this issue with legacy systems, Igloo, a regional insurance technology company that provides digital solutions to players in the insurance value chain, developed its platform Turbo, which operates across multiple business lines including B2B2C, B2A (business to insurance sales intermediaries such as agents), and B2C. Through Turbo, Igloo is able to deliver the same products and services across multiple distribution channels, including e-commerce, offline retail stores, and Igloo’s own digital solution for insurance sales intermediaries, the Ignite mobile app. To achieve this level of consistency and flexibility, Turbo allows insurance experts without coding knowledge to self-manage the product launch process.

One example of this system in action is the way Igloo provides gadget insurance (covering electronics accidental damage, water damage, and extended warranty). The same product — with consistent benefits and levels of service excellence — can be distributed at scale via e-commerce platforms, sales agents from retail stores, or through direct channels. This not only ensures a consistent customer experience and, hence, customer satisfaction, it also allows Igloo and its insurer partners to reach a wider audience.

A no-code platform for any user to easily and quickly launch new insurance products across channels

Another key issue associated with managing multiple channels and product launches is that it can be a complex and time-consuming process. Past methods of launching insurance products often require coding knowledge, limiting the involvement of non-technical staff. This can lead to delays, errors, and a lack of speed and flexibility when adapting to changing market demands.

Whether it’s launching a new product, or making changes or updates to existing insurance policies, Turbo’s no-code approach allows insurance experts to self-manage the product launch process. A user-friendly interface guides users through the process of setting up new products and launching them across multiple channels. This not only allows for faster and more efficient product launches, but also gives insurance experts more control and flexibility over the process.

In addition to providing more control and flexibility, Turbo reduces the risk of errors and inconsistencies. By centralizing the product launch process, Igloo can ensure that all channels receive the same information and that products are launched with the same level of quality and accuracy. This helps to build trust with customers and ensures that Igloo maintains its reputation as a leading insurance provider.

The diagram below illustrates how Turbo functions, following the insurance logic and process required for every new policy signup.

There are nine key benefits that Turbo provides to its users, namely: 

No-code – Anyone and everyone can use the platform, since no technical expertise is required

Re-utilization degree – Basic information is pre-filled so no reconfiguration is required, speeding up the process of filling in forms 

Streamlined collaboration – Anyone with access to the cloud-driven platform can use it

Insure logic and process variety – Easy set up with a step-by-step guide for every insurance journey

Presenting flexibility – Enable sales across channels

Purchase journey flexibility – Automate configuration of information for insurance purchasing flexibility to accommodate a variety of needs and use cases 

Low usage threshold – Simple interface and highly intuitive

Short learning curve – User friendly platform

Single truth domain definition – A centrally managed platform where all business logic is managed on the platform for consistency and reliability

“By utilizing Google Cloud’s cloud-native solutions, our insurance product engine, Turbo, has effectively leveraged scalable, reliable, and cost-efficient technologies. This has led to the creation of a sturdy and high-performance platform that enables rapid digitization and seamless deployment of high-volume insurance products across various distribution channels.” – Quentin Jiang, Platform Product Director, Igloo

Helping insurance carriers, channels, and businesses make more informed decisions

In addition to providing a user-friendly interface for insurance experts to self-manage product launches, Igloo’s Turbo system also collects and analyzes valuable data insights after getting users’ consent, without Google Cloud having any visibility into the data. This data includes user views, clicks, conversions, and feedback, which can provide important insights into customer preferences. By automating the collection and analysis of this data using BigQuery, Igloo is able to make faster and more informed business decisions for insurers and insurance agents. For example, if a particular product is underperforming on a particular channel, Igloo can substitute this with a similar product while running analysis to identify issues and make improvements to the underperforming product. This helps to ensure that Igloo is always offering the best possible products and services to its customers, while also maximizing its own business performance. 

Overall, Igloo’s Turbo platform is a powerful tool that allows Igloo to leverage data-driven insights to make faster and more informed business decisions, thereby helping to reinforce its ongoing success as a leading insurtech.

It is amazing how much technology has evolved over the years and continues to do so. AI is no exception to this trend, and it is exciting to see how it can assist us in various ways. There is no denying that many of us using AI have intentionally or unknowingly benefited from it over the past decade.

Regardless of where you are on your AI journey, there are many myths circulating about the role AI will play in our future work lives. Still, no matter your role in the tech stack, the promising reality is that AI is likely to make our lives easier and work more efficient.

In this blog, we are going to walk through a few of the myths floating around related to AI and our future.

Myth: AI will take over all technical jobs.

Reality: AI may automate certain tedious tasks in technical fields, but AI can not replace the creativity, intuition, and problem-solving abilities of human developers.

Today and more heavily in the future, technical job roles will leverage to assist developers and reduce developer toil. AI will help automate tedious and repetitive tasks, such as code reviews, testing, and debugging, which can minimize the time developers spend on these tasks while simultaneously allowing them to focus on more meaningful and innovative work. Overall, this can lead to faster development cycles and better quality software. 

Moreover, the development of AI itself requires human input, including data scientists, machine learning engineers, and software developers. AI is a tool that can enhance human capabilities and helps them to be more efficient and productive in their work.  

No doubt jobs will shift, as they always have. But these AI technologies will complement many jobs and create entirely new jobs we can’t imagine today.

Myth: Only data science experts can use AI.

Reality: While an understanding of data science is useful, you can use pre-trained models, or even experiences powered by AI, without understanding a lick about ML.

The myth that one needs to have a deep understanding of data science to take advantage of AI can be intimidating for those unfamiliar with the field. While understanding the basics of data science can certainly be helpful, it’s not necessary to take advantage of AI in many cases.

One example is pre-trained models, which are models that have already been trained on large amounts of data and are ready to be used for specific tasks, such as classifying images or translating languages1. These pre-trained models can be accessed through APIs and used to power experiences or applications without any knowledge of data science or machine learning required2.

Another example is AI-powered experiences, such as voice assistants or chatbots, that use natural language processing to understand and respond to user input. These experiences are typically powered by pre-trained models and can be integrated into applications without requiring any knowledge of machine learning3.

However, it’s important to note that while it’s possible to use AI without understanding data science, having a basic understanding of the field can make it easier to understand the limitations and potential biases of AI-powered solutions.

Myth: Training custom AI models is too expensive and resource intensive.

Reality: You can customize a pre-trained foundation model

We all know that training a machine learning model can be very resource intensive. It requires a lot of data, computing power, and time which will be a barrier for people who want to train their own models, but don’t have the resources to do so.

There are a number of ways to customize an already-trained foundation model. This can be a good option for people who want to use machine learning, but do not have the resources to train their own models. These uber-models are pre-trained on massive amounts of data and can be fine-tuned to perform specific tasks or cater to specific industries. By fine-tuning a pre-trained model, you can take advantage of the benefits of the original training while tailoring the model to your specific needs.

Another option is to use cloud-based machine learning platforms that offer scalable infrastructure and pre-built tools and frameworks for model development. These platforms can help reduce the computational burden of training your own models and provide access to pre-trained models and APIs.

Myth: AI is just another hype-y technology trend.

Reality: Don’t get left behind!

Unlike the revolving door of much hyped technologies over the past five years, AI is already proving to have an impact on many industries and will likely continue to do so in the future. AI is a disruptive technology that is already transforming businesses and industries by enabling automation, improving decision-making, and unlocking new insights from data. AI-powered solutions are being used in healthcare, finance, manufacturing, transportation, and many other fields, and the use of AI applications is only expected to grow.

Beyond the potential benefits, there are also potential risks associated with AI, such as job displacement, bias, and privacy concerns.

Even for those not in the technical field, AI can provide new job opportunities. Emerging roles like the Prompt Engineer will become increasingly important as the ability of the user to create a “good prompt” that is clear, concise, and easy to understand. It should also be specific enough to elicit the desired output, but not so specific that it limits the creativity of the language model. 

Waiting out AI is not a practical or wise approach. Instead, individuals and businesses should stay informed about the latest developments in AI and explore potential applications in their fields. Beyond career related benefits of AI, it can also improve your personal life by providing commute optimization, home automation or even personal finance recommendations to help you save money4.

Myth: No code/low code AI platforms are only for non technical users.

Reality: No code/low code platforms help bridge the gap between technical and non-technical users

One of the biggest benefits of no code/low code AI platforms is that they make it possible for anyone to build AI applications—think chatbots, or specialized search—regardless of their technical skills. These platforms can help bring technical and non-technical users closer together by empowering both groups to participate in the software development process. Non-technical users can create simple applications using visual interfaces and pre-built components, while technical users can customize these applications and integrate them with other systems.

Additionally, no code/low code platforms can also be useful for technical users, especially those who want to focus on higher-level tasks rather than getting bogged down in the details of coding. For example, a data scientist might use a no code/low code platform to quickly prototype a machine learning model without having to write code from scratch.

No code/low code platforms are extremely powerful and can be used for a wide range of applications, from simple forms and workflows to more complex applications that require data integration, machine learning, and other advanced features. This makes them a valuable tool for organizations of all sizes and industries to benefit from AI without hiring expensive AI developers, enabling both technical and non-technical users to contribute in the software development process, streamline business processes, and accelerate innovation.

AI still needs a human touch

AI is a powerful tool that can be used to make many different technical and non-technical tasks more efficient. However, it is important to remember that it’s not a replacement for human creativity and ingenuity. AI can help us generate ideas, but it is up to us to decide how to use them. 

For example, I actually used AI to help me develop and write this blog, including brainstorming ideas on where to start and how to structure my content. This allowed me to write faster and keep my thoughts organized, but AI did not (and could not) capture my creativity or unique perspective that is needed to make this content relatable and engaging for the right audience. All in all, the reality is that it continues to be up to humans to help AI do its job better. 

Interested in learning more about AI? Follow Google Cloud on Twitter and join us for upcoming Twitter Spaces on June 1st discussing all these AI myths and more!

1. VertexAI
2. Vertex AI API
3. Conversational AI
4. The 10 Best Examples Of How AI Is Already Used In Our Everyday Life

Twilio Flex is an omni-channel CCaaS (Contact Center as a Service) that makes it easy to build personalized support that’s unique to your business. In this post, we will show you how to integrate Flex’s asynchronous channels with Google DialogFlow.

Flex uses Twilio Conversations to natively support conversational messaging use cases such as customer support and conversational commerce via SMS, MMS, WhatsApp, Chat, GBM and FBM.

To integrate Flex with Dialogflow, we will leverage Flex’ Conversations API and SDKs to connect customers to virtual agents so you can use state-of-the-art Agent Assist and Dialogflow CX to handle customer inquiries. If you are looking for a natural language understanding platform to power your Flex asynchronous channels, these are great options; they are easy to implement, flexible, scalable, secure, and cost-effective.

This Dialogflow integration will enable you to easily create rich, natural language conversations using AI over your Twilio digital channels. 

Google Dialogflow with Twilio Conversations Differentiator  

Integrating Twilio’s Conversations API with Google Virtual Agent using Dialogflow allows you to get features that you can tweak and tune to each individual customer’s experience and you can use the power of programmability to drive deep personalization into your conversations. A virtual agent integration can help your organization to improve customer satisfaction while also reducing labor costs and increasing operational efficiency.   

Virtual agents can handle a high volume of simple, repetitive tasks, such as answering frequently asked questions, freeing up human agents to focus on more complex interactions. Additionally, virtual agents can offer 24/7 availability, quick response times, and personalized experiences through the use of data and can interact with customers through multiple channels.

Furthermore, in case a Virtual Agent is not able to resolve an issue for the customer, you can easily hand the conversation over to a human agent to continue the conversation.

Introducing a Google Open-Source middleware to integrate Dialogflow with Twilio Conversation 

At Google our mission is to build for everyone, everywhere. With this commitment in mind, the Google Cloud team has developed and open-sourced the solution for a middleware that is easily accessible and can be used as a foundational building block that integrates conversational messaging over text-based channels from Twilio with Google Virtual Agents. 

How it works

The provided open-source middleware processes the messages from a conversation by invoking Dialogflow API and returns the response from the virtual agent back to the conversation. Therefore,  two layers of communication will be handled by this solution, with Twilio and with Dialogflow. The following diagram describes a high level architecture to be presented.

After going through Twilio onboarding process the middleware can be built and deployed on a fully managed platform such as Cloud Run  

The middleware responsibilities are

Receiving callbacks for incoming messages from conversations connected with a virtual agent participant. 

Managing virtual agent lifecycle while connected with the participant.

Managing the conversation lifecycle between Twilio Conversations and Dialogflow Conversations

Mapping between Twilio Conversations and Dialogflow Conversations with Memorystore.

Processing conversation natural language understanding events from a participant and issuing responses, status and action callbacks to the conversations service.

You can find an examples of the implementation on Github:

Middleware example 

Continue Exploring

In this blog post we described how to integrate Twilio Conversations and Dialogflow CX to deflect customer interactions to a Virtual agent. But this is just the tip of the iceberg. Here are some more ideas you can explore:

Extract the intents detected by the virtual agent to build a snapshot of what the customers are asking for

Enable sentiment analysis and the Virtual Agent will include a score of the customer’s sentiment

Explore handing the conversation to a Twilio Flex Agent if the customer asks to talk to an agent and power with Google Agent Assistfeatures.

Explore using Twilio Studio SendToFlex widget

Check how you can integrate Voice channel here

Conclusion

In this post,  Google has open-sourced a solution for a middleware that can be used to integrate text-based channels conversations from Twilio with Google Virtual Agents powered by Google Dialogflow. Your organization can easily and rapidly build and deploy this middleware on a fully managed platform such as Cloud Run. This can help your organization improve customer satisfaction while also reducing labor costs and increasing operational efficiency in a contact center.  If you want to learn more, review our Agent Assist basics and Dialogflow Virtual Agents pages, and the Twilio Dialogflow CX Onboarding guide to get you started.

Thanks to Aymen Naim at Twilio and Ankita Sharda at Google for their support providing feedback on our content.  We could not have done this without you.

The Google Cloud console is a powerful platform that lets users manage their cloud projects end-to-end with an intuitive web-based UI. With over 120 Google Cloud products across thousands of pages, it can be challenging to navigate through the console quickly, and many users don’t like to use the command line interface. To help, Google Cloud console team recently made several improvements to our search and navigation features, making it easier to find what you need, when you need it.

Expanded resource-type search

One of the most significant improvements to the console’s search feature is the increased resource-type coverage. You can now find instances of nearly all of the over 120 products that Google Cloud offers directly from the search bar, rather than by manually clicking to the details section nested within specific product pages. This wider coverage saves you time compared to browsing through the different product categories to find what you’re looking for. This improvement also allows the console experience team to continuously add new resource types as we develop new features and capabilities in our various product offerings.

Improved documentation search

We also improved the coverage and accuracy of the search experience for documentation, making it easier to find specific pages or interactive tutorials. Developers looking to get started with something they’re unfamiliar with may want to undertake tutorials in the context of their own working environment. Even experienced developers just looking for a quick answer to their question may not want to leave the console, so we expect these improvements can help users of all experience levels.

We’ve heard from you that finding the right documentation from within the console can be tricky, and so we hope this change can save you from needing to switch over to web search to be confident that they’ll find what you’re looking for.

A refreshed search results page

To make browsing search results easier, we also overhauled our search results page by dividing results into tabs, similar to Google web search. This means that you can refine your search by diving into one of those categories individually. In addition to maintaining an “all results” tab, there are tabs for:

Documentation and tutorials

Resource instances, and

Marketplace and APIs

Each tab also has a better filtering experience that’s unique to that search result category. For instance, the Resources tab lets you filter by metadata like the last time a resource was interacted with, while the Documentation tab allows you to search for interactive tutorials only. If you can’t find what you’re looking for in the autocomplete dropdown, try the search results page. It can provide additional results or context to help you find exactly what you’re looking for.

Accurate industry-wide synonyms

Google Cloud console search now interprets industry-wide synonyms accurately — if you’re coming from AWS or Azure and know the name of a product in that ecosystem, searching for it will return the Google Cloud equivalent. A full list of synonyms can be found here. 

General usability improvements

We also shipped several smaller quality-of-life improvements related to search, including:

Improvements to accessibility, including better color contrast and zoom behaviors

Faster latency targets and shorter load times for results

A search keyboard shortcut — just type “/” to begin searching without using your mouse

The ability to search for an API resource by its key

 We also updated the look and feel of our platform bar to a cleaner, more modern experience that’s more in line with the branding across other Google Cloud interfaces.

A customizable navigation menu

Finally, we made usability improvements to the left-hand navigation menu by allowing you to pin specific products. Products can be pinned from the left nav menu or our brand new All Product Page. This is a shift away from the default ordering of products that attempted a “one size fits all” approach to navigation. This customization feature lets you tailor the console to your specific needs and work more efficiently.

Final thoughts

The Google Cloud console’s navigation and search features have come a long way. With these recent improvements, you can find what you need quickly and efficiently, making it easier to manage your cloud resources. From expanded resource-type search to improved documentation search and refined search results, the console is more user-friendly than ever before.

Many digital marketers and analysts use BigQuery to bring marketing data sources together, like Google Analytics and Google Ads, to uncover insights about their marketing campaigns and websites. We’re excited to dive deeper into a new type of connection that adds Google Search data into this mix. 

Earlier this year, Search Console announced bulk data exports, a new capability that allows users to export more Google Search data via BigQuery. This functionality allows you to analyze your search traffic in more detail, using BigQuery to run complex queries and create custom reports. 

To create an export, you’ll need to perform tasks on both Cloud Console and Search Console. You can follow the step-by-step guide in the Search Console help center or in the tutorial video embedded here.

Intro to Search performance data

The Performance data exported to BigQuery has three metrics that show how your search traffic changes over time:

Clicks: Count of user clicks from Google Search results to your property.

Impressions: Count of times users saw your property on Google search results.

Position: The average position in search results for the URL, query, or for the website in general.

Each of those metrics can be analyzed for different dimensions. You can check how each of the queries, pages, countries, devices, or search appearances driving traffic to your website is performing. 

If you’d like to learn more about the data schema, check out the table guidelines and reference in the Search Console help center.  

Querying the data in BigQuery

If you need a little help to start querying the data, check the query guidelines and sample queries published in the help center, they can be handy to get up and running. Here’s one example, where we pull the USA mobile web queries in the last two weeks.

Benefits of Bulk data exports

There are several benefits of exporting Search Console data to BigQuery:

Analyze Google Search traffic in more detail. If you have a large website, this solution will provide more queries and pages than the other data exporting solutions. 

Run complex queries and create custom reports. While the Search Console interface allows you to perform simple analyses, it’s optimized for speed and for the average user. Using BigQuery will open many possibilities in data processing and visualization.

Store data as long as you want. Search Console stores up to sixteen months of data; using BigQuery you can store as much data as it makes sense to your organization. Please note that by default data is kept forever in your BigQuery dataset, if you’d like to limit your storage costs you can update the default partition expiration times. 

Create and execute machine learning models. Machine learning on large datasets requires extensive programming and knowledge of frameworks; using BigQuery ML, you can increase development capabilities and speed with simple SQL.

Apply pre-existing data security rules. If you use BigQuery data security and governance features, you can expand them to include your search data on BigQuery. This means you don’t need separate rules for separate products.

We hope that this solution will help you store, analyze, and visualize your Search data in a more effective and scalable way. If you want to try out the Search Console export in BigQuery, you’ll need a billing account to do so. You can sign up for afree trial and add your billing account to get started analyzing Search Console data.