Ep. #56, Simpler Deployment with Joseph Cooper of KintoHub

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Joseph Cooper.

Joseph Cooper: Hey, how's it going?

Brian: Good, and you're calling in from Hong Kong. Do you want to tell us why you're here and what you do?

Joseph: Yeah, sure, sure. So, I mean, always been a fan of the JAMstack and, essentially, we did a viral piece and an open source piece around JAMstack, so definitely want to talk about that. And then I've also got a startup that I'm promoting, KintoHub, as well.

Brian: Cool, let's talk about what KintoHub is first.

Joseph: Yeah, yeah, so KintoHub, so what we're doing is that we are focusing on making it simple to deploy and debug full-stack apps in the cloud.

And when I say that, like full-stack, I'm talking' about a front-end website, a back-end API, and then some sort of database, be it like MongoDB, etc.

The reason why I think this is kind of important is because Heroku, about a decade ago, did a great job abstracting Amazon. Amazon was a lot more complex back in the day and with Heroku and other providers, now Netlify it makes it dead simple to be able to get that stuff and your apps into the cloud.

But, once your app gets a little more too complex and you need a database or things need to scale, and costs get outta hand, you leave Heroku and then you just go use Kubernetes and the cloud-native offerings and Amazon, Google, Azure, etc.

Brian: Yeah, so most companies end up growing out of the simple solutions, and into something a little more complicated?

Joseph: Yeah, exactly, and usually want a little more control, and then it's usually a cost thing.

The average person I hear that leaves those platforms is 'cause of the cost thing, or control.

Brian: So KintoHub's really aiming to just be an interface for cloud providers.

Joseph: We're not trying to do the next-gen cloud provider itself, and we're doing this by abstracting the powerful features that cloud providers already provide or, in the cloud-native space and Kubernetes space.

And then when we don't abstract it, we give our users the ability to control the infrastructure with these things called Helm Charts.

So it's really our thesis to be able to still get your full control, or use very clean dashboard abstraction of the cloud.

Brian: Okay, so I guess the life cycle is that you have a simple solution that someone could actually scale and grow with. Is that I guess the pitch to anybody interested in taking Kinto for a spin?

Joseph: Yeah, exactly, so if you like the Heroku or the abstracted cloud provider space, the simple cloud space, but you still want the power of Amazon, Google, Azure, before you jump over to their ships, take a peek at KintoHub.

Brian: Excellent, yeah. I personally am a fan of all those other things you had mentioned.

I come from the Amazon world, the AWS world, I saw that product grow and grow and grow into something that, it's a little overwhelming for someone new approaching it, but there's some other stuff, I'm not as familar with the Azure platform as well, so I tend to just stick to what I know.

And what I know is, either the one-click Heroku, Netlify's--

I appreciate tools like Kinto that can expand my breadth of what I touch to approach deploying applications.

Can we dig a little deeper into the post that you guys actually came out on the news stack? And how this is related to the JAMstack?

Joseph: Yeah definitely, yeah.

So what we did is, when COVID-19 hit, and we were one of the first to get hit, outside of China, being here in Hong Kong, one of our colleagues wanted to create an app to get the most recent information about COVID.

That information might be hospital queues. If you go to a certain hospital, how long would it take for you to see a doctor.

Maybe it's about, is there toilet paper available around the corner?

And then all the cases that have happened in your neighborhood. Because, here, you can be living with a thousand people in one single apartment complex.

If your building got hit, you can know about that.

So this data's all publicly available by the government, and we knew that there would be a high demand for such an app to look at what's going on, so we were thinking about, how do you create a solution that is super cost-efficient?

And that's where we were looking' at the JAMstack and CDN's, because, once you search something like Cloudflare, as a static website, then it's pretty much free, you could serve that millions of times and you're not paying the infrastructure costs and the server costs.

So what we did is we used Gatsby to scrape this data.

We created a job on KintoHub that runs every five minutes, that collects this data from the government, and then we rebuild a Gatsby website with the most recent data, every five minutes, and push it to Cloudflare.

Then we got about three million visitors within a four-week time span, and it costed us zero dollars.

So that's what the whole post was about. We open sourced the entire solution, and actually a couple other countries have picked it up and started using' it.

Brian: That's pretty nice. Actually, Gatsby's incremental build, did you leverage that, or did that come in after this project?

