David Dymko, Vultr

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes we explore topics from the world of APIs, but through the lens of business and engineering leadership. Joining me today we have David Dymko, director of engineering and cloud native at Vultr. David shared with me a fresh view of what the cloud means in 2022 and what the most meaningful aspects of how APIs in the cloud will be defined in the future. Let’s start with the basics. Who are you and what do you do?

Hey, my name is David Dymko, I am the director of cloud engineering at Vultr, and my day-to-day kind of maintains the open source API, load balancers, and Kubernetes for Vultr.

Describe Vultr for me.

Yeah, so we are a cloud provider, we kind of support your basic cloud needs. We have regular compute, block storage, object storage, load balancers, managed Kubernetes, a marketplace so you can kind of deploy any kind of operating system or image. So we’re a cloud provider through and through. We are an independent cloud provider, so when you’re kind of looking at us, we’re similar to someone like DigitalOcean or Linode, and we’re a bit simpler and easier to use than looking at someone like one of the hyperscalers like AWS. So we’re kind of simpler to use, a bit more predictable in terms of billing and behavior, but our bread and butter is a cloud provider for developers, enterprises, customers like that.

So where do we stand? I haven’t done a lot of reassessing of the cloud evolution and journey, but we’re going on well, 14, 15 years here of AWS, the battles between Azure and AWS and Google and all of this. But where, in the evolution of hosting providers, you mentioned DigitalOcean, which I would consider to be an older-school hosting provider. We have Rackspace, they’d gone all in on OpenShift and kind of an open approach to cloud to try to compete, but they’ve seemed to have gone away. What’s the race look like today, and you mentioned a few, but what are the differentiators that you’re competing on that you think really matter to folks?

Well, some of the things that I kind of take to heart are making it easy for developers to build infrastructure, to get started with open source tooling, to make that type of stuff easier. So let’s say I was looking to start a company and I needed some kind of cloud provider. No one’s really going to these data centers and stacking their own racks anymore, everyone’s kind of virtualizing and looking for that ease of use. So with the things that we offer at Vultr, it’s really simple for me to kind of get started with a simple VPS, one core, one gig, just to kind of get my site up and running. But then as I grow, we kind of want to cater to your scale, so you might want to deploy a load balancer and not have to really worry about the underlying networking, the underlying connectivity to make sure it’s highly available. So that’s kind of what, when I look at us as a cloud provider and my vertical slices that I work on, I’m trying to make it simpler and easier for users to build their resources, deploy their resources, but then also maintaining the API, the open source, making it super easy to give them multiple avenues to get started. So if I want to use the API to do some custom integrations and custom deployments, that’s really simple. We have a great API that’s been updated recently to a more modern OpenAPI type of specification, with tools like Terraform or Packer or CLI. We want to make it easy so that again developers have a very clear, multiple ways to get started without having to worry about the underlying headaches of what we used to kind of do to deploy applications in data centers. And I think Kubernetes is a big push, because Kubernetes is kind of the current buzzword that everyone’s going for with containers, and maintaining a Kubernetes cluster on its own, I would say, is quite complex. It’s like you need a dedicated DevOps team just to kind of maintain it. So offering something like a managed Kubernetes cluster, in my opinion, is a great segue to the cloud infrastructure for developers, because you just worry about your workloads, worry about your application, worry about scaling it, but you don’t have to worry about the control plane for the Kubernetes cluster, making sure that connectivity is working, or any of those nitty-gritty things. So again, when I kind of look at it, I would say it’s really making it easier for developers and companies of all sizes to really build their companies and their infrastructure without having to worry about a lot of this headache that comes with infrastructure. And that’s kind of my take, and that’s kind of a philosophy we’re applying to our open source load balancers, Kubernetes, and a lot of our other products too that we have currently and that we’re currently building out as well.

