API Evangelist Conversation with Pat Patterson, Chief Technical Evangelist at Backblaze

Hello, this is Kin Lane, the API Evangelist, and this is my podcast, API Evangelist Conversations, where we talk to interesting people who are doing interesting things with APIs. Let’s go ahead and dive in and bring our guest out and find out who they are. Hello there, who are you?

Hi Kin, I am Pat Patterson.

What’s your role, Pat?

So I have the wonderful grandiose title of Chief Technical Evangelist at Backblaze.

Okay, before we move on, why Chief Technical?

So I focus on our cloud object storage product, Backblaze B2, and a lot of my audience are developers, but a lot of them are not. So they might be DevOps engineers, admins, and so I kind of chose that title to emphasize that broad reach.

I like it. And you said Backblaze, so you’re in the storage industry, am I correct?

Yeah, so we were founded, gosh, 2007 I think, doing Mac and PC backup, and successfully did that for a few years. And the founders realized, wow, we’ve built a cloud storage platform for backing up people’s laptops, we could generalize this into cloud object storage. So they did that, I think in 2016, and then added an S3-compatible API in 2020. And here we are today with thousands of customers happily backing up, storing media, writing whole applications around cloud object storage.

Whoa, wait, let’s unpack that. So S3-compatible storage, what does that mean?

So you know, S3 was the original cloud web service. I think 2006 it was the very first Amazon web service. And they defined an API, a quite simple, I’m not going to get into the details of whether or not it’s RESTful, but a relatively simple interface for uploading data for storage in Amazon’s cloud. They obviously had fantastic first-mover advantage there. And as more cloud providers came along, saw this pattern, some of them, as Backblaze did, brought up cloud storage and maybe had their own API that was similar to S3. But there were so many utilities and applications that used Amazon’s S3 API that the market kind of coalesced around it as a de facto standard. And I got to be fair to the guys, AWS did a great job with that API. The authentication is, you know, we can get into, actually that’s a good topic to talk about later, how authentication happens with S3, because they took, made different choices from other products that were around at the time. But it’s very amenable to third-party providers providing their own cloud object storage, and then even Amazon’s own SDKs and CLI and so on can just override the endpoint URL and use them with Backblaze, or MinIO, whatever other object storage that you happen to be using.

Interesting. So you said de facto standard. Do you hold this up alongside other standards that have governing bodies and whatnot behind them?

It’s interesting. So this whole industry basically relies on Amazon’s documentation, which is more or less accurate. We don’t have a W3C or whatever issuing these things on a date with a public process. The documents are there, and I know tomorrow Amazon could announce, oh, here’s a new S3 feature and this is how it works and these are the parameters, and then we’ll look at it and say, okay, well, we won’t necessarily jump on day one and say, oh wow, scramble, implement this, but we’ll look at it. Amazon’s done this, is this something our customers need, is this relevant to our space here? And ultimately, we’d better implement this, there’s customer demand here, we can implement this. So it’s an interesting situation to be in. It’s very much, S3 compatibility is defined very dynamically. Your customer tests a particular product and it works, then for their purpose it’s compatible. There is no official test harness that you can run and get a stamp of approval from AWS.

Impressive. I use S3 for all the images I have. The same bucket that I stood up when I first started API Evangelist, and I have code running to automate that image syncing, that I’ve never touched since 2011, since I think you and I first started hanging out and meeting, right? That’s well over a decade, that’s 14 years of something working, that’s pretty standard.

And I should have had that Backblaze hat somewhere around me to put on, and say you could move that data to Backblaze tomorrow, change the endpoint URL and obviously the credentials and the bucket name, and it would just work unchanged.

That’s what it’s all about right there. Well, come back to the APIs, I want to get back to your title and more the developer evangelist portion of it, because this is one area that you and I have kind of danced and tangled in for many years as far as different types of evangelists with different words preceding it. So how long have you been a developer evangelist?

I’d say 20 years now.

So how’s that changed in that time? Wow.

Well, when I started there wasn’t even that title. I think there was probably one evangelist in the industry, and it was Guy Kawasaki at Apple, probably at that time. I think my title was something like technical architect, and I was working on single sign-on at Sun Microsystems, God rest its soul. We made a decision to open source that project, and the director of engineering pointed at me and said, Pat, you’re good at talking to people, you be the community guy. And there was a bit of learning from other projects. Open source was a big thing at Sun at the time, and you had GlassFish and these other projects, OpenSolaris, but there was a lot of just making it up as you went along, building a community around an open-source product. And that was 2004. So that’s really what I’ve been doing for the past 20 years, educating hands-on technical professionals on how best to use a particular platform technology, you name it.

So what’s the most effective tool in your toolbox?