Joseph: I think it might have came in after, and we wanted to see how Kinto fit into the play as well, so we used the job system within KintoHub to re-trigger new builds every five minutes.

What is incremental builds?

Brian: Yeah, so basically, similar to have when you take a DIF in Git, it only affects the things that you actually have changed.

So very similar to incremental builds, if there's a page that has changed, it only builds that page--

Joseph: Oh, interesting.

Brian: As opposed to the entire project.

Hopefully I didn't butcher that, for anybody who works at Gatsby or have already been using it.

I've only just written a couple blog posts. Saw Wes Boss actually started using Gatsby as well. Essentially that.

I could see, every five minutes, though, does it not getting too expensive if you're--

Joseph: Yeah, we got the build times using, it gets kind of crazy with what's underneath the hood at Kinto, but I'm using Kaniko, we're able to do a lot of caching, in the Gatsby layers of a Docker cache.

So really, we're only rebuilding a very small piece of it, and our build times are around a minute and a half for that. But yeah, standard gas people's could actually be pretty big, so I could see how that feature could help out a lot. Minute and a half, builds every five minutes, and we just pull the latest data from the government so that it looks like a realtime website or a up-to-date website, but, really, it's just a static website.

Brian: Yeah, that's pretty clever. I've done a lot of tinkering with public API's, to support some of my needs for side projects.

You're from the Bay Area, originally, so you know about the BART.

I was riding the BART pretty regularly, up until recent changes.

Being on a BART, you just naturally, it's like, "I'm going to build an app, so I can figure out how to avoid certain situations on the BART."

Ben Ilegbodu, who's now at Stitch Fix, he built an app called Bart Salmon, so he was like an engineer there.

But, because he lives in the last stop, which is Pittsburgh, he's got a lot of time to kill while he's on the BART, so he might as well get on the train that he could sit down on.

So he built an app where it just tells him when the next train's coming, and if it's worth going to the next stop up the chain, to get a seat.

Joseph: Oh, interesting.

Joseph: If you're going to get on at Montgomery, maybe take the chance and go up to 24th Street or go up to Mission, and then take it back down, because you'll get a seat at the Mission, but you won't get a seat at Montgomery Street.

Joseph: Nice.

Brian: It's a nice little app, I'm not sure, as far as how he was supporting it, we didn't go into detail, so like what servers he's writing on it, but, if I were to take that idea and I wanted to scrape the BART API and get me closer to realtime data, or some sort of socket, 'cause I don't think the BART API actually gives that to you.

It sounds like I can sort of fake that I have an open web socket, that's giving me information, at least within five minutes.

I'm curious about Kinto, can I set a few cron jobs? 'Cause I imagine if I wanted to set a cron job that hit only during rush hour, pretty heavily, are you able to batch some cron jobs together, to also maybe increase the rate at which you're deploying at?

Joseph: No, right now we haven't supported any dynamic changing of times, of maybe during the evenings you do every five minutes, and then, during down time at night, maybe you do it every hour or something like that.

So yeah, we haven't done anything dynamic like that, but you could maybe schedule your cron jobs at a specific time.

At least if you wanted to hack it today, you could say that I want these jobs to run at this time, this time, this time, between 5:00 and 7:00.

And then I want it to be at this kind of schedule, between midnight and 6:00 A.M., kind of thing.

So you could say a specific time versus a recurring time, on Kinto as well.

Brian: Excellent. I'm also curious, as I did some prep to look at the project, there's a lot of words that I'm not familiar with, but also a ton of words that I am familiar with.

Me as a lame person who has done a lot of frontend, in the past couple years, I'm familiar with Heroku, I've done some rail servers and Python stuff, but when you start talking about Docker and Kubernetes and Orchestration, that's where I start getting lost, and I back up and I'm looking for different solutions, to give me an easier way.

I think the space is now really developing, when we talk about cloud-native and a lot of these Orchestration pieces.

So I'm curious, is KintoHub, is it a solution for someone like myself who perhaps can build a website, but can't build a website to scale because I lack the knowledge of all that infrastructure?

Joseph: Yeah, that's the goal. What we're trying to do is, do it in a way that isn't opinionated, so you could come with any language, any framework, you don't have to switch your code to Lambda or do something special or different. But at the same time, we don't want to take too much control.

