Recommendations AI modeling

In this series of Recommendations AI deep dive blog posts, we started with an overview of Recommendations AIand then walked through the data ingestion process. In this post, we will walk you through the model creation process and how you can get the best of Google’s AI and ML techniques to solve your business problems without deep ML expertise. When you ingest the data into Recommendations AI, the product catalog and user events form the two key pillars to train the recommendation models. Product features such as Item id, title, categories, description, price, stock status, and Events such as homepage views, detail page views, add to cart, purchases depict the whole journey of each user. They enable Recommendations AI to capture the interconnection between a user’s history, current landing page, and next action, and build a deep neural network to provide personalized recommendations. Once the data successfully ingested, you are now ready to train your very first model. Woohoo!Create recommendations in the graphical interfaceRecommendations AI provides an easy-to-use graphical interface, with which you can choose your model type, define your optimization objective, customize your business rules, and begin training your model with just a few clicks.The model will be trained for you from scratch using the data you sent to us within the bounds of the GCP project.​​ In 3-7 days the initial model training and tuning will conclude, and you’ll see a visual indicator in the dashboard that the model is ready to query. You can then begin serving recommendations to your customers, or visually preview the recommendations being generated by the model before you serve them to production traffic to ensure that your setup is satisfactory.Google has spent years delivering recommended content across flagship properties such as Google Ads, Google Search, and YouTube. Recommendations AI draws on that experience to deliver personalized recommendations that suit each customer’s tastes and preferences across all your touchpoints.Recommendation model typesRecommendations AI offers five recommendation model types including “Others you may like”, “Frequently bought together”, “Recommended for you”, “Similar items”, and “Recently Viewed”, with the first four model types powered by machine learning, and the new model type “Similar items” in preview.The “Others you may like” recommendation predicts the next product that a user is most likely to engage or convert with. The prediction is based on the shopping and viewing history of the user and the candidate product’s relevance to a current specified product. In the example below, on a product detail page of a blue dress, the “Others you may like” model recommends another three dresses that the customer is likely to click on or purchase.The “Frequently Bought Together” recommendation predicts items frequently bought together for a specific product within the same shopping session. If a list of products is being viewed, then it predicts items frequently bought with that product list. This recommendation is useful when the user has indicated an intent to purchase a particular product (or list of products) already, and you are looking to recommend complements (as opposed to substitutes). This recommendation is commonly displayed on the “add to cart” page, or on the “shopping cart” or “registry” pages (for shopping cart expansion). In the example below, the “Frequently Bought Together” model recommends heels and a watch, which go well with the blue dress just added to cart, and a green dress as the customer may need multiple dresses for different occasions.The “Recommended for You” recommendation predicts the next product that a user is most likely to engage with or purchase, based on the shopping or viewing history of that user and contextual information of requests, such as timestamps. This recommendation is typically used on the home page. “Recommended for You” can also be useful on category pages. A category page is similar to a home page, except that you display only items from that category. You can achieve this using a standard Recommended for You model with filter tags. For example, you can add customized filter tags (corresponding to each category page) to the items in your catalog. When you send the prediction request, set the user event object as category-page-view and specify a specific category page’s tag in the `filter` field. Only recommendation results matching the requested filter tag are returned.”Others You May Like” and “Recommended For You” are highly personalized recommendations powered by Transformer-based sequence modeling. “Others You May Like” recommendation requires an anchor item and is usually used on product detail pages, while “Recommended For You” can be used on pages without anchor items, such as home pages and category pages. They take into account both the content and order of a user’s historical clicks and purchases, correctly identify their true intentions, and precisely predict the next items that they would love to check out or purchase. For example, if a user browses a variety of maxi dresses and switches to fashionable shoes, “Others You May Like” model may recommend a mix of scandals and heels that go well with maxi dresses for a casual look during the day or a dressier look at night.”Similar Items” is a new model type we’ve recently developed and is currently in preview. The “Similar Items” model will use only the product catalog, and not require user events in an effort to accelerate time to test model and preview recommendations results in the console for customers. We’ve leveraged self-supervised learning to accurately capture item similarities based on the metadata such as titles and categories, even if there is no user event ingested.Optimization objectivesMachine learning models are created to optimize for a particular objective, which determines how the model is built. “Others You May Like” and “Recommended for You” recommendation models have click-through rate (CTR) as the default optimization objective. Optimizing for CTR emphasizes engagement, and you should optimize for CTR when you want to maximize the likelihood that the user interacts with the recommendation. In contrast, revenue per order is the default optimization objective for the “Frequently Bought Together” recommendation model type, as “Frequently Bought Together” focuses on cross-selling and increasing order values.For “Others You May Like” and “Recommended for You” recommendation models, we also support conversion rate (CVR) as the objective. Optimizing for conversion rate maximizes the likelihood that the user adds the recommended item to their cart. When CVR is specified as the objective for a customer with sparse add-to-cart events, the multi-task learning mechanism will be automatically activated, and transfer learn from detail-page-view events, which are typically much denser than add-to-cart events.User event data requirementsBefore you create a new model, you must have met the requirements for creating a new model. The type of user events you import, and the amount of data you need, depends on your recommendation (model) type and your optimization objective. For example, you need to meet the following data requirement to train an “Others You May Like” model optimizing for click-through rate:10,000 detail-page-view events that include at least 100 unique visitor IDs, and1 week, with an average of 10 detail-page-view events per joined catalog item, or 60 days with at least one joined detail-page-view event.When you reach the minimum data requirement, you can begin model training. You can import historical user event data to meet the minimum event data requirements faster, or wait until the user event data collection meets the minimum requirements.Other features for better performanceOur models also support massive catalogs of tens of millions of items and ensure that your customers have the opportunity to discover the entire breadth of your catalog through personalized recommendations. Models are re-trained daily to draw insights from changing catalogs, user behavior, or shopping trends and incorporate them into the recommendations being served. We also correct for bias with extremely popular or on-sale items and better handle long-tail items with sparse data as well as seasonal items to ultimately drive better CTR, CVR and revenue lift for our customers.Getting recommendationsThe “Ready to Query” column on the Models page will change to “Yes” once the models are finished with the initial training and tuning.  Once your models are trained and ready to query, you can preview the results in the cloud console and make prediction requests with the API.  Requests aren’t made to a model directly, a predict request is made to a specific Serving Config (previously called a Placement).  A Serving Config contains some additional options to use – so you can have multiple placements that call the same model, each with different options like price reranking or diversification settings.Creating a Serving Config:Name your Serving ConfigChoose a modelSelect OptionsUsually you’ll want to create a separate serving config for each different placement of a model.  This is useful for reporting, and also allows you to change the model type in one particular place on a site without affecting other placements.Recommendations AI is migrating to a general Retail UI that can be used for both recommendations and search, and some options will change in the new Retail UI. For example, we will be supporting the configuration of business rules in serving configs instead of models, so that you can quickly try out serving configs with various business rules, such as different levels of price reranking or diversification, using the same underlying model.The Evaluate (preview) tab allows you to quickly see what the actual results look like.  The required parameters like visitorId or item ids can be entered in the form and then submitted to get results from a particular Serving Config/Model combination:You can leverage Recommendations AI anywhere in the customer journey.  Home page, product detail pages and cart pages are the most common placements, but you can also include recommendations in email campaigns and mobile apps. Let’s take a look at the customer journey here as an example.A customer begins their journey on their laptop, browsing the sports apparel category when Recs AI recommends shoes. The customer leaves, but comes back to the site on their phone to view more shoes. Recs AI steps in again to recommend sunglasses. Our customer adds sunglasses and shoes to their cart, indicating an interest in both items. Here, Recs AI recommends shorts which the customer clicks on to look at, but ultimately abandons their cart.Three days later, you can send a personalized follow-up email to the customer with recommended items based on the customers clicks and interests. Recs AI closes the loop, spurring the customer to buy sunglasses and shorts, both recommended based on the customer’s previous activity across devices.As we can see, Rec AI works throughout the entire buying process – from initial product discovery on a laptop, to consideration on a mobile device, to purchasing follow-through via email channels.And that’s just one example of delivering recommendations in the customer journey. Customers can use recommendations across different device types (mobile, computer), in email campaigns, in physical retail settings (kiosks), or even indirectly (call center representative, sales representative).If you’ve been following along the steps with these blog posts series, you would now have a ML model that is trained for your custom data and ready to query. In our next post, we will go over how to include the Recommendations from these models to incorporate on your site. Related ArticleHow to get better retail recommendations with Recommendations AIRecommendations AI is a solution that uses machine learning to bring product recommendations to their shoppers across any catalog or clie…Read Article
Quelle: Google Cloud Platform

Updated data processing terms to reflect new EU Standard Contractual Clauses

For years, Google Cloud customers who are subject to European data protection laws1 have relied on our Standard Contractual Clauses (SCCs), as previously approved by regulators, to legitimize overseas transfers of their customer personal data when using our services. Today, we are glad to announce an update to our data processing terms for Google Cloud Platform, and Google Workspace (including Workspace for Education) and Cloud Identity, to incorporate various modules of the new EU SCCs approved by the European Commission on June 4, 2021, as well as separate UK SCCs. For all Google Cloud customers, this new approach:Offers clear and transparent support for their compliance with applicable European data protection laws;Simplifies the entities involved in contracting by no longer requiring any customer to deal with an additional Google entity only for SCC purposes; andAligns more closely with potential flows of data within the services.For customers located in Europe2, Google has further simplified data transfer compliance by assuming all the responsibilities imposed by the new SCCs.We have also published a new whitepaper that outlines the European legal rules for data transfers and explains our approach to implementing the new EU SCCs – as well as separate UK SCCs – so that our customers can better understand what our updated terms mean for them and their privacy compliance.We remain committed to helping all customers who rely on our cloud services meet applicable regulatory requirements by protecting any international transfers of their data.FOOTNOTESWe refer specifically to the EU GDPR, UK GDPR and Swiss Federal Data Protection Act (FDPA)We refer specifically to customers located in the EEA, UK and SwitzerlandRelated ArticleReaffirming Google Cloud’s commitments to EU businesses in light of the EDPB’s RecommendationsReaffirming our commitment to GDPR and updated European Data Protection Board recommendations.Read Article
Quelle: Google Cloud Platform