Code, I would say. Sample code is just essential. I mean, that’s what I love about my job, is that I’m continually coding in many different programming languages, and I get a bit confused now sometimes, I start running semicolons in my Python and things like that. But really, as a teaching aid, a didactic aid I suppose I could say, code is invaluable. If you can give somebody something that runs that solves something close to their problem, they’ve got a starting point that they can work from. And these days, you can not only point somebody at a GitHub repo, you can point somebody at a Docker image that has a running shell of that code, so they can get started immediately. So yeah, there is nothing better than working code for teaching a new concept. Developers love code that saves them time. The success of Stack Overflow and GitHub I think really speaks to the social aspect of this, but coding.

But as a technical evangelist, what’s top of mind, what’s a priority for you right now at work?

So it is really explaining the new features that we are releasing. So again, that’s coding, part of that, but also there is technical writing, writing articles, presenting webinars. So it’s bringing that together, because this job, as you know, is way more than just sitting and writing sample code. I often talk about, there’s a Venn diagram of people who really understand a particular technology and then people who would be comfortable standing up in front of 500 hungry developers and explaining it, and that intersection is quite narrow. That’s what I’m always doing, balancing this. I could go deep and write code and have a lot of fun, but if I do that for too long, I’m not actually communicating it, sending it out there, people forget who you are if you go dark for too long. But on the other hand, if you’re out on the road at conferences and networking and glad-handing, you get out of touch with what’s happening in the technology. So all the time I’m balancing those two sides in order to do my job for the company, which, although I’m not like a sales guy with an AR target, the intention of hiring an evangelist is they have a positive effect on your revenue.

Yeah, I think bringing it back to the business bottom line right now is going to be a common theme, is something I predict here, not just for API producers but a lot of folks. So what keeps you going out of that mix that you just talked about, as far as what kind of gets you going and keeps you going?

It’s really the interaction with the community, actually having a sense that you’re making a difference and solving problems, answering questions, and getting that feedback that what you’ve created has worth and meaning and is making a difference. That’s huge for me. It cannot be a one-way street. And another way, gosh, anybody that’s had a conversation with me, another way I describe this role, it’s like you’re a bridge between product teams within the company and that external community, hands-on technical professionals, so developers, DevOps, admins. And on one side of the bridge there’s that outbound role of, hey, here’s the new feature, here’s some sample code, here’s a webinar that explains how to do it, you can ask questions at the end. But on the other side of the street, you’re bringing back in those experiences, that feedback, the fact that, oh, this is great, really handles this common condition, this feature works great for production but the developer experience is a bit lacking. All of that, being in that, not part, you as an evangelist, you’re not part of the community, you’re in the community, but having those interactions, bringing that experience back, is very, very rewarding.

You just summed up why I’m doing this podcast and why I’m having this conversation, because this is how I learn everything I learn, and this is how I know what I know, doing this over years. I just want to do it in a format that other people can learn from. And you’re someone I’ve learned from and followed your lead since I first started doing this. And then when you submitted the form for this, you helped me correct my form and make my form work better.

Yeah, sorry, I’m an annoying pedant, I have to, I’m like the proofreader from hell.

I love it, I need it, I need it. And then you had a question for me which I’m going to read out, I’m not going to make you read, because I thought the way you wrote it was pretty nuanced. So how do you balance your public advocacy with your day job? Are there occasions when what’s right for the business conflicts with industry best practices? I suck at this balance, and that’s precisely one of the reasons why now I’m back at API Evangelist doing this podcast, is because I’m not good at it. So I don’t have any words of wisdom. I think striking an honest balance and an honest tone and doing what you like, I think you reflect this, just stay true to yourself and find a nice balance to that performance, and you’ll be fine.

Yeah, it’s interesting you say that, because it sounds like API Evangelist, you’re still kind of booting this back up, it’s an outlet for that side of your personality where you have to be like corporate Kin at times, just because of the realities of business and large organizations, but having this outlet for the, okay, this is how things should work, seems pretty healthy. Part of my role is to be a pain in the ass to engineering and product, and bring back those niggly little things, like, why does it work this way, this makes no sense to anybody that doesn’t have backblaze.com in their email address, this is incomprehensible. But at the same time, it’s going to be balanced with, well, we started writing this code 17 years ago, so it’s not going to be like that, we can make this particular improvement. So this whole thing could be subtitled “balancing the API environment,” because there’s so many of these balances where it’s like, okay, be great to do it like this, to make a perfectly RESTful API, but we’re not going to get there overnight, until we have to support what we have, and may add a few endpoints, add a couple of parameters to support the way we do it right now, even though it’s not the best API in the world.

Do what you can, you do what you can. Well Pat, always a pleasure. The good thing with this new format is you can come back, so I can have you come back in a couple months and we can have a conversation again. So we can do this quite often, as you can tell, I could talk about this stuff all day long.

I think that’s why I have this job, really.

Well, I have this little record right here, and I’ve got more S3 questions, so I’m going to have you back, but I think that’s it for today. I appreciate you coming by and talking with me.

Yeah, absolute pleasure, Kin, thanks for asking me.

Thanks, Pat. All right, always fun talking to Pat. He’s a super knowledgeable guy, I definitely want to have him back and talk about auth and S3 and see where we can take it. Until the next conversation, thanks y’all.