Yeah, I think that’s one of the areas I feel like we’ve lost sight of with the big cloud battles, is just that simple abstractional way of what we shouldn’t have to. I mean, you mentioned racking, and I have those PTSD from the 90s. Like literally, I drove all of my servers one time from data center to data center, hauled them in on the cart, came back out, and someone had stolen all my cables from my car while I was in the parking lot. Like I have those kind of PTSD stories. And with DNS back when, you make a DNS mess up, you had to live with it for 24, 48 hours. So the cloud for me was about abstracting away a lot of that pain and suffering. And I feel like Heroku early on had done this well, they’ve lost sight of that, I would say, as well. But with Kubernetes it really feels like we could put guardrails on for developers, so we all don’t have to become Kubernetes experts and feel a lot of Kubernetes pain, but then see a lot of the benefits of Kubernetes.

Yeah, and I think that’s kind of what, the way I kind of looked at it when I came on board for Vultr, it was, we want Kubernetes, and I used Kubernetes in the past, but we quickly came to learn, or I quickly came to learn rather, was using Kubernetes and managing it in an abstracted way are just completely different beasts. And that was a very interesting problem to solve. And I think a lot of these problems, even with load balancers, are conceptually you understand how they work, but now if you have to manage it and offer an advanced solution where I, the user, don’t have to really, for lack of a better word, even care how it’s running, or I just need to make sure that it’s up and running, that’s all I care about. That’s a very interesting problem to solve, especially in the Kubernetes space, because there were so many interesting problems we kind of faced around the control plane. Because with the CNCF there’s these conformance tests, and there are specific things you have to do in order for it to be considered a managed cloud provider, and one of them was the control plane needs to be completely hidden. The user can’t have access to it, and it can’t have access to any of the components running on that Kubernetes cluster. And there’s a lot of interesting problems, like how do you do that, because if you look at a lot of these tutorials online, a lot of it’s like kubeadm, and with kubeadm everything runs as a container and you have access to everything. So you can’t really, I’m sure you can use that in specific ways, but there are a lot of these problems that you wouldn’t normally face using Kubernetes that we, or any cloud provider, kind of runs into, is you have to abstract these already complex solutions for the user so they don’t have to worry about it. So we’re basically taking on the burden there. But it’s great, like if I was using Kubernetes, I wouldn’t want to maintain the control plane and make sure private networking or these components are running, because that is a lot of work. I’d rather, as an engineer, I’d rather be focused on my applications and growing them out and not worrying about the infrastructure. And I think that’s kind of the next evolution, I’d say. You see a lot of these serverless type of open source tools where they’re abstracting it more and more, and these developers are really not even considering what it runs on, it’s just here’s my application, here’s my container, I don’t care how you run it, just run it. And I think that’s interesting, I think that’s an interesting problem that we’re kind of all working towards, is this next level of abstraction that is one step, I guess, lower than Kubernetes.

Not writing YAML would be great.

I know, so many folks would be much happier not writing YAML.

So you mentioned your API in there, and that’s one characteristic of cloud for me, is it’s not just about the infrastructure and everything we just talked about, but it’s also about the fact that, when I started using AWS there was no console, I was either using the CLI or I was using the API. And that automation for me is a super critical aspect, whether it’s all the way up to Terraform and Ansible and that infrastructure as code and programming your architecture, to just more ad hoc APIs, making API calls to configure, automate what you need. But tell me a little bit about the journey. You said you were on version two, so what’s been your API journey to bring that to life?