Introducing Quota Monitoring Solution: Single Dashboard with Alerting capabilities

If you are looking for an automated way to manage quotas over a large number of projects, we are excited to introduce a Quota Monitoring Solution from Google Cloud Professional Services. By default, Google Cloud employs resource quotas to restrict how much of a particular shared Google Cloud resource you can use. Each quota represents a specific countable resource, such as API calls to a particular service or the number of compute cores used concurrently by your project.Quotas are enforced for a variety of reasons, including:To protect the community of Google Cloud users by preventing unforeseen spikes in usage and overloaded services.To help you manage resources. For example, you can set your own limits on service usage while developing and testing your applications to avoid unexpected bills from using expensive resources.Quota Monitoring Solution solution benefits anyone who manages quotas across projects, folders, or organizations. It offers an easy and centralized way to view and monitor the quota usage in a central dashboard and to use default alerting capabilities across all quotas. Specifically, the solution provides:Automated aggregation of quotas across all projects in given organizations or folders and a recurring scan at a defined frequency (e.g. hourly, daily) for new projects to automatically capture their quotas.A dashboard that provides visibility into recent resource usage against the individual quotas across all projects.Preconfigured alerting through email or other communication channels (e.g., email, SMS, Pub/Sub, etc.) when a resource reaches a certain threshold of its quota.The solution is easily deployable through Terraform so that you can adopt it into your project with minimal time investment.Outside of the Quota Monitoring Solution, there are additional ways of viewing your quota information, such as using the Google Cloud Console or using the gcloud command-line tool. You can also manually define Alerting Policies in Cloud Monitoring to send out notifications when a resource reaches a certain threshold of its quota. For example, you can define an alerting policy that triggers when the CPU usage of Compute Engine VM instances goes above 75% of the quota in any region.In case your project needs more of a particular resource than your quota allows, you can request a quota limit increase for the majority of quotas directly in the Google Cloud Console. In the vast majority of cases, quota increase requests are evaluated and processed automatically. However, depending on the nature of your request, a small number of quota increase requests needs to be handled by human reviewers. They typically process your request within 2-3 business days, so it is important to plan ahead.Ineffective quota management can lead to many different problems. For example, the lack of sufficient quota can prevent consuming additional resources, which could be needed for auto-scaling events, or for performing a GKE cluster upgrade. This can cause outages or service degradation, which could impact your customers’ experience and potentially impact your business revenues.Please note: Many services also have limits that are unrelated to the quota system. These are fixed constraints, such as maximum file sizes or database schema limitations, which cannot be increased or decreased. You can find out about these on the relevant service’s Quotas and limits page (for example, Cloud Storage quotas and limits).1. Technical ArchitectureThe diagram below shows the Quota Monitoring Solution architecture flow you can deploy in minutes using the deployment guide and accompanying terraform scripts.The solution includes a terraform script that you can deploy in a GCP project. This templates provisions the following resources in a GCP project:Cloud Scheduler- Cloud Scheduler is a fully managed, enterprise-grade cron-job scheduler. It is used to trigger Cloud Functions at scheduled intervals.Cloud Functions – Cloud Functions is an event-driven serverless compute platform. It contains the code logic to scan project quotas.Pub/Sub- Pub/Sub allows services to communicate asynchronously, with very low latency. It is used to support event-driven application design and high scalability. BigQuery –  BigQuery is a serverless, highly scalable data warehouse. It is used to store data for project quotas.Data Studio – Data Studio is a Dashboard and reporting tool. It is used to display quotas across multiple projects in a single view. You can configure other visualization tools of your choice, like Looker. In the future, we will also provide a Looker-based Dashboard.Cloud Monitoring Custom Log Metric and Alert – Google Cloud Monitoring offers logging and alerting capabilities. This is used to enable alerting that gives timely awareness to quota issues in your cloud applications so you can request a quota increase quickly. In this solution, Cloud Scheduler also works as an interface for you to provide configurations:You can provide folder IDs, organization IDs as parent nodes for which you want to monitor quotas. Parent nodes can be a single folder ID or organization ID or list of folder IDs or Organization IDs. You can also configure metric threshold and email addresses for Alerting. Currently, you can receive alerts via Email, Mobile App, PagerDuty, SMS, Slack, Web Hooks and Pub/Sub.Metric threshold is used to generate alerts. For example you can choose 70% or 80% as a threshold to generate alerts. The alerts will be sent to the configure alerting channel. Please note:Any changes in the projects like addition of new projects or deletion of existing projects will be reflected automatically in the subsequent scheduled scanning.Any changes in the GCP Cloud Monitoring APIs will be reflected. For example,  the introduction of new quota metrics will be reflected automatically in the solution without making any code changes.Any changes in the Cloud Monitoring alert notification channels will also be available automatically without the need to make any code changes.1.1 WorkflowIf we put all these components together, the workflow starts at Cloud Scheduler. You can provide your preferences of folders and organization IDs, metric threshold, email addresses and configure to run the job at scheduled intervals. Create a service account and grant access to view quota usage in the target organization/s or folder/s.Cloud scheduler automatically runs at configured frequency, for example daily, and passes user configurations to Cloud Functions. Based on the service account access, the first Cloud Functions instance lists projects of the parent node, generates the list of project IDs, and publishes them to the Pub/Sub topic.The second Cloud Function instance is triggered from the message generated in the previous step and receives the project IDs as a separate message from the topic.Upon receiving the project IDs, the second Cloud Function instance fetches the quotas for each project using publicly available GCP cloud monitoring APIs. Cloud Function loads the project’s quota data in the BigQuery table. Alerting A scheduled query on the BigQuery table filters all quotas with usage greater than the configured threshold.The third Cloud Function’s instance logs the data for metrics in Cloud Logging.Preconfigured custom log metrics in Google Cloud Monitoring create alerts, which are sent to the configured notification channel. ReportingOnce the data is loaded into BigQuery, Data Studio fetches the data from BigQuery and displays it in the Dashboard in a single view across all projects and metrics.Data Studio Dashboard is easy to use, customize, and share. You can also configure scheduled reporting from this Dashboard to receive Quota monitoring reports in email as PDF.2. Deployment ProcessThe Google Cloud custom quota monitoring solution can be deployed in a few minutes using the deployment guide and accompanying terraform scripts. Following are three simple steps:Create a service account and grant accessRun terraform script to provision all resources in a Google Cloud projectConfigure the Data Studio Dashboard For step-by-step details, please see the Readme section of the deployment guide on PSO Github. 3. How to Customize?This is an open source code available on Google Cloud PSO Github repository. You can fork the repository and customize as per your requirements. During the deployment, Terraform downloads the code. The code and the data stays in the customer’s environment. 4. SummaryQuota Monitoring solution lets you to view and monitor quotas for Google Cloud services from one central location for an organization or folder. Service Quotas enables you to easily and consistently track quota usage and receive alerts to save time and effort in setting up quota monitoring for new projects.If you have questions or suggestions for this solution, please fill out this form or reach out to us at pso-quota-monitoring@google.com AcknowledgementWe would like to thank Darpan Shah, Raghavendra Kyatham, and Marlon Pimentel for their contribution in building the solution as well as Rahul Khandkar, Karina Rivera, and Rohan Karne for sponsoring this project. We would also like to extend our gratitude to all Technical Account Managers who helped prototype and roll out the solution globally, especially Naveen Nelapudi, Vijay Narayanan, Rohit Iyer, Emily Wong, and Isha Rana.Related ArticleBest practices for optimizing your cloud costsFollowing these best practices will help optimize your cloud costs to the needs of your business, so you can get through these unpredicta…Read Article
Quelle: Google Cloud Platform

What are the components of a Cloud VM?

