AWS Network Firewall now supports IPv6 for dual stack subnets so you can filter IPv4 and IPv6 traffic flows to and from the public internet, on-premises network, or any endpoint in your Amazon Virtual Private Cloud (VPC). Now, you can use AWS Network Firewall to protect your IPv6 workloads on AWS.
Read More for the details.
Amazon Elastic File System (Amazon EFS) has increased the maximum number of Access Points per file system from 120 to 1,000, enabling you to control file system access permissions across a larger number of applications in multi-tenant environments.
Read More for the details.
Amazon CloudWatch now provides enhanced visibility into errors in Embedded Metric Format (EMF), with two new error metrics (EMFValidationErrors & EMFParsingErrors).
Read More for the details.
Today, we released two new AWS managed policies for Amazon Detective. AWS managed policies make it easier for users to gain the proper level of permissions to leverage the service for security investigations. AWS managed policies are maintained by AWS to reduce work for customers in managing access permissions for users in specific job roles. For more information on AWS managed policies, you can read AWS managed policies in the IAM User Guide.
Read More for the details.
AWS Managed Services (AMS) Accelerate Operations Plan is now available in Cape Town region. AMS helps you operate AWS efficiently and securely. It provides proactive, preventative, and detective capabilities that raise the operational bar and help reduce risk without constraining agility, allowing you to focus on innovation. AMS extends your team with operational capabilities including monitoring, incident detection and management, security, patch, backup, and cost optimization.
Read More for the details.
Now deploy patch policies across AWS accounts and AWS Regions using AWS Systems Manager Patch Manager and AWS Organizations.
Read More for the details.
In Deloitte’s annual “State of AI in the Enterprise” survey, 94% of business leaders identified AI as critical to their organizations’ success over the next five years. That survey also uncovered a 29% increase in the number of organizations struggling to achieve meaningful AI-driven business outcomes. Part of this challenge lies in the ability to capitalize on existing data, in its various formats spread throughout the organization. For example, up to 80% of enterprise information assets are scattered across the organization in text, PDFs, emails, web pages, and other unstructured formats. This includes a wealth of valuable insights embedded within contracts, buried within patient files, recorded in chat transcripts, noted in EHR/CRM text fields, and present in other formats. This wealth of unstructured data is often untapped, as some business leaders may be unaware of the value or unsure how to leverage it.
Accessing data across various locations and file types and then operationalizing that data for AI usage is usually a cumbersome, manual, time-consuming, and costly process. Individually labeling files to build an adequate dataset to train a machine learning (ML) model is notoriously slow, while human errors and inconsistencies also tend to degrade data quality and negatively impact ML model performance.
Often, analyzing enterprise data requires the expertise of analysts, clinicians, lawyers or other domain specific experts. In highly-regulated industries such as financial services and healthcare, privacy regulations, standards, and other access restrictions make the challenges posed in using unstructured data proportionally higher.
Snorkel AI has teamed with Google Cloud to help organizations transform raw, unstructured data into a format that can be used to train actionable AI-powered models for insights and decision making. By combining Google Cloud services such as BigQuery and Vertex AI with Snorkel AI’s data-centric AI platform for programmatic data curation and preparation, organizations can accelerate AI development 10-100x [1]. Tapping into the value of unstructured data stored in BigQuery and making that data ready for ML training empowers enterprises to incorporate all types of data for training AI models.
Snorkel AI addresses one of the biggest blockers to preparing data for AI development: the massive hand-labeled training datasets needed to prepare data for supervised training of ML models. Snorkel AI overcomes this bottleneck through using a programmatic labeling approach implemented in Snorkel Flow, a novel data-centric AI platform.
Leveraging business logic, and using foundation models as a means of generating labels, data science and ML teams can use Snorkel Flow’s labeling functions to programmatically label data using various sources, including previously-labeled datasets that may have been poorly labeled while encoding knowledge or heuristics from subject matter experts. Snorkel Flow can leverage these multiple data and knowledge sources to label large quantities of unstructured data at scale.
In addition to data scientists, other users in the ML lifecycle, such as ML engineers, can leverage Snorkel Flow to rapidly improve training data quality and model performance using integrated error analysis and model-guided feedback mechanisms to develop more accurate AI applications.
The data-centric AI workflow within Snorkel Flow operates as follows:
Data scientists, ML engineers, and subject matter experts programmatically label large amounts of data in minutes to hours by creating labeling functions.
Upon creating labeling functions, Snorkel Flow generates a probabilistic labeled dataset that is used to train a model within the platform.
Next, data scientists use guided error analysis to analyze the model’s performance deficits. They look for the gaps that facilitate creation of more targeted and relevant labeling assignments. In other words, data scientists and other users specifically work on places where the model is most wrong, or on particular high-value examples, or on commonly confused classes of data.
Next, users collaboratively iterate on these gaps with internal experts, refining or adding labeling functions as needed to label even more data with which they can again feed into the model for analysis.
Users repeat this iteration even after deploying a model and monitoring a slice of production data.
As a result of this loop, the metrics improvements in an AI application are often orders-of-magnitude greater than what can be achieved with model-centric AI and hand-labeled data.
With training data curation and preparation unblocked via programmatic labeling of unstructured data, data scientists can harness the full power of Google’s end-to-end BigQuery ML and/or Vertex AI platforms to fast-track the development of analytics and AI applications. Google Cloud customers can easily deploy Snorkel Flow on their Google Cloud infrastructure using Google Kubernetes Engine (GKE), then consume unstructured, semi-structured or structured data from Google Cloud data services such as BigQuery and Google Cloud Storage (GCS). See the below figure for data sources and integrations.
BigQuery is a serverless, cost-effective, and cross-cloud analytics data warehouse built to address the needs of data-driven organizations. BigQuery breaks down silos across clouds, allowing enterprises to centralize all of their data – structured, semi-structured, and unstructured – in a single secure repository. BigQuery support for unstructured data management includes built-in capabilities to secure, govern, and share unstructured data.
The Snorkel Flow platform integrates natively with BigQuery to streamline and simplify AI development:
With a few clicks, data scientists can immediately pull relevant data from BigQuery directly into Snorkel Flow using the integrated BigQuery connector.
Data can then be labeled programmatically using a data-centric AI workflow in Snorkel Flow to quickly generate high-quality training sets over complex, highly variable data. Snorkel Flow includes templates to classify and extract information from unstructured text, native PDFs, richly formatted documents, HTML data, conversational text, and more.
Newly labeled datasets can then be used to either train custom ML models or fine-tune pre-built models.
Labeled data can be loaded back into the BigQuery environment as structured data.
Top U.S. banks, healthcare, insurance, and other Fortune 500 organizations have used Snorkel Flow to extract information from complex documents such as 10-K reports, clinical trial protocols, technical manuals, rent rolls, legal contracts, and more. One Fortune 500 telecom provider and long-time Google Cloud customer, for example, uses Snorkel Flow to classify encrypted network data flows into key application categories. Using Snorkel Flow’s comprehensive data exploration and error analysis tools, the telco successfully trained 200,000 labels in a matter of hours, achieving 25% better accuracy compared to an internal ground truth baseline.
Google and Snorkel AI have collaborated on a Snorkel research project for Google’s internal use. Google used early versions of Snorkel’s core technology to tackle data labeling for content, product, and event classification problems that were not amenable to manual labeling due to the rapid variations in the labels. Using Snorkel, Google condensed a six month process involving thousands of hand-labeled examples into just 30 minutes and built content classification models that achieved an average performance improvement of 52% [2, 3, 4].
Together, Google Cloud and Snorkel AI enable Fortune 500 enterprises, federal agencies, and other AI innovators to operationalize unstructured data to build and and accelerate AI applications to solve their most critical challenges
To learn more, schedule a custom demo tailored to your use case with Snorkel AI ML experts or watch one of the below recent presentations:
Accelerate AI development by eliminating the pain of manual labeling, delivered by Snorkel AI co-founder Henry Ehernberg as part of a Google Cloud BigQuery Innovation event
Promises and Compromises of Responsible Generative AI Model Adoption in the Enterprise, delivered by Google Director, Cloud Partner Engineering, Dr. Ali Arsanjani at Snorkel’s Foundation Model Summit
[1] Snorkel AI documented customer results reflect 45x, 52%, 98% and similar improvements vs hand-labeling https://snorkel.ai/case-studies/
[2] Case study on Google’s use of Snorkel’s core technology: https://snorkel.ai/google-content-classification-models-case-study/
[3] Harnessing Organizational Knowledge for Machine Learning: https://ai.googleblog.com/2019/03/harnessing-organizational-knowledge-for.html
[4] Snorkel DryBell: A Case Study in Deploying Weak Supervision at Industrial Scale: https://arxiv.org/abs/1812.00417
Read More for the details.
Editor’s note: To kick off the new year and in preparation for NRF The Big Show, we invited partners from across our retail ecosystem to share stories, best practices, and tips and tricks on how they are helping retailers transform during a time that continues to see tremendous change. Lucidworks had previously published “4 lessons learned from 2022’s Cyber 5.” Please enjoy this updated entry from our partner.
Ecommerce retailers that got customers in and buying on Black Friday won an early piece of wallet share. According to Adobe Analytics, shoppers spent more than $9B dollars this Black Friday, a 2% increase from 2021.
For many retailers, Cyber Monday outperformed Black Friday sales. However, Lucidworks saw several of their retail customers buck the Cyber Monday lore and watched website activity peak on Black Friday. For one athletic apparel retailer, search query volume was 60% higher on Black Friday compared to Cyber Monday. Meanwhile, customers on other retail sites stuck to tradition and saw a 96% uptick from Black Friday to Cyber Monday.
Here are four trends Lucidworks, a Google Cloud partner and search solution provider for some of the world’s biggest ecommerce brands, saw from a top athletic apparel retailer as well as insights from Lucidworks leaders.
Nearly 75% of unique individual shopper sessions took place on mobile devices over the course of the Cyber 5, the five days from Thanksgiving to Cyber Monday. On Black Friday, 92% of all unique shopper sessions took place on a mobile device. However, on Cyber Monday, mobile shopping was only 66%. Conversion rates on mobile still lag those on desktop. Statista notes conversion rates were approximately 2.3 percent lower than desktop.
As one could imagine, travel and mobile commerce are strongly tied. As brands get better at connecting every channel, brand engagement and purchase behavior across devices increase. The increased connective tissue with the shopper, particularly through mobile apps, increases the accuracy of targeted offers and products as well.
Search queries for one of Lucidworks’ apparel retail customers topped out at a cool 59 million on Black Friday, with the most searches happening from 10am-11am ET. The number of searches at the same hour on Cyber Monday were nearly three times lower. Unique shopper sessions also peaked on Black Friday, with Thanksgiving day in a close second. Black Friday sessions eclipsed Cyber Monday by about 35%. Search and discovery solutions like Lucidworks, hosted on Google Cloud, are able to handle the scale. Lucidworks leverages Google Kubernetes Engine (GKE) to help manage the Lucidworks search engine at scale through containerized deployments. This enables Lucidworks to develop, test, and release new features quickly and to isolate its workloads. Further, the accessibility, stability, and strong foundation of security provided by Google Cloud are essential during the peak shopping season.
“Promotions across the web, on email, social, and on the site can play a big role in how early shoppers start their browsing and buying,” says Jenny Gomez, Lucidworks VP of Marketing. “Many retailers opt to keep the promotions rolling from Thanksgiving Day through Cyber Monday. Facets, landing pages, and recommendations are powerful tools for the customer experience. But after this year’s Cyber 5, we saw that search still rules the roost. The core to a great digital experience starts with the search bar, the place where shoppers act with the most intent; better search, happier customers, bigger Cyber 5 conversion haul.”
The ability for retailers to accelerate relevance and reduce search abandonment will continue to be a priority. Recently, Lucidworks announced that they will integrate their Fusion technology with Google Cloud’s Retail Search solution to deliver an elevated online product discovery experience. When combined with Google Cloud Retail Search, Lucidworks Fusion orchestrates Google’s search and shopper intelligence trained on queries and events to enable instant sharper relevance across the shopper journey.
The number of total customer carts peaked on Black Friday. There were six times the number of carts as compared to the Tuesday of that week. Most customers had somewhere between 1-5 items in the cart over the course of Cyber 5. Regardless of items per cart, the number of products across all carts peaked on Black Friday.
Increased cart rate and cart size relative to theincrease of traffic are good indications that shoppers are finding relevant items. Shopping carts are also frequently used by gifting shoppers as a tool to get confirmation on product availability and the final cost after total fees and discounts. Shopping cart sharing can also help purchase rates as it allows gifters to collaborate with others, removing the guesswork out of the purchasing as well as enabling group purchases.
Shoppers relied on recommendations on product detail pages over the course of Cyber 5. Based on what customers were looking at, they were served relevant “You may also like” recommendations. The number of total clicks on recommended items peaked on Black Friday, with Thanksgiving in a close second. In addition, shoppers clicked on and then bought recommended items on Black Friday more than 55% more often than on Cyber Monday.
Applying a recommender strategy based on touchpoints and context is key. As new visitors may lack familiarity with a retailer’s catalog, recommenders for “you may also like”, “similar items”, and “complete the look” that are placed on a product detail page or the shopping cart page are particularly effective in driving purchases for these new shoppers. For known or repeat shoppers, personalized recommendations such as “may we suggest” or “just for you” based on the customer’s engagement—past and present—are a great way to drive additional purchases.
Is it already time to start preparing for Cyber 2023? Not until you have an understanding of how your website performed during this year’s holiday shopping season. Look through the data to understand the customer journey. Did they get stuck with dead-end searches? Were they clicking on recommendations on the product detail page? Did they journey from mobile to desktop and back? Once you can answer questions like these you can optimize everything from the search bar, to suggestions, to landing pages, and more. Now pat yourself on the back for making it through Cyber 5 2022.
Need a hand optimizing your site so shoppers can find what they need easily? Drop us a line and check out the Lucidworks data discovery and search solution available on the Google Cloud Marketplace.
Read More for the details.
Application Health Extension, Rich Health States allows for more detailed health reporting on your VM applications.
Read More for the details.
Today is the start of the two year implementation period for the EU Digital Operational Resilience Act (DORA). Financial entities in the European Union (EU) and their critical ICT providers must be ready to comply with DORA by January 17, 2025. At Google Cloud, we firmly believe that DORA will be vital to accelerating digital innovation in the European financial services sector. We have been engaging with policymakers on DORA since September 2020. We are now excited to collaborate with customers and regulators to operationalize the new DORA requirements ahead of the deadline.
As we approach the 2025 deadline, we intend to continue to support our customers with new resources and updates to our Compliance Resource Center. The first of these resources is our new DORA Customer Guide, which contains helpful information about how our customers can navigate the DORA regulations.
DORA standardizes how financial entities report cybersecurity incidents, test their digital operational resilience, and manage Information and Communications Technology (ICT) third-party risk across the financial services sector and EU member states. In addition to establishing clear expectations for the role of ICT providers, DORA will also allow EU financial regulators to directly oversee critical ICT providers. Where the criteria are met, this would apply to cloud service providers like Google Cloud.
Over the last two years, our team has been engaging with policymakers and regulators to understand their perspectives on how the new law could improve digital operational resilience in the European financial sector.
Now that DORA is finalized, a cross-functional team at Google Cloud (including subject matter experts from Risk and Compliance, Security, Legal, Government Affairs, and Product) is reviewing the details and preparing compliance plans where needed. These plans build upon our strong foundation in areas like security, resilience, and third-party risk management that already enable our EU financial services customers to address their rigorous regulatory expectations.
We plan to use the implementation period to further enhance our capabilities in each of the DORA focus areas, including:
Oversight: We’re preparing for potential designation as a critical ICT provider and the annual engagements that will follow, including oversight plans, inspections, and recommendations. We’re confident that this structured dialogue will help to improve risk management and resilience both for our customers and across the sector. We will approach a relationship with our lead overseer with the same commitment to ongoing transparency, collaboration, and assurance that we approach our customers and their regulators with today.
Incident reporting: We’re very focused on how we can support customers with the incident reporting requirements under DORA. In particular, we’re looking at ways that our industry-leading information security operation and sophisticated security monitoring tools and solutions could be even more helpful to customers. With the addition of Mandiant to the Google Cloud family, we now also offer proven global expertise in comprehensive incident response and technical assurance to help organizations mitigate threats and reduce business risk before, during and after an incident. We are excited about how these capabilities can help our customers with DORA compliance.
Digital operational resilience testing: We firmly believe that cyber resilience must be tested. If done well, activities like threat led penetration testing can be powerful tools. Given the clear benefits of pooled testing in the public cloud context, this is something we’re very interested in exploring. Our customers have had continued success with pooled audits of Google Cloud. This gives us confidence that a similar collaborative and scalable approach can enable robust and effective testing.
Third-party risk management: Google Cloud’s contracts for financial entities in the EU already address the contractual requirements in the EBA outsourcing guidelines, the EIOPA cloud outsourcing guidelines, the ESMA cloud outsourcing guidelines, and additional member state requirements. We recognize that DORA also contains requirements for contracts with ICT providers. We are reviewing these closely to understand how they may impact our contracts for financial entities in future.
Like our customers, Google Cloud is thinking about the key DORA issues now. However, we understand that the details in these areas still need to be fully defined in forthcoming regulatory and implementing technical standards. We are committed to engaging in the discussions about these standards in the same transparent and constructive way that we participated in the DORA dialogue.
Our goal is to make Google Cloud the best possible service for sustainable, digital transformation for European organizations on their terms — and there is much more to come.
Read More for the details.
When a software change is deployed — after being designed, coded, tested, packaged, and tested some more — a journey comes to an end. At the same time, a new journey begins: your customer’s relationship with your service. It’s here, in the domain of operations, that abstract risks like launch schedule slippage give way to tangible risks like lost revenue, degraded trust, and tarnished reputation. Only when it’s available to users can software contribute to (or threaten!) the success of your organization. And so, throughout the past several years, the DevOps Research and Assessment (DORA) project has incrementally deepened our research into the reliability of services, through and beyond deployment, into ongoing operation.
Reliability is a broadly defined term, which refers to a team’s ability to meet their users’ expectations — for software services, it may encompass aspects of availability, latency, correctness, or other characteristics that influence the consistency and quality of user experience. Google’s practice of Site Reliability Engineering (SRE), which has been embraced and extended by a global community of reliability engineering practitioners, is an approach to operations that prioritizes user-oriented measurement, shared responsibility, and collaborative, blameless learning. Starting with the 2021 Accelerate State of DevOps Report, we began asking survey respondents detailed questions about reliability engineering in their organizations. We continued and expanded our investigation in 2022, and found further evidence that modern reliability engineering is widespread: a majority of respondents report that they employ SRE-style practices. With this extensive body of data to draw from, this year we pushed further into analyses of the impact of reliability and its interaction with other dynamics present in our model of technology’s influence on organizational success.
Reliability is more than beneficial: it’s essential. As in prior studies, we find that software delivery performance (as measured by the “four key metrics” of change lead time, deploy frequency, change failure rate, and failure recovery time) is predictive of organizational performance. However, this year’s analysis revealed a previously unseen nuance: the influence of software delivery on organizational performance is predicated on reliability. When reliability is high, high-performance software delivery predicts better outcomes for the organization. But when reliability is poor, improvements to software delivery have no effect — or even a negative effect — on organizational outcomes. This affirms a long-held belief among reliability engineers: “reliability is the most important feature of any system.” If a service or product doesn’t meet its users’ reliability expectations, it’s counter-productive to rapidly ship flashy new features, because users can’t properly experience them. Software delivery relies on a foundation of reliability to create value.
Any experienced leader will tell you that progress is rarely linear: even with a discipline like SRE, widely practiced and with demonstrable benefits, the path to success is unlikely to follow a straight line. DORA describes the “J-Curve” of organizational transformation, a phenomenon in which durable success comes only after setbacks and lessons learned. This year, we compared the depth of teams’ reliability engineering practices to their impact on the services they provide: will an investment in SRE produce greater reliability? The answer is yes, but with a significant caveat: not at first. Comparing reliability outcomes across a range of levels of SRE adoption, the J-Curve is plainly visible. A team which practices SRE only lightly — at the beginning of their SRE journey, perhaps — is likely not only to not benefit, but to regress in terms of the reliability experienced by their users. However, after these practices have more deeply permeated, an inflection point is reached and we see strong reliability benefits from continuing to grow the reliability engineering capability.
Knowing that it will likely take time to realize the benefits of adopting SRE, it may be tempting to start the process as soon, and as broadly, as possible. But we offer a note of caution here: organization-wide cultural transformation initiatives typically fail from overreach. We studied this and reported findings in a previous report. And even if you manage to beat the odds and fully adopt SRE across multiple teams simultaneously, the cost may be unacceptable: the setbacks in reliability that you are likely to experience early on, amplified across an entire organization all at once, could have catastrophic consequences. Therefore the SRE principle of gradual change should also be applied to the adoption of SRE itself.
Reflecting back on over a decade of SRE practice and theory, the Enterprise Roadmap to SRE underlines the importance of culture, suggesting that Site Reliability Engineering is in fact emergent from culture. Tools and frameworks are important; language is essential. But only a trustful, psychologically safe culture can support the environment of continuous learning which enables SRE to manage today’s complex, dynamic technology environments. DORA’s research in 2022 demonstrates the interplay between culture and reliability: we found that “generative” culture, as defined by the Westrum model, is predictive of higher reliability outcomes. And reliability has benefits not only for a system’s users, but for its makers as well: teams whose services are highly reliable are 1.6 times less likely to suffer from burnout.
Got a story to share about your DevOps journey? Submit it to Google Cloud’s 2022 DevOps Awards by January 31, 2023!
Read More for the details.
For organizations, it is important to build a data lake solution that offers flexible governance and the ability to break data silos while maintaining a simple and manageable data infrastructure that does not require multiple copies of the same data. This is particularly true for organizations trying to empower multiple data science teams to run workloads like demand forecasting or anomaly detection on the data lake.
A data lake is a centralized repository designed to store, process, and secure large amounts of structured, semistructured, and unstructured data. It can store data in its native format and process any variety of it, ignoring size limits. For example, many companies have matrix structures, with specific teams responsible for some geographic regions while other teams are responsible for global coverage but only for their limited functional areas. This leads to data duplication and the creation of new data silos.
Managing distributed data at scale is incredibly complex. Distributed teams need to be able to own their data without creating silos, duplication, and inconsistencies. Dataplex allows organizations to scale their governance and introduce access policies that enable teams to operate on the portion of the data that is relevant to them.
Google Cloud can support your data lake modernization journey no matter where you are with people, processes, and technology. BigLake allows Google customers to unify their data warehouses and data lakes. Dataproc empowers distributed data science teams in complex organizations to run workloads in Apache Spark and other engines directly on the data lake while respecting policies and access rules.
This blog will show how Dataproc, Dataplex, and BigLake can empower data teams in a complex organizational setting, following the example of a global consumer goods company that has finance teams organized geographically. At the same time, other functions, such as marketing, are global.
Our global consumer goods company has centralized their data in a data lake, and access policies ensure that each of their regional finance team has access only to the data that pertains to the appropriate location. While having access to global data, the marketing team does not have access to sensitive financial information stored in specific columns.
Dataproc with personal authentication enables these distributed teams to run data science and data engineering workloads on a centralized BigLake architecture with governance and policies defined in Dataplex.
BigLake creates a unified storage layer for all of the data and extends the BigQuery security model to file-based data in several different formats on Google Cloud and even on other clouds. Thanks to Dataproc, you can process this data in open-source engines such as Apache Spark and others.
In this example, our global consumer goods company has a centralized file-based repository of sales data for each product. Thanks to BigLake, this company can map these files in their data lake to tables, apply row and column level security and, with Dataplex, manage data governance at scale. For the sake of simplicity, let’s create a BigLake table based on a file stored in Cloud Storage containing global ice cream sales data.
As seen in the architecture diagram above, BigLake is not creating a copy of the data in the BigQuery storage layer. Data remains in Cloud Storage, but BigLake allows us to map it to the BigQuery security model and apply governance through Dataplex.
To satisfy our business requirement to control access to the data on a geographical basis, we can leverage row-level access policies. Members of the US Finance team will only have access to US data, while members of the Australia Finance team will only have access to Australian data.
Dataplex allows us to create policy tags to prevent access to specific columns. In this case, a policy tag called “Business Critical: Financial Data” is associated with discount and net revenue so that only finance teams can access this information.
Dataproc allows customers to run workloads in several open-source engines, including Apache Spark. We will see in the rest of this blog how users can leverage Dataproc personal authentication to run data science workloads on Jupyter notebooks directly on the data lake, leveraging the governance and security features provided by BigLake and Dataplex.
For example, a member of the Australia finance team can only access data in their geographical area based on the row-level access policies defined on the BigLake table. Below, you can see the output of a simple operation reading the data from a Jupyter notebook running Spark on a Dataproc cluster with personal authentication:
As a reminder, even if we use the BigQuery connector to access the data via Spark, the data itself is still in the original file format on Cloud Storage. BigLake is creating a layer of abstraction that allows Dataproc to access the data while respecting all the governance rules defined on the data lake.
This member of the Australia finance team can leverage Spark to build a sales forecasting model, predicting sales of ice cream in the next six months:
Now, suppose a different user who is a member of the US Finance team tries to run a similar forecasting of ice cream sales based on the data she has access to, given the policies defined in BigLake and Dataplex. In that case, she will get very different results:
Sales of ice cream in the United States are expected to decline, while sales of ice cream in Australia will increase, all due to the different seasonal patterns in the Northern and Southern hemispheres. More importantly, each local team can independently operate on their regional data stored in a unified data lake, thanks to Dataplex on BigLake tables’ policies and Dataproc’s ability to run workloads with personal authentication.
Finally, users in the Marketing department will also be able to run Spark on Jupyter notebooks on Dataproc. Thanks to policy tags protecting financial data, they can only leverage the columns they have the right to access. For example, despite not having access to discount and revenue data, a marketing team member could leverage unit sales information to build a segmentation model using k-means clustering in Apache Spark on Dataproc.
In this blog, we saw how Dataproc, BigLake, and Dataplex empower distributed data science teams with fine-grained access policies, governance, and the power of open-source data processing frameworks such as Apache Spark. To learn more about open-source data workloads on Google Cloud and governance at scale, please visit:
Create and manage BigLake tables
Read More for the details.
Dialogflow CX is a powerful tool in Google Cloud that you can use to design conversational agents powered by Natural Language Understanding (NLU) to transform user requests into actionable data. You can integrate voice and/or chat agents in your app, website, or customer support systems to determine user intent and interact with users.
If you’ve ever wanted to get started with Dialogflow CX, you might have seen or ran through the quickstart steps to build a shirt ordering agent that you can ask for the store location, get store hours, or make a shirt order.
While going through the quickstart steps, you might find yourself wanting to codify all of the Dialogflow CX components and settings, which would help you quickly spin up agents and manage their configuration programmatically. In fact, you might already be using infrastructure as code tooling and best practices to manage virtual machines in Compute Engine, Kubernetes clusters in GKE, or topics and subscriptions in Pub/Sub. You can also use the same infrastructure as code approach with your Dialogflow CX agents: Terraform and Google Cloud to the rescue!
You can use the Terraform modules for Dialogflow CX along with the sample Terraform + Dialogflow CX configuration files to reproduce the chatbot/agent described in the “build a shirt ordering agent” quickstart. Try them out and spin up a Dialogflow CX agent with a single command in your own Google Cloud account!
There are a few things that you’ll need to set up before you run the sample Terraform configuration files for Dialogflow CX.
Register for a Google Cloud account.
Enable the Dialogflow CX API.
Install and initialize the Google Cloud CLI.
Install Terraform.
Once you’ve completed the setup on your local machine, you’re ready to spin up your own fully-configured Dialogflow CX agent in seconds:
Clone the CCAI samples repository and cd into the dialogflow-cx/shirt-order-agent/ directory.
Edit the values in variables.tf to specify your Google Cloud project ID along with your desired region and zone.
Run terraform init to initialize the directory that contains the Terraform configuration files.
Run terraform apply, the command that spins everything up!
Once you run terraform apply and confirm the proposed plan, you’ll see messages about all of the components that were provisioned, including the agent, pages, intents, flows, and more:
Now that you’ve provisioned your agent in Dialogflow CX, you’re ready to view and test your agent in the Dialogflow CX Console!
We’re using the Terraform modules for Dialogflow CX to define a conversational agent and all of its components. We’ve reproduced the agent described in the build a shirt ordering agent quickstart.
All of the agent’s associated entity types, flows, intents, and pages are created and managed with Terraform, so you can edit your Terraform configuration files to change certain parameters, run terraform apply, and see your changes instantly reflected in the Dialogflow CX console.
You might notice that the flows.tf file actually uses a local-exec command within a null_resource block to make a REST API call instead of using a Terraform resource for Dialogflow CX to define the flow. This approach was used since Dialogflow CX creates a default start flow when the agent is created rather than being created and managed by Terraform. As a result, we can use a REST API call to PATCH the default start flow and then modify its messages and routes. We can still use Terraform to templatize and trigger the REST API command, which means that you can manage any setting that is also available in the Dialogflow CX REST API, or even add custom callbacks to other Google Cloud services if needed.
It’s convenient to be able to manage conversational agents as code using Terraform in Google Cloud. We get all of the benefits of Dialogflow CX with the convenience of Terraform to manage everything in a stateful and version-control friendly way.
Now that you’ve captured all of your Dialogflow CX agent settings and configuration in Terraform, you are ready to check your Terraform scripts into version control, spin up and destroy agents as you please using terraform apply and terraform destroy, or even store remote Terraform state in Google Cloud using the GCS backend.
Take a look at the Terraform + Dialogflow CX sample code along with the Terraform modules for Dialogflow CX so you can spin up your own Dialogflow CX agents with a single command. If you found this Terraform code sample useful, be sure to star, watch, or ask questions in our CCAI samples repository on GitHub!
Read More for the details.
Amazon CloudFront now supports the “Cloudfront-viewer-header-order” and “Cloudfront-viewer-header-count” headers, enabling customers to track the total number of HTTP headers sent with each request, as well as the order in which the headers were sent. Customers can use the two headers to detect and identify request patterns and compare them to the expected and legitimate patterns. This, used in conjunction with other access control rules, can help customers detect and block any attempts to spoof requests.
Read More for the details.
Maintaining optimal pricing in the retail industry can be challenging when relying on manual processes or platforms that are not equipped to handle the complexity and scale of the task. The ability to quickly adapt to factors affecting pricing has also become a critical success factor for retailers when pricing their products.
As a whole, the retail industry is working to absorb and respond to changes in the way customers buy and receive products, and to how pricing affects competitive advantage. For example, within some vertical domains, customers’ expectations for the price of products differ when buying online as compared to in-store, but are expected to align in others. Additionally, because of the ease with which shoppers can assess the prices across competitors, retailers are looking for ways to retain their most valuable customers; loyalty pricing, private label strategies, and bespoke promotional offers are seen as key aspects of possible solutions in this regard.
Whether in an everyday, promotional or clearance sense, the need to maintain optimal pricing requires a forward-looking mechanism that employs AI/ML capabilities based on multiple sources of input to provide prescriptive decision-making. Such an AI/ML platform can encourage specific buying behaviors aligned to a retailer’s strategy, for example, to rebalance inventory, expand basket sizes or increase private label brand sales. A pricing process can be thought of as having four stages:
Transfer and processing of information about a retailer’s operational structure, customer behavior related to its products, and other elements impacting supply and demand
Synthesis of information that represents the relationships between prices for products available across a retailers’ sales channels and business outcomes vis-a-vis financial metrics
Decision making, about price-related activities such as price increases / decreases or promotional offers, driven by human or software systems
Actions to actualize pricing decisions and to inform stakeholders affected by changes, driven by human or software systems
In the Solution Architecture section we will examine these stages in detail.
The complexity of pricing in the retail industry, particularly for Fast Moving Consumer Goods (FMCG) retailers, can be significant. These retailers often have over 100,000 items in their assortments being sold at thousands of stores, and must also consider the impact of online shopping and customer segmentation on pricing decisions. Different buying behaviors across these dimensions can affect the recommendations of a pricing system, and it is important to take them into account in order to make accurate and effective pricing recommendations. An AI/ML-driven platform can provide greater agility and manage complexity to make more informed pricing decisions.
Speed is a critical factor in the retail industry, particularly for retailers selling Specialty Goods who face intense competitive pricing pressure in certain key products. In this environment, the ability to respond quickly to changes in the market and customer demand can be the difference between staying relevant and losing business to competitors. Automation using AI/ML, enabling real-time, on-demand price changes and promotions is a key factor in the evolving retail industry, particularly in the context of ecommerce and digital in-store systems like Electronic Shelf Labels (ESLs). These systems provide on-demand price changes and promotions that can positively alter customer behavior by increasing the basket size during a session.
To make this possible, the decision-making and delivery mechanisms behind these systems need to be driven by a flexible, programmatically accessible AI/ML engines that learn and adapts over time.
Revionics’ product, Platform Built for Change, is a new platform that aims to address the significant changes occurring in the retail market by providing a flexible, scalable, intelligent and extensible solution for managing pricing processes. A foundational design principle for the platform is that it can be easily adapted, through configuration rather than code changes, to support a wide range of approaches and states of maturity in pricing practices. By externalizing dependencies of changes from the underlying code, the platform allows retailers to make changes more easily and quickly adapt to new requirements.
The above diagram shows Revionics solution where we can see GCP serverless technologies used across all different layers, from ingestion to export. The key services used are:
Data Storage: Google BigQuery, GCS (blob storage), MongoDB Atlas
Data Processing: Google BigQuery, Google DataProc, Google Dataflow
Data Streaming: Kafka, Google PubSub
Orchestration: Cloud Composer (Airflow), Google Cloud Functions
Containerization & Infra Automation: GKE (Kubernetes)
Analytics: Google Looker
Data Sharing: Google Analytics Hub
Observability: Google Cloud Logger, Prometheus, Grafana
We will discuss the key problems, challenges to solve and how the various stages of the solution; Ingest, Process, Sync and Export have enabled Revionics to address the need for speed, scale, and automation, all while solving increasing complexity and evolving challenges in Retail pricing.
1. Transfer and processing of information
As Revionics is a SaaS provider, supporting retailers at the first stage of the pricing process – the transfer and processing of information – essentially boils down to overcoming one major challenge: wide variability. In our domain, variability comes from several data sources shown in Figure 2 below:
Each retailer’s pricing practice and technical environment exist in various states of maturity and sophistication
Entire sources of data may be included in some cases, but excluded in others
API usage and streaming may be plausible with some customers, whereas SFTP transfers are the only available means for others
Data quality, completeness and correctness vary by retailer according their upstream processes
Both large batch and near real-time use cases need to be supported
The Data transformation logic that feeds into science modeling will differ according to a combination of grouping and configuration choices based on the retailer’s operations and objectives. Essentially, there is no single “golden data pipeline”.
In order to describe how the variability challenges are addressed, let’s drill into the Ingest and Processing portions of the architecture in the above diagram of a Customer Workflow example. There are three primary concepts:
a feed is a representation of a streamed or scheduled batch data source which has a number of methods for handling file formats and for plugging into various data technologies
a pipeline represents a combination of transformations taking in feeds and other pipelines
a DAG (directed acyclic graph) is generated by the configuration or wiring together of feeds and pipelines as well as supporting methods that execute validation and observability tasks. The generated DAG represents the full workflow for ingesting and processing information in preparation for Revionics’ Science platform
Let’s explore the benefits of the solution that leverages GCP, as depicted in the DAG Generation flow diagram in Figure 3, below:
The logical flow is a combination of Templates, Configuration and a Library of modular processing methods to generate workflows for ingesting, combining, transforming and composing data in a variety of ways. These are abstracted in a set of human readable configurations, simplifying the setup and support accessible to non-engineers. The DAG Generator outputs a JSON file for the entire workflow that can easily be understood.
The Data Platform natively delivers support capabilities such as validations and observability. Configurable validation checks are insertable at various levels for inspecting schema, looking for anomalies, and running statistical checks. Similarly, event logs, metrics and traces are collected by Cloud Logger and consolidation within BigQuery, to easily explore building dashboards or building ML models.
From an architectural standpoint, there is very minimal intervention needed to scale, operate and manage infrastructure. The workflow logic is represented in an execution agnostic fashion by a DAG JSON file that orchestrates method calls and artifact creation such as Tables, Views, Stored Procedures etc. The DAGs become instruction sets for Airflow, ultimately executed on a Composer Cluster (serverless). DataProc reads from GCS or SQL procedures on BigQuery to do all the heavy lifting in terms of combining data, aggregating, ML feature prep, etc.
The bulk of event-driven processing is achieved using Cloud Functions or DataFlow, PubSub or Kafka and Dataflow. The architecture provides a high level of reliability and zero degradation in performance as requirements for scale and speed vary. The platform thus provides the ability for the team to focus on building novel approaches to challenging problems and being cost conscious on infrastructure spend.
2. Synthesis of information (balancing scale and skill)
At the heart of Revionics’ pricing process is an AI/ML engine used to synthesize the combined data signals that express the sources and contexts for demand of retail goods over zones, stores and customer segments.
Trained models learn to explain the influence of a multitude of features, such as seasonal effects, inflation trends, cannibalization across products, and competitive pricing on the quantity of products sold at a particular location and/or to a particular customer segment. These models are then used to forecast the impact of changes in price or in the structure of promotional offers given all known contexts prevalent during the time interval of interest.
The forecasts drive optimization processes that balance one or more business objectives (e.g. profit, margin, revenue or total units) while adhering to constraints based on the retailer’s operations and desired outcomes.
For example, in Figure 4, we are showing the data science modeling aspects employed by Revionics, leveraging the benefits of the GCP platform:
A retailer may want to optimize profit on its private label brands, while maintaining a minimum and maximum relative price differential to certain premium brands in a product category.
A retailer may look to set a markdown or clearance schedule while capturing as much revenue as possible using only discount multiples of 10%.
A retailer may want to optimize the discount level of a brand of flat screen TVs to maximize profitability over the whole category along with its related products.
The primary technical challenge within the AI/ML domain for pricing is in balancing scalability with predictive skill during modeling, forecasting and optimization. Keep in mind that our median customer has 500,000 independent models (see Figure 5) that need to be trained per the histogram below; each training run is inherently iterative and computationally intensive. While the details of the science are beyond the scope of this blog, from a system perspective, Revionics architecture combines:
Two proprietary AI/ML frameworks, Probabilistic Programming Language (PPL) and the Grid, for expressing pricing domain behavior, and dynamically provisioning infrastructure to orchestrate separable modeling jobs based on statistical dependencies. PPL for expressing AI/ML models of pricing domain behavior; and the Grid infrastructure for orchestrating millions of parallel, separable modeling jobs.
Google-led open source platforms: TensorFlow for its rich machine learning library and framework and TensorFlow Probability for probabilistic modeling methods
Several of Google Cloud serverless services for data storage, compute, messaging, containerization & logging – GCS, BigQuery, PubSub, GKE & Logs Explorer.
Again, what is noteworthy about this solution is the breadth of challenges and capabilities that don’t have to be solved by Revionics because the services sit on infrastructure where sizing, configuration, monitoring, deployment and scaling are managed as a platform service.
Revionics’ modeling framework leverages a Hierarchical Bayesian methodology that can optimize each individual retailer’s product, store and customer relationships. This is a key aspect of differentiation from a predictive skill perspective, as complex relationships between entities can be preserved with a learned reduction of an otherwise intractable problem space.
3. Decision making and Action
The DAG generation-based architectural pattern used in the last two steps of the pricing process, handles the need for Automated Intelligence described earlier. Note, the purpose of the final steps in the pricing process are:
To expose outputs from the data science modeling and price recommendations to teams or systems for decision making about price-related activities such as increases / decreases or promotional offers
To take actions, or to actualize pricing decisions, as well as to inform stakeholders affected by the changes being made
The Automated Intelligence enabled by the Google Cloud Platform enables us to scale these steps by providing well-designed APIs that allow users to integrate with and build on a platform’s output. However, AI/ML -based applications have specific challenges that need to be overcome in pricing.
One of these challenges is to build trust through explainability and greater transparency of the decisions behind the models. Because AI/ML software is non-deterministic, poorly understood by non-practitioners, and often replaces human processes, confidence isn’t easy to engender.
Visibility is the best asset for creating trust, which is why Revionics uses BigQuery and Looker at the center of our approach. With these technologies, reports and visualizations are interwoven into all aspects of the Revionics solution, creating a clear line of sight from data to decisions – this gives users visibility:
Forecasted business results from recommendations – for example, by making it easy for a user to understand the weighting of profit and revenue in a multi-objective optimization resulting in a particular price recommendation
Statistical confidence around decision variables – by showing visualizations and metrics such as 95% credibility intervals around price elasticity, for example
AI/ML model output analytics over time – including histograms, statistical metrics, outlier detection and the like that express the health of the models
Figure 6: Analytics Embedded in Solution
Automated Intelligence. The Looker + BigQuery combination is particularly effective because:
Performance in high-dimensional analytics. Its ability to maintain performance at scale in the context of high-dimensional analytics without the need for manual intervention.
Personalization. Its capacity for personalization and business relevance views and reports that reflect the specific conditions and metrics representative of the business.
Collaboration. In order to gain the confidence of people whose jobs are not pricing (e.g. category managers, merchandisers, executives), users have to be able to engage with and share analytical content in a completely frictionless way. In the Revionics solution, people within the organization who have no user login nor experience with the tool can view any analytical asset as well as engage with in-app comment threads.
Triggers. Additionally, analytical assets, such as reports and datasets, can also be scheduled or triggered for export.
Enhancing Performance and Managing Cost. Due to the scale of the data that is needed to drive downstream processes, APIs or even distributed streaming-based egress approaches are not always ideal. To resolve this, Revionics is exploring the use of Google’s Analytics Hub. The service gives an ability to create and securely share BigQuery datasets, tables and views that are simply available within the customer’s environment, which is an incredibly powerful tool for increasing the impact of Automated Intelligence. The benefit of exchanging data via the Analytics Hub is that we can preserve flexibility for users at scale in the system they are already likely to be using to drive their analytics, stream, and execute large transformations. In addition, Analytics Hub provides the levers to create exchanges and listings in Revionics’ SaaS solution without having to move data, thereby being incredibly cost optimized.
In particular, use cases that require very granular data from Revionics’ pricing system to be combined with a retailer’s other source data are very well served here. In a more tangible sense, we foresee users automating eCommerce-related capabilities, merchandising processes and digital marketing systems, in addition to any number of operational use cases that we have yet to conceive.
By building on the Google Cloud Platform and data cloud, Revionics has built and hosted solutions that have yielded numerous benefits. Some of the notable outcomes are:
Enhanced speed and agility: By replacing customer-specific stored procedures and scripts with human readable configurations, the solution has lowered the barrier for variable data transformation logic and better validation logic. All of these have made the solution easier to configure and more agile.
Improved stability: As the reliance on data quality is fairly high, several constructs in the solution have ensured data hygiene has improved leading to meeting SLAs and reduced downtime. Collectively, the customer support issues have lowered.
Rapid Data processing: Below graphic shows the multi-fold improvement in various parts of the data processing pipeline with progressively increasing volumes.
Faster Technical implementations: The time to value has been quicker enabled by design and performance. For instance: Test cycles and customer feedback sped up leading to quality standards being achieved faster. Historical loads have run significantly faster.
Increased accuracy: The forecast accuracy grew by a greater percent while maintaining training and optimization over the first phase of customers migrating to the new platform.
Decision making: The rising statical and decision confidence led to higher-impact results and better SUS (system usability scores).
Click here to learn more about Revionics.
Google is helping tech companies like Revionics build innovative applications on Google’s data cloud with simplified access to technology, helpful and dedicated engineering support, and joint go-to-market programs through the Built with BigQuery initiative, launched in April as part of the Google Data Cloud Summit. Participating companies can:
Get started fast with a Google-funded, pre-configured sandbox.
Accelerate product design and architecture through access to designated experts from the ISV Center of Excellence who can provide insight into key use cases, architectural patterns, and best practices.
Amplify success with joint marketing programs to drive awareness, generate demand, and increase adoption.
BigQuery gives ISVs the advantage of a powerful, highly scalable data warehouse that’s integrated with Google Cloud’s open, secure, sustainable platform. And with a huge partner ecosystem and support for multi-cloud, open source tools and APIs, Google provides technology companies the portability and extensibility they need to avoid data lock-in.
Click here to learn more about Built with BigQuery.
We thank the Google Cloud and Revionics team members who co-authored the blog: Revionics: Aakriti Bhargava, Director Platform Engineering. Google: Sujit Khasnis, Cloud Partner Engineering
Read More for the details.
AWS Nitro Enclaves now supports the ability to create more than one enclave per EC2 instance. AWS Nitro Enclaves is an Amazon EC2 capability that enables customers to create isolated compute environments to further protect and securely process highly sensitive data such as personally identifiable information (PII), healthcare, financial, and intellectual property data within their EC2 instances.
Read More for the details.
Amazon Relational Database Service (Amazon RDS) has new certificate authorities with 40 year and 100 year validity. SSL/TLS certificates enable secure communication between your clients and databases.
Read More for the details.
AWS Security Hub is now available in the Middle East (UAE) Region. You can now use Security Hub to centrally view and manage the security posture of your AWS accounts in the Middle East (UAE) Region and take advantage of 108 security controls to automatically check your security posture in the Region.
Read More for the details.
While there are as many ways of defining DevOps as there are people, most would agree that at the most basic level, DevOps is about tools, practices, and how people work together to deliver software quickly, reliably, and safely. A big part of how people work together has to do with their organization’s culture.
Research conducted by the DORA team over the past eight years has consistently shown that culture is foundational to an organization’s success and the well-being of its employees. Our data has shown that high performing organizations, those that meet their performance and profitability goals, are more likely to have a generative culture – the 2022 State of DevOps report’s findings continue to support this claim.
This year, we examined three main areas related to the impact of culture on DevOps:
If the shift in work arrangements that has occurred since the start of the Covid-19 pandemic has had an impact on organizational performance.
Whether higher team churn impacts organizational performance.
The impact of employee burnout.
Flexible work arrangements have now become the norm at many organizations. Employees across many industries have the opportunity to choose between in-person, hybrid or fully-remote work arrangements that best fit their unique needs. Our research indicates that this shift has been a good one. Specifically, we find that flexible work arrangements are associated with higher organizational performance compared to organizations with more rigid work arrangements. This is good news! These findings demonstrate that being employee centric can have tangible and direct benefits to organizations.
Constant churn can impact productivity and morale as new team members need time to onboard. And those who stay might need to adapt to changes in their workload and team dynamics. We found that stable teams — teams whose composition hadn’t changed much over the last 12 months, were more likely to exist within high-performing organizations. Our research also showed that stable teams were more likely to report producing quality documentation compared to teams that experienced more churn. A team that is constantly dealing with change may have a harder time keeping up with practices that lead to quality documentation.
Lastly, we focused again on burnout – the feeling of dread, apathy, and cynicism surrounding work. Experiencing burnout can lead people to have lower levels of job satisfaction and increases in turnover – not to mention the increased risk of poor mental and physical health outcomes such as increased risk for depression and anxiety, heart disease, and suicidal thoughts1. Our findings from this year showed that rigid work arrangements increase the likelihood of employee burnout by 30%.
Taken together, these three findings underscore the importance of creating a healthy and inclusive culture for employees both at the organizational and team level.
While we continue to emphasize the importance of culture, we acknowledge that changing or even improving an organization’s culture is no easy task. We recommend that organizations seek to first understand their employees’ experiences and subsequently invest resources in addressing culture-related issues as part of DevOps transformation efforts.
To learn more about how culture impacts organizational performance check out the 2022 State of DevOps Report. And if you have a story about how you are implementing DORA devops practices, don’t forget to share your transformation journey by applying to the2022 DevOps Awards by January 31, 2023!
Maslach C, Leiter MP. Understanding the burnout experience: recent research and its implications for psychiatry. World Psychiatry. 2016 Jun;15(2):103-11. doi: 10.1002/wps.20311. PMID: 27265691; PMCID: PMC4911781.
Read More for the details.
We are constantly looking for ways to simplify the developer experience on Google Cloud.
Google Kubernetes Engine (GKE) is a simple way to automatically deploy, scale, and manage Kubernetes. Cloud SQL is a fully managed relational database service for MySQL, PostgreSQL, and SQL Server. Developers often deploy their applications to GKE and store their data in Cloud SQL, so connecting GKE to Cloud SQL is typically one of the first big steps in deploying a full stack application. The Kubernetes operator simplifies that process.
Generally, the easiest way to connect to Cloud SQL is with a language-specific Cloud SQL connector. There are Cloud SQL connectors for Java, Python, and Go — with more to come in the future. If your application is written in one of those languages, we recommend starting with a connector. Otherwise, the Cloud SQL Auth proxy is likely the right choice for your applications running on Google Kubernetes Engine. If you’re willing to join us on the leading edge, the Kubernetes operator is now in Public Preview.
The Cloud SQL Proxy Operator is currently in Public Preview. Here are a few exciting benefits for those ready to make the switch:
Configure a Cloud SQL Auth Proxy in 8 lines of YAML — saving you about 40 lines of YAML configuration (or thousands for large clusters)
Simple configuration of a single Cloud SQL Proxy specific resource — allowing multiple Kubernetes applications to share the same proxy
Best practices by default — we maintain the operator and update it to the latest recommendations
Automatic deployment when the proxy configuration changes (coming in the GA release)
Here’s an example of what configuration might look like before the operator. Note how much simpler and more elegant the new operator makes deployment.
And here is what the configuration looks like for the same project after adding the operator:
While the Cloud SQL Proxy Kubernetes operator is in Public Preview, we want to hear what could make it even better for you. We are working on this project in our public GitHub Repository. You can find the code, quickstart, and contribution guidelines there. We’d love to accept your patches and contributions to this project. We’re hoping with all of the typing we save you on YAML, you might have enough time to create issues or make a pull request. Then someday, we can give your fingers the much-needed vacation they deserve.
Read More for the details.