Guest: Randall Hunt
Company: Vendia
Show: Let’s Talk

Randall Hunt, Director of Developer Relations at Vendia, sits down with me to chat about product-driven and access pattern development. 

“Technology should not get in the way of what you’re trying to do. And you know, maybe that means you use old and boring software stacks that you’re familiar with, that your team is familiar with. As long as you can move quickly and iterate on the product, you’re doing fine…,” the conversation starts with Hunt defining product-driven development in the industry. However, access pattern development differs in that you have to first break everything down into principles. He uses a simple example to drive his point home: “What’s the minimum number of roundtrip network requests that I need in order to serve relevant information to the users of my application.” Those access patterns can help developers break down incredibly complex applications, ones that might talk to a million different data entities.

According to Hunt, access patterns are putting the user of an application in charge and asking: “What are the common operations they’re doing? What are the ways they’re using the data that our application exposes? With the answers to such questions, developers can optimize each one of those access patterns and unblock as much undifferentiated work for their customers.

When the conversation turns to Kubernetes, Hunt states there’s a lot missing. He says, “A lot of times startups will spend a tremendous amount of time on their core infrastructure, their backends, their dev ops, their CIO, and their CD. What they really need to be focusing on is the product, because that backend infrastructure, if we’re all honest about it, it’s mostly undifferentiated, heavy lifting.” Instead, Hunt believes it should go back to access pattern-driven development to answer questions like “How are users using your product?” and “What are you doing to provide value for that partner in the fastest possible way?”

Once companies reach a certain scale, this all makes sense. With Kubernetes, you have to figure out how to optimize everything to cloud costs. But, according to Hunt, “if it costs me 100 grand a month to run my business in the cloud and I know that if I spend six engineering months, I could get that cost down to like 10 grand. That’s great. But in this market, when VC money is prevalent and there are all these opportunities to go out and build, you need to be building, you don’t need to be focusing so much on iterating on your backend infra.”

When asked whether he prefers GraphQL or REST, Hunt opts for GraphQL. He’s seen it all, from the worst to the best. To justify his choice, Hunt says that GraphQL was designed to help you build applications that can adjust dynamically. To that end, he says, “You separate the concern between the front-end developer and a backend developer. So the front-end developer says, oh, I just need this field. Cool. I’m just going to add it into my graph QL query.”

The conversation then turns to High Availability (HA), with Hunt saying, “If it’s a developer-facing application. that multi-region architecture is really important. As a consumer-facing application, your customers don’t care at all about multi-region or anything like this. The only thing they care about is, is it fast, is it working well, is it performant? So if you  can say, “Hey, I’m going to serve my customers in Australia from this region or this actual location…you’ve solved the fast problem for them.”

When asked to offer some tips for developers, Hunt suggests starting with user stories. Who are the end users of your applications and what are their motivations? If you iterate backward from those questions and iterate continuously from what the customer is trying to do and can currently do, you’re set. Hunt concludes by adding, “If you find a way of removing something that is undifferentiated heavy lifting as a developer, as a founder, do that. It’s worth the time.”

Summary for this interview/discussion was written by Jack Wallen

Here is the full, rough transcript of the discussion:

Swapnil Bhartiya: Hi, I’m your host, Swapnil Bhartiya. And welcome to Let’s Talk. We’re going to talk about access pattern-driven development, how your teams can shift their focus from building back end credit to something that provides value to their customers. And of course, friends and teams to discuss this topic we have with us Randall Hunt, Director of Developer Relations at Vendia. Randall, it’s great to have you on the show.

Randall Hunt: It’s great to be here. Thank you for having me.

Swapnil Bhartiya: If I ask you, how would you define product driven development? What is it and how different it is from regular development?