Last week, we published our second episode of VM End-to-End, a series of curated conversations between a “VM skeptic” and a “VM enthusiast”. Join Brian and Carter as they explore why VMs are some of Google’s most trusted and reliable offerings, and how VMs benefit companies operating at scale in the cloud. Here’s a transcript:Carter Morgan: Welcome to VM End to End, a show where we have a VM skeptic and a VM enthusiast try and hash out are VMs still amazing and awesome? So Brian, thanks for coming in today. I appreciate you.Brian Dorsey: Happy to be here. Let’s get to it.What a Cloud VM isCarter: Yes. Yes. Last time, we talked about if cloud VMs are relevant and if VMs are still relevant in a cloud-native future? You said, “definitely yes.” So today I want to go a little bit deeper and find out what exactly is a cloud VM? Can you help me out?Brian: Absolutely. Let’s get into it. And first, it’s a virtual machine. I think most of what people know about virtual machines is all true for cloud VMs. And the thing I hope we get out of this today is that there’s a bunch of extra stuff you might not know about or might not think to look into.Carter: Okay. All right. It’s like a regular VM, but not. So a regular VM. We said it’s a machine on a computer. You said a cloud VM is a little bit different. What are the specific differences with the real parts, the physical parts?Brian: Yeah. In the end, it’s all running on real computers somewhere. So when the VM is up and running, you’ve got a real CPU. You’ve got a physical memory. And I think the parts that are the most fluid are probably the disc and the network. And in Google Cloud, those are both software-defined services that give you a lot of flexibility. So I think the takeaway here is instead of thinking about it as a slice of one computer, think about it as a slice of a data center’s worth of computers.How we interface with a “slice of the data center”Carter: Wow. All right. So that’s an interesting thought to me. And what I’m curious about is if I have a slice of a data center, how is that manageable or usable? If I wanted to make a video game, what can I do with a slice of a data center?Brian: I think that’s a great example. So it’s down to what are you trying to do? And we then take a bunch of the variables that are possible and group them up. So we group them up into compute optimized, memory optimized, accelerator optimized, and then general purpose. So the compute ones are for where you need the lowest latency, single-threaded computation possible. Memory is where you need the maximum memory you can possibly stuff in a machine. You’re running an in-memory database or something. And the accelerator ones are for when you need a GPU or one of our tensor processing units. And then for everything else, general purpose.Carter: General purpose. It’s like most people just need a laptop. So, okay. You have these specific groupings, maybe families of machines ordered. Within those families, can I specialize, like if I need a high-end gaming laptop versus just a low-end gaming laptop?Brian: Absolutely. And the first knob you have is just how big it is. So how many CPUs and memory. So you can have a two-core machine or a 20 or a 460-core machine. Carter: Really?Brian: Yeah, really. And up to 12 terabytes of memory right now. And those numbers keep getting bigger over time. So it depends when you see this, it might be different. And by default, those come in a preset ratio. So they grow together. But part of the main reason people wanted to use containers at all is that not everything fits in that exact shape. So you end up orphaning some of the capacity and you’re wasting money. So we also allow you with the general purpose machines to pick your own ratio. So if you’re like, “Oh, I know this is a really CPU-heavy thing, but I don’t need that much memory.” You can make a computer that’s that shape, and you’ll only pay for what you actually need.Where the physical disks live in the data centerCarter: Oh, that’s really cool. Okay. So if you can make your own shape, somewhere there has to be physical memory. So where do we get this in a cloud VM?Brian: Yep. So when you go to set one of these up, we find one of the machines out there that has space for the shape you want and start it up there. And so this Tetris problem becomes not your problem. And we’re big enough that there’s almost always a good spot for that to fit.Carter: Yeah. And so these are all on one machine, it just sounded like there.Brian: Oh. So there’s a data center worth of machines. And so when you go to start yours up, we find the right spot for it, find a computer that has open space.Carter: So tell me a little bit more about disk then in this slice of a data center world.Brian: So if we can just turn it on on any one of these computers in a data center, how do the discs work? Where’s my data? And so by default, our discs are almost always network-attached storage. And so instead of a physical disc plugged into one computer… I mean, those still exist, but we provide a virtual disc made up of hundreds or thousands of discs plugged into a whole bunch of computers, and then assemble the blocks together virtually, which gives you… You actually get higher performance than you might get normally. So the throughput is very fast. And then you get a bunch of the features that you might expect from a SAN, a storage area network.Carter: So you’re going to attach and detach on the fly. You can-Brian: Yep.Carter: Okay. That’s really cool.Brian: So you can do that. You can resize it and use the snapshots to take backups. But the resize thing is amazing. If you run out of disc space, you can actually make the disc bigger while the computer’s running.What OSes are allowed to run on a Cloud VMCarter: Brian, you’re blowing my mind right now. I’ve got to act skeptical. I’m going to be skeptical. But you’re blowing my mind. Here’s something I’m curious about: When I’m using containers, I can select an operating system. And so the benefit of that is I can write applications to operating systems that I know and love. I can only use what I need. Is there that same concept in the VM world, or am I stuck… Am I forced to use certain types of operating systems to use a cloud VM.Brian: Yeah. Very similar concept. Whereas in a container, it’s mostly just the files that make up that system per runtime, whereas here, we have the whole operating system running. But other than that, it’s really pretty much the same concept. Most workloads these days are running on Linux or windows. And so we provide pre-made images of Debbie and CentOS, CoreOS, Ubuntu, Red Hat Enterprise, SUSE, and Windows Server Datacenter, a bunch of different versions. So when you create a VM, you say, “Okay, I want it to run this OS,” and it makes a copy of that image on the fly and boots your machine off of that.Carter: Okay. That’s really cool. Can you use your own at all?Brian: Yeah. Two ways to do it. So one, if you want to use one of these OSes and just put your flavor on it, add some tools, configure it the way you want it to be, you can boot off of one of them and then make a new image based off of the work you did. So that’s a really common thing. And then if you want to, it’s a block device. And so you can make a customized version of an OS or develop a whole new OS. And as long as that runs in a virtual machine, you can boot off of it and go.What you can actually *do* with Cloud VMsCarter: I got to be honest. It sounded like there’s a lot of flexibility. All these things, I’m like, “Well, in containers you can do this.” And you’re like, “Yes, you can do this in the VM world too.”Brian: And a lot of it’s based on… So this is a high-level version of what a cloud VM is. You can basically run anything that runs on a computer.Carter: Okay. All right. We just specified really quick. There’s some virtual parts, there’s some physical parts. Your disks are going to be spread out over a wide data center, pooled together to give you more reliability, more consistency. A lot of times you said it’s even faster throughput. This is really cool. What I’m curious about is what are actual things that are non-obvious extensions of this? What can I do with this? Brian: I think one of the underused or underknown things is actually running a container, one container per VM as a pattern.Carter: Yeah. Why would I do that?Brian: So a couple of different reasons. One, containers have become a distribution format. So a lot of software’s already ready to go in a container. And sometimes, you don’t want to deal with setting up a whole cluster or managing some other stuff. You just want to run one thing. So that’s a reason to do it. And then sometimes, there’s constraints. Like that particular thing, it might make sense to run it on a very large machine for a short amount of time, or it needs some particular configuration that you might not have otherwise. So it may make sense to run-Carter: Right. And still use that packaging of containers.Brian: Yeah. One-to-one.Carter: Okay. That makes a lot of sense. All right. But I mean, in theory, I could still run containers for a lot of this. What are some other features of cloud VMs that you’re excited about?Brian: Yeah. So one, I think, is it’s really commonly used in almost all architectures, and pretty much everybody has a load balancer when you have multiple machines, right?Carter: Mm-hmm (affirmative).Brian: And the non-obvious cool thing is that yes, we have a load balancer, but it’s a load balancer service that is provided at the data center level. It’s not some particular computer that has a certain capacity that as soon as you hit, things start slowing down or getting overdrawn. So you’re actually configuring the data center level load balancer that Google uses for YouTube and Gmail to run your own machines.Why developers operate at the VM / IaaS levelCarter: So one, that’s just really cool, thinking about that concept. But what I’m blown away right now is thinking that in Kubernetes, I use services all the time. And if I’m using GKE (aka Google Kubernetes Engine), the load balancer that’s provided is the cloud load balancer, the Google one. So even then, I’m using the Google Cloud load balancer. My question though is I can still access this load balancer. It sounds like it’s configured already for me through something like Kubernetes. Is there a reason to go lower? Is there a reason to go to this level?Brian: So if you’re already using Kubernetes, use Kubernetes. Those patterns are super useful, but not all software is set up to run containers. So if you want to use those same patterns-Carter: That pattern of having a single end point that you can communicate with.Brian: Yeah. There’s this idea of having a known endpoint that provides this service. And then there’s a group of containers usually in Kubernetes, but a group of computers, in this case, that do that. And once you do that, you have a known endpoint and a group of computers. And we call that group in Compute Engine a managed instance group. Then you can put a bunch of logic on that. So it’s actually a service in and of itself. So it handles starting up new machines when they’re needed. If you turn the dial up and you’re like, “Oh, I have five now and I want to have 10,” it starts the new ones. That can be set up to be run automatically depending on the load you get. And then you can spread those out across the world. You can have some of them running in one country, some of them running somewhere else, and route the traffic to the closest one for your users, that sort of thing.What’s next?Carter: I’m going to have to find out more about this. I’m going to have to dig in deeper because I want to be skeptical. And I’m like, “This all sounds amazing.” Further, I think… I don’t want this conversation to go too long, but I’m definitely going to want to dig in deeper here. In fact, maybe we can have an episode… Would you count this as an admin infrastructure networking? What is this that we’re talking about?Brian: Yeah. I think we should dive into networking a bit more next and how that actually works. And when I say it’s not running on one box, how does, “Wait, what? How do you distribute traffic if it’s not going through one machine?” So let’s do networking. And then I love the discs, and there’s a lot more to talk about there. Let’s do that. What else do you want to hear about?Carter: There is, for sure. I want to hear about costs. I’m going to have to do some of my own homework after hearing about machine families and all of this. I need to go start and create a VM. And I hope people listening at home do the same thing. Yes. Because I’m going to be more skeptical next episode. Okay? I’m going deeper. But this episode, I have to admit, cloud VMs sound pretty cool.Brian: They are. Give it a try.Carter: All right. Well, thank you, Brian. And I’ll catch up with you next time.Brian: See you soon.So they’re you have it: we learned what cloud VMs were last time, but this time we focused on what cloud VMs are made of. Since cloud VMs are a slice of a data center, they have some benefits over traditional VMs: for example, disks can be fit to exactly the workload you’re trying to run. In other instances, cloud VMs behave like traditional VMs and, as Brian stated, can “run anything a computer can run.”If you want to learn more about GCE, be sure to check it out here: https://cloud.google.com/computeRelated ArticleVMs and their relevance to a cloud-native future: A conversationDo VMs Even Matter? A conversation, based on a new Podcast “VM End-To-End”, about VMs and their relevance to a cloud-native futureRead Article
Quelle: Google Cloud Platform

