When I Look At The Landscape Of API Services & Tooling I See The Future Of Technical Debt
08 Sep 2017
There are a number of API service and tooling providers that I still get excited about in the space. 3Scale, Restlet, Runscope, and Tyk - to begin with my sponsors! ;-) ;-) ;-) However, there are others like Postman, APIMATIC, Materia, OAuth.io, Stoplight, Apicurio, API Platform, API Umbrella, Github, API Science, and others that keep me thinking good thoughts about the things that API service providers are doing. However, I also see a lot of services and tooling that are simply playing the startup game, and have more to do with investment, then they do about APIs.
It is these services and tools I see as the next generation of technical debt. When you bundle the vendors who are usually chasing trends as part of their investment and exit strategy, and really don’t care about truly helping you solve your technical, and business challenges, with your existing problems, you are just multiplying your problems. These types of customers only want you as an active customer, preferably locked into a contract, with their services and tools baked into your operations. You know what all of this leads to? Technical debt. When you buy into the vendor stories, and jump on trends, without thinking through the consequences of your actions, and the long term effects on your road map, you end up with a significant amount of technical debt down the road.
I have taken a number of IT and developer leadership positions in my career, where I had to come in and clean up the mess from the previous guy (always guys). Nobody was questioning the decisions being made, and allowed someone to make purchasing, and technology decisions that ended up just taking things in a bad direction. That vendor we bought into was acquired, and now that tool we depend on is part of a larger enterprise suite we really don’t need, but because we can’t unwind it from our systems, we are forced to keep paying the subscription. We went for that trendy to way of doing things, decoupling, automating, assembling a framework, offshoring, outsourcing, and whatever came along with the current technological season, and investment cycle. We didn’t invest in internal capacity, or leveraging the web and standards, and now we are locked into this proprietary way of getting things done.
Ok, I get it. It is hard to see what is a trend, and which vendors are full of shit. I mean, they took us out to lunch, and were real nice guys. Right? They spoke all the buzz words, and seemed to really get the problems we faced keeping things up and running. I’ve made many bad decisions when it came to leading the IT or developer charge (I used to program in ColdFusion), but most of the time these were decisions that were handed to me, not ones that I made on my own (1/3 were my bad decisions ;-). These experiences have made me very skeptical about which technology I invest in, and the world of APIs has taken this to new levels for me–I trust nobody. This is the default stance I take now. I won’t adopt something new, or change the way I do things, if there is no way to easily recover, evolve, or mitigate form the decision. While the majority of these lessons have come from unreliable APIs, I still see many folks doubling down on API services and tooling that is going to burn them down the road. I just don’t think some of us are being honest with ourselves about how all this technical debt occurs in the first place, and somehow it is all just inevitable.