Over the last few years, one of the more painful things to watch (from a business perspective) is how Twitter hasn’t been able to seriously capitalize on its insane popularity. The stock currently trades at roughly the same level it did one year before the 2016 presidential election.
In addition to being US President Donald Trump’s sole platform for speaking directly to his base (or ribbing opponents), Twitter has, over the years, evolved to be the official channel of communications for a great many celebrities, businesses, government agencies, movements (#MeToo, #NeverAgain, etc.) and other organizations. The list is simply too long to enumerate. As a communications channel, Twitter is almost invariably selected over the other alternative; Facebook.
Yet somehow, growth in the company’s stock hasn’t corresponded to its indispensability as the hotline between so many entities and their constituents. But, in my mind, now is when Twitter has an opportunity to leverage one of the hotter trends in the API economy by ripping a page out of the Amazon Web Services playbook. One that could probably generate some handsome revenues.
Networkable integration technologies like web APIs have been around for eons. Ever since Microsoft’s MAPI, Lotus’ VIM, and Novell’s MHS were competing for the hearts and minds of third party messaging application developers in the early 90’s, I’ve been writing about the evolution of networkable APIs. Every time a new one comes along, it is hailed as a savior from its predecessors. In other words, the typical web-based REST architecture where APIs are polled by their consuming applications is by no means in the end of the line.
In my view, the polarity of APIs is going to flip. Instead of polling APIs for their data and functionality (which is predominantly how it’s done today), API consumers will simply be waiting for that data and functionality to be streamed to them. The idea isn’t new. Some architectures for doing this — Webhooks and Websockets for example — have been around for a long time.
But, what is new is the minuscule cost of the resources needed to support such streaming architectures at scale. We’ve passed a tipping point where most organizations now have access to nearly infinite compute, storage, and network resources at a tiny fraction of the historical cost for such horsepower (forgetting for a moment that historically, you couldn’t even find that kind of horsepower idling somewhere on the planet).
One relatively new technology that deserves credit for this trend is the so-called serverless function as a service (FaaS). When applications are properly architected to take full advantage of FaaS, over or under-utilization of resources is an issue that practically disappears. Application footprints expand and contract in direct proportion to the number of consumers (people, apps, etc.) consuming them at any given millisecond. I never thought the pay-as-you-go model of IaaS would become obsolete. If it isn’t now, it will be soon. Thank you FaaS.
If you could have groceries streamed to you on an as needed basis for no additional cost when compared to “polling” the grocery store once per week (and you probably will some day), why would you ever go back to the store? In my mind, the idea of polling APIs is like IaaS compared to FaaS; already obsolete. Newer streaming API technologies — ones like gRPC that can stream in multiple directions at lightning speeds — will eventually seal the fate of older slower approaches. Several startups are hot on the trail of this trend, eager to serve early adopters who have an idea of how streaming APIs can make them better, stronger, and faster than their competitors that are still stuck in polling mode.
No single company is better positioned to capitalize on this trend than Twitter. Via its subsidiary GNIP, Twitter runs the most famous streaming API on the planet; aptly known as the Twitter Firehose (but technically, it comprises a combination of APIs known as PowerTrack and Decahose). According to Twitter’s website, “We provide realtime data as well as access to every publicly available Tweet dating back to the very first Tweet from March 21, 2006.”
Can you imagine how Twitter’s Firehose has to scale just to deal with the accounts with the top three followings (Katy Perry, Justin Bieber, Barack Obama) all the way down to #20: Donald Trump? When you consider the sheer volume of Twitter activity that someone like Donald Trump can spawn with just a few keystrokes with nary a Fail Whale in sight (remember Fail Whales?), you have some idea of just how good Twitter is at running secure scalable streams.
Today, Twitter offers enterprises a variety of services that are all connected to the data that Twitter itself has to offer. Perhaps now is the time for Twitter to pull an Amazon and make the same technology it built for itself available to enterprises who want to build their own firehoses. Twitter has the technology, the track record, and the brand. But does it have the will?