Announcing Apigee’s native support for managing lifecycle of GraphQL APIs

Application Programming Interfaces (APIs) are the de facto standard for building and connecting technology solutions. They facilitate software-to-software interactions that allow developers to leverage data and functionality at scale. APIs come in various styles such as REST, gRPC, GraphQL, and AsyncAPI, and each style has its own features. Picking the right API style completely depends on your use case and what you are solving for. While REST is widely used, of late, formats like GraphQL are gaining popularity among developers.GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. Developers are increasingly adopting GraphQL for its flexibility and ease of use. It provides a single endpoint for all data exchange, prevents over- or under-fetching of data, and lets developers make one API call that seamlessly aggregates data from multiple apps and services.Today, we are excited to announce that Google Cloud’s Apigee API management platform natively supports GraphQL APIs, allowing developers to productize and manage their lifecycle in Apigee. Before we learn more about these capabilities, let’s take a closer look at GraphQL.REST and GraphQL API styles differ across many dimensionsREST and GraphQL API styles differ across many dimensions:Endpoints- REST provides multiple endpoints and a URL taxonomy that’s used as a logical resource manager. In GraphQL, there’s one endpoint that captures all fields for a given operation.Interactions – REST commonly uses HTTP verbs and JSON/XML to exchange data. GraphQL mostly uses the HTTP POST verb, and uses a custom query language called Schema Definition Language for request with standard JSON returned in response.Documentation- While REST uses OpenAPI specs and portals, GraphQL most frequently employs schema-generated documentation. Developers frequently use browser-based development environments such as GraphQL playground in order to interact with schema-based endpoints.Discovery- To discover and interact with REST APIs, developers usually use the portal provided by the management vendor, whereas GraphQL APIs tend to be offered with a built-in portal that enables users to explore new queries on the fly.Therefore, instead of picking one style over another, consider using them together in your API program, to solve for the use cases they’re best suited for. Why GraphQL APIs need to be managed Regardless of their design styles, APIs provide access to your enterprise’s most valuable data and functionality. They’re how developers leverage your data for new partnerships and digital services. This means enterprises must control and understand how and by whom APIs are used. Moreover, beyond access management, enterprises need to design and deploy APIs that give developers a first-class experience and help them to be productive. Consequently, APIs should not be viewed as snippets of code but rather as digital products that need full lifecycle management.Packaging GraphQL APIs as products allows you to overcome some limitations of this style such as:Limited authorization capabilities especially for schema browsingNo standard for throttling or quotasNo unified analytics for consumptionLack of version controlAs you scale the adoption of GraphQL APIs for solving business critical problems, it becomes extremely important to manage those APIs as products. This is where there’s a huge opportunity to extend the proven best practices of REST API management to GraphQL.Using Apigee for GraphQL APIsApigee is a market-leading full lifecycle API management platform trusted by thousands of enterprises across the globe. With the new native support, Apigee now allows you to productize and manage full lifecycle of GraphQL APIs for consumption, just like REST.Developers can use the GraphQL policy to:Impose restrictions on the payload by setting a maximum on the number of fragments allowed.Associate GraphQL with API products.Leverage the OAuth2, VerifyAPIKey, and Quota policy features, just as in REST.Validate and authenticate requests at the schema level.Getting StartedVisit the documentation and get step-by-step instructions on how to get started. If you are not familiar with Apigee, click here to sign up for a free trial. Related ArticleDesigning and managing APIs: Best practices & common pitfallsThe job of an API is to make the application developer as successful as possible. When crafting APIs, the primary design principle should…Read Article
Quelle: Google Cloud Platform

Building the data engineering driven organization from the first principles