So the API journey kind of starts a little bit earlier than that. What I mentioned before, that when I came on board with Vultr, our vision was managed Kubernetes, so we kind of had to take inventory and stock of like, okay, what do we need to even start working towards that. And the first thing we kind of realized was, we need a Go client. Because there’s a lot of these open source plugins, for those familiar with Kubernetes, there’s a CCM, the cloud controller manager, and a container storage interface, these are all public plugins that anyone can use, and we kind of need to interact with Vultr as a first-class citizen. So we started building out the Go client, and that was, version one of the API was still there. And anyone who’s written loosely typed languages, you can kind of get away with certain things, but with Go and strictly typed, we quickly ran into a lot of these headaches where the API was a bit inconsistent. So list calls would return one field as a string, and then the next one it would be an int. If you’re writing Ruby or something else, it’s not a big deal, you don’t even think twice about it, but implementing that with the Go client was a headache. Because we tried to fix and introduce as much of these inconsistent fixes to the API, and we tried to be thoughtful of not introducing breaking changes, because as we all know, if that was the API’s behavior, someone’s depending on that. So even though we might be fixing one of these problems, we’re probably going to break something for someone. So that was an interesting problem to solve for. So we kind of tried to do as much as we could that made sense on the API, but then do a lot of fixes in the Go client, which was kind of type juggling, doing custom JSON marshaling or stuff like that. And then once we had that Go client, in the back of our minds we’re like, we’re going to have to update this API to a V2 at some point, but we kind of got derailed and we started implementing Terraform, a CLI, because we had this Go client, why not start building out our open source which we kind of didn’t really have at the time. So fast forward a bit, we got to the point where we had to start integrating with the CCM and the CSI, and it was at this point where it was kind of like, the Go client got us this far with all these integrations, but it’s not going to work with the CCM or the CSI or these Kubernetes plugins that we’re going to have to start writing. Some of the big pain points there was we didn’t have pagination in V1, so a lot of these integrations had to do a lot of list calls and start filtering and stuff, and without pagination, if you have a few resources it’s not a big deal, but in a Kubernetes cluster we were thinking about larger scale enterprise customers, if they have thousands of instances, these list calls were heavy. We could support them, but it just wasn’t really the optimal solution. So it was at that point where we’re like, okay, we need to update the API to V2. And that’s when we really, if you look at API V1 in comparison to V2, they’re drastically different. We have pagination in V2, the URIs are more JSON spec where they’re more CRUD-oriented. V1 had a lot of verbs in the URI, so it was like get-list, get-servers, list, stuff like that. So we kind of modernized the URIs to be a bit more standard, we switched to an OAuth 2 type of authentication with the headers, and we also introduced just proper JSON responses for request and response. Because V1, that was an interesting thing in V1, and it was a product of its time so I try not to bash it that much, we would send form requests and get back JSON. So that was a very fun thing, the software and the Go client and a lot of these tools, we have these two types of data, we’re sending form data and we’re getting back JSON, it was just really kind of hard to work with. So V2 introduced a lot of fixes for consistency, a lot of modernization of what you would expect out of an API in today’s kind of software climate. And then once we had V2, a lot of changes, in order for you to upgrade from V1 to V2 it would have required a decent amount of work, just because the return types were different, the URIs were completely different, the list calls now had pagination, so that would require you to kind of properly integrate with that. So V2, I was worried that a lot of people would be kind of upset that it’s drastically different, but it was the total opposite. People kind of were really happy, and we’ve seen huge adoption of people migrating from V1 to V2. But after that, we then had to go update our Go client and update all of our tooling. But one thing we’ve seen is some good performance gains and just overall easier maintainability across these tools and products. So it took a while for us to update to V2, but we tried to make it last as long as we could until it was just like, this isn’t going to work anymore.

How did you come about the design of this API? Did it take you a while to come up with all the characteristics that you wanted, or did you have that feedback loop and all those pain points that you’d been experiencing yourself, or that customers had over years?