Randall Hunt: Well when I think about product driven development and access, pattern driven development, they go hand in hand. What you really want to unblock when you’re a development team or a product leader is you want to unblock that product driven development. You know, technology should not get in the way of what you’re trying to do. And you know, maybe that means you use old and boring software stacks that you’re familiar with, that your team is familiar with. As long as you can move quickly and iterate on the product, you’re doing fine. That’s product driven development, but one of the patterns that’s evolving and becoming more prevalent in the industry right now is access, pattern driven development, which is when you, you know, if you think about physics and you think about launching rockets or any of this other stuff, you know, you have to break everything down into first principles. So how do you break an application down into first principles? You talked about the access patterns, what’s the minimum number of roundtrip network requests that I need in order to serve relevant information to the users of my application. And if you think about those access patterns, if you think about, you know, what all goes into it, you can go and break down incredibly complex applications, you know, ones that maybe talk to a million different data entities, and you can break it down into simple access patterns and you can compose those and build out a very strong data model and a very strong product from first principles.

Swapnil Bhartiya: So if I Am not wrong, access pattern, more or less flips the table and instead of looking at application developers’ perspective, you’re looking from user and consumption perspective.

Randall Hunt: Yes. So it’s really putting the users of your application in charge and saying, Hey, what are the common operations they’re doing? What are the ways they’re using the data that our application exposes and then go to town, figure out how you can optimize each one of those access patterns and unblock as much undifferentiated work for the customers.

Swapnil Bhartiya: Yeah. And Some of the most iconic products in history. Also, if you look at Steve Jobs and apple is a very good example, Braun is a very good example where the products are not created from engineers in the center, they are created around users in the center and the product was created around them. So thanks for explaining that approach. Now, if you just go back to the software, just narrow down to the cloud native, or even further narrow down to the Kubernetes community. And how do you see people, folks are approaching development, how they are either doing it right? Or what are they missing from your perspective or from access driven development?

Randall Hunt: I think there’s a lot that’s missing right now, to be honest, there’s a tremendous focus on, you know, Kubernetes and setting up your infrastructure. And that’s a very deep rabbit hole. And a lot of times startups, they will spend a tremendous amount of time on their core infrastructure. Their back ends their dev ops, their CIO and their CD and what they really need to be focusing on as the product, because that backend infrastructure, if we’re all honest about it, it’s mostly undifferentiated, heavy lifting. It is, you know, I’m, I’m building yet another cloud app. You know, maybe I’ve got a rail stack and I’m throwing a, you know, engine X along with it, or, or, you know, I’ve got a flask app and I, or, you know, I’ve got a Postgres database and I’m throwing PostGrest in front of it. That work is going to be the same for the base set of operations. And it doesn’t make sense to keep focusing and iterating on that work when it doesn’t add any value to your product, your, your users don’t care how things are implemented or on that backend your users care about what value you’re providing to them through your product.

So again, it goes back to that access pattern driven development, like how are users using your product? What are you doing to provide value for that pattern in the fastest possible way? And once you reach a certain scale, yeah, it makes sense. You got to go, you got to check out your Kubernetes set up. You have to figure out how you can optimize things, save some money on your cloud costs, all of that good stuff. But that’s so much later than a lot of people start. You know, if it’s, if it costs me a hundred grand a month to run my business in the cloud. And I know that if I spent, you know, six engineering months, I could get that cost down to like, you know, 10 grand. That’s great. But in this market when VC money is prevalent and you know, there are all these opportunities to go out and build, you need to be building, you don’t need to be focusing so much on iterating on your backend infra. You know,

Swapnil Bhartiya: Yeah sometimes a lot of these projects and products, they become more about tech Marvel than about actually serving a user in most cases. But are there, you know, it’s, you know, either access or, or, you know, product driven development, is this the only way, or maybe depending on the use case, depending on the industry that you are in that, Hey, this, this model applies in certain businesses or certain time of projects, or is it like, this is the ideal way to do it? Or in other words, if I ask you that, Hey, what are the areas? What types of industries are projects? It makes sense and where it doesn’t make sense.