In the “What type of data processing organisation” paper, we examined that you can build a data culture whether your organization consists mostly of data analysts, or data engineers, or data scientists. However, the path and technologies to become a data-driven innovator are different and success comes from implementing the right tech in a way that matches a company’s culture. In this blog we will expand the data engineering driven organizations and provide how it can be built from the first principles.Not all organizations are alike. All companies have similar functions (sales, engineering, marketing), but not all functions have the same influence on the overall business decisions. Some companies are more engineering-driven, others are sales-driven, others are marketing-driven. In practice, all companies are a mixture of all these functions. In the same way, the data strategy can be more focused on data analysts, and others on data engineering. Culture is a combination of several factors, business requirements, organizational culture, and skills within the organization. Traditionally organizations that focused on engineering mainly came from technology driven digital backgrounds. They built their own frameworks or used programming frameworks to build repeatable data pipelines. Some of this is due to the way the data is received, the shape the data is received and the speed of the data arrival as well. If your data allows it, your organization can be more focused on data analysis, and not so much on data engineering. If you can apply an Extract-Load-Transform approach (ELT) rather than the classic Extract-Transform-Load (ETL), then you can focus on data analysis and might not need extensive data engineering capability. For example, data that can be loaded directly into the data warehouse allows data analysts to also do data engineering work and apply transformations to the data.This does not happen so often though. Sometimes your data is messy, inconsistent, bulky, and encoded in legacy file formats or as part of legacy databases or systems, with a little potential to be actionable by data analysts. Or maybe you need to process data in streaming, applying complex event processing to obtain competitive insights in near real time. The value of data decays exponentially with time. Most companies can process data by the next day in batch mode. However, not so many are probably obtaining such knowledge the next second data is produced.In these situations, you need the talent to unveil the insights hidden in that amalgam of data, either messy or fast changing (or both!). And almost as importantly, you need the right tools and systems to enable that talent too.What are those right tools? Cloud provides the scalability and flexibility for data workloads that are required in such complex situations. Long gone are the times when data teams had to beg for the resources that were required to have an impact in the business. Data processing systems are no longer scarce, so your data strategy should not generate that scarcity artificially.In this article, we explain how to leverage Google Cloud to enable data teams to do complex processing of data, in batch and streaming. By doing so, your data engineering and science teams can have an impact when (in seconds) after the input data is generated.Data engineering driven organizationsWhen the complexity of your data transformation needs is high, data engineers have a central role in the data strategy of your company, leading to data engineering driven organization. In this type of organization, data architectures are organized in three layers: business data owners, data engineers, and data consumers.Data engineers are at the crossroads between data owners and data consumers, with clear responsibilities:Transporting data, enriching data whilst building integrations between analytical systems and operational systems ( as in the real time use cases)Parsing and transforming messy data coming from business units into meaningful and clean data, with documented metadataApplying DataOps, that is, functional knowledge of the business plus software engineering methodologies applied to the data lifecycleDeployment of models and other artifacts analyzing or consuming dataBusiness data owners are cross-functional domain-oriented teams. These teams know the business in detail, and are the source of data that feeds the data architecture. Sometimes these business units may also have some data-specific roles, such as data analysts, data engineers, or data scientists, to work as interfaces with the rest of the layers. For instance, these teams may design a business data owner, that is the point of contact of a business unit in everything that is related to the data produced by the unit.At the other end of the architecture, we find the data consumers. Again, also cross-functional, but more focused on extracting insights from the different data available in the architecture. Here we typically find data science teams, data analysts, business intelligence teams, etc. These groups sometimes combine data from different business units, and produce artifacts (machine learning models, interactive dashboards, reports, and so on). For deployment, they require the help of the data engineering team so that data is consistent and trusted.At the center of these crossroads, we find the data engineering team. Data engineers are responsible for making sure that the data generated and needed by different business units gets ingested into the architecture. This job requires two disparate skills: functional knowledge and data engineering/software development skills. This is often coined under the term DataOps (which evolved from DevOps methodologies developed within the past decades but applied to data engineering practices).Data engineers have another responsibility too. They must help in the deployment of artifacts produced by the data consumers. Typically, the data consumers do not have the deep technical skills and knowledge to take the sole responsibility for deployment of their artifacts.This is also true for highly sophisticated data science teams. So data engineers must add other skills under their belt: machine learning and business intelligence platform knowledge. Let’s clarify this point, we don’t expect data engineers to become machine learning engineers. Data engineers need to understand ML to ensure that the data delivered to the first layer of a model ( the input ) is correct. They will also become key when delivering that first layer of data in the inference path, as here the data engineering skills around scale / HA etc really need to shine.By taking the responsibility of parsing and transforming messy data from various business units, or for ingesting in real time, data engineers allow the data consumers to focus on creating value. Data science and other types of data consumers are abstracted away from data encodings, large files, legacy systems, complex message queue configurations for streaming. The benefits of concentrating that knowledge in a highly skilled data engineering team are clear, notwithstanding that other teams (business units and consumers) may also have their data engineers to work as interfaces with other teams. More recently, we even see squads created with members of the business units (data product owners), data engineers, data scientists, and other roles. Effectively creating complete teams with autonomy and full responsibility over a data stream, from the incoming data down to the data driven decision with impact in the business.Reference architecture – ServerlessThe number of skills required for the data engineering team is vast and diverse. We should not make it harder by expecting the team to maintain the infrastructure where they run data pipelines. They should be focusing on how to cleanse, transform, enrich, and prepare the data rather than how much memory or how many cores their solution may require.The reference architectures presented here are based on the following principles:Serverless no-ops technologiesStreaming-enabled for low time-to-insightWe present different alternatives, based on different products available in Google Cloud:Dataflow, the built-in streaming analytics platform in Google CloudDataproc, the Google Cloud’s managed platform for Hadoop and Spark. Data Fusion, a codeless environment for creating and running data pipelinesLet’s dig into these principles. By using serverless technology we eliminate the maintenance burden from the data engineering team, and we provide the necessary flexibility and scalability for executing complex and/or large jobs. For example, scalability is essential when planning for traffic spikes during mega Friday for retailers. Using serverless solutions allows retailers to look into how they are performing during the day. They no longer need to worry about resources needed to process massive data generated during the day.The team needs to have full control and write their own code for the data pipelines because of the type of pipelines that the team develops. This is true either for batch or streaming pipelines. In batch, the parsing requirements can be complex and no off the shelf solution works. In streaming, if the team wants to fully leverage the capabilities of the platform, they should implement all the complex business logic that is required, without artificially simplifying the complexity in exchange for some better latency. They can develop a pipeline that achieves a low latency with highly complex business logic. This again requires the team to start writing code from first principles.However, that the team needs to write code should not imply that they need to rewrite any existing piece of code. For many input/output systems, we can probably reuse code from patterns, snippets, and similar examples. Moreover, a logical pipeline developed by a data engineering team does not necessarily need to map to a physical pipeline. Some parts of the logic can be easily reused by using technologies like Dataflow templates, and use those templates in orchestration with other custom developed pipelines. This brings the best of both worlds (reuse and rewrite), while saving precious time that can be dedicated to higher impact code rather than common I/O tasks. The reference architecture presented has another important feature: the possibility to transform existing batch pipelines to streaming.The ingestion layer consists of Pub/Sub for real time and Cloud Storage for batch and does not require any preallocated infrastructure. Both Pub/Sub and Cloud Storage can be used for a range of cases as it can automatically scale up with the input workload.Once the data has been ingested, our proposed architecture follows the classical division in three stages: Extract, Transform, and Load (ETL). For some types of files, direct ingestion into BigQuery (following an ELT approach) is also possible.In the transform layer, we primarily recommend Dataflow as the data process component. Dataflow uses Apache Beam as SDK. The main advantage of Apache Beam is the unified model for batch and streaming processing. As mentioned before, the same code can be adapted to run in batch or streaming by adapting input and output. For instance, switching the input from files in Cloud Storage to messages published in a topic in Pub/Sub.One of the alternatives to Dataflow in this architecture is Dataproc, Google Cloud’s solution for managed Hadoop and Spark clusters. The main use case is for those teams that are migrating to Google Cloud but have large amounts of inherited code in Spark or Hadoop. Dataproc enables a direct path to the cloud, without having to review all those pipelines. Finally, we also present the alternative of Data Fusion, a codeless environment for creating data pipelines using a drag-and-drop interface. Data Fusion actually uses Dataproc as its Compute Engine, so everything we have mentioned earlier applies also to the case of Data Fusion. If your team prefers to create data pipelines without having to write any code, Data Fusion is the right tool.So in summary, these are the three recommended components for the transform layer:Dataflow, powerful and versatile with a unified model for batch and streaming processing. Straightforward path to move from batch processing to streamingDataproc, for those teams that want to reuse existing code from Hadoop or Spark environments.Data Fusion, if your team does not want to write any code.Challenges and opportunitiesData platforms are complex. Having on top of that data responsibility the duty to maintain infrastructure is a wasteful use of valuable skills and talent. Often data teams end up managing infrastructure rather than focusing on analyzing the data. The architecture presented in this article liberates the data engineering team from having to allocate infrastructure and tweak clusters but instead to focus on providing value through data processing pipelines.For data engineers to focus on what they do best, you need to fully leverage the cloud. A lift & shift approach from any on-premise installation is not going to provide that flexibility and liberation. You need to leverage serverless technologies. As an added advantage, serverless lets you also scale your data processing capabilities with your needs, and be able to respond to peaks of activity, however large these are.Serverless technologies sometimes face the doubts of practitioners: will I be locked in with my provider if I fully leverage serverless? This is actually a question that you should be asking when deciding whether to set up your architecture on top of a provider. The components presented here for data processing are based on open source technologies, and fully interoperable with other open source equivalent components. Dataflow uses Apache Beam, which not only unifies batch and streaming, but also offers a widely compatible runner. You can take your code elsewhere to any other runner. For instance, Apache Flink or Apache Spark. Dataproc is a fully managed Hadoop and Spark based on the vanilla open source components of this ecosystem. Data Fusion is actually the Google Cloud version of CDAP, an open source project.On the other hand, for the serving layer, BigQuery is based on standard Ansi SQL. Whereas in the case of Bigtable and Google Kubernetes Engine, Bigtable is compatible at API level with HBase, and Kubernetes is an open source component.In summary, when your components are based on open source, like the ones included in this architecture, serverless does not lock you in. The skills required to encode business logic in the form of data processing pipelines are based on engineering principles that remain stable across time. The same principles apply if you are using Hadoop, Spark, or Dataflow or UI driven ETL tooling. In addition, there are now new capabilities, such as low-latency streaming, that were not available before. A team of data engineers that learn the fundamental principles of data engineering will be able to quickly leverage those additional capabilities.Our recommended architecture separates the logical level, the code of your applications, from the infrastructure where they run. This enables data engineers to focus on what they do best and on where they provide the highest added value. Let your Dataflow and your engineers impact your business, by adopting the technologies that liberate them and allow them to focus on adding business value. To learn more about building an unified data analytics platform, take a look at our recently published Unified Data Analytics Platform paper and Converging Architectures paper.
Quelle: Google Cloud Platform

Cloud DNS explained!

How many times have you heard this:”It’s not DNS.””NO way it is DNS.””It was the DNS!”When you are building and managing cloud native or hybrid cloud applications you don’t want to add more stuff to your plate, especially not DNS. DNS is one of the necessary services for your application to function but you can rely on a managed service to take care of DNS requirements. Cloud DNS is a managed, low latency DNS service running on the same infrastructure as Google which allows you to easily publish and manage millions of DNS zones and records.Click to enlargeHow does DNS work?When a client requests a service, the first thing that happens is DNS resolution. Which means hostname to IP address translation. Here is how the request flow works:Step 1 – A client makes a DNS requestStep 2 – The request is received by a recursive resolver which checks if it already knows the response to the request Step 3 (a)- If yes, the recursive resolver responds to request if it has it stored in cache already.Step 3 (b) – If no, the recursive resolver redirects request to other serversStep 4 – The authoritative server then responds to requestsStep 5 – Recursive resolver caches the result for future queries. Step 6 – And finally sends the information to the clientWhat does Cloud DNS offer?Global DNS Network: Managed Authoritative Domain Name System (DNS) service running on the same infrastructure as Google. You don’t have to manage your DNS server, Google does it for you. 100% Availability & Automatic Scaling: Cloud DNS uses Google’s global network of anycast name servers to serve your DNS zones from redundant locations around the world, providing high availability and lower latency for users. Allows customers to create, update, and serve millions of DNS records  Private DNS Zones: Used for providing a namespace that is only visible inside the VPC or hybrid network environment. Example – a business organization has a domain dev.gcp.example.com, reachable only from within the company intranetPublic DNS Zones: Used for providing authoritative DNS resolution to clients on the public internet. Example – a business has an external website, example.com accessible directly from the Internet. Not to be confused with Google Public DNS (8.8.8.8) which is just a public recursive resolver Split horizon DNS: Used to serve different answers (different resource record sets) for the same name depending on who is asking – internal or external network resource.DNS peering: DNS peering makes available a second method of sharing DNS data. All or a portion of the DNS namespace can be configured to be sent from one network to another and, once there, will respect all DNS configuration defined in the peered network.Security: Domain Name System Security Extensions (DNSSEC) is a feature of the Domain Name System (DNS) that authenticates responses to domain name lookups. It prevents attackers from manipulating or poisoning the responses to DNS requests.Hybrid Deployments: DNS ForwardingGoogle Cloud offers inbound and outbound DNS forwarding for private zones. You can configure DNS forwarding by creating a forwarding zone or a Cloud DNS server policy. The two methods – inbound and outbound. You can simultaneously configure inbound and outbound DNS forwarding for a VPC network. Inbound Create an inbound server policy to enable an on-premises DNS client or server to send DNS requests to Cloud DNS. The DNS client or server can then resolve records according to a VPC network’s name resolution order. On-premises clients use Cloud VPN or Cloud Interconnect to connect to the VPC network.OutboundYou can configure VMs in a VPC network to do the following:Send DNS requests to DNS name servers of your choice. The name servers can be located in the same VPC network, in an on-premises network, or on the internet. Resolve records hosted on name servers configured as forwarding targets of a forwarding zone authorized for use by your VPC networkCreate an outbound server policy for the VPC network to send all DNS requests an alternative name server.For more #GCPSketchnote, follow the GitHub repo. For similar cloud content follow me on Twitter @pvergadia and keep an eye out on thecloudgirl.devRelated ArticleIt’s not DNS: Ensuring high availability in a hybrid cloud environmentLearn how to configure your environment to ensure that your Cloud DNS environment is highly available in a hybrid environmentRead Article
Quelle: Google Cloud Platform

Deploying the Cloud Spanner Emulator remotely