So we were dogfooding a lot of API V1 in our open source tooling, our integrations, because we started becoming way more active in open source. So we were integrating with Terraform, Packer, a lot of, anywhere we could integrate with Vultr we were dogfooding as much of our API and our own clients into those. And before coming to Vultr, I actually worked at Vonage, where I worked on a lot of monolithic to Kubernetes microservice migrations, and that’s where I kind of picked up a lot of API design and became a bit more obsessed with API design. That’s kind of my bread and butter before kind of switching over to the Kubernetes scene. So I was always a bit outspoken, I’d say, about API V1, tried to be reasonable about it, but there was a lot of things, like right off the bat I was just like, this isn’t going to work, the URIs aren’t RESTful, we don’t have paging, there’s just so much about it that didn’t work. Like one thing I disliked, but we kind of did end up mixing, was proper top-level nodes in your responses, which we didn’t have. So it was a lot of us dogfooding it and us kind of using it, realizing like, we should fix this, we should fix that, it would be really cool if we could do this. And also while we were dogfooding a lot of these integrations, we got very close to a lot of these calls, and we were starting to realize like, some of these calls could be condensed. I don’t have any good examples off the top of my head, but let’s say there was like a list call which would return pretty much all the data about a given resource, but then one or two resources just didn’t exist in that list or get call, so then we would have to make a supplementary call. In certain cases we couldn’t fix that, it was there for specific reasons, but we did cut out a lot of unnecessary calls and a lot of these secondary calls that just made the integration a bit funky. So now some of the resources are pretty clean, where you just have your CRUD actions, your create, read, update, delete, list, and that’s all you need. But if you look at V1, you’ll see that there’s like five versions of update, it was update this, update that, update so on and so forth. And we did release the API in a public beta type of thing, so we did release it, we didn’t upgrade all of the tooling and the Go clients yet, we did have these nightly builds of them, but we wanted to kind of put it out there and get immediate feedback from customers, because once we go with a hardened “this is V2” and then we integrate all the tools and our clients, it’s really hard to make those changes later on. Because I try to be very conscious about, if we change this field or if we change this call, like adding data to these calls, not a big deal, but changing the behavior, that’s, I want to limit breaking changes as much as possible. So that’s why we released it as a beta early on and tried to get as much feedback to see if there’s anything that any customer may or may not have liked, or what were the pain points, and just trying to get as much feedback. Because once we cut a V2, or once V2 became behind a GA and all the tools got cut over, that’s when I was just a bit more worried about, I want to make sure that we’re not going to be inherently breaking tools down the line, or integrations, or whatever the case may be. Because that’s always a concern once you kind of make something go GA, especially an API, and I try to limit that with everything we do at Vultr.

Yeah, well, I mean kudos to you for mentioning breaking changes enough times, so thank you for honoring the podcast, that’s awesome. Because I don’t always get that, but yeah, you took it home there. That’s the pain and suffering that people experience the most. So a lot of the customers I talk to, they’re just scared to death of releasing early like this. What gets you the confidence and the ability to release like this early on and get feedback?

So we do that with a lot of things. We did that with load balancers, we did that with Kubernetes, where we kind of call it a beta, and I try to be very clear, like, hey, this is a beta, use it, but I don’t say don’t rely on it for production, but just use it, try to give us this feedback. Because there’s a lot of things, I can account for what a Kubernetes or what a load balancer should have, but I’m more interested in what users are kind of using it for, because I don’t know what all the edge cases are. The cloud is so vast, where I might think, this is a bad example, let’s just say I don’t need HTTPS, I’m like, I don’t need SSL, but it turns out we release a product and everyone’s like, where’s TLS, we need HTTPS support on a load balancer. So I kind of like that feedback loop, because there’s so many of these edge cases that I can’t account for, I’m not even aware of. So releasing these products, I try, we try to polish them up like they are working, we call them beta, but everything is pretty much done to the point it’s more or less, it’s beta, but what features are we missing, or what features aren’t working the way you would think. So it is a bit, you mentioned people are scared to death, and it is a bit scary, because we’re releasing this product that may or may not have all the bells and whistles that a user might want yet. So like sometimes the feedback is good, and you’re always thinking in the back of your mind, like, oh man, someone’s going to get really upset and then just completely write a mean ticket or something. But I think for us it’s, if we release it, I’d rather release it early in a beta state and get that feedback and just see what works, what doesn’t, and work with our customers and our community and just fine-tuning it for them. Because again, I can only know so much about how they would use it, because the cloud, so that’s, I think that’s interesting about the cloud is, you’ll be surprised to see how people are using a load balancer, Kubernetes, or instances, or DNS. Like some people have really creative solutions that I’ll look at and I’ll be like, oh wow, I would have never thought of that, that’s really interesting. So I think for us, releasing these things early on and asking and working with our users and our community, whether that’s open source or just early adopters, to kind of fine-tune and adapt and iterate over these products, is a better kind of way of working about it, as opposed to just releasing it and calling it finished, and then not being open to that feedback loop.