So let's say that, yes, if you go to KintoHub today and you just need a new website and you want to put it up and put it on a CDN and get an SSL certificate really easily, yeah KintoHub does that. If you want a back-end API, or Ruby instance, and you want to be able to scale that horizontally, you could do that within a few clicks without learning anything about load balancers or any of the stuff to take autoscale up. But then there's that moment where you're like, 'I need a database, and I want it to be super production grade.'

'I want a MongoDB replica set with five different instances, etc., which might go outside of your domain name, but, maybe for more serious, larger apps or teams, they might want that control, and that's where the whole Docker and Helm exposition comes.

So if you do want to control your containers, you could bring your own Docker file.

If you do want to set up a much more complex containerized system, and multi container setup, you could bring Helm charts. So that's the offering that we're doing.

Brian: Interesting. Can you explain what Helm is?

I think most of our listeners are familiar with the idea of Docker, but I haven't actually heard of Helm, and know what the benefit of that product gives you.

Joseph: Cool, yeah, Helm is very similar to what the MPM, Maven, and you get the package management of actual languages is, for Kubernetes.

Brian: Gotcha.

Joseph: So, if you wanted to get a service running, even if it was just a website, running on Kubernetes, you might package that as a Helm chart, which would be the same as an MPM package.

Of the differences, you are thinking more as an infrastructure level.

So really, the DevOps world, and infrastructure engineers would use Helm charts.

It'd be very rare for a back-end or a front-end developer to transition over into that world, but it's a fun world to check out.

But Helm is probably the winner for package management in the Kubernetes space right now.

Brian: Okay, yeah, that's good to know, I appreciate you taking the time to explain that to you as well, 'cause, I've tinkered with the Kubernetes, I've literally gone through Kelsey Hightower's Kubernetes for, I want to call it "Kubernetes for dummies," but I think it's "Kubernetes The Hard Way?"

Joseph: Yeah.

Brian: But I definitely felt like a dummy, copying and pasting everything, and sort of figuring it out.

Joseph: Was that on you to see?

Brian: No, it's actually a repo that he has, under his org on GitHub.

Joseph: Cool.

Brian: If you just go to kelseyhightower/kubernetes-the-hard-way you start copying and pasting, you start generating keys and doing controllers.

I had something running, but I couldn't tell you exactly what it was.

But, I have a lot of experience in being a consumer on that end, so when I say I don't really know how to set it up, I do know how to run a Docker container, I do know how to run scripts that are given to me; in the README's and within the dock files.

I had a lot of experience, though, when I worked at Netlify, specifically.

Actually doing features for Netlify involved running a lot of that stuff, but it didn't require me for actually doing any of that work, to get that running.

That's what I fall over. I'm always intrigued to learn it, but I don't have a legit problem to solve.

If I go to approach using a new JavaScript framework, I know the problem I will be solving, to put that on the web.

But when we start talking about scaling, I don't know what the first step is to start orchestrating stuff.

So I'm curious, if I'm interested in a thing like KintoHub and using tools like this, or even a Helm, to manage some of this stuff, are there Helm worlds for things that involve some of this orchestration and DevOps stuff?

Joseph: Well, we have two things, one is we have a catalog, so we do have pre-built Helm charts that we've curated for KintoHub.

And that's all open source, so if you wanted to see what we changed, and see all the PRs and the commits and all that other stuff, it's all opensource as our catalog offering.

And then also, in our docs, underneath "quick starts," you'll be able to find all that stuff as well; how to set up a Helm chart, or even how to use different frameworks on KintoHub as well, if you wanted to do Go, PHP, Java, Ruby, you name it.

W e have a bunch of different examples, I think we hit 23 or 24 examples of how you would set that up with KintoHub.

No video tutorials yet, but probably sometime in the next month or two, we'll be doing another video series on the new version we're launching with Helm charts.

Brian: Okay, excellent. I'm a fan of reading the docs, but I'm also a fan of the videos, because if I'm looking for an answer, I can fast-forward to it.

But I know everybody learns in a different way. I'm sure somebody will appreciate having videos eventually.

Also appreciate how nice these docs looked, as well. You Django, Flash, Gen. It's like you're crossing the scope, Koa, Express, JavaScript, Python. I think Gin is a Go?

Joseph: That's Go, Gin is Go.

Brian: I remember, back in the day, it was like Negroni, was Negroni before Gin? There was something before Gin.

Joseph: I think that was the first one, and gin was kind of a play on that.

