The Guardian’s Chris Stokel-Walker penned the TechScape newsletter earlier this month. As any good piece and its author will do, it sets bells ringing. His immediate subject focuses on Twitter’s ending free access to its APIs, and calls into question exactly how changes at that level will impact usage. Notably, his sources are all external, and his conclusions based on what notable people/organizations/bots have been observed to be doing on the public web. This makes sense, as even Elon Musk has been unable to quantify exactly who and what has been accessing Twitter behind the scenes.
So, as we happily travel down the Internet rabbit hole, the linked CNN story highlights Cyabra’s contract to externally monitor and analyze Twitter usage, and I’m guessing those folks were paid a considerable pile of money to deliver what they were able. So why couldn’t ex-Twitter-CEO Parag Agrawal just push a button (or call an underling to push a button) to produce an automated and accurate monitoring and analysis in the first place? And why wouldn’t a business to which APIs are so important have put a priority on that sort of capability prior to needing it in the first place?
The Cobbler’s Children Have No Shoes
The truth is that API programming stubbornly remains an industry in its infancy. Like cobblers’ children without shoes, the folks racing to create our programming interfaces have generally yet to take a breath to create any automation for themselves. If they have, they’ve certainly done it “bespoke” and without any recognized standard or consistent approach—who sells tools for such things? Which makes it all, thus, a giant opportunity for some enhanced “API APIs” and a hefty dose of “automation automation.”
The Expedition to API Skull Island
Every established market is announced by the emergence of its own (or pair or trio of) 800lb gorilla(s). You only knew music players were hot when there was Sony to make a Walkman, and then Apple with its iPod. To hatch Twitter, social media rose and felled MySpace, went through its Facebook phase, and is now TikTok-ing through its new flavor of the month. Financial transaction automation is so new that you really can’t say if Apple or Google or Visa or name-your-favorite-here is going to win the gargantuan primate race, but we surely know that “tap” is the next verb after “dial” on your phone, and definitely replacing “swipe” on your credit card. APIs enable and define each of these and countless other areas to stream music, socialize medially, and access the cash, credit, or crypto needed to do just about anything online. And no API area is hotter than FinTech. But who pounds their chest the loudest when API makers want to turn to someone to get help making, analyzing, running and monitoring their APIs? No monkey of any creditable size has yet to have their back.
What We Know to Be Coming
Like arms dealers to the sounds of battle, API monitoring merchants will daily keep emerging from the trees. Gorillas in other related disciplines, like Amazon (AWS) and IBM, are already pretending to the throne, but, like in Game Of, the most obvious contenders are generally the ones cut down during the first season or two while the long-term players put the work in to get it right. We can already see the flaws to such ponderous folk (do you use their Amazon API tools if you’re on Azure or Google?) and it’s easy to anticipate that the real winners are unlikely to be obvious in these early stages anyway. There are the current upstart boutique leaders, of course, (Datadog, Dynatrace, etc.) but Sony and MySpace looked great out of the chute, too. There are folks in infrastructure standards who are making noises, (Cisco, VMWare, etc.), but will they be able to keep their eyes on all their prizes when push comes to API shove? The list of hardware and infrastructure vendors that do code well is pretty short. (As in, unh uh, nope). So if you’re programming APIs and want to evaluate some automated assistance, how do you make sound early choices?
The Good News and The Good News
The good news is there is so much value to automating your API monitoring that any decent choice is going to have a creditable payback. Which is to say, even if you don’t pick the eventual winner, let alone a player who can last, you’re still not losing in the meantime. The better news is that a little attention paid to what you need will immediately clue you in to who is providing it. Chances are those providers are going to do well. So what questions would you like to answer? Twitter wants to know who is jacking into their API. I’m guessing you might also like to know how frequently there are errors, how quickly requests are being served, (based on geography, user, device, etc.), and what trends are emerging (by week, day, hour, and minute). Wouldn’t it be nice to know about problems before your users do?
With all these categories in mind, ask for a demo! Take ‘em off-script. Say what you’d like to see. Take note when they obfuscate vs take you right to the panel that shows you what you want to see. Get a feel for your choices. Then ask if you can take a test drive. If it’s good stuff, they’ll WANT you to prototype it.
The John Landry Acid Test
Don’t forget, it’s never as simple as which mousetrap may be better. It should be new and different. It should be valuable. The migration/implementation aspects should be easy. That’s all a given, and easy to quantify. But you also want to judge how well-funded each candidate might be, and how many other irons they have in how many other fires, and which ones might be ahead of the one in which you’re interested. Great tech undermined by not-so-great businesspeople is not just great entertainment. You want to invest your money where it’s going to accumulate power and return additional residual value through enhancements and other accruing benefits. When you go to the market to hire your next API programmer, you’ll love it when your favorite candidate already knows your favorite development tools.
Happy Interfacing!