Yeah, and you’re going to not waste as much time, that feedback loop gets shortened, rather than it being an 18-month feedback loop where you put an API out there, or two, three years, it’s shortened and condensed, so it’s much healthier. So what’s the next year hold for Vultr? What’s top of mind as far as what you all are into, investing in with your roadmap? What are customers needing, what’s the most important part of what you’re building?

So one thing we recently kind of teased on the Vultr home page is we are working on databases as a service, will be coming out. So that’s one thing that we kind of already announced, which is in the pipeline, which is exciting to kind of get out there for users. And I think in relation to that, what we kind of want to do is we really do want to tailor to our customers. Like if I’m deploying this entire application to this entire stack, we want to make sure that they have their databases that they can connect to Kubernetes and load balancers and kind of not have this sprawl of multiple products, like the hyper cloud providers may or may not have, where it’s like there’s like 16 different container solutions and it’s like, which one do you use, but rather having all of these critical core products that are easy to use, that have predictable pricing, that just work. It’s just like really easy Lego pieces that just kind of click into one another. Other things we’re kind of working on, we did just release our 25th location, which is really cool to see, it is Mumbai, so we have 25 regions worldwide. And we’re working, especially, I can talk for Kubernetes and VKE, where we’re working on a lot of cool features, automatic upgrades, and allowing VKE, the Vultr Kubernetes Engine, to be on more regions, and along with some other things that are kind of in the pipeline with that is high available control planes. So in regards to Kubernetes, we’re looking to get it in more areas for more users, and making it simpler, making these harder components like high available control planes easier for all users to kind of have. It’s just, the way I look at it is, if I have a Kubernetes cluster, regardless of where it is, it’s hard to do a high available control plane and wiring it up and configuring it. As a user I just want to click a button on my control plane and convert it to be highly available. So there’s a lot of things like that, like for existing products we’re looking to enhance them and make them more feature-rich, easier to use, and kind of streamline them a bit more. And one thing that’s on my mind is making it easy so that all these components can kind of click into one another. For example, load balancers and block storage with Kubernetes, that they’re natively supported, you just kind of deploy your Kubernetes manifests as Ingress or load balancer type or PVC, and they automatically get deployed and they’re linked on your account, your account can show you, like, hey, these resources are part of this and they’re all kind of intertwined, and you have that ease of use to kind of see things and switch things around. So as we kind of evolve a lot of these products with something like database as a service, we’re looking to see what’s the easiest way we can hook this into Kubernetes or a load balancer or whatever the case may be, just kind of looking holistically at all of our products and kind of bringing them in closer together. There are other things we are working on, but I can’t announce them just yet, but they’re definitely some exciting things in the pipeline that over the next few months or so we’ll be rolling out, which I think a lot of our customers will be very excited to see, so we’ll stay tuned for that.

When it comes to the regional deployment, is the primary driver of this performance and being closer to customers, and/or is it regulatory and that?

So yeah, like we’re looking at, a big portion of it is like, where are a majority of our customers and what’s the closest we can get to them. So most of our customers, when they’re deploying cloud resources, they always want their resources as close as possible to them, for latency reasons or whatever kind of specific use case they want. But enabling our users to deploy any one of our products that we offer as close to them as possible is definitely beneficial for them, because now they don’t have to worry about the only location in Europe is Frankfurt, or the only location in the US is either US West or US East. We kind of have a global footprint that enables users to deploy as close as possible to them. But it also enables them to have good options for failovers, so if we’re in US East, let’s say New Jersey, New York data center, but we want to fail over but still have it on the East Coast, we offer a Miami data center there. So it enables users to get, one, to have it as close as possible, but two, also offer them more options in what they’re building out, if they choose to have these failovers or these more interesting kind of infrastructure build-outs or whatever it is they’re building. So for me, when I’m looking at it, I’m looking at how close can I get it, but then what kind of failover paths do I have, do I have multiple points where I can kind of have my infrastructure fail over, or can I build my infrastructure in a way where I have one central location and then it kind of sends data out to multiple regions, kind of like in a CDN type of manner, where I can kind of spread out my data to where my applications’ users are. So I think the biggest thing is just enabling users more locations closer to them and just giving them the option, instead of just like eight data centers or whatever the case is. The more options you have, the always better off you always are.