Randall Hunt: Well, I think that access pattern driven development and kind of a focus on the user is the primary way you should be developing applications. And in, you know, 20, 21, there are exceptions. Of course, you know, there, there are certain industries where this kind of top-down approach has to be done or requirements of specification: you’re building spacecraft, or you’re building, you know, life support systems, things like that. Then that slower kind of top-down Spec driven approach is likely going to serve your needs better. And it also provides this kind of auditable chain of work that you can go back on and verify and share with partners and things like that. So there there’s certain industries where you might still hold off on that full access pattern. Like let’s move quickly kind of deal. But the gross majority of consumer apps and even developer-facing apps can be supported by access driven development.

Swapnil Bhartiya: We have been talking more about processing. Let’s just talk about, you know, the tools and technologies as well. There’s a big debate going on about Rest. You know, everybody talks about that, but if I ask you, what do you prefer? You prefer GraphQL or Rest and, and what, why.

Randall Hunt: I prefer GraphQL. So, I mean, I’ve been involved with APIs back to, you know, soap and XML and, you know, even remote procedure calls across, you know, cluster computing, interfaces and NASA, like, so I’ve seen it all. I’ve seen the gamut, you know, from, from, from the worst to the best, you know, the, in the beginning, you know, we had these monoliths, you would split those, break them up into microservices, service oriented architecture, and maybe you’d start out, you’d send things over soap, so it’s like XML and, you know, Pearl or something in the backend. And then we started transitioning into these Ajax apps. So this is when Json became prevalent and it became the primary method by which you would transport things between dynamic websites. So you’d have your front end, it go.

It would make an Ajax request and get some Json back. And that was really when Rest kind of took hold of everything, because you were able to take these different HTTP verbs and you were able to put payloads in them and you could build a lot of content around that. But the problem was HP1 still only allowed you to make one request in one round trip network. So HP3 and other protocols have a little bit more cool stuff going on to make you be able to do more in a single network request. But graph QL was designed to say, Hey, I know everything that I need to render this component. So when you talk about access, pattern driven development, I know everything I need to show this user or that, you know, if I’m Spotify, I know what this page is going to be. I can put it all in one graph, QL request, and I can get back all the data. And I don’t care what the backend is doing. Right.

As long as I get back the data from my user, what the backend is doing to me as a front end engineer doesn’t matter. And that power is really it. It allows you to build applications that can adjust dynamically. You separate the concern between the front end developer and a backend developer. So the front end developer says, oh, I just need this field. Cool. I’m just going to add it into my graph QL query. And now it comes back and, you know, as backend developers, we have to go back and make sure those queries, whatever is happening on the backend, that it’s optimized, that it’s going to be served well and correctly, but it’s still pretty cool to be able to just add a new field. I don’t have to learn a new API. I don’t have to learn a new thing. It’s just all fully explorable and introspective. So that’s why graph QL is probably what I would prefer. And that’s where I see most API is going in the future.

Swapnil Bhartiya: Right. And also, you kind of touched upon it a little bit, but if you go back to access better and even development, how did this choice of graph QL will also kind of compliment, you know, your approach towards how to do development, right?

Randall Hunt: Yeah. So with graph QL, you’ll have an easy. There’s this Apollo client, for example, is a, is a great way from the front end to go. And, or even the back end, if you want to go and interact with graft based applications, you essentially give it an end point and then you can go and figure everything else out. And let’s say you’re using TypeScript, for example, rather than you having to go and introspect and learn the whole API and have maybe an SDK built on top of the API or some data object model built on top of the API, you just have graph QL and then everything can be determined from the queries that you’re making or from the introspection into the schema that you’re making. So if you’re a front end dev and you get given a rest API, you now have multiple end points that you’re having to track. You have to make a pseudo SDK. That’s going to go and talk to each one of these things. You have to fire the request separately, have to manage all of that complexity within your front end application with graft QL, and react. For example, I plug it in, I say, Hey, subscribe to changes on this. And then anytime I get a new request, I just update the UI. So it really, really allows for you to go full speed with that access pattern driven development. It’s like, whatever information I need. I know I can get it from this API. So I’m just going to add that to my query.

