 Hello, welcome back. The next thing I want to talk to you about is automation design patterns. So what I mean by this is when to use webhooks and when to use launch, because those are two types of automation that you have learned about, and you might be wondering when should you use one over the other. So I'm going to talk a little bit about that. So in this slide, I'm going to do kind of a comparison of webhooks and launch, just to give you some background and some grounding. So just to review, webhooks and launch can both be triggered by an event, and that event can be some kind of action in the model registry, such as adding a tag or adding an artifact, so on and so forth. Now, if you recall, in webhooks, when you have an event, what happens is it sends a payload. And a payload is just kind of a package of information. You can think of it as a JSON that has information. And the information are things related to weights and biases, metadata, and the artifact in the registry. And your web server receives this webhook. And we can call this web server a consumer. Now, it's not always strictly a web server receives this web hook and we can call this web server a consumer now it's not always strictly a web server that's why I called it consumer because web hooks are very common when we talk about developer tools so one there's many different tools that can receive a web hook doesn't have to strictly be a web server and one example of that is GitHub Actions. You can have weights and biases send events to GitHub Actions. Now, with webhooks, you are responsible for handling the queue. And what is a queue? Queue is just kind of a holding area where you have all of your jobs that you want to execute. And so with webhooks, weights and biases fires the webhooks, you receive the payload, and then if you're receiving many different payloads, it's up to you to implement how to process those payloads, you know, in what order, and keeping track of those payloads. And really, like, the idea behind webhooks is not really to have your own web server and manage all that yourself most of the time. The real idea is to integrate with third parties, third party software like GitHub Actions. And the other thing you can do with webhooks is you can build tools on top of weights and biases. So webhooks is kind of a general purpose, flexible, kind of paradigm that allows you to kind of do anything you want. It's very flexible. You have to catch this payload, and based on the payload, you decide what to do. You can download the artifacts. You can do whatever you need to do. Now, launch is a bit different. So the idea is that in Weights and Biases, in response to an event, a lot of times you want to run code. And specifically, you might want to run training code or evaluation code. And you might want to do a training run. And instead of having to orchestrate this yourself, for example, having a web server, catching this kind of payload, and then managing your own queue, and then finally running some code, let's say for a training evaluation run, launch packages that up very nicely. So you don't have to, you have to do less. So in the case where you want to do a training run or evaluation run, the way that launch works is when an event is triggered, that event is put in a queue. And Weights and Biases has this queue. And essentially what you do is on the compute of your choice, whether that's a VM, a local machine, Kubernetes, so on and so forth, wherever your compute is, you run agents and agents consume from the queue. So it's a kind of a different consumer. It's constantly pulling the queue and it's grabbing things from the queue. So you don't have to manage the queue. Things can get pushed into the queue and agents can kind of pull from the queue. And that's very convenient. And the idea behind launch is is again it's meant for training and eval runs and you know agents are designed to run docker or python code on the computer of your choice. And you know if you need to do a training run or evaluation run if that's what you have in mind then you should go with launch if you are trying to create some tools on tops of weights and biases that need lots of you know you need lots of flexibility and you know you might want to do other things or you're trying to integrate with a third-party service that offers webhooks then use webhooks. I just want to summarize these points in this slide. Again, webhooks are about integrating with third-party applications. That's what they're intended for. You have to manage your own queue and you can also build custom tools and applications on top of weights and biases with webhooks. It's the most flexible general purpose sort of kind of communication pattern. It is a very general communication pattern when you have different applications communicating with each other. And there's very little or no assumptions made about your infrastructure. You build things the way you need to build it, and you have to build it yourself. Launch does a little bit more for you. So with launch, weights and biases manages the queue for you. There is a paved path for running Python and Docker code in response to events on the compute of your choice. And again, this compute of your choice is very general. You can run it anywhere, including Kubernetes and things like SageMaker for AWS and Vertex for GCP. And it's really meant for training or evaluation runs. So I hope this clarifies your mental model of when to use webhooks and when to use launch.
Automation design patterns
In this lesson Hamel compares Webhook vs. Launch automation and provide guidance on when to use them.