mike_bifulco: Hello, and welcome back to APIs.
You won't hate the podcast.
My name is Mike Filko.
I'm one of your co-hosts, and today I'm joined by, uh, two
friends of mine, including the, uh, ever wandering Phil Sturgeon.
Phil, how are you today?
Track 1: Hey, how you doing?
Um, uh, I'm good.
I actually dunno where I currently am.
Um, but uh, I have internet and that seems like the most important thing.
mike_bifulco: that's good.
Yeah, you seem to be in good health too, which is, uh, usually a relief.
yeah, and we're here today also speaking with our friend
Josh Twist from Zulo, Josh.
Uh, thanks for joining us today.
josh_twist: Yeah, no, great to be here.
Great to sort of meet you guys in person and uh, yeah, thanks
for having me on the show.
mike_bifulco: of course.
Interestingly enough, uh, you guys have come on board as a sponsor for
one of our sites, that, uh, APIs Walnut Hate has developed along
the way called Open api.tools.
Open api.tools is just what it sounds like.
It is a, open source list of tooling for working with open api.
So if you're listening to the show, you can head to the url.
It's one of those funny top level domains that sounds like it might
not be real, but it is actually real.
And there's a list of dozens dozens of, open API tooling that
has been, cobbled together from.
The APIs, you all hate community, including, uh, myself and Phil and
Matt Trask and a bunch of other people
uh, You're welcome to submit things you might want to add.
And, you'll notice, Zulo is our, uh, prime sponsor for the site at the moment.
Why don't we start there?
Why don't you give the 32nd pitch for, uh, what you're working on at Zulu,
what, uh, what the story is and why our API devs might be interested in it.
josh_twist: 30 seconds is quite a tight time slot.
Um,
Track 1: We have, we have more questions, Kevin,
about it as well.
So don't worry.
That's, that's not the whole thing,
josh_twist: so yeah, I've worked , let's sit podcast over.
Uh, no, I've worked on, uh, I've worked on in on APIs for a long time.
I actually founded the Azure API management product at
Microsoft through an acquisition.
And I've sort of sat watching that whole industry for, I dunno,
nearly 10 years, seven years, somewhere between those two numbers.
And I just felt that none of the products were fun to use.
Uh, there's like a, it's a red ocean.
There's lots and lots of API gateways and API management tools,
but I think they have low N ps.
They're really not designed for engineers.
Um, and I just felt there was time for a fresh take on it.
And so we created Zulo in, uh, July of 21 was when we founded the company.
And we're, we're trying to bring a really sort of fresh perspective to.
API management and democratize the technology is kind of our goal.
So we wanna make it something that every business would consider using.
You know, API management today is typically used by larger companies.
Um, and I think it's something startups should use.
Like, don't spend time on this.
We can do it faster, better, more secure, uh, and cheaper than if
you build this stuff yourself.
And yeah, we're gonna do that by making it easy, making it affordable, making it fun.
Track 1: fun.
Nice.
You said a bunch of stuff in there and I dunno what NPSs is and a bunch of those
other things, but first we have to ask the question, what is an APA gateway?
josh_twist: Oh, is that to me,
Track 1: to me?
Yeah.
josh_twist: oh God.
Wow.
I feel like I'm being tested now.
Well, it's a gateway.
And what's the difference between API management is like
a constant sort of, uh, debate.
So, um, you know, a gateway at, to simple level in my mind is, is, is sort of a
layer, an architectural layer you put in front of your, your APIs that typically
take care of some sort of common, um, uh, common concerns that, that, that you need
when you're, when you're shipping APIs.
So authentication, um, security, uh, protection, like rate limiting,
um, Uh, et cetera, et cetera.
And so, you know, there's lots of gateways in the market actually,
that that market is really enormous.
Uh, uh, you considered engine X and um, uh, all of the platforms that
are forked Engine X, um, that exist.
Um, and then you've got API management, which I think is, is, is API gateway
plus plus that takes, that looks after additional concerns and
really tries to give you a holistic way of managing a lot of APIs.
In our case, we also try and make it easier for people to ship APIs.
So, so one of the things we say, actually, both Mike and I worked at
Stripe for a while, is that we helped startups ship, uh, Stripe Quality api.
Very quickly.
And to do that, we take care of your developer documentation.
We call it the, the three pillars actually of, of sort of shipping an api.
You need protection, you need authentication, and
you need documentation.
Like that's the bare minimum that you want when shipping an api.
So protection means things like rate limiting and funny,
like this happens all the time.
And I talk to customers, they're like, I, some half of people say I don't need rate
limiting cuz I'm not gonna get attacked by, uh, anonymous or this hacker gang.
And.
It's not the hackers that are gonna get you, it's your customer that's gonna
write a bad fall loop and take you down.
And then the other half of customers are like, yeah, this happened to me yesterday.
useEffect in react is probably the ultimate culprit for taking APIs down
that don't have rate limiting in place.
Um, so protection is, is things like rate limiting and quotas.
Uh, documentations fairly self-explanatory I think.
And then authentication is, you know, what's your approach to orth?
Are you gonna use Jot?
Are you gonna say API keys?
I have strong opinions on that as well.
And we make those, you know, just drag in a policy or drop at your
ship you'd done and you can get on focusing on your business logic.
Um, so yeah, A quick take on API management, API gateway,
Track 1: Nice.
We don't like strong opinions on, on this podcast.
Uh, we like to be fair and balanced at all the things.
Um, that's not true.
That's pretty cool.
And so what, what sort of, um, users are you going for?
Right, because there's, there's a whole bunch of a API I Gateways and
a p a management tools out there.
There's, there's all like the Enterprisey A and all of that.
Um, there's, uh, every one of the cloud solutions, like a Azure has one.
Um, AWS has two for reasons.
Um, there's, there's, there's loads of 'em.
Um, there's uh, tyke, there's Kong, there's little JavaScript based ones.
Like what, what separates yours from all of them?
Is it different personas?
It different functionality?
josh_twist: No, I don't.
Interestingly, we've, we, we've approached this a little bit
unusually in terms of persona.
I th I think there's definitely differentiators that I could go into.
Um, but actually one of the things when we, you know, we're a newish company
about year, year and a half coming, uh, coming approaching two years,
one of the things I was keen to do, I mentioned democratizing API gateways.
Um, I really wanted to build a product that would span the needs of
a large organization and a small one.
And so one of the hypotheses we set out to prove or disprove, uh, initially
is, can you, does such a product exist?
Can you do that?
And, um, my belief was you can, because actually the, the
concerns are roughly the same.
It's just the experience that matters more to that low end.
So we, you know, I feel like we've done that.
I've got, uh, a good number of tiny customers that have like two
employees and they just wanna ship an API quickly and they're delighted
that they have this great, um, uh, they have this great experience that
they didn't have to work so hard on.
And I have, um, uh, customers with 5,000 employees, um, large contracts that we're
considering, I won't name any names, but you've already said them, um, in an rfp.
And we went through a formal RFP process.
And so what's really exciting to me is we've kind of, I feel like we've
proven that hypothesis recently that a product can do both of those.
You can build a product that's easy to use and that's why these big
companies are choosing us is because.
They don't need to be sent on a training course for a week to use sulo, but it
can do pretty much everything the, the bigger, more mature products can do.
And it just fits into their, their life cycle better fits into
their, uh, developer workflow.
That's a, been a massive focus for us.
mike_bifulco: Yeah, it's interesting.
It sounds like it fits sort of the classification of products that like
enables a lot of superpowers without, uh, having to spin up an entire team
of, of wizards or experts or whatever to go and, uh, figure out how to, uh, you
know, go around all the edge cases of rate limiting and all of the things that,
uh, your team is no doubt an expert on.
Um, I, I tend to think that it's a pretty good hallmark too of a product
that's worth looking at when it works for both the small and large teams.
Uh, especially because that means that someone at a larger company
can grow their, you know, their little, uh, niche, uh, api, um,
from, from nothing with a couple of people to something pretty massive.
josh_twist: The a hundred percent.
And the, the other thing actually just from.
Like a business perspective in my mind.
You know, I think, I think one of the businesses that's done
this very well is OTH zero.
Um, and they built a product that works great for large companies, they have
massive customers, but pretty much every startup I talk to uses them.
And that was actually part of their go-to-market strategy is, you know,
people used Orth Zero on their side project and their hobby project
or, but they also worked at Big Co.
And so when the time came that, hey, we need this identity solution.
Um, you know, and very much I hope that's what what I hope happens with Zulo.
We have lots of hobbyists building things.
We did, we did some stuff with Superb Base recently as a backend.
And if you want to go API first with a super base backend, you know, Zulo
is a pretty easy way of doing that.
Um, very low lift, which is great for that audience cuz
they don't have a ton of time.
And you know, the hope is that they'll fall in love with the product
and go and sell it at their big company they work at during the week.
mike_bifulco: Sure.
Yeah.
I was, uh, diving in and looking at your docs.
Uh, I guess as I was preparing for the show here, and one of the things that
stood out to me as interesting is, um, I think there's a section in documentation
that's something like, um, get started or quickstart or something like that.
Uh, and that there were a couple of key use cases that fell into that
quickstar category that really made it feel like, um, if you're looking
for these things, the solution is, you know, dead simple right in front of you.
Um, and the, the two that I recall off the top of my head are documentation
and rate limiting as, as, or, uh, you know, just general gateway
features as a, as a quick start.
Uh, and like that's.
, that's a, a really simple way to evaluate the product and, uh,
whether or not it fits your use case.
Um, and that meshes well, uh, with the pricing tiers that you have as well.
So if this is me putting on my, you know, uh, startup founder hat, I guess too,
but that's a really interesting way to like, just let someone get in and use
the thing and then go sell it to their organization as opposed to having to
deal with the sales team on your side.
Are you finding that that's a, that's a way that people, um, really
do sort of join and get started.
Like you've left the right breadcrumbs for people to try out Zu.
josh_twist: Yeah, the smaller folks for sure, um, they tend to come in, try
the free product, and then, you know, uh, we see them in the Discord chat
and end up becoming paying customers.
Um, the larger customers, we've, there's actually a bit of a, uh, I
don't know how relevant this is to you, to the podcast, but I'll share
it anyway, but there's a bit of a, the, it's called product led growth.
This idea what, what, um, if you're familiar with it, what, what ZE did
a great job of, and it's actually become, there's a bit of a backlash
against it in the startup world today, that it's not the be all and end all.
And I think we see it as like, you actually need both streams.
Like our larger customers at the moment, they haven't come in that route.
They don't really sign up themselves.
We get sent a formal, they hear about us, they're excited about
it, they see the demo, and that's usually when they suddenly get
very interested and are willing.
You know, to be clear for a large company to take a bet on zulo, it takes
someone risking some personal capital.
It's like, you know, they're saying you don't get fired for choosing b m.
It's like, just pick Apogee or Congo, one of the big names, you know, it's easier.
But once they see what they can enable their teams to do, and their teams
will actually like using it, they're, they're willing to fight for Zulo.
But that's a more formal, sort of sales led process, um, for those folks.
I hope it switches.
You know, I love it when people come in and stick a credit card in and
they're just away, uh, at the races.
But we definitely see both channels being important, um, uh, important for
us, but we're very passionate about, I, I think about building a product
like this, like building a video game.
And I think, um, someone did a great article on this actually.
I'll, I'll add it to your show notes.
Um, when I dig it out, um, actually I got it from, Uh, uh, a memo
in Side Stripe from Patrick.
Um, and, uh, and it talks about like the best products are like video games
in terms of, they start very easy, you know, when you, when you start Mario
level one, you know, you just gotta jump around a bit and you're gonna finish.
But there's a way and a ramp to like use all the power of a product.
And it's like your face of bows are on the, the last level,
on the, the, the bad guy.
But, so, uh, products in this market, I find it feels like you're just
facing Bowser from the get-go, right?
That's your, like , you're literally on the last level.
It's really hard to get started.
And so we, we spend a lot of time and attention is how do we make the, a really
nice sort of glide slope to the product.
You come in, you've got API key management set up, it's tied to a
project, but then as things get more complex and you're, you're starting to
wanna do some wild stuff, then we, we give you all the tools that you can,
you can do whatever you need to do.
So that's a thing we think about a lot.
mike_bifulco: Yeah.
Uh, that's, um, one of those things that I think, um, people using your products
too won't realize it's happening, right?
But they'll, they'll have become experts and kind of grown this
understanding and attachment, uh, to the tools that they're using.
Um, and in particular, if that feels familiar, like that journey is
something that feels like they've felt with products that they already love.
You know, like, oh, this is just like when I started with super base,
for example, or whatever, right?
You feel like you're, uh, hopping from lilypad to lilypad in a way that,
um, is familiar and generally good.
You, you get the network effect of those associations too.
josh_twist: Yep.
Track 1: Yeah, I mean that's something that I quite liked about the way that
things ended up going at stoplight.
Um, that was, Whether you see it as like a skeezy marketing tactic or whether
you see it as um, kinda like that product led stuff you're talking about.
Like we released a bunch of open source tools, um, and, and loads
of people were used to working just purely with those open source tools.
Like people love spectral and they'll just use spectral all the time and
it's little c l i thing, and then maybe they'll use it in the VS code thing.
But you get used to using this stuff from stoplight and then.
, you're like, actually I'm, I'm fed up with editing open API via Yammel, so I'm gonna
go use their studio, but I'll download the desktop one and it's totally free.
So these hobbyists and these individuals, and maybe you're working
at a company using that stoplight stuff without the company signing off
on anything cuz you didn't need to.
It's just an app on my computer and then all of a sudden someone's like, ah man,
we need a editor that everyone can use.
And there's like five people at that company going stoplight, I already use it.
We're already in there.
Um, so kind of having, it's just freemium, I guess, but having that freemium model.
Where you can get loads done.
Um, and, and not try and like kneecap people with, uh, all these
useful, critical features are gonna be hidden behind a table you can
get so far but you can't publish or something, you know, crap like that.
Giving them an actual genuine experience but then just saying, oh, if you want
these complicated, confusing, um, like shared design libraries or shared style
guides and things that involve our servers doing loads of work, I gotta
charge you some money for that cuz the server has gotta do loads of work.
And I, I think that's just a nice way of going about it.
Just like, yeah, genuine freemium stuff to get your foot in the door as well.
It's like a win-win for everyone
josh_twist: Yeah.
Help people solve real problems as well.
And we, well also actually, the, the premium tastes great for us.
Like we get a lot of good feedback from people who use our free product,
and they're probably not gonna become paying customers anytime soon.
But they've been some of our best customers in terms of helping
us build a great experience.
You know, these folks who are doing this, not for their job, but for, for fun or
for their hobby or their side gig, they're trying to start, you know, um, they're
doing it from a real place of passion.
And so their, their feedback's especially interesting to us.
Track 1: Tell us more.
So you're talking about a p management, we've mentioned that
gateway is kind of one aspect of it.
Um, but a p management is a huge nebulous topic.
There's a million different parts of the life cycle that you might be managing.
Um, and actually another stoplight mention, they're
not sponsoring us anymore.
I don't work there anymore.
At some point I'll shut up about stoplight.
Um, but , um, Jason Harmon, the cto, wrote his really good blog post for, um,
is it a blog post if it's for Forbes?
I don't know, whatever he wrote for Forbes.
Um, talking about how it's basically impossible to cover every single
aspect of the API lifecycle.
Properly.
There's a lot of companies pretending that they do, but they
don't because you've got, um, especially his design, there's a api.
Design management has, has been separated out as its own kind of, um, vertical.
But you've got kind of the designing, um, which you kind of do, cause you've
got an editor, you've got mocking, you've got docs, you've got testing, kinda,
you were talking about some contract testing on a chat the other day, right?
There's um, there's the whole like developer portal getting
new API keys, which hooks in with the actual production stuff.
Like what parts of the life cycle are you going for and what are you not going for?
I know you're just trying to do it all like a madman,
josh_twist: No.
Uh, we're definitely not, not yet.
I mean, you know, I think maybe there's a world where we continue to sort of
eat up adjacencies, but our focus, um, you know, we do have a designer, but
I don't think we're trying to become an alternative to stoplight or to, um,
you know, postman, I think as, as sort of has some good tools here as well.
Um, that's not our intention with the designer, the designers though really,
again, to give you that sort of very, very easy onboarding experience.
That's, that's, you know, we're, we're not suggesting anyone tries to design
an open API document in our designer.
Don't do that way, I mean, it just won't work.
Um, but if you're coming in and you just wanna get started, it
kind of gives you this very gradual glide slope to being successful.
But then if you look, when you're designing whatever you're
designing, it's just generating a text file in the background, right?
Um, and in that you can do a lot more than our design could do.
So we're not trying to own API design.
I don't think at this point we, it's hard to say exactly where the
stages are, where they end, uh, where they begin and where they end.
I think one of the, first of all, we wanna make you it easy to have a, like a
great runtime like running and operating.
Uh, an API needs to be great.
So the fact that you're protected, um, the fact that, uh, you have analytics
and understand what's going on, and, you know, we have integrations
with like Datadog for, for logging.
So sort of operations is, um, is covered.
That's the, that part is the real focus for us at this point.
And the reason we have tests is really just in support of
getting people to that place.
So one of the biggest things we've spent time on is, is what
is the deployment story for Zulo?
So, I mean, you mentioned great open source companies, actually,
I think like Versace is a company we admire, uh, tremendously.
Um, and you know, they had Op Xjs is open source and then the, the paid products is,
is the sort of segue I'm going for there.
Um, they also, along with Netlify, have this great GI ops
model where everything's in.
In GitHub and you, um, you push a commit and then it'll
deploy, uh, for each branch.
Well, we have exactly the same behavior.
So, uh, we make it crazy, easy to deploy.
And part of that is being able to test easily.
So really that's why we built the testing.
We don't think of ourselves as like the ultimate API testing platform.
Not at all.
Um, rather, we wanna make sure that when you're running and operating these
tier zero mission critical APIs, as they are for most of our companies, that
you're not gonna deploy something bad.
So we want, we want to help you to help yourself effectively.
So that's why we have things like the, the testing.
I am definitely interested in helping teams.
because there's blurry lines at the edge of that part of just like
running and operating an api, right.
And managing it.
It, there's, there's, there is this idea of, well, how can I put it?
What my experience of customers using API gateways, like most of
the, or API management products in the market is that the, the gateway
lives on like an iron throne in the, in the business, in the enterprise.
It's guarded by a team of architects dressing like Knight
outfits as I'm going for the full on Game of Thrones thing here.
Uh, you know, and no engineer can touch it.
They probably have to fill in a Google form to make request changes.
And it's just, it's just BS frankly from like how engineers normally work.
And so we wanna fix that.
And so now, Creating a new deployment, creating a new environment in zoo PLO
tech, 20 seconds and you'll have it live.
I have a customer paying for 250 concurrent production environments,
and that's cuz every team gets a preview environment, gets
multiple preview environments.
They just wanna throw, create them, play with them, throw them away.
Every engineer gets to do that where we are.
Where I am interested in going a little bit further is, so how do we.
You know, those architects, now they've kinda lost control, right?
How do we give them governance with a little G?
And we really wanna do that in automated ways.
So some of the stuff we're, we're playing with now is the, the
tests have to pass before you can promote this to the true production
environment or the true QA environment.
Um, maybe some lin rules are gonna come into play, like, Hey, you know,
we have a set of standards here.
And, um, and it, you can do whatever you want on your, what we call working copy.
That's like the pri developer's private gateway we give them.
Um, but if you wanna get that into production or QA or staging or whatever,
then it's gonna have to pass these rules.
You're gonna get warnings, and then they're gonna turn into errors.
So there's blurry lines, but really we're about, you know, operating,
um, operating a large API at scale.
Track 1: That's, yeah, that's interesting.
Cause that's one thing I wanted to ask about is like who, who operates
it, like who's in charge of it.
Right.
Because I've worked at a bunch of companies where, You don't,
you almost don't even know that the EPA gateway exists.
It, it's like a, or any of the, you know, I, I throw around gateway
and management interchangeably sometimes cuz they're pretty close.
But, um, like they'll, they'll just kind of like sneak it in.
You, you build whatever Rails app you're building or whatever, and then someone
will just like slide this layer in, in front and you get rate limiting, which
you never had to think about Cool.
Or whatever.
Um, and you might get a bit of like edge caching or something else, but like, it
is just kind of this, this like DevOps implementation detail that you, it's
more like infrastructure, um, but it, it kind of sounds like you are looking
for other people to get involved.
Right.
So the, the developers maybe getting a bit more involved, but like, is
there any, is there any room for the client side to get involved?
Because you were showing me, um, the caching feature and
I can absolutely, I, I bet.
There's people out there.
Kind of my frustration with the way that people talk about Graph UL a lot is that,
that there's, there's lots of people out there that are really upset with bad rest
APIs that are then building their own kind of API layer in Graph UL building
bff so that, you know, they're a client team, but they're building a BFF to
solve ship problems with that shit api.
Um,
and I could just kind of
josh_twist: other
Track 1: oh, sorry.
Backend, backend, backend for front end.
josh_twist: Oh, okay.
Okay.
Back in for
Track 1: So, yeah, like say, say you are building a React app and you've gotta talk
to like six different APIs that all have completely different, um, authentication.
I've been in that situation and I was like, I don't think that every client
should have to build their own BFFs to, to solve all these inconsistencies.
We could just use an API gateway to remove those inconsistencies and it
would use the same authentication system.
But I could imagine that the clients would also have a bit more control if there, if
there's just this one shared repo that's a bit less freaky to try and configure than
some like hosted gateway somewhere else.
Um, then they can add some cash headers.
Just like, you know, you, you assure me how to add cash headers to my badly
built API and then my client was quicker.
Um, is that a use case that you kind of intended or
josh_twist: Uh, no, I, I guess we hadn't thought much about the, the, the
client as in the person calling the api.
You mean, just to be a hundred percent clear.
Track 1: Yeah.
Yeah.
The api, API
josh_twist: React app or something?
Yeah, the API consumer.
Um, no, we wanna give them a great experience, particularly the developer.
We care about that.
We care about, we know, we think engineers are cramps people, and so
we, we want, we wanna build something they're proud of, sort of saying they
have their name attached to, but we don't think about it much beyond that.
what'll happen is there's, there's a company, it has, it's, it's
typically gotten a little bit bigger.
It's not one of the startups we're working with.
And now it has like seven teams building microservices and they want those
teams to run really independently.
But they also occur as an organization that their API is beautiful, is consistent
and is ideally one single thing.
So that react clients aren't calling 12 APIs.
But that's hard to organize in the sort of, in the setup you just described, Phil,
because there's this magical gateway, but how do I add new routes to it?
Like what's the process to do that?
So if you can, if you can create it, so it's very self-serve
for the engineers inside those organizations to add new route.
They can just go and clone the gateway, have their own copy of it that they
run with, add in a bunch of new routes, and then there is a process
by which that goes to production that the architects or the, the leadership
still feel like they can manage.
Then that, um, then we feel like that's a win-win.
And that's actually one of the things where, where folks are really
excited about zpa, it's one of the, the main wins we ways we win deals
with like medium sized businesses.
Does that make sense?
Track 1: Yeah, that makes sense.
Um, I'd like to ask Giant, uh, never-ending questions that
are mostly just statements.
mike_bifulco: So I've definitely found your outreach strategy interesting.
And it's been cool to see, uh, Zulo showing up at, um, various
events and bringing , content to conferences and things like that.
Um, I'd imagine education is a big part of this and, and trying to
figure out how to, uh, make the call to API developers that this is
something that they should consider.
Is there like a segment of the market, a way that you're trying to identify
sort of, uh, API devs who, who you should be talking to, or devs who
don't consider themselves API devs who, uh, you know, should be spun
up on this sort of information?
josh_twist: I wish I had a better answer to this.
Not yet.
We're, we're really kind of exploring that still.
You know, we're, we're kind of early.
People are finding us by one means or another.
Um, some of our sponsorships, like the one we're doing with you
folks, you know, is, is great.
Uh, uh, so sort of our sort of just talking startup business for anyone
trying to build something like this, you know, one of our initial strategies
was we were just doing cold outreach and hitting people with like emails and
trying to sense when they might be ripe to be thinking about an API gateway.
And then, you know, that's hard because.
Um, if someone's already got Apigee or Cong or something, you are not
just gonna send 'em an email that's gonna make them, you know what?
I changed my mind.
Let's, let's uninstall this thing and let's replace it with Zpl.
That's just not gonna, you know, that's not gonna happen easily.
Um, so you've gotta time it where they're already thinking about that.
And that's like shooting arrows into the woods with a blindfold on at
night and hoping to hit some prey.
Um, um, weird analogy for a vegan, but okay.
. Um, so then we said, maybe a better analogy is actually we, we go and put
trip wires out, um, around the forest where we think these people are running.
And so, like, you know, we did, we'd done a bunch of content around
rate limiting, around sponsoring, uh, spaces where people work.
Like, uh, we've had a successful sponsorship with, um, have
you seen Jason Schema?
Um, by Jack Wooden.
Um, so yeah, that's a, a really cool online designer if you wanna design
Jason's schema documents using a tool.
So we sponsor that.
We've had a great relationship with them.
There's another developer portal, an open source developer portal
called Raddock that we sponsor.
Um, uh, because again, like people in that area might be starting to think about like
maturing how they're approaching APIs.
So they'll, they'll see zulo, the, the sponsorship we've done
with you folks@openapi.tools.
That's, that's one of the ways we're trying to reach out to people.
But I think we're just beginning.
Um, some of the stuff we've done, um, is creating YouTube content,
um, for super based developers.
You know, this idea that if you're working on super base and you suddenly
going, how do I build an API out of this that's actually feels like an
api that's like not, not rest over data, which is what you kind of get
with, um, Postgres, I think they're using, um, I want it to feel custom.
So all zla can be a very easy gateway.
On top of that, that's a dot.
So we made a bunch of content for that, which has gone great for us.
Um, so we're still, we're still really finding our way of doing it.
I don't, I won't say we've cracked it yet, but, um,
mike_bifulco: Yeah, sure.
I, I feel like you, um, you laid out the, the breadcrumb for me earlier
that I feel like you should be writing an incendiary blog poster, making a
YouTube video that has a title, something along the lines of like, use Effect
is costing you money, uh, and, and go publish that on the web and you'll
get a billion
josh_twist: making notes here right now.
mike_bifulco: for sure.
Yeah.
You can put me on the byline for that one if you want, but I, I like,
those are the sorts of things that people don't realize, you know?
Uh, and, but it does give people's attention.
They know they're having problems with use effect doing, you know, rendering a
billion times or whatever the case is.
But, uh, they, they don't often have the solution to that, and that's why
you find the same four Stack overflow threads that are, you know, as
condescending as Stack Overflow can be.
Uh, and, and as unfriendly as you could, you might imagine.
josh_twist: Yeah, actually a great chance for a plug.
We're actually trying to hire a developer relations developer advocate right now.
Our first, a full-time developer advocate would be creating
lots of content like this.
So if anyone listening to the podcast is interested, you know,
where to, you know, where to go.
Hope you guys don't mind me sneaking that in there.
Um, we did do one in, oh, sorry.
One interesting article that again was, was quite popular when we designed our
api I key, um, service like the, the fact, the fact that you can sort of
add API I key authentication to an api.
We did a lot of research, like how do people do this?
You know, we, even though I worked, they're poured over stripes implementation
cuz they're still sort of seen as the gold standard, I think of like APIs.
Actually, I, I'd be curious on what you guys think is the best today.
You know, we looked at Twilio, we looked at the same group, we looked at
all these companies, looked at GitHub and we're like, how do they do it?
What are the rules?
What are the best practices?
And so we thought, you know, it'd be, even though it's kind of IP for us
really in a way that research and that knowledge, we thought, well, let's write
it up in a really detailed article.
And share that knowledge with folks.
It might mean they don't use zoo PLO when they go and build it themselves.
It's fine.
Go and do that.
You know?
But also people may hopefully, um, see us as someone who's sort of, you know, done
some thought leadership in this space and, and potentially will come and use us as
a solution so they don't have to build that stuff and manage it all themselves.
And that, that went well.
And we'll keep doing things like that.
Like the way, one of the things that Unico Zulo is it runs at the edge.
So it's not, it's not, you know, it's not, um, an engine X or an Envoy Fork.
This is built from the ground up.
We had to build this thing from scratch pretty much.
And, uh, so we run on edge compute like CloudFlare and Fastly and Dino Ploy, if
you've heard of those folks using sort of, um, JavaScript, um, worker technology.
And there are some hard, there are some hard lessons for someone if you do that
for the first time and try and build like, real infrastructure on the edge.
It's just, it's just different, you know?
How do you do rate limiting in a consistent way if
there are 250 data centers?
Each with a thousand processes in it.
I mean, how does that work?
Right?
So we have spent a lot of time solving that problem.
Um, and, um, and yeah, we'll be willing to, I just haven't got
around to writing it up yet.
We'll be willing to share our learnings though, and hope that like, you know,
we're seen as like, oh, these guys are real experts at this, so maybe we should
just use them versus try and roll around
Track 1: writing.
Yeah, that's a brilliant segue.
You, you don't wanna roll your own.
So you want to use something like an API gateway that will, that will handle
something like authentication for you, but you have just rolled your own
josh_twist: I'm caught here.
. The, the, because it's edge technology, there isn't really
much we could have built on.
I mean, we, we probably would've done, I mean, we used a few open source libraries
that were compatible with workers, but you know, things like N Engine X and Envoy,
they are designed to run like on native.
Hardware with access to like file systems and, and you just don't have
that in this, in this technology.
You know, there's a bunch of advantages though.
Um, and so we deliberately made a trade off.
We said like, what, what does the best gateway in the world look like?
It's like, well, it runs at the edge, obviously.
So if you use caching, like, like, uh, Actually the, the cashing trick we did
Phil, was we were cashing in the edge.
So when you made your second request, uh, request, when when we did that,
it was still making a request.
We didn't set the cash outs.
We can do that too.
Um, but in that case it's just, we just kept it there on that worker.
So if you'd have had two clients, would that two browsers request that
they'd have both received the cashed version from the edge so that it's
not just a question of browser cash, we can actually use server caching as
well, like a bit like a cdn, right?
Cause that's what the edge is good at.
And so that means everybody gets a 50 millisecond response time
wherever they are in the world.
Um, so there's lots of advantages to building a, a gateway at the edge.
And that's why we decided to sort of take a risk and, and build our own.
We would've happily used something else.
I think if there'd have been something suitable, but we didn't find anything.
Track 1: something .Yeah, fair enough.
It's, um, that's just always the, the tough one, I think.
Yeah.
Trying to find the balance of like using a few open source libraries to, to, to
josh_twist: and we do like credit to people like, uh, path to RegX, which is
the, the open source library, uh, that powers like express JS in node happens
to be compatible with worker technology.
So we use that for our routing.
Nobody wants to write that stuff again.
That's a really great library.
Um, although actually I think there's one shipping now is a standard called
URL patent, which is super interesting.
So we'll probably move over to that at some point.
It's actually based on Pat RegX, but it's actually part of the, the, like it's on,
um, uh, which, who owns the standard?
I'm not sure, but it's on MDN and I E T F and all that stuff.
So yeah, it's, it's actually shipping as part of browsers.
Track 1: And so something else, uh, obviously we're big fans of Open API here.
I bang on about it all the time, um, for some reason.
And, uh, you mentioned there's a little bit of open API coming to
to
Zulo.
josh_twist: a backstory actually.
So I have a sort of a love-hate relationship with Open api cuz when
it, when I first encountered it was when I was working on API management in
like 2013, I think it was still called Swagger and it was a burgeoning standard.
It wasn't very popular.
And then I went away from the space and I came back to build Zulo,
having not worked on a specific gateway for a while and still had
this image in my mind of open api.
And um, we, we started out, when we built Zulo, we have a routing file,
um, that's adjacent structure that tells us how to route your request.
And we initially thought, should we make that open api?
And we decided not to, you know, we thought we should own the standard.
And what we do is we build an import for open API so it would
import the file and convert it into.
Standard format.
And what we've just seen is when, when people come into the product, they
click that import open API button first.
Um, the, the, since I last spent time in the space, the, the perspective on Open
API and just how useful it is and how broadly adopt it is has really changed.
And so we really into embracing that.
Like we love embracing standards if they're working well, you know, we just
shipped actually, um, uh, all of the standard error responses from ZULO now
come as, um, uh, problem details, which is a new it I E T F 7 8 0 7 I think it is.
Uh, friends of yours I'm sure like Eric Wild and Gang,
uh, who, who worked on that.
So we, we shipped that recently.
Saw all our standards are are problem, but h B.
and then we're like, how do we lean more into open api?
Because this is a great community, it's our people and, uh, we think we
can do something really specialist.
We're actually moving our routing file to be completely based on open api and
we're just gonna use vendor extensions to, um, to essentially plug in the things
that are zulo specific to open api.
And there's a couple of things we're doing with that as well.
So one is you can then import.
So if you have like your public open API doc or your primary,
you can import that to zulo.
And what we'll do is we'll take everything that's not Zulo specific and overwrite it.
and then we'll just keep the zulo specific stuff for you so that you have
kind of a really seamless workflow.
You know, I've, I've been told, um, I was actually checking to someone
from another open API focus company called cusk, which is kind of a
open source, uh, open API gateway based on Envoy for, for Kubernetes.
And you know, lots and lots of stories of people trying to write generators to
generate a format for Kong or ambassador or something based on open a p i.
And I think you can really change the workflow if you just actually
make the whole thing native that way.
So we're pretty close to shipping that, that soon.
mike_bifulco: Yeah, I think that's, uh, a, a good thing
to, to see the support coming.
I think we have found sort of the same thing, right?
Like our audience, the people that we talk to, uh, generally are coming
to us from some sort of, uh, search term that looks a whole lot like
open API plus something, right?
Like how do I x with open api?
And I think that's a signal that, uh, there's been a real change in, uh, the
way those thing, the, the, you know, the developer marketplace has kind
of followed over the past, gosh, I don't know, maybe six or seven years
since things have really changed.
Uh, and we're, we're having less and less to tell people to call it open
API and not swagger to, to that point.
Which I think is one of those things that was a bug bear, you know,
a few years ago and has less and less, um, been an issue for us.
josh_twist: Yeah, I don't bump into swagger that much now, actually.
The word, um, I don't know if that's, I'm just hanging around
with the wrong people I'm hanging around with, with people like you.
So, so you're all such fans of the, of the platform, but it is awesome and,
you know, people like Darryl Miller, who I missed narrowly when he worked
on Azure, came into work on Azure API management, I think super open to, to
collaborating and, and, you know, gi giving advice, people like Kevin, uh,
Schwaber, uh, and so on have helped us understand how we can do this better.
So, yeah, it's cool.
Track 1: And Darryl, who also is currently, um, maintaining open api.tools.
Um, cuz we both are a smidge busy.
It's really funny, it's really funny having, um, people who work for
some of the tools listed on there.
Um, because yeah, I mean e even stoplight was saying like, Hey,
why don't you put us at the top?
I'm like, no, I'm not doing that.
there's, there's always, I don't think it's particularly serious, but um,
yeah, there's, there's always that like, perception of, uh, of being biased.
And so no, we, we, we have all the tools on there and yeah, it's not,
it's not suddenly only Microsoft tools listed on that website.
So
josh_twist: it is the downside of picking a company with the name Z When you go
into these catalogs, like we're always the last entry on all of these things.
And we honored it.
When I, when I made the poll request to open api.tools, I was like,
I, I see what they're doing here.
I'm not gonna, I'm not gonna disrespect that.
Can I ask you guys a question?
Is that loud?
mike_bifulco: away.
Track 1: Can I
josh_twist: have you seen, since we're talking about open api, uh, Microsoft,
I dunno if they just announced it, but I just came across it on a blog
post, this thing called cattle.
Track 1: don't think just
josh_twist: C a d L.
Um, and it's a new a, oh, I've caught you out.
Sorry.
I thought you might have seen
it.
I didn't mean
Track 1: it's Yeah, yeah.
I've, I haven't looked into it too much.
Um, isn't that the API design language that Darryl's been talking about yet?
So we haven't talked about that on here yet, but I think it's a really
interesting idea because Darryl's basically talking about how, um,
currently open API is, is being used.
I call it an API description language.
That's fairly standard language at this point, although people call it all sorts
of stuff an a API description and you can, and, and he's saying that it's not very
useful for designing an API that will.
right.
So the way I've, I've said it is you can describe the A API that you would
like as well as you can describe the A API that you already have.
But Darryl suggesting that it's a very terse open API is a very terse
way of describing what you would like and you immediately get bogged down
with implementation details like paths and headers and the names of query
strings and, and everything else.
Whereas you probably want to kind of plan something maybe in a bit more
of a shorthand, like scratch notes kind of way is the understanding.
I've not looked into the
josh_twist: Yeah, no, I mean, we, we played with it just the last
few days and we're super impressed.
It's like, it's nice, it's very terse, it's very sort of short.
Um, and then you can generate an open API document from that.
Um, so I think it's an exciting development.
We're, we're not sort of planning on jumping into it too deeply at any point.
Um, but I think the great things about these is, and the reason why
we we'd pick Open API is, is there's just so much else going on in that
ecosystem, you know, from spectral.
So when we wanna build this lintering, it's like we could just lean on the
shoulders of, of stand on the shoulders of giants that are, and um, you know,
all of the things that folks can do with open API that just make it great.
Track 1: Yeah, you gotta take a look at some of those rule sets I was doing, um,
in, in between tree planting seasons, I went back to stoplight for a little bit.
They gave me a bit of extra, extra income cuz uh, yeah, when there's no trees to
plant, I'm like, wait, what am I doing?
Um, And um, yeah, they had me build a whole bunch of raw sets and so I,
one of them was the, uh, spectral OWA set, which is quite a fun one.
And it just, it tries to take a swing as many of the owas as it possibly can.
Um, so you could just bake that one in there, like have, have a, do a quick
check and go, um, that'll get you hacked, mate, you know, just by looking
josh_twist: No, that sounds great.
And I'm definitely gonna, uh, uh, uh, I think there was something else you
mentioned actually the other day when we chatted, um, that I wanna, I want
to come and knock on your door as we, as we start to work on that problem.
So,
uh, but yeah, no.
Track 1: Mm Oh yeah.
Things like, um, adding, um, request validation and kind of response
validation, aka a contract testing.
Um, yeah, those things, I mean the, there's just so much you can do.
Once you have open API as your source of truth, you can then do, you know, if,
even if your tool isn't trying to touch every single vertical in the entirety
of the APA lifecycle, you can just kind of send people off to the tools that do.
Um, so it's, it's kind of why I was asking about how the Open API would work.
I remember talking to, I think it was Kong and I think Tik were quite similar a
couple of years ago, and they were like, oh yeah, we've added open API support.
There's this one text box that you can pay something into.
And I was like, and then what?
They're like, no, that's it.
Oh, like So like the idea that you just have this open API in
one file that's incorrect and that you, you know, at some point you're
done with it, that's incorrect.
Um, there, there's all these kind of, uh, data assumptions about it and.
. So yeah, the fact that you are kind of aware that it's an evolving thing
over time and can live and get and can be updated with pool requests
and can, can integrate and hand off with, with other parts and other tools
to do different bits of it better.
Like that's the beauty of using a standard whether you like it or not.
josh_twist: Phil.
Yeah, the one, one other thing we, we really love about it is if, if
we go open API first, cuz actually there's a couple of, you know,
there's a couple of customers using a zoo aren't particularly open api.
They're just trying to get something out the door.
But, so they've gone in and they've used our route designer,
you know, that you, you mentioned earlier, Now in the background that
is generating an open API file.
Now it's not very fancy.
It's not, you know, it's not, it's not as good as an open API file.
You'll get out a stoplight or something.
Um, but it's a good beginning.
You're like off to the races.
And then if you start to customize the developer portal that we give
you, you know, again, not all of the customers use our developer portal.
Some folks say they're happy with readme or you know, reoc, all those folks.
And again, we're fine with that.
That's absolutely fine.
Um, but I love that now that you know, that, that people are
automatically just getting something, it's like some extra value for free.
They might not know it yet, but they will in a year's time when they wanna
start linking that a p i and they've got open a api, I, or they wanna
start, does doing a API I design first.
It's like, oh, well great, we've already got this in Zulo and we know
it's the truth cuz it is the gateway that is, I know this is what's
happening cuz it defines the gateway.
Um, so we're excited about that as well.
mike_bifulco: Josh, I would love to hear what you're thinking about
in terms of other things that are coming next what are the big
things that you're thinking about?
josh_twist: I mean, I think there's a couple of trends
obviously that are interesting.
Like, I think edge compute is gonna be important.
I think we see a lot of workloads shifting.
There are, um, I haven't again, might be one for you folks to ruminate on as well.
Obviously there's some really interesting stuff going on with AI right now, like
from co-pilot to chat G P t writing your code, and I'm like, I've kind of
got one eye on that going, how is this gonna play out in the world of APIs?
And I'm not sure, I don't have a, anything intelligent to say
on that, so I'm not gonna try.
Um, but I, but I'm curious if you folks have, um, from a Zulo perspective, um,
we have a lot of ambitions about helping, um, helping companies sort of govern APIs.
But with lowercase g we talk, it, talk about it being, you know, api
again, breaking down this, this silo of the, the API gateway being.
Um, being sort of sat on a, on a, on a, in an ivory tower, on an iron throne.
Um, and so we're really looking at a lot of ways we can do that.
So there's, there's all kind of things we're being asked.
So customers are asking for, um, they want to run these tests.
We have that, we say basically make sure they, they're mostly
like smoke tests, right?
That the API they're shipping is not bulked in some way, or
they've not mis wired a route.
But then they're saying, I want to have other rules now that say someone can't
go to production unless they've written tests that give them, and I'd never
thought of this concept before, unless they have like 95% route coverage.
So, you know, we think of code
mike_bifulco: interesting.
Yeah.
josh_twist: right?
But imagine a gateway that's like, you know, you've got tests, but you're only,
you're only adding 30% of your routes.
Playing with so many percentage of parameters and leaders
in these organizations.
They wanna be hands off.
They wanna let their developers do what they do.
And so the idea of creating automated rules and so on, that, that enforce
the standards they're looking for.
So Lin is one, but this testing is another.
So we're exploring a lot of stuff like that.
Um, and you know, we're, what I like doing there is we're building it with customers.
So we're, you know, we're not, we're not inventing this, or we're sort of, there's
a customer saying, I want this, and we're building it in partnership with them.
So if anybody listening is interested in something like that, then we'll be
all ears and very open to potentially sort of partnering with you and
building it out as a POC for you.
And then we'll, we productize it basically.
mike_bifulco: Sure.
Yeah.
I think that's fascinating.
gosh, uh, I guess I'm gonna admit to this on a recording, but I would
identify myself as someone who spent a disproportionate amount of time poking at
AI to see what's actually going on there.
Uh, and, and ha have gone as far, actually, when I was at Stripe,
I was building a product with AI just to show people how to build
something using stripes, APIs, right.
And sort of like a menial product that doesn't do anything, uh, earth shattering.
But as a result, got me going down every rabbit hole under the
sun, trying to find things out.
Um, and I, I think from a generative code based.
Thing.
The, the things that strikes me that AI and APIs might get really interesting
are things like writing better tests and writing better documentation.
Uh, because it's pretty good at that.
You can, you can, uh, have it sort of intro, spec, um, a bit of code and say
like, explain to me what this code does.
Uh, and to me, documentation is less mission critical than writing the,
the code itself in the sense that like, if you write documentation and
it's not great, it's not going to open up security holes necessarily.
Uh, so it's a good place to start from, uh, in test case just as well,
you could say, you know, write me a test case for this, that tests
a dozen different ways that zip codes might not work for, you know,
validation or whatever the case may be.
Uh, and that ends up being pretty quick.
Um, I've also found it to be invaluable for learning.
So, uh, if, if it was something like, explain to me how to do this with, uh,
you know, zola's management, uh, APIs or something like that, it's good at that.
Would I trust it to build a bank for me?
Probably not anytime soon.
You know, that's a different story.
But, um, the, it's the, it's the, I don't know, the liminal space between, uh,
the, the actual creation of something and connecting it to other things that
I think AI is very good at right now.
Um, I will also say, I'm on the record saying I think AI is
pretty dangerous because it looks authoritative when it isn't always.
Uh, and I'll, I'll drop a, I'll link in the notes.
I'll send it to you as well, Josh, about one
josh_twist: hallucination they call it or something where it's like, um,
halluc, is that the name I've seen?
Yeah.
I mean, I've been following it.
I'm, I'm really interested in it actually.
I thought it was a great answer that Mike, actually, the idea of
testing seems like a really, I, that, that's another startup almost.
Right?
Someone should just go and do that, like build an API testing
company that, that is AI generative.
Um,
Track 1: when it comes to documentation, I'm not sure.
Um, I mean with most open APA documentation, it's like
peram user ID description, the
josh_twist: that's like the,
it's like those comments that say, you know, the comments say
the same thing as the function.
It's like, this is the request parameter and this is the food parameter.
And you're like, yeah, thanks for the
comments.
So you don't want documentation like that?
mike_bifulco: Yeah,
well, it'll save you a bunch of keystrokes in writing the
JS doc that surrounds your thing or, you know, the, the
Ruby equivalent or whatever.
Um, I, I will say I need to caveat this with the most important AI story I have,
which is, um, early on, in early days, I was trying to see if I could get AI
to generate an interesting blog post for me about, uh, human psychology, like a
thing that I found really interesting.
And so I plugged this stuff into, uh, um, uh, open AI open api.
Yeah.
Gosh, now I'm getting all crossfire open AI's, uh, G P T A api.
Right.
And I asked it to write me an article about this very specific,
like, psychological thing, and it wrote me a story and cited
a marketing case study from.
, uh, yellow Tail wine and it said Yellow Tail Wine did all this stuff
and here's how they made a billion dollars with this marketing campaign.
And like came up with examples and all these other things.
And I went to look up the campaign that they had cuz it was , a um, campaign
where they were bashing themselves.
Basically the campaign was called Yellow Tail Wine Tastes like Crap, right?
And that was like the whole thing.
And, and the AI out of thin air completely made up this entire case.
Study cited numbers provided, uh, names of campaigns and things like that.
And near, as I can tell, it never existed.
Track 1: Yeah, that's a known thing.
It just makes up citations.
Like all of the scientific, all of the scientific studies and like all
of the researchers and all of the psychology, like all of the citations
are invented for no apparent reason, but it's always like, Three random white
dude names with like, you know, middle initials to make it sound intelligent,
but done from the University of
josh_twist: amazing.
I've seen some examples of hallucination where like, it's getting some stuff
wrong or some like obvious math problem wrong, but I've not seen anything
that, that sort of elaborate where it looks almost like deliberately
fraudulent, you know, with like citation.
I hadn't seen that.
I wonder what the, the phenomenon that's actually occurring there
must be fascinating to someone who understands how this stuff
works.
Track 1: there's a, there's a thing.
I can't remember what it was, but it's like intentional.
They have some particular reason for intentionally making
up citations.
I
josh_twist: Wow.
Okay, well I've got some reading material here myself.
These are great show notes for me and I'm on the show.
That's awesome.
Track 1: some, yeah.
I'm also wondering if the open AI G P T API has an
open api.
That's the most important question here.
josh_twist: That is the hardest sentence that has ever been
successfully said in a first take ever
Track 1: ever.
I honestly don't know how I said that.
I
am
shocked and impressed,
josh_twist: done.
Yeah, no.
I wonder if they do.
I know they use Off zero actually.
They're not using Zulo.
Not yet.
Maybe, uh, maybe, uh, if anyone has a connection with Sam, we
can um, we can get 'em over.
Um, Yeah.
mike_bifulco: So the, the one thing I feel like I would be, um, remiss,
uh, if I didn't ask you Josh, is for developers who are building API
products and, uh, building API projects as side hobbies, things like that.
Um, where do you go for news?
Where do you go to look for things, uh, that are not APIs you won't
hate.com, uh, or open api.tools?
Like how do you keep your eyes on what's coming and how do you know,
um, you know, when, when changes are coming, like edge compute
and things like that?
josh_twist: Yeah, I, I'm not super strategic about this, sadly.
I wish I had a better answer to this question.
I mean, I spend a bit of time on hacking news.
I just, it'll be like the obvious places, you know, um, often I'm looking
for, I, I, I probably, it just comes across my path now cause of what I do.
Like someone on the team's gonna send it to me or something so that I, I kind of
have like a bunch of curation happening.
I proactively spend time where I think people will be,
Asking questions about this.
So, you know, I recently found, I hadn't seen this before, I was kind of amazed.
There's this site called Indie Hackers.
I dunno if you know it, I think it's created by someone at Stripe actually.
Um, and that's a great place for conversations if I'm from thinking
about what are the problems those people are trying to solve.
So I'm, I'm a bit more strategic about trying to go out there and discover
the things people are talking about, the problems they're trying to solve.
Cause that's, I think, that's where I can come in and add value.
Um, I'm not super good at keeping up with, um, with, uh, all the latest trends.
I follow the usual people, Ken Lane, you know, uh, Kevin Sch fiber, you guys, um,
you know, I, I probably could share a list of, of people I enjoy, uh, Kenneth
Thunberg, um, these folks, and they tend to flag, flag things I'm interested in.
But yeah, that's, that's
my, I'm not super strategic
mike_bifulco: Sure.
Um, well, that's reasonable to me.
My, um, I've, I've abandoned Twitter somewhat recently, and so I've been having
to look in different places for, uh, you know, expertise and learning and all that.
And apart from having Phil send me a link every now and again to something that,
you know, uh, learns me this and that, uh, I've, I've really had to change, like
my, my behaviors and places I've gotten to learn are really changing lately.
So,
yeah.
josh_twist: You're on
mike_bifulco: I am, yeah.
josh_twist: I, someone needs to teach me how to use it.
That's the only problem.
I, uh, I'm, I'm hit by that wall of like, it's bowser level one problem, right.
That we talked about before.
It is tricky, but, uh, I, the, the, you feel the reward is
there.
It's worth it.
mike_bifulco: Um, I'm not sure.
Uh, I, I will say I benefited quite a bit.
Early days when I first moved over last summer.
Uh, someone who was touting themselves as, uh, mastodons, unofficial
Derell, uh, was posting some really great tutorials on how to mastodon
correctly, and that was really useful.
Um, I've, I've, um, really just kind of turned down the taps on all of that
for myself, like less, less mastered on than I was doing on Twitter.
I've started posting on LinkedIn and I really don't like it.
Uh, it's just not like the, the kind of place that's validating
for sort of expertise I seek.
Um, and so like, I don't know, Google blogs, things like
that, or, or podcasts, right?
Or where a lot of my learning comes from YouTube disproportionately too.
josh_twist: Yeah,
Track 1: Yeah, I don't know where I would go to to be able
to just be the same person.
My, my, the people that follow me now are the most weird collection
of people of like hardcore old school PHP nerds and API nerds.
And then more recently, like a bunch of counselors who are like, mostly
are like trying to get me to help them remove invasive species from
their woodland around the corner.
And I'm just effing and blinding and banging on about computers and then
getting really nerdy about
josh_twist: might be the way this Twitter stream might follow.
Actually, it's definitely up there.
It's like, why am I following this guy again?
What's here,
Track 1: this guy again.
josh_twist: It's good content.
It's just random.
It's
just out there,
Track 1: here's me showing you
how to fix a, a, a flat tire by shoving grass in there.
And then next, like, it's just, there's such a weird
mixture of stuff.
mike_bifulco: Yeah, Phil, I routinely tell people that you are, uh, the,
the, the person I know with the highest talent for telling people when to go fuck
off, uh, and exactly why they're wrong.
Uh, and, and I want to channel some more of that in my life,
for sure.
Track 1: Well,
I'm currently getting into an argument with a whole bunch of
people cuz the Wildlife Trust and HS two, the high speed rail line.
Um, I just tweeted and said they're both going at each other like an
overserved hen party fighting over who gets to hold the inflatable cock.
Um, and they, uh, yeah that's super professional off me
mike_bifulco: Oh, we all have something to learn from you, Phil.
I think
josh_twist: I think there's a training course there, a Udemy
course on, on, on the skill.
You described that Phil has like a, like a, a self-help course
and um, there's a book like that.
How to Give
Less.
Track 1: Anyway, that, That's probably about time to call it a
day .Cause it's just, it's just send it into nonsense that
that
that always
happens at
mike_bifulco: Josh, where can our listeners find you and where
can they find
Zulo?
josh_twist: Uh, they can find me on Twitter.
I'm not super active.
Um, uh, Josh Twist, they can find zulo on Twitter as well
at zulo, um, and uh, zulo.com.
Um, I'm super chatty, so you can email me@joshzulo.com as well, and
I will almost certainly respond.
So yeah, um, reach out, say hi.
Those are easy places to find me.
I'm on LinkedIn as well though,
Mike.
Uh, , that's a thing.
Track 1: make
mike_bifulco: Perfect.
I'll, I'll send you my, uh, list of 10 things I do to make my
josh_twist: There we go.
mike_bifulco: on LinkedIn.
Uh, you also mentioned before that you're hiring for at least one role.
Where's the place to go for that?
josh_twist: Uh, you can actually just email, just email josh zulo.com if
you're, if you're interested in the developer advocate role, um, it, it is
on our website, um, listed as a role too.
You can email jobs zulo.com as well, but I'll be person looking
at 'em, so, so
yeah, get in
touch.
mike_bifulco: Perfect.
Well, thanks so much for your time.
It was wonderful chatting with you.
And thanks for, uh, your sponsorship as
josh_twist: Yeah,
Track 1: your talk.
Yeah, thank you
josh_twist: Yeah, I had a laugh.
That's great.
Thanks folks.