Swapnil Bhartiya: Now I want to ask you to lead, you know, change gear and, and, and move away from development to, you know, once you have built your replication and let’s talk about X, you know, we talk about site reliability, we talk about high availability. Can you also talk about the importance of high availability or multi region, especially from the perspective of early stage companies, because creating a cool app is fun, but having access to that app all the time and it’s prospective very user. So even more important. So talk about some of those factors, because sometimes earliest companies don’t even focus on those things, but over a period of time, it becomes

Randall Hunt: Critical. Yes. So to be honest, that’s one of the core reasons that we in Vendia realized this multi-region architecture. It shouldn’t be something that is left to the fortune 500 companies who have, you know, millions of dollars to throw at either Kubernetes or, or Azure, AWS, or GCP. You know, they can just spend all this money and time building this multi-region application architecture. And I do think it’s important to get it right early on. So, you know, if you, if you’re a developer facing an application and your control plane only exists in one region, and that region goes down, regardless of what cloud it’s on. If you’re serving customers, you know, if you’re serving developers who are in turn serving customers, your support workload is multiplied, right? All the end customers are complaining to the developers and all the developers are complaining to you. So if it’s a developer facing application that multi-region architecture is really important as a consumer facing application, your customers don’t care at all about multi-region or anything like this.

The only thing they care about is, is it fast? Is it working well? Is it performance? So if you can go and you can say, Hey, I’m going to serve my customers in Australia from, you know, this region or this actual location. There you go. You’re, you’re all set. You’ve, you’ve solved the fast problem for them. And that’s one of the things that we try to do with India is we want to make it so adding a new region, adding a new node essentially is one change in adjacent schema file or one change in a, what we call uni registration file. And then you have a multi reader, multi writer, you know, set of your data available via graph QL. And I remember, I mean, I I’ve been in the cloud for a long time. I remember the early days of setting up multi-region architectures and, you know, doing DNS and doing geolocation, DNS and load balancers and multiple stages of load balancers. I don’t want to do that anymore. You know, it’s the same every time, but it’s so much work to get, right? So it’s a lot easier to just kind of pawn it off on somebody else and say, Hey, run this for me.

Swapnil Bhartiya: Excellent, I mean, you can not share the whole bulk here, but if I ask you if you have any playbook, or if you can share a few steps, how, you know, early stage companies, it’s more or less like to summarize what you have said should approach development, not just from the first line of code that they write to all the way here. You know, when we talked about availability all across the region,

Randall Hunt: Right? I’d start with user stories. So I always try to go, who are the end users of my application? What are their motivations? And then how am I going to allow them to build and do the things that they want with my product? And if you iterate backwards from that, you know, Amazon is famous for their working backwards approach. It works, you know, if you, if you iterate continuously from what the customer’s trying to do and what they can currently do, you’re, you’re set. And then from there, if you, as an early stage startup, anything you can get as a platform, as a service or a backend as a service, anything that’s just kind of removing that undifferentiated, heavy lifting, grab that, go for it. You know, the companies like Pinterest and Airbnb, you know, they were able to scale significantly because they went out and they said, I don’t need to get a data center.

I can just use AWS and I’ll be all set. So if you find a way of removing something that you know is undifferentiated heavy lifting as a developer, as a founder, do that. It’s worth the time. It’s worth the effort to focus on your product. Instead of focusing on, you know, this, this undifferentiated heavy lifting of backend infrastructure. And I know I keep saying that and I keep repeating it, but it’s true.

Swapnil Bhartiya: No, that was a very fun discussion. So thanks for sharing. Those incites, it’s hard to, I mean, I think most people think about it, but none of us, you know, actually apply them. So it’s good to kind of keep returning, keep repeating them. And as you said, you know, I like to repeat and that’s really important. You have to beat the message again and again, Randall, thank you so much for taking time out today and talk about access pattern driven development. Why companies should do that? I mean, it looks like in most cases, it does make sense. You did share some use cases where it may not be applicable regulated industry and stuff like that, but this is how we should be approaching it. So thanks for sharing all those insights and also sharing those steps that how to approach it was really a icing on the cake. Thank you for your insight. And I love to have you back on the show thank you.

Randall Hunt: Thank you. Thank you so much for having me. I hope you have a great rest of your week.