Welcome to the third part of our series on the Cloud Spanner Emulator. In the first part, we got an overview of Cloud Spanner and the emulator, as well as the various ways that it can be provisioned. In the second part, we explored the various options available for running the emulator locally, as well as how to build the emulator as one of the components in an application container.The emulator can also be deployed on a remote GCE instance or Cloud Run. Today, we will deploy the emulator services on a GCE host manually and via Terraform. Finally, we will also run the emulator on Cloud Run. Cloud Spanner emulator on GCEIn the previous post, we have deployed the application and the emulator on separate containers by attaching both containers to a Docker network. In environments with VPC / project level separation for dev, stage and production it might be useful to run an emulator on a dedicated remote host. Apart from the ability to point your applications to the public/private IP of the emulator instance, this also allows for collaborative troubleshooting of failed test cases, etc.  Manual deployment This section covers the steps to provision a GCE instance and start the emulator services. For the sake of completeness, it has instructions starting from creating a VPC; however, you can skip this and make changes according to your environment.If you have been working through this series so far, your gcloud config is likely set to the emulator. Before you proceed with the commands below, please switch to a different configuration (e.g., your default one)Next, you need to ensure the default gcloud configuration is set correctly. Below we are enabling authentication, unsetting any API endpoint URL set previously, and setting the GCP project we intend to use in the default gcloud configuration.Create a VPC, subnet and firewall rules (you might want to edit the firewall rule source range to be more restrictive):Create an emulator VM. We will run the emulator service with the instance creation itself by passing –metadata startup-script. Replace the placeholder [Your-Project-ID] with your GCP project ID. Once the instance comes up and the emulator services are running, you can follow the instructions from the earlier blog posts to deploy the sample application. The only difference is that we change localhost to the public IP address (or private IP address if you are working from the same VPC or connected via VPN). NOTE – If you are using a public IP address here, all of the data exchanged between your client and the remote emulator will be transmitted in plain text over the internet. Please ensure that you’re not sending privacy-sensitive data.Example configuration below:Provisioning an emulator GCE instance via Terraform In an environment that follows the GitOps style of deployments, having a Terraform template for provisioning the emulator instance can be useful as well. You can follow the instructions below to spin up an instance with the emulator running.Clone this repo which contains the Terraform code modules that we will be using:First, we will have to initialize Terraform so it would download and install the provider plugin and configure the child module.Open the terraform.tfvars file and edit the name of the VM, Project ID, Region and Zone based on your environment. Initialize Terraform:And apply:You can now connect to the VM verify if the emulator services are up and running.Once the VM is up and running with the emulator services started, you can use the VM’s public or private IP address to configure SPANNER_EMULATOR_HOST and connect, similar to what we described in the Manual Deployment section above. Cloud Spanner emulator on Cloud Run Since the emulator is available as a pre-built Docker image (or you can manually build from the source), deploying the emulator services on Cloud Run is straightforward. Cloud Run supports gRPC (after enabling HTTP2). However, it is important to remember that when using Cloud Run, you will be able to route requests to only one port at any given point in time. NOTE – While it is possible to run multiple processes inside the same container in Cloud Run (in this case, gRPC server and REST server), the requests can only be sent to one port. If your application uses only client libraries or RPC API (gRPC), then you can configure Cloud Run to send requests to the 9010 port. If you use only the REST API, then you can configure port 9020. Also, remember to set minimum instances to ‘1’ to prevent the container from being removed and thereby losing data when there is no activity.You can choose from any of the following options:Option 1: Deploy emulator gRPC on Cloud RunOption 2: Deploy REST server on Cloud Run NOTE – Avoid using both options simultaneously, as that will create two different instances of the emulator, and two different copies of your database that would be out of sync, i.e. depending on which emulator instance serves your request, you may get completely different results.Once done, you can configure your emulator profile pointing to Cloud Run’s URL like below:If you are using REST server:If you are using gRPC:NOTE – We have not specified a port number above since the requests to the Cloud Run URL already route to the port used (9010 or 9020) directly. Therefore, you just need to add the Cloud Run URL, without the port. Conclusion Through this 3-part series of blogs, we introduced the Cloud Spanner Emulator and detailed various options available to start and use the emulator both locally and on a remote host. We also demonstrated how the emulator can be used in a development workflow as a no-cost experience for Cloud Spanner using a sample application. Hope you found this useful! To learn more about Cloud Spanner, visit the product page here and to learn more about the Cloud Spanner emulator, please see the documentation here.Related ArticleDeployment models for the Cloud Spanner emulatorThis is the first of a three-part series of blog posts, which together will form a solution guide for developers using the Cloud Spanner …Read Article
Quelle: Google Cloud Platform

Introducing Google Cloud Deploy: Managed continuous delivery to GKE

Continuous delivery is frequently top-of-mind for organizations adopting Google Kubernetes Engine (GKE). However, continuous delivery —deploying container image artifacts into your various environments—remains complex, particularly in Kubernetes environments. With little in the way of accepted best practices, building and scaling continuous delivery tooling, pipelines, and repeatable processes is hard work that requires a lot of on-the-job experience.It doesn’t have to be this way. Today, we are pleased to announce Google Cloud Deploy, a managed, opinionated continuous delivery service that makes continuous delivery to GKE easier, faster, and more reliable.Solving for continuous delivery challengesGoogle Cloud Deploy is the product of discussions with more than 50 customers to better understand the challenges they face doing continuous delivery to GKE. From cloud-native to more traditional businesses, three themes consistently emerged: cost of ownership, security and audit, and integration.Let’s take a deeper look at these challenges and how we address them with Google Cloud Deploy.Cost of ownershipTime and again we heard that the operational cost of Kubernetes continuous delivery is high. Identifying best and repeatable practices, scaling delivery tooling and pipelines, and staying current—to say nothing of maintenance—is resource-intensive and takes time away from the core business. “We can’t afford to be innovating in continuous delivery,” one customer told us. “We want an opinionated product that supports best practices out of the box.”Google Cloud Deploy addresses cost of ownership head-on.As a managed service, Google Cloud Deploy eliminates the scaling and maintenance responsibilities that typically come with self-managed continuous delivery solutions. Now you can reclaim the time spent maintaining your continuous delivery tooling and spend it delivering value to your customers. Google Cloud Deploy also provides structure. Delivery pipelines and targets are defined declaratively and are stored alongside each release. That means if your delivery pipeline changes, the release’s path to production remains durable. No more time lost troubleshooting issues on in-flight releases caused by changes made to the delivery pipeline.We have found that a variety of GKE roles and personas interact with continuous delivery processes. A DevOps engineer may be focused on release promotion and rollback decisions, while a business decision maker thinks about delivery pipeline health and velocity. Google Cloud Deploy’s user experience keeps these multiple perspectives in mind, making it easier for various personas to perform contextualized reviews and make decisions, improving efficiency and reducing cost of ownership.Contextualized deployment approvalsSecurity and auditLots of different users interact with a continuous delivery system, making a variety of decisions. Not all users and decisions carry the same authority, however. Being able to define a delivery pipeline and make updates doesn’t always mean you can create releases, for example, nor does being able to promote a release to staging mean you can approve it to production. Modern continuous delivery is full of security and audit considerations. Restricting who can access what, where, and how is necessary to maintain release integrity and safety.Throughout, Google Cloud Deploy enables fine-grained restriction, with discrete resource access control and execution-level security. For additional safeguards against unwanted approvals, you can also take advantage of flow management features such as release promotion, rollback, and approvals.Auditing with Google Cloud Deploy works just like it does for other Google Cloud services. Cloud Audit Logs audits user-invoked Google Cloud Deploy activities, providing centralized awareness into who promoted a specific release or made an update to a delivery pipeline.IntegrationWhether or not you already have continuous delivery capabilities, you likely already have continuous integration (CI), approval and/or operation workflows, and other systems that intersect with your software delivery practices.Google Cloud Deploy embraces the GKE delivery tooling ecosystems in three ways: connectivity to CI systems, support for leading configuration (rendering) tooling, and Pub/Sub notifications to enable third-party integrations.Connecting Google Cloud Deploy to existing CI tools is straightforward. After you build your containers, Google Cloud Deploy creates a delivery pipeline release that initiates the Kubernetes manifest configuration (render) and deployment process to the first environment in a progression sequence. Whether you are using Jenkins, Cloud Build, or another CI tool, this is usually a simple `gcloud beta deploy releases create`.Delivering to Kubernetes often changes over time. To help, Google Cloud Deploy  leverages Skaffold, allowing you to standardize your configuration between development and production environments. Organizations new to Kubernetes typically deploy using raw manifests, but as they become more sophisticated, may want to use more advanced tooling (Helm, Kustomize, kpt). The combination of Google Cloud Deploy and Skaffold lets you transition to these tools without impacting your delivery pipelines.Finally, to facilitate other integrations, such as a post-deployment test execution or third party approval workflows, Google Cloud Deploy emits Pub/Sub messages throughout a release’s lifecycle.The futureComprehensive, easy-to-use, and cost-effective DevOps tools are key to building an efficient software development team, and it’s our hope that Google Cloud Deploy will help you complete your CI/CD pipelines. And we’re just getting started! Stay tuned as we continue to introduce exciting new capabilities and features to Google Cloud Deploy in the months and quarters to come.In the meantime, to get started with the Preview, check out the product page, documentation, quickstart, and tutorials. Finally, If you have feedback on Google Cloud Deploy, you can join the conversation. We look forward to hearing from you!Related Article2021 Accelerate State of DevOps report addresses burnout, team performanceThe SODR is continually one of the most downloaded assets on the GCP website. We are releasing the updated version of the report with new…Read Article
Quelle: Google Cloud Platform