Yeah, agreed. So in this day and age right now, I manage a team of 25 people, and it’s a challenge to keep everyone motivated, working in the same motion. What are your secrets to staying passionate, driven, interested in what you’re working on each day, so that you can move things forward in this time?

It’s a good question. So for me, one of the biggest reasons, and I guess this is a bit of a cop-out answer, when I was working at Vonage, API design was one thing that I just became obsessed with. I don’t know why, it just, it doesn’t seem rational to me, like, what about APIs is interesting, but I thought, this is a gateway to your applications, and it’s the first thing you just kind of interact with. And that then kind of led me into the cloud scene with Kubernetes. So when I came to Vultr, I came here with a specific kind of goal, where I want to build out Kubernetes, that’s why I came on board. But I think that what we’re building out is just so unique and interesting, and the space is always evolving. Like if we look six years ago, there was no Kubernetes, it was just people were just deploying regular cloud compute and kind of configuring it. Or actually it’s more than six years ago now, but with Kubernetes now, it’s changing so much, like containers are kind of taking over, but then I don’t say Kubernetes is slowing down, but you’re seeing people kind of now solve these other interesting problems where they’re like, containers are great but I hate YAML, how can I now kind of automate that another level. So I think while we’re kind of solving for these managed load balancers, Kubernetes, all these kinds of solutions, it’s enabling us to also kind of think about, how can we, what can we do with this. We already have a managed container service, can we go another layer lower and kind of abstract it out, or maybe write some kind of custom resource definitions, or can we build on top of it, or what can we do. And I think that’s what always got me interested, because I was always looking to build these out in my free time before coming to Vultr, where I was obsessed with automation. I was trying to build something like Buildpacks, which builds your containers without the need of Dockerfiles. Those are the things that I’ve been fascinated about, automation and just kind of abstracting a lot of these layers. And shamelessly, I guess, but working at Vultr, that enables me to kind of be interested and work in these really interesting spaces and solutions.

Well, I’m super thankful for nerdy folks like you diving in, because I like Kubernetes, I’ve done enough just to scare the hell out of me and to know that I don’t want to become an expert in all of the minutia in there. So I’m super thankful that people like you are going to abstract that away from me.

You’re welcome. And sometimes, look, I’ll admit, there are some times where we’re facing some kind of, I want to say problem, but there’s this problem we’re kind of facing, and we’re just like, oh man, this was a mistake, let’s just go back to racking and just kind of doing this stuff by hand, like maybe that was the better way. But no, I think the advent of a lot of these things are just enabling developers to do more with needing less, and I think that’s kind of what automation, what really kind of drives me, is like, I’m obsessed with how can we automate this in a way that just really disconnects us. So that’s always kind of my angle when I’m approaching these things. So I think those are the killer things that we were kind of working on.

I like it. So back to the API design piece, because I, like you, I’m obsessed with API design, but I encounter a lot of, so putting on my hat of, I’m trying to move forward an API-first, design-first initiative within my enterprise organization, and I hit these pockets of resistance, folks who are, for lack of a better word, code-first, and they’re like, I try to show them the benefits of OpenAPI, and they’re like, I’m a programmer, I’m not a YAMLer, I don’t want to do these things. What do you say to convince them of the benefits of API design, and just kind of pausing? They’re like, we’re moving fast, we’re in the business of producing things and releasing, and your design-first approach, your focus on design, just gets in the way. What do you say?

