How ‘vendor engineering’ can help tame your API complexity

If you’re like me, you may blithely throw around terms like “microservices” and “APIs” and not stop to really, deeply, consider what they mean–or, rather, what they mean in context. But Taylor Barnett has thought deeply about them, and used an analogy that I found incredibly helpful for understanding why software has become so complex, and how to manage it.

It’s all about the supply chain.

SEE: 5 programming languages application solutions developers should learn (free PDF) (TechRepublic)

New, yet not new

No, there’s nothing particularly novel about talking about software supply chains. I talk about the open source supply chain all the time, and it’s become common to talk about “supply chain attacks.” But Barnett illustrated the concept in a way that made complete sense to me, prodding me to think about software differently.

Today, APIs are the building blocks of the internet, which has shifted our approach to architecting software. Software is now developed and operated in a totally different way than before cloud computing and APIs. Barnett wrote:

Like any industry that has grown and evolved, a supply chain forms around it. In industries that create physical goods, manufacturers don’t produce every aspect of their product in house. For example, automotive manufacturers like Ford, Toyota, BMW, and others are not making every piece of the vehicle themselves. They buy the metals from metal companies, computer chips from semiconductor companies, and tires from a tire company, who in turn is buying rubber from yet another company. There are hundreds of suppliers in the chain. This helps the industry be more efficient and productive.

Again, this isn’t new. Barnett isn’t the first to make this analogy (and, indeed, her post is actually focused elsewhere), suggesting that “Today’s software supply chain is heavily made up of APIs. Like a car part, we take chunks of code and piece them together to make finished applications that run on componentized infrastructure.” Not new!

But this was the first time, thinking about an automotive factory, visualizing the steering wheel coming from one provider, the engine from another, etc., that APIs became blindingly obvious to me. I mean, I’ve known what they are, and how developers use them, for many years, but it was this visual that Barnett painted that brought it all together.

And then she takes it a step further:

APIs are an abstraction of complicated systems, but just because APIs with great developer and operator experiences exist does not mean complexity doesn’t. Complexity is neither created nor destroyed–it’s just shuffled around. Instead of managing our own infrastructure, we manage the APIs that make cloud computing possible. Today, managing complexity is about managing the relationships between the different vendors, their APIs, and the components we use.

This does feel different, and suggests that the role of a developer, and the role of IT, has changed. It’s long been true that software development is as much about assembling existing code (an open source library here, a Stack Overflow entry there…), but this has become doubly true in our API age. It means that we must do a fair amount of “vendor engineering,” in Barnett’s words, to ensure the complexity of our systems is made more manageable by managing providers of our software.

Just like in that automotive use case. 

Disclosure: I work for AWS, but the views expressed herein are mine.

Also see