Brian: Actually, if I learned the history correctly, 'cause I learned Negroni back in the day when I was learning Go and I guess Negroni did not follow best practices for Go.

So, gin is what you would actually put in a drink. There's no gin in Negroni, if anybody cares, but yeah, I digress, anyway.

I am actually super intrigued about this.

I wasn't sure what to think about this project, but I'm super intrigued on how to get myself into DevOps World, 'cause I don't have any scaling issues today, but I know I will have, in one of the projects I'm working with.

One thing that I am aware of, that you can use Kubernetes but also Docker containers for, is things like A/B testing.

So when you start talking about load balancing, is a term you already mentioned, but being able to load balance different versions of your site to different servers, as well.

You'd mentioned Cloudflare, so I imagine there's a hook in the Cloudflare, with KintoHub? Or are you just manually shipping that?

Joseph: Yeah. We let people choose what CDN or outside host name that they want to use.

We're slowly going to give more of an opinionated option on that, where you could say you deploy your environment, and it's going to be in the U.S., it's going to be in Europe and it's going to be in Asia, and then we will automatically load balance that, based on your geo location.

So we will give you those one-click options as well, but then if you don't want to do that and you still want to control the load balancer, or what you're load balancing with, we'll give you that option too.

That's always our forte is, if you want to do it yourself, do it yourself, but there is the one-click button option, too, if you want it.

But yeah, load balancing and A/B testing is actually a pretty interesting topic, because it's really hard to do once you get a lot of different services, and what I mean by that is, I think, the preview deployments on Netlify, inside, for example, are great, and it works great for one service, if you want to preview it.

And if you wanted to do an A/B test between one service, then it's pretty cool.

But then, the moment you have a back-end API, that's version 2.0, that you want to test with a new front-end, with, maybe, a database migration.

Once things get a little funky in that sense, if you're not using MongoDB, it gets even more complex, if you have proper migration, so like, MySQL and Postgres, then you got a pretty complex problem underneath the hood. I don't think there's many solutions for that, until you get into the deep cloud-native space, with Istio and blue-green deployment, so all this other stuff, but still, it's extremely hard to accomplish.

But what I would say, if you are going to experiment with that in the near term, is LaunchDarkly is a very cool feature flag.

I believe GitHub does it all well with how they release features, they feature flag.

You really are controlling what you're exposing on the front-end, so that simplifies the problem a lot.

But it's a completely different approach to blue-green deployments.

So I usually recommend, if you want to start scratching' there, you should start with feature flagging, 'cause it's a lot more--

Brian: Yeah, yeah. That's definitely a good thing to mention too, and also this shout out to LaunchDarkly who, Edith actually co-hosts a podcast, so the CEO of LaunchDarkly co-hosts a podcast on the same network.

Joseph: Oh, nice.

Brian: So definitely check out "To Be Continuous," which is their podcast.

Joseph: Cool.

Brian: The other thing I wanted to mention too, as well, I was just taking' a peruse through your pricing page.

I didn't mention, but, when I went through the whole "Kubernetes The Hard Way"with Kelsey Hightower, one thing I did not mention is I ended up paying $80 for that.

Joseph: Oh wow.

Brian: I did it on a Friday, 'cause you know, you always try new things on Fridays while you're not really doing anything, and spun up some controllers and had some stuff running, and then I ended up pausing the tutorial and then walking away from it, over the weekend.

I was running things 24/7, sorry, well, 24 hours for the entire weekend, and then, by the time I realized it, I was like, luckily, it was the end of the month, so I ended up getting ping'd on a bill, and I was like, "Oh, that's weird. I just signed up for this thing." I got a Google Cloud account, thanks to Firebase, but.

I've been a Google Cloud member, I don't have any free credits because I've been a Cloud member, which is another "Gotcha!" So now I'm like, "Oh, wow, 79 bucks? What did I do, this must be wrong."

I ended up seeing my credit card pending charge and I was like "Ah." And then I was like, "Oh, I left that thing running."

Because, at this close to terminal, I just kept it running on my machine, never restarted it or anything like that. It was charging me, which was amazing.

Joseph: An expensive tab.

Brian: Yeah, very expensive tab.

Especially when you're doing it the wrong way like I was, where I was just copying and pasting, going through it, just learning.

I wish I was learning the terms and learning the terminology of how to approach that and build something like a load balancer, I think that's what we were focusing on in that tutorial.