Dual deployments on Vertex AI

In this post, we will cover an end-to-end workflow enabling dual model deployment scenarios using Kubeflow, TensorFlow Extended (TFX), and Vertex AI. We will start with the motivation behind the project and then we will move over to the approaches we realized as a part of this project. We will conclude the post by going over the cost breakdown for each of the approaches. While this post will not include exhaustive code snippets and reviews you can always find the entire code in this GitHub repository. To fully follow through this post, we assume that you are already familiar with the basics of TFX, Vertex AI, and Kubeflow. It’d be also helpful if you have some familiarity with TensorFlow and Keras since we will be using them as our primary deep learning framework. MotivationScenario #1 (Online / offline prediction)Let’s say you want to allow your users to run an application both in online and offline mode. Your mobile application would use a TensorFlow Lite (TFLite) model depending on the network bandwidth/battery etc., and if sufficient network coverage/internet bandwidth is available your application would instead use the online cloud one. This way your application stays resilient and can ensure high availability.Scenario #2 (Layered predictions) Sometimes we also do layered predictions where we first divide a problem into smaller tasks:1) predict if it’s a yes/no, 2) depending on the output of 1) we run the final model.In these cases, 1) takes place on-device and 2) takes place on the cloud to ensure a smooth user experience. Furthermore, it’s a good practice to use a mobile-friendly network architecture (such as MobileNetV3) when considering mobile deployments. A detailed analysis of this situation is discussed in the book ML Design Patterns.The discussions above lead us to the following question:Can we train two different models within the same deployment pipeline and manage them seamlessly?This project is motivated by this question. The rest of this post will walk you over the different components that were pulled in to make such a pipeline operate in a self-contained and seamless manner. Dataset and modelsWe use the Flowers dataset in this project which consists of 3670 examples of flowers categorized into five classes – daisy, dandelion, roses, sunflowers, and tulips. So, our task is to build flower classification models which are essentially multi-class classifiers in this case. Recall that we will be using two different models. One, that will be deployed on the cloud and will be consumed via REST API calls. The other model will sit inside mobile phones and will be consumed by mobile applications. For the first model, we will use a DenseNet121 and for the mobile-friendly model, we will use a MobileNetV3. We will make use of transfer learning to speed up the model training process. You can study the entire training pipeline from this notebook.On the other hand, we also make use of AutoML-based training pipelines for the same workflow where the tooling automatically discovers the best models for the given task within a preconfigured compute budget. Note that the dataset remains the same in this case. You can find the AutoML-based training pipeline in this notebook.ApproachesDifferent organizations have people with varied technical backgrounds. We wanted to provide the easiest solution first and then move on to something that is more customizable.AutoMLFigure 1: Schematic representation of the overall workflow with AutoML components (high-quality).To this end, we leverage standard components from the Google Cloud Pipeline Components library to build, train, and deploy models with different production use-cases. With AutoML, the developers can delegate a large part of their workflows to the SDKs and the codebase also stays comparatively smaller. Figure 1 depicts a sample system architecture for this scenario.For reference, there are a number of tasks supported ranging from image classification to object tracking in Vertex AI. TFX But the story does not end here. What if we wanted to have better control over the models to be built, trained, and deployed? Enter TFX! TFX provides the flexibility of writing custom components and including them inside a pipeline. This way Machine Learning Engineers can focus on building and training their favorite models and delegate a part of the heavy lifting to TFX and Vertex AI. On Vertex AI (acting as an orchestrator) this pipeline will look like so:Figure 2: Computation graph of the TFX components required for our workflow (high-quality).You are probably wondering why there is Firebase in both of the approaches we just discussed. For the model that would be used by mobile applications, that needs to be a TFLite model because of tremendous interoperability with mobile platforms. Firebase provides excellent tooling and integration for TFLite models such as canary rollouts, A/B testing, etc. You can learn more about how Firebase can enhance your TFLite deployments from this blog post.So far we have developed a brief idea about the approaches followed in this project. In the next section, we will dive a bit more into the code and various nuts and bolts that had to be adjusted to make things work. You can find all the code shown in the coming section here.  Implementation detailsSince this project uses two distinguished setups i.e. AutoML based minimal code and TFX-based custom code we will divide this section into two. First, we will introduce the AutoML side of things and then we will head over to TFX. Both these setups will provide similar outputs and will implement identical functionalities. Vertex AI Pipelines with Kubeflow’s AutoML ComponentsThe Google Cloud Pipeline Components library comes with a variety of predefined components supporting services built-in Vertex AI. For instance, you can directly import dataset from Vertex AI’s managed dataset feature into the pipeline, or you can create a model training job to be delegated to Vertex AI’s training feature. You can follow along with the rest of this section with the entire notebook. This project uses the following components:ImageDatasetCreateOpAutoMLImageTrainingJobRunOpModelDeployOpModelExportOpWe use ImageDatasetCreateOp to create a dataset to be injected to the next component, AutoMLImageTrainingJobRunOp. It supports all kinds of datasets from Vertex AI. The import_schema_uri argument determines the type of the target dataset. For instance, it is set to multi_label_classification for this project.The AutoMLImageTrainingJobRunOp delegates model training jobs to Vertex AI training with specified configurations. Since the AutoML model can grow very large, we can set some constraints with budget_milli_node_hours and model_type arguments. The budget_milli_node_hours how many hours are allowed for training. The model_type tells the training job what the target environment is, and which format a trained model should have. We created two instances of AutoMLImageTrainingJobRunOp, and model_type is set to “CLOUD” and “MOBILE_TF_VERSATILE_1″ respectively. As you can see, the string parameter itself describes what it is. There are more options, so please take a look at the official API document. The ModelDeployOp does three jobs in one place. It uploads a trained model to Vertex AI model, creates an endpoint, and deploys the trained model to the endpoint. With ModelDeployOp, you can deploy your model in the cloud easily and fast. On the other hand, the ModelExportOp only exports a trained model to a designated location like GCS bucket. Because the mobile model is not going to be deployed in the cloud, we explicitly need to get the saved model so that we can directly embed it on a device or publish it to Firebase ML. In order to make a trained model as an on-device model, export_format_id should be set appropriately in ModelExportOp. The possible values are “tflite”, “edgetpu-tflite”, “tf-saved-model”, “tf-js”, “core-ml”, and “custom-trained”, and it is set to “tflite” for this project. With these four components, you can create a dataset, train cloud and mobile models with AutoML, deploy the trained model to cloud, and export the trained model to a file whose format is .tflite. The last step would be to embed the exported model into the mobile application project. However, it is not flexible since you have to compile the application and upload it to the marketplace every time. FirebaseInstead, we can publish a trained model to Firebase ML. We are not going to explain what Firebase ML is in-depth, but it basically lets the application download and update the machine learning model on the fly. This ensures that the user experience becomes much smoother. In order to integrate publishing capability into the pipeline, we have created custom components, one for KFP native and the other one for TFX. Let’s explore what it looks like in KFP native now, then the one for TFX will be discussed in the next section. Please make sure you read the general instructions under the “Before you begin” section on the official Firebase document as a prerequisite.In this project, we have written python function-based custom components for the KFP native environment. The first step is to mark a function with @component decorator by specifying which packages to be installed. When compiling the pipeline, KFP will wrap this function as a Docker image which means everything inside the function is completely isolated, so we have to say what dependencies this function needs via packages_to_install.The beginning part is omitted, but what it does is to download the firebase credential file and the saved model from firebase_credential_uri and model_bucket respectively. You can assume that the downloaded files are named as credential.json and model.tflite. Also, we have found that the files can not be directly referenced if they are stored in GCS, so this is why we have downloaded them locally. firebase_admin.initialize_app method initializes the authorization to the Firebase with the given credential and the GCS bucket which is used to store the model file temporarily. The GCS bucket is required by Firebase, and you can simply create one within the storage menu in the Firebase dashboard.ml.list_models method returns a list of models deployed in the Firebase ML, and you can filter the items with display_name or tags. The purpose of this line is to check if the model with the same name has already been deployed because we have to update the model instead of creating one if the one exists.The update and create routine has one thing in common. That is the loading process for the local model file to be uploaded into the temporary GCS bucket by calling ml.TFLiteGCSModelSource.from_tflite_model_file method. After the loading process, you can choose either of ml.create_model or ml.update_model method. Then you are good to publish the model with the ml.publish_model method.Putting things togetherWe have explored five components including the custom one, push_to_firebase. It is time to jump into the pipeline to see how these components are connected together. First of all, we need two different sets of configurations for each deployment. We can hard-code them, but it would be much better to have a list of dictionaries like below.You should be able to recognize each individual component and what it does. What you need to focus on this time is how the components are connected, how to make parallel jobs for each deployment, and how to make a conditional branch to handle each deployment-specific job. As you can see, each component except for push_to_firebase has an argument to get input from the output of the previous component. For instance, the AutoMLImageTrainingJobRunOp launches a model training process based on the dataset parameter, and its value is injected from the output of ImageDatasetCreateOp. You might wonder why there is no dependency between ModelExportOp and push_to_firebase components. That is because the GCS location for the exported model is defined manually with artifact_destination parameter in ModelExportOp. Because of this, the same GCS location can be passed down to the push_to_firebase component manually.With the pipeline function defined with @kfp.dsl.pipeline decorator, we can compile the pipeline via the kfp.v2.compiler.compile method. The compiler converts all the details about how the pipeline is constructed into a JSON format file. You can safely store the JSON file in a GCS bucket if you want to control different versions. Why not version control the actual pipelining code? That is because the pipeline can be run by just referring to the JSON file with create_run_from_job_spec method under kfp.v2.google.client.AIPlatformClient.Vertex AI Pipelines with TFX’s pre-built and custom componentsTFX provides a number of useful pre-built components that are crucial to orchestrate a machine learning project end-to-end. Here you can find a list of the standard components offered by TFX. This project leverages the following stock TFX components:ImportExampleGenTrainerPusherWe use ImportExampleGen to read TFRecords from a Google Cloud Storage (GCS) bucket. The Trainer component trains models and Pusher exports the trained model to a pre-specified location (which is a GCS bucket in this case). For the purpose of this project, the data preprocessing steps are performed within the training component but TFX provides first-class support for data preprocessing.Note: Since we will be using Vertex AI to orchestrate the entire pipeline, the Trainer component here is tfx.extensions.google_cloud_ai_platform.Trainer which lets us take advantage of Vertex AI’s serverless infrastructure to train models. Recall from Figures 1 and 2 that once the models have been trained they will need to go down two different paths – 1) Endpoint (more on this in a moment), 2) Firebase. So, after training and pushing the models we would need to:1. Deploy one of the models to Vertex AI as an Endpoint so that it can be consumed via REST API calls.To deploy your model using Vertex AI one first needs to import their model if it’s not already there. Once the right model is imported (or identified) it needs to be deployed to an Endpoint. Endpoints provide a flexible way to version control different models that one may deploy during the entire production life-cycle. 2. Push the other model to Firebase so that mobile developers can use it to build their applications. As per these requirements, we need to develop three custom components at the very least:One that would take input as a pre-trained model and import that in Vertex AI (VertexUploader). Another component will be responsible for deploying it to an Endpoint (if it’s not present it will be created automatically) (VertexDeployer). The final component will push the mobile-friendly model to Firebase (FirebasePublisher). Let’s now go through the main components of each of these one by one. Model uploadWe will be using Vertex AI’s Python SDK to import a model of choice in Vertex AI. The code to accomplish this is fairly straightforward:Learn more about the different arguments of vertex_ai.Model.upload() from here. Now, in order to turn this into a custom TFX component (so that it runs as a part of the pipeline), we need to put this code inside a Python function and decorate that with the component decorator:And that is it! The full snippet is available here for reference. One important detail to note here is that serving_image_uri should be one of the pre-built containers as listed here. Model deployNow that our model is imported in  Vertex AI we can proceed with its deployment. First, we will create an Endpoint and then we will deploy the imported model to that Endpoint. With some utilities discarded the code for doing this looks like so (full snippet can be found here):Explore the different arguments used inside endpoint.deploy() from here. You might actually enjoy them because they provide many production-friendly features like autoscaling, hardware configurations, traffic splitting, etc. right off the bat. Thanks to this repository that was used as references for implementing these two components. FirebaseThis part shows how to create a custom python function based on the TFX component. However, the underlying logic is pretty much the same to the one introduced in the AutoML section. We omit the internal details on this post, but you can find the complete source code here.We just want to point out the usage of the type checker,  tfx.dsl.components.InputArtifact[tfx.types.standard_artifacts.PushedModel]. The tfx.dsl.components.InputArtifact means the parameter is a type of TFX artifact, and it is used as an input to the component. Likewise, there is tfx.dsl.components.OutputArtifact, and you can specify what kind of output the component should produce.Then, we have to tell where the input artifact comes from within the square brackets. In this case, we want to publish the pushed model to the Firebase ML, so the tfx.types.standard_artifacts.PushedModel is used. You can hard code the URI, but it is not flexible, and it is recommended to refer to the information from the PushedModel component.Custom Docker imageTFX provides pre-built Docker images where the pipelines can be run. But to execute a pipeline that contains custom components leveraging various external libraries we need to build a custom Docker image. Surprisingly, the changes are minor to accommodate this. Below is the Dockerfile configuration to build a custom Docker image that would support the above-discussed custom TFX components:Here, custom_components contains the .py files of our custom components. Now, we just need to build the image and push it to Google Container Registry (one can use Docker Hub as well).  For building and pushing the image, we can either use docker build and docker push commands or we can use Cloud Build which is a serverless CI/CD platform from Google Cloud.  To trigger the build using Cloud Build we can just use the following command:Do note that TFX_IMAGE_URI which, as the name suggests, is the URI of our custom Docker image that will be used to execute the final pipeline. The builds are available in the form of a nice dashboard along with all the build logs. Figure 3: Docker image build output from Cloud Build (high-quality).Putting things togetherNow that we have all the important pieces together we need to make them a part of a TFX pipeline so that it can be executed end-to-end. The entire code can be found in this notebook. Before putting things together into the pipeline, it is better to define some constant variables separately for readability. The name of model_display_name,   pushed_model_location, and pushed_location_mobilenet variable itself explains pretty much what they are. On the other hand, the TRAINING_JOB_SPEC is somewhat verbose, so let’s go through it.TRAINING_JOB_SPEC basically sets up the hardware and the software infrastructures for model training. The worker_pool_specs lets you have different types of clusters if you want to leverage distributed training features on Vertex AI. For instance, the first entry is reserved for the primary cluster, and the fourth entry is reserved for evaluators. In this project, we have set only the primary cluster. For each worker_pool_specs, the machine_spec and the container_spec define hardware and software infrastructures respectively. As you can see, we have used only one NVIDIA_TESLA_K80 GPU within n1-standard-4 instance, and we have set the base Docker image to an official TFX image. You can learn more about these specifications here.We will use these configurations in the pipeline below. Note that the model training infrastructure is completely different from the GKE cluster where the Vertex AI internally runs each component’s job. That is why we need to set base Docker images in multiple places rather than via a unified API. The code below shows how everything is organized in the entire pipeline. Please follow the code by focusing on how components are connected and what special parameters are necessary to leverage Vertex AI.As you can see, each standard component has at least one special parameter to get input from the output of different components. For instance, the Trainer has the examples parameter, and its value comes from the ImportExampleGen. Likewise, Pusher has the model parameter, and its value comes from the Trainer. On the other hand, if a component doesn’t define a special parameter, you can set the dependencies explicitly via add_upstream_node method. You can find the example usages of add_upstream_node with VertexUploader and VertexDeployer.After defining and connecting TFX components, the next step is to put those components in a list. A pipeline function should return tfx.dsl.Pipeline type of object, and it can be instantiated with that list. With tfx.dsl.Pipeline, we can finally create a pipeline specification with KubeflowV2DagRunnerunder the tfx.orchestration.experimental module. When you call the run method of the KubeflowV2DagRunnerwith the tfx.dsl.Pipeline object, it will create a pipeline specification file in JSON format. The JSON file can be passed to the kfp.v2.google.AIPlatformClient’s create_run_from_job_spec method, then it will create a pipeline run on Vertex AI Pipeline. All of these in code looks like so:Once the above steps are executed you should be able to see a pipeline on the Vertex AI Pipelines dashboard. One very important detail to note here is that the pipeline needs to be compiled such that it runs on the custom TFX Docker image we built in one of the earlier steps. CostVertex AI Training is a separate service from Pipeline. We need to pay for the Vertex AI Pipeline individually, and it costs about $0.03 per pipeline run. The type of compute instance for each component was e2-standard-4, and it costs about $0.134 per hour. Since the whole pipeline took less than an hour to be finished, we can estimate that the total cost was about $0.164 for a Vertex AI Pipeline run.The cost for the AutoML training depends on the type of task and the target environment. For instance, the AutoML training job for the cloud model costs about $3.15 per hour whereas the AutoML training job for the on-device mobile model costs about $4.95 per hour. The training jobs were done in less than an hour for this project, so it cost about $10 for the two models fully trained. On the other hand, the cost of custom model training depends on the type of machine and the number of hours. Also, you have to consider that you pay for the server and the accelerator separately. For this project, we chose n1-standard-4 machine type whose price is $0.19 per hour and NVIDIA_TESLA_K80 accelerator type whose price is $0.45 per hour. The training for each model was done in less than an hour, so it cost about $1.28 in total.The cost of the model prediction is defined separately for AutoML and custom-trained models. The online and batch predictions for AutoML model cost about $1.25 and $2.02 per hour respectively. On the other hand, the prediction cost of a custom-trained model is roughly determined by the machine type. In this project, we specified it as n1-standard-4 whose price is $0.1901 per hour without an accelerator in the us-central-1 region. If we sum up the cost spent on this project, it is about $12.13 for the two pipeline runs to be completed. Please refer to the official document for further information.Firebase ML doesn’t cost anything. You can use it for free for Custom Model Deployment. Please find out more information about the price for Firebase service here.ConclusionIn this post, we covered why having two different types of models may be necessary to serve users. We realized a simple but scalable automated pipeline for the same using two different approaches using Vertex AI on GCP. One, where we used Kubeflow’s AutoML SDK delegating much of the heavy lifting to the frameworks. In the other approach, we leveraged TFX’s custom components to customize various parts of the pipeline as per our requirements. Hopefully, this post provided you with a few important recipes that are important to have in your Machine Learning Engineering toolbox. Feel free to try out our code here and let us know what you think.AcknowledgementsWe are grateful to the ML-GDE program that provided GCP credits for supporting our experiments. We sincerely thank Karl Weinmeister and Robert Crowe of Google for their help with the review.Related ArticleNew to ML: Learning path on Vertex AIIf you’re new to ML, or new to Vertex AI, this post will walk through a few example ML scenarios to help you understand when to use which…Read Article
Quelle: Google Cloud Platform