To build, or to buy, that is the question
To build or to buy, that’s a constant question we ask ourselves as software engineers. In this episode we dig into the nuance of these options and the space between them with an eye toward both the building of software and its eventual maintenance.
Matched from the episode's transcript 👇
Kris Brandow: I think from a maintenance perspective, a maintenance side of things, this is an area where it absolutely makes sense to really lean heavily into this idea of standardization and only open standards. I think that there is a rather large amount of upfront cost though, because standards do take a lot of time to develop, you have to be very careful, you have to be able to think and project into the future in a way that people just really aren’t used to.
I think gRPC is a good example of this. gRPC is really nice - you write a protobuf file, you write some APIs… Real easy to get started. But almost every place I’ve been, gRPC becomes this kind of mess where every time you wanna do something, every time you wanna change something, you’re adding just more new methods, and there’s not a lot of documentation infrastructure around it, so you’ve gotta build that up on your own, or you just have this human documentation system where you just go ask people…
[47:44] And when I look at HTTP, I see a system that’s – you don’t care about the version of Facebook or the version of Google that you land on when you navigate to that website. You don’t care about any of those things that we have to care about when it comes to APIs. And the whole system just works. And there’s a beauty to that, because you can kind of swap things in where you like, you don’t have to use a particular thing. You can experiment, you can try new things, you can develop new things. And that is, in my experience, extremely difficult to do with bot solutions, especially when it comes to SaaS solutions. I think a lot of SaaS products have this incentive to make it hard for you to move away from them, and make it hard to interoperate with other solutions. And we do have some standards around things that people offer as SaaS products, but those never feel as robust as something like HTTP, or something as robust as TCP.
And I feel like there’s another side to this, as well. gRPC is built on top of HTTP/2, GraphQL is also built on top of HTTP… But it’s always struck me that there’s these things that we build on top of them that are this buy model. The thing you get with gRPC is a bunch of code. You don’t have to go implement something yourself. But it kind of breaks the model as well. gRPC is not just HTTP. You can’t do a lot of the things you can do in just regular HTTP with gRPC. So it’s not the same amount of flexibility.
So we kind of think from that perspective, it’s like “I would like us to be able to buy more standards. I would like us to be able to just use HTTP by default and layer on the stuff that we want after the fact, knowing that we’ll be able to change and modify it over time.