But stopping that, and moving on, that's enough for me to be like, "I'm never touching this again, I will hire somebody for $800 before I actually pay $80 to do it wrong."

And getting zero dollars of value out of it.

Joseph: And hopefully they know how to do it right.

Brian: Yeah, yeah, it's not even a knock on Kelsey's tutorial, and it's not a knock on, even Kubernetes is a product in itself, but, it's more of a knock on myself that I don't have the knowledge enough to know what I need to get outta this, so it's almost like, if you don't know what you don't know, then it's almost not approachable to you; which I've felt for most of the DevOps space, outside of CI.

But when you started talking about True, DevOps and Orchestration and all this other stuff that we've covered, that's what makes this really enticing for me.

When I start thinking about, hey, I need some sort of, not fancy, but, I need some bespoke situations of how I orchestrate how my site is or my project is being delivered, I, honestly, I think you've convinced me, I'm not sure, the goal wasn't really for you to sell me on the podcast, but I'm actually really intrigued on trying this out.

And I hope the listeners gone through this journey with me.

Joseph: Yeah no, I hear you. Its been a dream for me, and it's funny that you mentioned and learned that from Kelsey as well, because I learned Kubernetes from Kelsey on the UDC.

I think it was 'Introduction to Kubernetes.

When I first started looking into this idea, back in early 2017, late 2016, I just took the course and just learned Kubernetes, and it was mind-blowing.

But then it was also costly, like you said. It's actually a crazy journey because, the Kubernetes space is the first step to cloud-native, and then when you get into the cloud-native CNCF, then you're installing all these crazy packages that cost you a lot of money.

You want to do monitoring with Prometheus, and you're doing that for months with multi-tenant servers, you're spending thousands of dollars if you don't know how to manage that data.

Just on data alone. And it takes one little configuration to say, "Hey, put it in cold storage," versus, "Put it in memory." You know what I mean?

It's crazy, the learning curve in terms of costs and this space is insane.

So that's one of the things that, of course, why you would leave, maybe Heroku or another place too, 'cause of cost, we're also trying to start with cost optimization by default, so that we do put you on a pre-emptible note or spot instance by default, so you don't have to pay for full servers and stuff like that.

Brian: Yeah, excellent. Is there anything else you wanted to cover in regards to the space?

Joseph: Yeah, definitely, we're here to help. If you do start playing with KintoHub, we have a discord channel and we're supporting people left and right there.

Always open for feedback. The early days for us, so we're just trying to keep our ears open to see what people want, and work towards that.

Brian: Excellent. Yeah, so with that being said, I want to transition us to picks, so these are JAMpicks, things that keep us going.

Could be music, movie-related, could be tech picks.

At this time, we have spent a lot of time inside, so my picks are around being inside, so if you don't mind, I'll share my first couple picks.

First one is actually, I started streaming on Twitch programming, and I think I've mentioned this a couple times, I've had a Twitch account for a while, which is my gaming tag, which is meatrobot.

I've recently switched that tag to my regular Twitter handle, so, if anybody's looking for me, @bdougieYO on Twitch, and I've been streaming twice a week for at least the last 30 days, and its been quite the experiment.

It's been a lot of fun to pull up my terminal in Visual Studio Code and just start hacking' away at some of the problems, that weren't really work-related, I just wanted to hack on something, but also get feedback. Usually on Fridays, I get a couple guys who will jump in and start chatting and giving me pointers and tips on what I'm doing wrong.

If you like to learn in the open, and learn in public, I highly recommend it; using that as an opportunity, especially if you're looking to level up.

And level up with a group or a learning club or whatever. But yeah, if you are doing a learning club on Twitch, let me know, I would love to see how that works and how to build a community around that.

The next thing I wanted to mention is tmijs. tmijs is Twitch messaging interface. It's a nice little cool API.

Actually it's not even an API, it's STK around their API. So it gives you a lot of stuff like what you would normally get in STK. But, at the moment, I'm building a chat bot, so that way anybody who shows up in my Twitch stream can do some pretty generic commands, at the moment.

Actually, I'm going to be building a 'yo'command, so that way, whenever you just type in 'yo', since my name on Twitter is bdougieYO, it actually does something a little cool.

Joseph: Nice.

Brian: As well as some other of those little Twitch interactions that a lot of people are doing.

So yeah, check out mutualfun.live, which is my new site, if you want to see all the stuff I'm working on in regards to live streaming.