That’s a good one, because I think there’s an upfront cost that people kind of get intimidated by. And I think the same goes with Kubernetes there, where there’s this hurdle. With API design, the first thing I did is I wrote out a rough OpenAPI spec, and that’s a 5,000-plus-line YAML, and you share that to someone, they’re going to be like, whoa, all right, what is this. I’m like, well, that’s the OpenAPI spec. And I think there is an upfront cost, and it’s like when you’re looking at it, with any kind of design work, you’re just like, I could have built half of it already by the time you kind of spin around messing around and monkeying around with this YAML spec. But I think what you get later on is, once that’s concrete, that’s a solid contract. And what that contract gives you is, we can take that YAML and put it into an OpenAPI spec parser for our application, so if we’re using it against our services, we don’t have to spend the time of updating and just trying to remember, what are all the definitions, like, all right, this field has to be a string, but we should use this when this is. We eliminate a lot of that headache, we have this defined spec that we can kind of share around the organization, regardless if it’s a public API or even if it’s an internal service. Like that specification, I think it also opens up a conversation as well, because I can share that with you for example, and we can kind of go like, all right, these fields make sense, this URI is a bit weird. So there is upfront cost, and people get scared by it, but I think later on, once you start implementing, or maintenance rather, once it’s already out there, people usually tend to see like, okay, I can see why we did this entire YAML, because now we just kind of feed it into our services when we’re making API calls and it kind of checks against it. And we also have consistent documentation. I think as developers we can all admit our documentation isn’t always the most up-to-date, because we have this difference between our application code and our documentation. So I might update the API for example with new fields, but then completely forget about the documentation. If we kind of take this design-first approach, we have this source of truth that our application will check against and that we can offer as documentation to our users. So the benefits to me are mostly around the initial conversation that may be painful, because people are like, all right, why am I looking at this YAML, but later on it serves as a blueprint, whether that’s validation against API services or just validation against public documentation or internal documentation that needs to be changed first, and then we all work against it, and it’s a source of truth. And I think, like I said, the initial hurdle is a bit rough, but once you have it, it’s pretty straightforward to update with tools like Swagger, Redoc, or Stoplight, or whatever else is out there, Postman as well, which we use. So I think for me, that’s, I have to kind of bite the bullet, I’ll do the spec, it’s one of those things where you’re happy that you have it once it’s there, but when you don’t have it and you need it, that’s when you’re like, oh man, this is really rough. So I think it’s one of those cases where it’s a hurdle, but the benefits that come out of it later on usually tend to show themselves to developers in situations where, if they didn’t have it, they’d be kind of upset.

Great, it really gets us on the same page when it comes to a human and a machine readable. So us humans, because I think we take for granted, as teams, like, hey, yeah, we got, we understood what you said, yeah, sure, parameters, headers, blah blah blah, but we’re not, and we make a lot, there’s a lot of inconsistencies. But then machine readable to get everyone on the same page downstream across all the tools we use, all the third party services, it’s pretty critical, but it’s hard to make folks see all that sometimes. So I’m always just trying to build that toolbox so we can convince the people, the skeptics, that can’t see it, and then convert them, because I think that’s the other part, is you got to convert them to kind of being believers and seeing the benefits, and then they’ll be on your team.

Yeah, definitely. I think that’s pretty much it, like from my experiences, once they kind of see the benefits, usually everyone, they won’t admit it, like they’re not going to be like, hey, you were right, they’ll just be like, grumpily, like, yeah, all right, I could, maybe it works, you know, that type of behavior.

Well, this has been great. I think I covered a lot of the areas. I definitely wanted to learn, I think the Kubernetes kind of abstracting away the complexity of Kubernetes, I’m super interested. But your own API journey, and then I would say your views on API design, are just a bonus for me, because that’s very helpful in what I do. But I really appreciate you joining me today and being part of this conversation and sharing your views of things.

I appreciate you guys having me, thanks.

Thank you. Thanks again to David for stopping by. You can find more on David at LinkedIn, and Vultr at vultr.com. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers. Thank you.