How much time do you spend solving negative engineering problems?
And can a framework solve them for you?
Think of negative engineering as things you do to avoid bad outcomes in software.
At the lowest level, this can be writing good error handling with try-accept.
But it's broader than that.
Logging, observability, like with Sentry Tools, retries, failovers,
as in what you might get from Kubernetes, and so on.
We have a great chat with Chris White about Prefect,
a tool for data engineers and data scientists, meaning to solve these problems automatically.
It's also a conversation I think is applicable to the broader software development community as well.
This is Talk Python to Me, episode 365, recorded May 9th, 2022.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy,
and keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube
to get notified about upcoming shows and be part of that episode.
This episode is sponsored by Microsoft for Startups Founders Hub.
Check them out at talkpython.fm/founders hub to get early support for your startup.
And it's brought to you by us over at Talk Python Training.
Did you know we have one of the largest course libraries for Python courses?
They're all available without a subscription.
So check it out over at talkpython.fm.
Just click on courses.
Transcripts for this and all of our episodes are brought to you by Assembly AI.
Do you need a great automatic speech-to-text API?
Get human-level accuracy in just a few lines of code.
Visit talkpython.fm/assemblyai.
Chris, welcome to Talk Python to me.
Yeah, thanks for having me.
Happy to be here.
I'm happy to have you here.
It's going to be a lot of fun.
We're going to talk a lot of data engineering things.
Try to loop that back to the more traditional software development side.
You have a really cool open source project and startup in Prefect.
And we're both going to talk about the product as well as, you know, making an open source successful business model, which is really cool.
Yeah.
I'm very into that and very, you know, that's very important to me.
And I love to highlight cases of people doing that.
Well, it looks like you all are.
Yeah, excellent.
Yeah.
It's a, as we'll see as we get into it, it's a core part of how we view the world.
Yeah, that's awesome.
Before we get to all that, though, let's start with your story.
How'd you get into programming in Python?
So I think like a lot of, so I was born in the 80s.
I feel like a lot of people in my generation, right?
We got into HTML and building websites on AngelFire and GeoCities.
So, you know, from the early days, I was into playing around with computers.
I would say didn't really get into Python until probably high school is when I first started dabbling.
And it was really just, I was working at a bank.
I was like trying to automate some small things.
And to be clear, I did not get very far.
It was a mildly successful undertaking.
And then college, kind of similar story.
Like it was one of those things that I just would, I had a couple of books.
I would play around with it.
It was always just a fun activity for me, but I never had any serious focus on it.
I think in college, when it started to get into really econometrics, it's when I started to play more seriously and start to try to understand some of the performance implications of what I was doing and things like that.
And then taking kind of the next level in grad school, a friend of mine and myself thought that we were smart enough to build some machine learning models for trading.
And we did all of that in combination of Python and Otter.
Surprise.
Okay.
That's amazing.
Yeah.
Lost some money.
But it was a great lesson in understanding data and exactly what you're doing.
And genuinely, so I was studying pure math in grad school.
And that experiment and kind of the actual like visceral outcome of it is what really got me into studying machine learning more deeply.
Because I was like, wait a second, there's something interesting here.
And so I started to dig in more.
That must have been a really cool experience.
Even if you did lose money.
It's important to put some skin in the game.
Exactly.
Right.
Like it's a hobby until you start to take it seriously and try to get real outcomes.
Because there's always these layers of these levels, right?
Like I'm going to learn this thing and poke around and kind of get it to work.
Or I'm going to learn this thing so that it actually works.
Or I'm going to learn this thing so I can explain it when there's three ways.
They all kind of do the same thing.
I can explain when to choose which one, right?
And the more seriously you take it and the more is on the line, the more you kind of, you get that real understanding of it.
I mean, this is a little off of Python, but I think that resonates with me so much on every dimension when it comes to learning something.
You have to, it's not a passive activity.
You have to engage with it.
Right.
And it's in my opinion, the only way to learn anything.
Math, programming, business, whatever.
Totally agree.
Speaking of math, you have a math background, right?
I do.
Proudly so, yes.
Yeah, awesome.
Yeah.
So do I.
I just last episode spoke with the SymPy, S-Y-M-Py guys, about doing symbolic math with Python.
And that was pretty fascinating stuff.
Have you played with any of the symbolic stuff?
I have played with it, yeah.
I had no serious project.
Like genuinely just playing around with it to see kind of what it's capable of.
It is really cool.
I would definitely go look up that episode, yeah.
Awesome.
What kind of math did you study?
So I started my PhD program focusing on arithmetic geometry, which for people out there, it's one of the more abstract forms of math.
I still really like that stuff a lot, honestly.
But what I found was that-
Is it like manifolds and stuff like that?
Not quite.
It's a little bit-
So they use a lot of the same-
A lot of their arguments are kind of by analogy with things like manifolds.
But you're studying geometric structures that are way more discrete than a manifold.
And so like the spectrum of prime numbers on the integers is like a geometric object for the purposes of arithmetic geometry.
Wow.
Okay.
Hard to visualize, but it just turns out a lot of the formal definitions of geometry have these really deep analogs and arithmetic.
And you can actually learn a lot.
And the most famous example of this that I think a lot of people will probably be familiar with is Fermat's last theorem.
Yeah, that's right.
So that was all arithmetic geometry.
It was all using some of those techniques.
Yeah, that's right.
So they're really heavy duty to solve very simple two-state problems.
There was a really good book about Fermat's last theorem by this guy named, something like Amol or something like that.
Maybe you'll find it for the show notes.
It's just absolutely fascinating book.
Oh, that's awesome.
It just talks about the struggle that guy-
Yeah, yeah.
It really talks about the struggle that guy who solved it went through.
Cool.
Well, how about now?
You're at Prefect, right?
What do you do day to day?
I didn't finish where I went with grad school, which is relevant to how I got to Prefect, which I ended up going into optimization theory, still on the pure side.
So still very much proof-based.
But that was right when machine learning was becoming a thing, right after I had done this experiment with my friend and started getting into it.
And so that's kind of how I started to head more towards industry.
And for me, I consider myself a problem solver.
And so I was always very good at solving problems.
But I'll admit, I wasn't always the best at maybe justifying a grant proposal or something like that.
And so that's kind of when I started to think more about industry and started doing some consulting and test the waters.
And so anyways, long story short, got into data, got into machine learning, got into tooling for machine learning, got into backend engineering for hosting the tooling, et cetera, et cetera.
And then met with Jeremiah, who's the CEO of Prefect.
Yeah.
Just sucks you in, right?
Exactly.
It's a black hole.
Yeah.
Yeah, cool.
So you started out working at banks doing sort of homegrown data engineering, right?
Is that maybe a good way to describe it?
Homegrown a lot of things, yes.
So homegrown data engineering, one of them.
Homegrown model building was another big, big thing.
Homegrown data governance at one point.
Homegrown data platform.
And actually, the data platform was particularly interesting because looking back, it kind of felt like a microcosm of a lot of the,
the tool explosion we've seen lately.
Where the platform we were building was for data scientists to deploy their model to and connect it up to data sources that, you know, we would keep up to date.
And so that's where the data engineering comes in.
And then business analysts are the actual downstream users.
And they would interact with these models through an API that we would build for them on top of the models.
It was still in Python.
So they would actually have to write Python, which was really interesting.
So you got to teach them classes on it.
That is interesting.
Yeah.
I've seen, you know, non-developer types do that before.
I've seen it in like real-time stock trading, you know, like brokerages and hedge funds.
Right.
And yeah, it's, you're going to learn Python because you need to talk to the tool.
I've also seen people learn SQL who have no business knowing SQL otherwise, but for sort of a similar reason.
Yeah.
And SQL is a little bit more approachable, I think.
Yeah.
But Python, Python is just a little, it's easier to kind of shoot yourself in the foot with Python, I think, if you don't really know it well.
It's just more open-ended, right?
It's just, it's way more open-ended.
Cool.
All right.
So you talk a lot about negative engineering concepts and how you've structured Prefect to help alleviate, eliminate, solve, prevent some of those problems.
So maybe we should start the conversation and sort of twofold, like maybe give us a quick overview of what you might call data engineering.
And then what are these negative engineering things that live in that space?
So, yeah, and I think these two concepts are related, but also, but I think negative engineering is definitely more general.
So for, well, let me start with negative engineering and then we'll kind of, kind of drill in.
Yeah.
So negative engineering, we've got a blog post that we published, I think three years ago at this point on negative engineering.
Encourage anyone who's interested, go read it.
I think since we have released that blog post, we have refined kind of our own understanding and thinking about this.
And one thing that I kind of noticed is negative engineering got this sentiment, like it's just anything I don't really like to do.
And that's not accurate.
There's a lot of things.
Those are negative engineering.
I'll tell you what.
Yeah, exactly.
Got nothing done in those meetings.
Yeah.
Exactly.
And like, I don't think so.
And so, yeah, to be really precise with the way we think about this, positive engineering is code or interacting with software systems that you do explicitly to achieve an outcome.
So I run a SQL query to populate my dashboard or something like that.
It's a very concrete connection to some sort of outcome.
And then negative engineering are code you write systems you interact with that ensure those outcomes.
I am sort of like insurance.
And so defensive code is a great example of negative engineering.
It's something that you're writing.
When you're writing those try accepts and everything, you're really hedging against anticipated failure modes that you're trying to account for right now.
If the data was always well formed, it would never crash.
If the servers was always up, it would never crash.
Exactly, exactly.
But then you get the reports, the sentry messages or whatever.
Exactly.
And so observability, I think.
Complete negative engineering.
Observability is not something you do for its own sake.
You do it in anticipation of an unknown future failure mode.
It allows you to recover the outcome.
That you want to avoid.
Yeah, failure is only like the first class citizen here, right?
Something failed and you want to figure out what happens so that you can fix it.
To really tie it to insurance even more directly, all of the things we're talking about are situations where a small error has a disproportionately large negative impact on an outcome.
So scheduling is an example here.
If you have Cron running on a server, running a Python script, and something you do, maybe you load just far too much data in your script and the machine crashes out of memory.
You don't get an alert.
You wake up the next morning and 30 jobs have not run.
You don't know why.
You have to figure out why.
By the time you figure it out, you're five hours deep.
Maybe not that long, but two hours deep.
And using a service or a system, and we'll talk about the details, like Prefect or some other type of observability negative engineering tool, you would potentially get a text alert.
Or at a minimum, you would wake up and immediately see, oh, that happened at 1 a.m.
I know what happened.
Let me just fix it really quickly.
And you're back up to speed.
Yeah, interesting.
Yeah.
Frank out in the audience says, defensive programming, that means good handling on exceptions and so forth.
And I think that's interesting, Frank.
I think I do agree.
But it sounds to me, Chris, like you're even talking like way broader.
Like, do you, if you're writing an API, do you have to even think about hosting that or making sure that it's scaled out correct?
Or like, you know, observability as tracking error reporting in the broad sense of sure, you should be doing the small defensive programming, but also to deal with these negative engineering problems.
But like, there's whole businesses around dealing with segments of it.
Exactly, exactly.
And I think putting a word to it, as simple as it may seem, really helps, especially for building a company and a product like refine and target.
Like, what are the features that are important to us and which ones are not important, at least at this time?
And especially in orchestration and data engineering.
I mean, it's very tempting to build cool stuff because there's lots of cool stuff you can build.
But are you guaranteeing an outcome?
Are you ensuring against some outcome?
Like, are you sure you know exactly what you're providing here when you build that cool thing?
Right.
So you guys use, you try to identify some of these areas of negative engineering that data engineers run into.
And you're like, how do we build a framework such that they don't have to worry about or think about that?
Exactly, exactly.
And so for data engineering, I think of this as it's any software engineering that you do that either moves data, cleans data, or prepares data.
Either for another person to ingest or maybe another system to ingest, but it's all the activities surrounding that.
And I think for, I know, maybe not everyone listening is in the data space specifically.
So just as the easiest example, we have a production database running behind some web server, some API, and you want to do analytics on it.
Well, maybe you're using Postgres, not the best analytics database.
And also you don't want to actually write a query that takes down the database.
So what do you do?
You take the data out, you put it into BigQuery or Snowflake or somewhere else.
You run your analytics over there.
The schema is there.
Right.
You probably totally change the schemas because you want to, in a relational database, somewhat in the document database, maybe a little less, but definitely in a relational database, your job is third normal form.
Like, how do I not have any data that repeats?
I'll have a 10-way join rather than have something repeat.
But when you want to do reporting, those joins are killers.
You just want, like, I want to do a straight query where, you know, this column is that and just, like, wreck the normalization for performance reasons, right?
Right.
You just want to have fun.
Yeah.
Exactly.
So you can ask the questions in very interesting ways, like many ways, in simple queries rather than being a SQL master.
Exactly.
And keeping that system running, keeping the data fresh, keeping the schemas in sync, that's a lot of work, actually.
And that's one of the classic examples of data engineering.
There's a lot of other stuff, too, but that's the classic.
This portion of Talk Python to Me is brought to you by Microsoft for Startups Founders Hub.
Starting a business is hard.
By some estimates, over 90% of startups will go out of business in just their first year.
With that in mind, Microsoft for Startups set out to understand what startups need to be successful and to create a digital platform to help them overcome those challenges.
Microsoft for Startups Founders Hub was born.
Founders Hub provides all founders at any stage with free resources to solve their startup challenges.
The platform provides technology benefits, access to expert guidance and skilled resources, mentorship and networking connections, and much more.
Unlike others in the industry, Microsoft for Startups Founders Hub doesn't require startups to be investor-backed or third-party validated to participate.
Founders Hub is truly open to all.
So what do you get if you join them?
You speed up your development with free access to GitHub and Microsoft Cloud computing resources and the ability to unlock more credits over time.
To help your startup innovate, Founders Hub is partnering with innovative companies like OpenAI, a global leader in AI research and development, to provide exclusive benefits and discounts.
Through Microsoft for Startups Founders Hub, becoming a founder is no longer about who you know.
You'll have access to their mentorship network, giving you a pool of hundreds of mentors across a range of disciplines and areas like idea validation, fundraising, management and coaching, sales and marketing, as well as specific technical stress points.
You'll be able to book a one-on-one meeting with the mentors, many of whom are former founders themselves.
Make your idea a reality today with the critical support you'll get from Founders Hub.
To join the program, just visit talkpython.fm/foundershub, all one word, no links in your show notes.
Thank you to Microsoft for supporting the show.
One of the things I see stand out, I don't want to get the API right away, but I just see like coming out of the API that you all build is there's like retries like right front and center.
Like here's a task and I wanted to retry with this plan, right?
You have this number of times or there's probably like a back off story and stuff.
Exactly.
And that's another great example of small error, the tiniest network blip.
Kubernetes, I don't know, I've seen kubedms sometimes just doesn't do what it's supposed to do.
Somebody was flipping over the load balancer and you hit it at just the wrong time and there it goes, right?
Exactly.
And now next thing you know, I mean, a lot of different things can happen depending on the script you wrote.
Maybe you did a lot of good defensive programming yourself and the try accept was a little bit too much.
And so your next task actually runs despite the first one failing.
And maybe it passes the exception downstream.
And now you have this cascade of errors that you have no idea what they mean.
And another thing in negative engineering is dependency management, making sure that if this fails, things that depend on it do not run unless they are configured to run only on failure.
Yeah.
Worst case scenario, they say, yes, this is a good investment.
You should buy it.
Or yes, this is a good decision.
And they like.
Exactly.
It's really cheap.
Well, it's zero because the task failed to find the price.
So, of course, you should buy it.
Exactly.
And you want to know that it happened and make sure that the effect, the blast radius is minimized.
And that's really what it's all about.
And like retry is a perfect example of just one of those small things that can cascade weird, unexpected ways.
Yeah.
What are some of the other areas of crufter of these problems you see in data engineering?
Logging is a big one.
Just having a place where you can see some centralized set of important logs.
Any and all.
The more you use like Kubernetes are more like you kind of.
Oh, yeah.
Distributed systems.
Microservice it out.
The harder it is to know what's going on in the logging story.
Well, right.
And the definition we work with in the modern data stack are data tools that deliver their feature over an API.
And so if you think about that, you're dealing with inherently this giant microservice system that you want to like coordinate and see in some centralized place.
In some meaningful way.
And collaboration, versioning, those are all other things.
Caching.
So just configurable like storage locations for things.
And then maybe the biggest one that is simple, but I see people building this internally all the time, which is just exposing an API, a parametrized API, which is triggering some type of job.
Next thing you know, it needs to be available, you know, throughout your whole network.
It needs to be up.
It needs to be monitored and tracked and audited and all these things.
Maybe versioned.
Exactly.
Oh my gosh.
Yeah.
It just gets, all of a sudden you're like, okay, I'm building an entire system.
My job is not this.
Yeah.
It's one of those things that seems so simple.
Like I would love it if you would just really help us out, you know, Michael here, if you could just give me a quick little, little API that we could just call that API.
I mean, look, I'll just, here's the JSON.
It's like that big.
And if I could just call it, boy, things would just unlock.
And then, then it's like a holiday and it's not working.
And now I'm dealing, like, how did I get this job?
Right.
Yeah.
And the second someone says just anything, you're like, oh, I'm on edge.
What do you mean?
Are you sure?
Exactly.
I don't want it.
Give it to someone else.
Awesome.
All right.
Well, you know, maybe that's a good time to talk a little bit more in detail about Prefect.
So you all have on the GitHub page, if I track it down, you've got an interesting way to discuss it.
It says Prefect is the new workflow management system designed for modern infrastructure and powered by the open source Prefect core.
Users organize tasks into flows and Prefect takes care of the rest.
So there's a lot of stuff here that I thought might be fun to dive into.
So new workflow management system, as opposed to what was there before.
So maybe we could sort of take this apart a bit.
Yeah.
So we actually.
What do you mean by new workflow?
We have.
I know you also have a new, new one coming as well, right?
Yeah.
We have new, new.
You always got to keep rebuilding.
We have a great post on at least part of this that encourage people to go check out called the history of data flow automation that really will get our head of product wrote it.
And it's just a great kind of tour through the history.
But so for us, a lot of the different workflows, so workflow management, right?
You have some set of businessy business logic tasks that are stringed together with some dependency.
It could be a lot of conditionals or something like that.
You want to run it usually on a schedule, but sometimes ad hoc or maybe event based.
And there's a lot of different systems for managing these quote unquote workflows.
Okay.
Many of them.
I guess one way to think about it is they're cut by context.
What context are you operating in?
Is this like a data context or like Zapier, for example, is a very consumer facing?
And what is the user persona?
Right.
If you think about Zapier with all these different automations, all these triggers, and then all these actions, it's just like.
Right.
I mean, if that must be insane.
Yeah, exactly.
And that's a workflow.
It's totally valid.
And their user persona is a no code person.
Also totally valid.
And so for us, new workflow management system means kind of the next generation after a lot of the Hadoop tooling.
So Hadoop, as you can kind of see in this post too, Hadoop caused an explosion of just really cool new tools.
And Airflow, Luigi, Azkaban, I like this another one, maybe Uzi.
A lot of these kind of came out of that error to manage these distributed jobs.
And so they're kind of like, I think of them as like distributed state-based Cron.
You can put them on a well-defined schedule.
They manage the depend.
So it's actual dependency management, which Cron does not do.
And they can do it kind of across multiple computers, which is really convenient.
Yeah.
In a real simple way, it's like kind of the Cron.
It is kind of like Cron, right?
Like just look here for data and then just run this process against it.
But it's so much more with the dependencies and then pass it to here.
And then, yeah, right.
It's just the flow of it.
Exactly.
And you would be insane to try that with just timing.
Exactly.
And so new for, I mean, new for us can mean a lot of different things, but I'll just, I'll
just say, we just talked about it.
It's really taking approach of scheduling is important and alerting on failures of scheduling
is important, but we're like expanding the vision there.
And it's much more about this negative engineering, which includes observability, configuration management,
event-driven work, not just scheduled work.
Scale is really important because data scientists have a lot of the same needs as data engineers
and those tools were not meant for data scientists.
Right.
Yeah.
You were talking, I heard you speak about wanting to run a bunch of experiments, like hundreds
of thousands of experiments as a data scientist.
And some of the other tools would talk about running operations in tens per minute or tens,
something like that.
And you're like, I need something that does it in tens or hundreds per second.
Yeah.
I mean, anything that, you know, allows you to just explore a search space of hyper parameters
and do so in a way that is easy to quickly find, you know, some subset of those parameters
and see whether they succeeded or failed.
You can define that criteria.
You can raise an exception, for example, if like some output just violates some assumption
you have.
And then that way it shows up as red is like, you're not going to look at that.
And managing an interface to the infrastructure is another big part of this.
So I guess maybe I'm jumping ahead, but the next part is design for modern infrastructure.
And I think modern infrastructure can mean a lot of different things.
For us, it means first off that there's a diverse array of infrastructure people use.
And so creating a system that can plug and play with a lot of them.
So we support, for example, some of the more popular ways of deploying prefig flows are in
Kubernetes and Fargate.
So kind of like a serverless style model.
So you can do it on your local machine.
And so just having that kind of unified interface to interact with all these things is one aspect of modern.
Another is that local development to cloud development story.
That's really important, right?
You want to make sure that these are as close as possible to each other so that you can debug things locally and things like that.
And so that's another aspect as we try really hard.
And 2.0 gets this way better than 1.0 for the record of mirroring what code is exactly running in prod versus your local.
Something that always makes me nervous when I hear people talking about, oh, this is cloud native.
And you can just, there's like 50 different services in this particular cloud.
And so why don't you just leverage like nine or 10 of them?
And I just always think, you know, well, what is the development going to feel like for that?
You know, how, if I'm on a spotty internet connection or something like that, is it just inaccessible to work on?
Do I have to just completely sort of live in this cloud world?
And it sounds like there's a more sort of local version that you can try and work with as well here.
Yeah.
And one of the things that we achieved with 2.0 is we refactored kind of where orchestration, different aspects of orchestration takes place.
And so all of the true orchestration logic that we want to own runs behind an API.
And the reason that I'm saying, I'm like emphasizing that is in 1.0, that's not 100% true.
And so when you run a workflow locally, it's talking to an API.
Maybe it's your self-hosted open source API.
So it's maybe responding slightly differently.
But the code path running on your machine and its requirements and everything else is exactly the same as what's going to run in production.
It just might talk to a different URL.
Sure.
Let me stick on this.
We were halfway through your sentence.
I do want to talk more about like the cloud and stuff.
So powered by the open source preflect prefect core workflow engine.
Tell us about that.
So since day one, always wanted to put as much open source as is reasonable.
And one of kind of the ways that we think about what we put in the open source, and then I'll tell you what kind of this workflow engine is, are like, what are the things that we are maximally leveraged to support extensions of and, you know, new configurations of?
And our core workflow engine is definitely one of those things, right?
We're the experts in it.
And that engine is the thing that manages, for example, that a downstream dependency can't run if it's upstream failed or maybe just hasn't completed yet.
The caching logic is a part of that workflow engine.
The triggering logic for the workflow, the scheduling of the workflow, all of that stuff is open source.
That's the UI visibility sort of tracking bit as well, right?
A hundred percent.
Yep.
That is all open source.
And we build it as a part.
So we actually have a dedicated front-end team and we build the UI and package it up in the packages of pre-built website.
Yeah.
I'm not sure of where I would.
Oh, here we go.
I found a cool little UI picture.
Oh, there we go.
That's, yeah, that's the 2.0 one.
Yeah.
So, I mean, this UI to see what's working, what's not working, how often has it succeeded, you know, what's succeeded, what's failing, what jobs are unhealthy, for example.
Like, that's all negative engineering, right?
Your job wasn't to start out to build this observability web front-end.
Your job was to get the data in and then get it into the database and start doing it for analysis or whatever.
Exactly.
Predictions.
But here you are in Vue.js going after it, right?
Or whatever it is.
No, it is Vue.
Good call.
Yeah.
Right on.
And one of the ways I think about this dashboard view is it gives you this landing page to, you have some mental model of your expectations.
You can check quickly if they are violated here.
And then if so, dig in further, click around.
And if not, you know, we are more than happy when people exit out of the UI and are like, we're moving on.
It's like, perfect.
We did our job then.
Yeah, that's good.
But yeah, that's pretty neat.
So that's part of the core engine.
Yep.
A hundred percent.
And so things like auth, for example, are not part of that.
So in that case, like a lot of ways auth can get extended.
There's a lot of different ways that we might implement it.
And that's not exactly right.
Our competitive advantage, supporting different ways that you might deploy auth securely.
And so it's like, nope, that's our platform feature.
We can do it in the way we know best and can do it securely.
Sure.
And so it's worth pointing out, I suppose, that the way it works is there's the open source engine and then there's the Python API.
And then you talked about different ways to run it and to host it, right?
So one way to host it is to just use your cloud, right?
You've got the Preflect cloud where it just runs with all these things there.
And then the others, I could run it.
I could self-host that core workflow engine or just run it on my laptop or whatever.
So it's a little bit more complicated than that, actually, in an interesting way.
All right.
Tell us about it.
So Jeremiah and I both come from finance world.
And so a lot of our first kind of early design partners and advisors come from that world.
And one of the challenges one of our advisors gave us was very genuinely, I don't want to learn your tech stack so that I can host it within my tech stack.
And there's no way I'm ever going to give you my code or data because it's highly proprietary.
That's your problem.
And we're like, okay, well, that sounds impossible, right?
But we thought about it.
I think companies are already so freaked out about losing the data without even meaningfully giving it to someone else, right?
They're already like, well, we might lose this.
We might, you know, might be ransomware.
There might be other things, right?
And so the idea of just handing it over does seem probably pretty far out there for a lot of them.
Exactly.
And so what we designed after a long time, we really like thought about it, but we did this back in 2018, maybe beginning of 2018.
We came up with a model where orchestration takes place over an API.
And if you really think about it, think of other orchestrators, Cron, Kubernetes is a container orchestrator.
They operate on metadata.
They operate on container registry locations and specs for how you expect it to run.
And once we had that insight, we designed the system so that the cloud hosted API that we run operates purely in metadata, result locations, flow names, flow versions, things like that.
And then you run an open source agent anywhere that you want.
And it operates on a pure outbound pull it model.
So all of our features are based on the agent polling and then your workflow also potentially doing some communication.
And because of that, you know, there's still this outbound connection you have to think about.
You still have to trust us with some of your parameters.
And, you know, there's definitely still some security surface area that we have to think about.
But we do not post your data and we do not have access to your execution.
And that unlocked this problem for us.
And so as long as we have enough agents that can be deployed in lots of different places, then, you know, we can deliver a lot of value.
Yeah, that's pretty excellent.
So if you want to host it in AWS or Kubernetes or Linode or wherever, you just, that's up to you, huh?
Exactly.
100% up to you.
Is there a way where I can do it somewhat offline?
Like, for example, with the open source core engine, does that still go back to you guys or is that sort of local?
No, that's totally local.
And it's designed with the same hybrid approach.
So you could have, you know, your platform team, maybe your DevOps team hosting the API for you and the database behind it.
And then you as the data team can manage your agents.
And just as long as you have access to the API, you can set it up the exact same way internally if you want.
And we've seen places do that for sure.
Sure.
If you're a regular listener of the podcast, you've surely heard about Talk Python's online courses.
But have you had a chance to try them out?
No matter the level you're looking for, we have a course for you.
Our Python for Absolute Beginners is like an introduction to Python, plus that first year computer science course that you never took.
Our data-driven web app courses build a full PyPI.org clone along with you right on the screen.
And we even have a few courses to dip your toe in with.
See what we have to offer at training.talkpython.fm or just click the link in your podcast player.
Let's maybe talk through a quick example of using it.
Oh, hold on.
The last part of that sentence is users organize tasks into flows.
And so let's look at a quick example maybe of the code that you might do here.
Let's see.
Sure, here.
This probably isn't.
It's always tricky to talk about code on audio formats.
But just give us a sense of what does it look like to write code for Prefect.
Yeah.
So one of our design principles, right?
We talked a little while ago about this negative engineering problem.
It kind of emerges.
And eventually you're doing all those activities that you didn't care about.
And kind of in an interesting way, we try to mirror that with the way Prefect gets adopted.
So I love to call it incremental adoption.
I want the complexity of what you're trying to achieve and the amount of code you have to write to scale.
I mean, ideally like sublinearly or something, but, you know, scaled together.
And so an example you have here, our 2.0 takes this way further.
But we operate on this decorator model.
So just really simple.
You have Python functions.
You already wrote them.
You presumably already even have this script.
You just want to sprinkle in some Prefect so that you get some observability into it.
And then if you want to start to do more and more things, you might have to write more and more code.
But it's, you know, appropriate for the activity that you're trying to achieve.
And so, yeah, we try to be really simple.
We like it when people kind of get the feeling that this is like a toy kind of package that you play around that just has these heavy duty impacts.
So, yeah, tasks are the smallest unit of work that we can look at.
Tasks can do things like retry.
They can cache.
They have well-defined inputs and outputs.
Flows are containers for managing dependencies of tasks.
They also have well-defined inputs and outputs, also have their own states.
But flows are the things that can be scheduled and triggered via API.
And tasks are kind of just the smaller, more granular units of orchestration within those workflows.
And so the way that this looks is it looks just like a function.
And you kind of just call it with the arguments or whatever.
Yep.
And then you put a task decorator on there, which is pretty interesting.
And that's where the retry thing can be.
Exactly.
Then you also have a context manager, which I think is a nice pattern.
So you have a context manager to create the flow.
And then you basically simulate doing all the work with an abstract parameter.
And then you kind of set it off, right?
So that is true in 1.0.
However, what we found.
Something new is coming.
Yeah, this is important.
That context manager, all that code runs like you called out.
And so it compiles this DAG.
That's everyone.
Directed acyclic graph.
What we realized in talking to a lot of our users on 1.0
is that confronting the DAG.
Because sometimes people would write their own Python code
that wasn't prefect in that context manager.
And it would actually run.
It wouldn't be deferred.
And they would get confused.
They're like, why do I have to care about this?
And we started to realize that this DAG model really came most likely
out of the constraints of YAML flat file formats.
And they were mirrored in all the different tools
that were built on top of that.
And then all of a sudden, everyone's talking about DAGs.
Data engineer, when they're writing a script,
to move data around, should focus on the script.
They shouldn't focus on this abstract program concept of
can't do control flow, essentially,
without really thinking deeply about it.
And so in 2.0, we remove this context manager.
Flows are also now specified via decorator.
So the deferred computation is just function definition.
And now we will discover the tasks at runtime.
And you can implement native Python logic in flows.
And that's totally fine by us.
So it just unlocks the expressiveness of what you can write in Prefect really natively.
natively.
That's awesome.
So you can have loops or if statements or whatever you want to write.
Oh, yeah.
While statements even.
Yeah.
You can have flows that change structure from run to run.
All of it.
Okay.
So the thing that strikes me here is you kind of write regular Python code.
And you put a decorator or two on it.
And it just works in a different but similar way.
That's a little bit of that negative engineering influence as well.
It's like, how do I take normal stuff without too much work and make it more general for pipelines?
Exactly.
We call it workflows as code instead of code as workflows.
I'm sorry.
Code as workflows.
Because you have the code.
It is the workflow.
And now you just want us to care about it.
And so we should be minimally invasive when we do that.
Because the second you have to refactor your code significantly, you're back in negative engineering.
You have to think about the consequences of the refactor and everything else.
And we want to avoid that as much as humanly possible.
You should have to do a little bit.
Yeah.
A couple of things that I saw that stood out to me checking out your API here that was interesting.
One was I can have async methods and async execution of these things.
So async and await style, async def methods and await operations.
You want to talk about that support?
Yeah.
So if you actually go to orion-docs.prefect.io, that's where a lot of our 2.0 docs are currently
located while we're still in beta.
But they will, of course.
And then hyphen docs.
Yeah.
So this async works.
That's probably where I saw it.
Yeah.
Cool.
Big shout out to our prefect engineer, Michael Adkins, who really took a lot of time to dig
into the guts of async.
And he set it up so that you can do crazy things.
You can have synchronously defined flows with asynchronous tasks.
And our engine, the executor, will manage it all for you just to make sure that they're
running in the right event loops and things like that.
It's really cool.
We've got to create a loop and just run this in a way because internally it's synchronous
or something like that, right?
Exactly.
And so it's really slick.
And it gives at least users who know how to write async code, kind of this native feeling
of parallelism.
We all know it's not quite parallelism, but it gives you at least that feeling, especially
when you're doing a modern data stack.
If it's all API driven, you've got a lot of network IOs.
It's talking to databases.
It's talking to file IO.
It's talking to external APIs.
Like all of those are perfectly scalable.
Exactly.
Yeah.
Cool.
So you can have at task and say, I'm just going to do an async def some function.
The example you have in your docs, your Orion docs is using HTTPX async clients to go talk
to the GitHub stuff.
Oh, yeah.
And here you also have, here's your at flow decorator, right?
For this thing.
And another thing too, that we did that I'm really proud of that I've already started
to see kind of be one of the ways people onboard into Prefect is previously with the API, you
had to pre-register your flow and tell the API this thing exists, you know, get ready for
it.
And then runs had to get created server side before they could run client side.
With the new model, we set everything up and all of this was this like deep study in bookkeeping.
Like how can we create stable indices or stable identifiers for things that, you know, we can
identify across processes and runs.
And so in the new model, you can take this flow.
And if you are just pointing to our cloud API, you can call it as a function interactively,
and it will still communicate with cloud API just as opposed to deployed workflow.
And so what that means though, sorry, just going back to the incremental adoption story is you
can use cron and then you can just put one line of code on your main function at flow, keep
cron running with that Python script.
And you've immediately gotten a really pretty kind of record of all of the jobs that cron's
running.
And if it fails, you'll get the failure alerts and everything else.
And cron's still your scheduler, which is totally fine by us.
Sure.
Oh, that's interesting.
Yeah.
And then, you know, at some point you want to start to see into the future and that's when
you have to use our scheduler instead of cron.
But yeah.
But once again, incremental adoption.
Yeah.
The API here is pretty wild.
You're exploding a list comprehension of calls to the task to an ASIC IO gather.
That's a pretty intense line right there, but I like it.
It's not intense in the way that it's like, oh my gosh, what is this insanity?
But no, yeah.
It's a lot going on there.
Yeah.
You know, there's the joke t-shirt maybe you've seen.
It says, I learned Python.
It was a great weekend.
Right?
Like, that's true for like variables and loops and functions, but like, then you see
stuff like it.
It's like, oh wait.
Yeah.
There's more patterns here.
Maybe it's longer than a week.
It might be more than a weekend.
Give me a moment.
Yeah.
No, this is really cool.
I really like this new API.
So when's 2.0 a thing?
When is it released in the main way of working?
Our planned release date, or I shouldn't say date, but just like target, you know, you can
expect it's one of the weeks or something around is July 1st.
But we are still releasing.
So anyone out there is intrigued by this, especially if you're completely new to Prefect,
I definitely encourage you to just start with one of our beta 2.0 releases.
They're way slicker, way easier to get your head around, more interesting.
And there's still like everything, you know, working.
We just, there's some critical paths that we haven't fully released yet that we want to
make sure are there and tested heavily before we go into GA.
Right.
But if what's there works for people that they could, they could use it.
Oh yeah.
Should definitely work.
And if you run into weird bugs like that, let's not.
Yeah.
How does it plug into the cloud visibility layer and all that is if I run some one and want
some two, is it going to go crazy or?
No.
So they both will be configured to talk to the right API.
And so you won't be able to see them in the same place.
So that's unfortunate if you will, but you can definitely run them side by side.
I mean, the environments aren't compatible.
So you'll have to have different Python environments that you're running them in.
But yeah.
But otherwise, yeah.
I mean, I think some of our 1.0 clients, for example.
Because what?
Pip install prefix is equal, equal one, something or equal, equal two or something along those
lines.
Right.
You'd like need different libraries.
Yeah.
So if you just did pip install prefix right now, you'd get a official 1.0 release.
I don't remember the number.
So you'll have to make sure that you allow for pre-release in your pip command.
So either, I think if you just specify equals equals 2.0, I think we're at like B3 right
now.
Then you'll get it.
But yeah, you have to explicitly call it out since it's not, since it's still in beta.
Sure.
I always like going to pipi.org.
It's just like, it's 375,000.
I know.
It's impressive.
Yeah.
So 1.2.1 is the current one.
But in here, yeah, you're 2.0, beta 3.
And we are planning to cut another release later this week.
So you can expect B4.
Probably it'll be B4 by the time people get around to hearing this and shipping and so on.
Yeah.
But still, really cool.
So basically, your advice to people who are like, hey, this sounds interesting.
I want to check it out.
Like, just start with two.
Yeah.
I'd say just start with two.
It's working, easier to grok, and I think is more powerful and more flexible for different
use cases, especially if you're thinking outside of data.
Sure.
So when I hear people talk about data engineering, you know, if you go into that world, you see
all these amazing tools that people have built that look like, wow, these are really
amazing.
And to me, they feel quite similar, like Prefect and Friends.
It feels real similar to the web frameworks, right?
Like Flask or Django.
And you're like, okay.
So for example, what I mean by that is in Flask, all I have to do is I have to say, here's a
function that goes to this URL.
And I just write the code and return a dictionary or something like that.
I don't have to think about headers, cookies, connect, you know, like stay connected header,
HTTP2 traffic.
Like I just do the little bit and it just, it puts it all together for me.
And in the data engineering world, there's a bunch of stuff like that, that I feel many
people are wholly unaware probably.
Yeah.
There is an explosion of tooling in data engineering right now.
And also in kind of the adjacent analytics world.
This kind of goes back to what I was saying about how we kind of crystallize this concept
of negative engineering.
And it's just important.
I think all of these tools come from some very real use case, right?
And I think it's just important to figure out, like the way I talk to people about this
stuff is you shouldn't really pick a tool just on its current feature set.
You should pick it on its vision as well as whether it works for you today, because you're
going to change a lot and you want to make sure that the tool is changing with you because
these tools, especially the explosion of startups, we're all changing quite quickly.
And you want to make sure that we're changing in an aligned way.
And having that fleshed out vision is important.
And if it's just a tool that like seems cool, but like, what exactly is this doing for me?
Exactly.
Precisely.
If you can't really articulate that, then, you know, that's not to say you shouldn't keep
using it or something, but just that's, that's always my exercise that I do with
new tools.
Yeah.
When it's something as fundamental as this, you kind of have to think about, I'm going
to live with this for a while.
Exactly.
Do I want to have this as my roommate when I come to work?
Right.
Do I want to debug this?
Do I want to exactly extend it?
You know, you're definitely going to do something weird with it.
We've all done weird things with every tool we use.
Oh yeah, absolutely.
All right.
So my question to you about this sort of like parallel to Flask and the web frameworks and
various other things.
This is solving a lot of negative engineering problems for data scientists and data engineers.
What do you see?
Where do you see maybe people like me who mostly do APIs and web apps and things along those lines?
Should I be using stuff like this?
And where do you see the solving problems for people who don't like traditionally put on the
data science, data engineering hat?
So there's two, two places that I think are relevant.
I think the first is just like really kind of tactical, just tracking of background work,
tracking of background tasks, right?
Like Celery is a popular example for something like this.
Yeah.
Let me give you an example.
So like for, in my world, I've, I might hit a button, have to send out thousands of emails
like because of that.
Right.
And then maybe based on, on that, I might, if it bounces, take them out of the email list
or whatever.
Right.
Exactly.
You want to record the fact it's a perfect example.
So just anything like that for a background task.
And that's one of the things too, that we're going to try to make even simpler because we
have focused a little bit on the data space and the very easy changes we can make to
kind of extend that.
And then the second thing, and this is, this is the way I always kind of
kind of like to think about Prefect.
It's one way you can consider everything I've been saying is we're kind of like the
SRE toolkit at the business logic layer.
And it's something that kind of everybody could just use just that single pane of glass.
You get alerts, you get notifications, you can collaborate with people and it's just
kind of all right there for you.
And at the end of the day, like, you know, you don't really have to manage the code that
much if you're just using the UI.
And so I think that's how we can expand by just kind of giving people that value.
You want to look at the things that are happening.
You want to see a place where all of your systems are just right there.
And it's at the business logic layer.
You're not looking at CPU and memory all the time, although you could display that if you
wanted to.
So how about this as an example?
I created an e-commerce site and I want to track, I just want visibility into people buying
stuff.
What's working?
What's failing?
What's the rate?
The bosses.
I need something on the web that I can look at this.
Exactly.
Get reporting.
And the key thing here, right, that you said that is like puts it in Prefect's camp
and not in, say, Datadog's camp is you want to track the user button click, for example,
like some business logic thing.
Whereas something like Datadog is an SRE or observability tool that's going to tell you
your API throughput.
Prefect isn't trying to do negative engineering for your raw infrastructure.
It's trying to do it for your business logic.
Got it.
Okay.
Yeah.
Very interesting.
So Prefect, open source, if I want, I could just take it and do my own thing, right?
Oh yeah.
Go for it.
It is Apache 2.0 licensed as of maybe a month ago.
So before we had a few different licenses floating around, but now we're all in, all Apache 2.0.
Okay.
Give me the elevator pitch on Apache 2.0.
So what does that mean that I can do?
It means you can do quite literally anything as long as you don't violate trademarks, essentially.
And so, you know, don't violate, don't use logos or something like that.
So with MIT or something like that.
Yeah, exactly.
It's very, very generous.
You know, you don't have to check with us or anything like that.
Sure.
Okay.
Excellent.
Yeah.
You guys are doing a lot of stuff, not just with Prefect, but with other projects out there
as well, right?
Yeah, we are.
We really kind of, like I said at the beginning, tried to instill this kind of open source ethos
that even at the business layer, like we're trying really hard to genuinely deliver value,
right?
And that includes to our customers and users, but also to just the broader ecosystem that
we find ourselves in, which is exploding right now.
And so we have a lot of different efforts that we, yeah, I can definitely go through and list
them all like ways we try to contribute back to open source.
Yeah.
Give us a little bit.
So we do a few different things.
So one thing that we do is we will send pizza to basically any conference or meetup talk
that has a talk featuring Prefect.
And so you just have to submit a quick application.
We'll probably reach out to you.
And then, you know, that's pretty much it there.
If you are a Prefect engineer, we have kind of this like advocacy program.
And if you get involved with that, we've sent people to conferences before that are not
Prefect employees.
So that's another thing that we try to give back.
More concretely on the business side, we, every engineering team at Prefect, so right
now there are five kind of distinct teams.
They each get a $10,000 annual budget to sponsor any and all open source projects or just maintainers
directly that they think are impactful, maybe for their work or maybe for our ecosystem.
And so some of them, just to give you an example, one of the ones that kind of kicked this whole
thing off was we sponsor MKDocs material theme, just really slick theming.
And so that was, that was the first one.
We also sponsor a lot of view projects and we're going to be expanding this to like fast
API and some other ones that we just have to, you know, dot our eyes and everything and
cross our T's.
And then, so this is kind of an escalating rate intensity.
And the last thing is we've actually Prefect, the company has gotten into investing in certain
open source tools that we think are very compatible with some of the things we want to do.
So the big one, the headline one here is Textualize.
So Will, who the author of, yeah, exactly.
I always be afraid to say this a lot of things, I'm afraid I'm going to say it wrong.
So he's the author of Rich and Textual.
And as everyone knows now, it's all out there.
So he's building the service Textualize for hosting these text-based terminal applications and
distributing them through the web.
So in kind of an interesting sense, it's like spiritually similar to the hybrid model,
right?
You can kind of run one of these agents.
And we've always wanted to expose richer interactions with Prefect agents running in
your infrastructure through our UI.
And like, when we talked to Will, it was like, oh, this is it.
This is perfect.
And it's got all the right like theming differences.
So you'll be able to tell this is something you wrote.
It's like very text-driven compared to kind of our more branded, you know, assets lurking around
the UI.
And so, yeah, we invested in his company, yeah, in their seed realm.
I'm really glad to hear that.
I'm also really glad for Rich that he's got that going.
He's been making such progress.
Oh, yeah, yeah.
He gets to the top of Hacker News, I feel like, every other day.
So I will.
I always switch his name.
I feel so bad.
I'm very happy for Will.
And he's been doing so much with Rich.
My brother's named Rich.
It's a problem.
But, you know, you go and I'm finding so many of these projects.
I'm like, oh, this is really interesting, especially for our Python Bytes podcast.
We're just covering packages and things that are interesting that week.
And more often than not, you're like, that's got a really cool UI.
Oh, I see in the dependency, you know, requirements.txt or PyProject.toml.
Rich is at the heart of making that look good.
Oh, yeah.
We use it.
It is great.
Yeah, absolutely.
It totally is.
So one of the final things I want to talk to you about is creating a business around open source with this very permissible model that you're giving away.
And I think it's super admirable.
I know there's other companies doing it to various degrees and to various degrees of success.
Like MongoDB comes to mind, for example, and, you know, Red Hat and stuff.
But all these examples that I see are just are like, fantastic.
Look at what you guys are doing.
You're investing in other open source projects by having a successful business with this open source core engine as the core.
And so I just, you know, wanted to give you a chance to talk about the business model, maybe, you know, riff on that a bit and give people advice out there who are doing their own thing.
Like another one that comes to mind is you guys do a lot with Dask and like Coiled is now sort of in a similar position with Dask hosting Dask as a service, sort of.
Right.
Yeah.
And we're partners with Coiled, too.
So we keep up to date all our integrations there.
So, yeah, our business model for cloud.
And it's, you know, unsurprisingly, too, that we're going to get some slight changes, but like spiritually very similar.
So first and foremost, we really want to make sure, especially like the hobbyists, the open source projects out there, you can come in and, you know, use the system to actually achieve, you know, powerful use cases for free.
And so one of the ways that we came up with our free tier volume, which is 20,000 free task runs a month, is we asked ourselves for just a very bare bones airflow deployment running.
Like how many tasks would you turn through a month?
And like that's, you could run a business's ETL processes off of that volume.
And so that's kind of roughly where we picked this number.
So like we do think that this satisfies real business need.
And then kind of the reason that you would move out of it would be for kind of pretty standard reasons, right?
You want to unlock more scale.
Okay.
So then you talk to us.
You want to add more users because, you know, you're capped on users and maybe even you want more teams.
So if you're an actual enterprise, you're presumably going to have some more permission structures that you need to grapple with.
And so that's when our enterprise tier comes in, SSO integrations, all of that fun stuff.
And kind of this isn't really going to change in spirit for 2.0.
It's going to be pretty similar.
There's going to be some sort of throughput metric.
Maybe it's task runs, maybe it's storage, something else that, you know, a lot of it's free.
And then you want to add more users, more workspaces.
You start to talk to us and then kind of it grows.
You know, if you start to have really big performance needs or you have requirements for data locality and things like that, like we start to talk, you know, enterprise plans.
So we try to align it.
And one of the things, too, that was insight for me to really think about in the early days was like business models, you're not selling the code you write.
And that's why open source, you know, works.
There's some value that you're providing and you have to find, figure out what that is.
And like for us, it's kind of almost like funny.
Having to host and maintain an API locally is negative engine.
And so that's not what you're trying to do.
You're trying to schedule jobs.
And so kind of migrating up to cloud tends to be a natural thing unless you've got the resources to manage it and scale it out, which is also perfectly fine.
And the thing is, there's a lot of expertise in running systems like this.
Yeah, there really is.
Yeah.
And the database, too, you want it to be scalable.
And yeah.
Yeah.
So I think there's a lot of value.
I think it makes perfect sense.
Like give you the core for free and you can run it and you can maintain it.
It can be your baby or it can be kind of hands off and we'll take care of it.
Like you said, authentication and all that kind of stuff.
Yeah.
And we have a really active, like a crazy active Slack community.
So, you know, if you're doing that yourself and self-hosting, I can go ask there and I'm sure you're going to get a lot of responses.
I think there's 16,000 people, something like that in there right now.
Wow.
Okay.
It's active.
Like messages pretty much, you know, flying by pretty regularly.
And then, oh, our discourse as well is up and coming.
Yeah.
I think it's worth maybe just highlighting.
There's, you guys have almost 9,000 stars on GitHub, which is, that's quite far up there.
That's pretty awesome.
Yeah.
So, yeah, that's, y'all must be proud.
Yeah.
We, you know, it's always fun when you're open source project.
We reached the number one trending repo on GitHub one time.
This was maybe two years ago.
Oh, wow.
We had a random happy hour that night just to celebrate.
I was one.
How long has it been out?
When did you start it?
So, let's see.
Prefect, the company is four years old.
And I believe we open sourced, I want to say, in December of 2018.
So, the core, at least, has been out for quite a while.
And then cloud was maybe six months later when the first version of cloud got out.
Cool.
Yeah.
So, not brand new, but not super old.
Yeah.
Battle tested, but definitely still got a lot to build.
Yeah, for sure.
Did you guys build it on Python 3 only just at that point?
Yeah.
Python 3 only.
Yeah.
We try to just build for the future, right?
Yeah.
Shrinking audience.
Yeah.
You end up in a place with a lot of negative engineering if you try to support too much too
far back, I would say.
Yeah.
For the community, you got the Slack, and that's pretty awesome.
You got the discourse.
Then you also have Club 42.
And if people just go to your website and they go to a community, they'll see this.
You'll see the I Want a Pizza if you've got a user group.
But I'm guessing this has to do something with Hitchhiker's Guide.
What's the story with this Club 42 thing?
Yeah.
So, Hitchhiker's Guide definitely is a theme for us.
Everyone gets a free copy when you join.
Club 42 is our application only.
So, you can apply.
It's not invite-o.
It's a private group of kind of external advocates of prefect.
So, people who just really want to get early access to things, who have proven themselves
to be the positive forces in our community, which, to be clear, doesn't mean that they're
necessarily, like, some of them are technical experts, but you don't necessarily have to
be.
The point is just that you kind of help our community succeed in whatever way that makes
sense.
Just keep it healthy.
Yeah, yeah.
That's fantastic.
Yeah, we run, like, special events with them.
And they get early access to everything.
They were the first people that got Cloud 2.0 access.
I think that's really valuable.
I think more companies should be doing it.
I know MongoDB did that for a while.
I don't, I think they stopped.
You know, Microsoft has Microsoft MVPs, and I'm pretty sure Docker has something similar.
But, yeah, it's a cool idea.
I'm glad you guys are doing it.
Yeah, it's really fun.
And just to kind of get, right, you get a bunch of people all caring about one thing
kind of together, and interesting conversations always happen.
For sure.
All right.
We're getting short on our time here, Chris.
But I guess one more thing I can imagine, you know, it's, I know a lot of people who are
working for amazing companies are starting to reevaluate the amazingness of it now that
they've got to go back to the office or like the rules have changed and then they've changed
again.
And they may be thinking of other positions.
What's the hiring situation?
You guys have open positions to work on this fun stuff?
We do have open positions.
We're fully remote.
So no worries on that.
Although we do have plenty of opportunities for meeting people in person as well, optionally.
So we have kind of these hubs that people can apply to and will show up like 20 people at
a time and have like a mini internal conference.
And we're having our first full company off site later in July.
It'd be really fun.
But anyways, yes, we have open roles.
Highly encouraged.
If you don't, so right now the biggest roles on my mind are kind of more in the platform
space.
So SRE style roles, platform engineer roles.
And so if that appeals to you or you have any experience there, let us know.
And if you don't see a role on our website that maybe fits you, don't be shy about reaching
out because sometimes these things take a long time and let's just formally keep a conversation
going and, and yeah.
Sure.
Say I have this special power.
It doesn't match one of your three listings, but I bet it could help somehow, right?
Exactly.
I mean, you know, it happens.
It happens.
It's happened to Prefect before.
So yeah, my email is, is Chris at Prefect.io.
So you can feel free to just email me.
Yeah.
Fantastic.
That's great.
All right.
I think, I think that might be where we got to leave it for data engineering and Prefect,
but very, very interesting.
But before we get out of here, you've got to answer the final two questions.
If you're going to write some Python code these days, what editor are you pulling out?
Oh, put me on the spot.
I'm still a Vim user.
I'm a platform survivalist.
If I find myself in the, in the corners of an old system, I want to be, I want to feel
powerful.
And so Vim's worth it.
Pretty sure.
I think there's still a ton of people who are on the Vim and the Emacs.
I mean, they can't talk to each other.
They can't, they don't get along.
I started out programming, but I started out programming, doing Emacs on Silicon graphics
machines.
Wait.
So what's your now editor of choice?
Right now, these days I'm on PyCharm.
Okay.
That's a good choice.
PyCharm and VS Code seem very, yeah.
Yeah.
I use VS Code as well for like small little things.
And if I'm like, here's my big project, then PyCharm is the choice.
Yeah.
And then notable PyPI package, I mean, pip install prefect is one of them, but like
some library that you've seen that you're like, oh, this thing is amazing.
I really should tell the world about it.
Rich in textual for sure.
Oh yeah.
FastAPI, I think is amazing.
I really think that you can scale out some pretty powerful web servers with that.
It's really pretty amazing.
I was just doing that before we jumped on the call.
Oh, nice.
Nice.
And then we did mention it earlier.
Dask is a really powerful Python framework for distributed computing.
Definitely easy to get started with and really powerful as you scale.
Those are the ones come to mind immediately.
Cool.
Those are all fantastic.
All right, Chris, final call to action.
People are interested in prefect.
What do you tell them?
What do they do?
Definitely join our Slack and go to our GitHub.
That's where you'll really be able to immediately kind of get involved in the action, figure out
what's going on, just ask around for best practices, how to get started, get some project
ideas, whatever the case may be.
Yeah.
And you have a nice tutorial, but maybe what you would
recommend Orion docs, orion-docs.prefect.io to like the tutorial to follow along for now?
Yes.
I would definitely recommend Orion docs to get started.
And we'll slowly start making these more discoverable over the coming weeks.
Well, I'll put it in the share notes so people can get to it.
Awesome.
All right.
Well, it's really great to chat with you.
Thanks for being here.
Yeah.
Thank you so much, Michael.
This was really fun.
Yeah, it sure was.
Bye.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
Starting a business is hard.
Microsoft for Startups, Founders Hub provides all founders at any stage with free resources
and connections to solve startup challenges.
Apply for free today at talkpython.fm/foundershub.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Thank you.