So yeah, that's pretty much where I'm at for picks, but, Joseph, did you have a pick?

Joseph: Yeah, I guess I'll just do a little local here in Hong Kong, now that I've been stuck over here.

We're actually opening back up on Monday, on May the Fourth be with you. So the Punjab Club is probably one of the best Indian foods, and I lived in India for 15 months, actually, as well.

Brian: Nice.

Joseph: So Punjab Club, here in Hong Kong, just got its first Michelin star, congrats to them.

Brian: Oh, nice.

Joseph: Really amazing food. Very excited to finally go out on a date with the wifey, and we're planning on doing' that soon.

So just wanted to mention that. I guess, as I've been trying to live in the 900 square feet that I live in, here, I've been trying to start a new hobby and do other things, other than stare at the screen all day.

It's definitely harder to disconnect. So I picked up, out of all things, spinning and DJing a little bit.

Brian: Oh nice, yeah.

Joseph: So I just started a little sound cloud, DJ Milk Man, after my son, 9 months old. Yeah, I've picked up a DDJ-SX2.

Brian: That is a good pun.

Joseph: Yeah. That was his nickname, 'cause he was always just having' fun with his milk bottle. But yeah, the DDJ-SX2, really amazing controller, its been a lot of fun playing with that and the learning curve has been minimal with YouTube videos and everything, which has been great.

Brian: Who makes that controller?

Joseph: Serato.

Brian: Serato, okay, yeah, 'cause I'm actually eyeing controllers. Like yourself, I am also picking up hobbies left and right--

Joseph: Sorry to mention, it's actually a Pioneer, but it's a Serato-based Pioneer.

Brian: Okay.

Joseph: So I guess they had a partnership or something, but both their logos are on it.

Brian: Yeah. And at this point, a lot of this music gear, because I have a Behringer mixer.

A lot of these companies, they're buying each-other, so you have this different level.

Sometimes can be confusing on who. I know all this stuff 'cause I used to do music in college. I produced beats and stuff like that.

Joseph: Awesome.

Brian: But yeah, I'm super envious of one of my coworkers who's actually been picking up sampling, and learning how to do that.

Joseph: Oh wow.

Brian: And using some of the Push 2 and then the machine. I just don't need another hobby.

I think, if I do that, then my family will never see me, 'cause I'll be coding, I'll be streaming, I'll be playing games and then I'll also be making music.

My kids will have to raise themselves. I'm hoping that one of my other hobbies will die off, once everything opens up, but I'm really intrigued in a lot of these Instagram artists.

I don't know how much you've been paying attention to some of these DJs, doing their sets on Instagram Live. And even Twitch as well, which has been weird.

It's a weird place to watch stuff that's not gaming, so coding's even weird, to watch it there.

Joseph: New content.

Brian: But not weird enough that you can't watch me.

Joseph: I'm actually from the game industry, this is my first startup outside of the game industry, did you get a chance to play Valorant at all, or got the invite?

Brian: No, no, I've watched a bit of it, but, the first-person shooter is like, I haven't really been into them since college.

I'm a very passive player. I wouldn't even be playing right now, if I had the invite.

But I have been watching. I'm a bigger fan of watching the first-person shooters nowadays. Mainly 'cause I'm not really into the Battle Royale, I used to play Counter-Strike. Counter-Strike probably the only one I still do play.

Joseph: So you're playing go?

Brian: Yeah, jumping outta airplanes and then dying, and then waiting another 30 minutes until you get put into another room. It's just not my speed, right now.

Joseph: I hear you. I'm a huge Counter-Strike fan, I clocked over six thousand hours in high school playing Counter-Strike, which is ridiculous.

Brian: I believe it. I was a OG Counter-Strike player, so I used to play on my janky Windows machine, back in middle school.

Joseph: Yeah. But Valorant looks like it has the CS mechanics, or at least the 1.6 old, you shoot them, they're down kind of thing.

Definitely excited to try it out, when it comes out.

Brian: When it's open to everybody, I'll definitely give it a spin, but I just don't have it in me to start really going hard, 'cause some of these kids are just way too good.

Anyway, Joseph, I just appreciate you coming on, calling us from all the way from Hong Kong and sharing about your budding DJ career, as well as talking about the DevOps space and clearing it up for me, as well as the rest of our listeners.

Thanks for that, and listeners, keep spreading the JAM.