Normally, ProgrammableWeb doesn't pay much editorial attention to mergers, acquistions, partnerships, customer announcements, and IPOs within the API economy. It's all "inside baseball" and our traffic patterns suggest that our audience isn't terribly interested in inside baseball unless it's a really big deal. Well, within the API economy, you'd be hard-pressed to find a bigger deal than Google acquiring API management solution provider Apigee. On the one hand, no one I know saw this coming. On the other, we might have anticipated it. Hindsight is, of course 20/20.
So, how did we get to this point in the API economy's history?
First and foremost, some interesting numbers: Apigee went public in April 2015 at $17 per share and it's been a bit of rocky ride ever since. On the day of its IPO, it briefly rose to $20 per share before closing on the downside at $16.68. Google has agreed to acquire Apigee for $625M which works out to be about $17.40 per share. During Apigee's outing as a public company, some pundits were mistakenly bullish. In 2014, on the eve of Apigee's IPO, SeekingAlpha's Don Dion called it the "Tech Buy of the Week." In September 2015, Zacks Equity Research called Apigee "a great momentum stock." I have no insight into whether Apigee's investors got what they hoped for (sometimes they take the money and run at the IPO, other times not). But I know enough to know that most public companies do not view an acquisition at 40 cents north of their IPO price to be a stellar outcome.
For Google though, it was a good deal. Maybe not as good as it would have been had it tried to make the buy in February when the company was trading at its 52-week low of $5.35. In its coverage of the deal, Recode said that "sources in the industry applauded the deal as smart (and thrifty) for Google." While I'm sure no one at Google sneezed at the deal, perhaps it helps to put it into financial perspective: Google's total value (its market cap) typically fluctates on a daily basis by more than 10x the price it paid for Apigee.
Google's acquisition of Apigee is the third such acquisition of an API management pure play in the last year (give or take a few days). By "API management pure play," I mean a solution provider that focuses exclusively on the management of the API lifecycle. In August 2015, Tibco, a company more traditionally know for solutions that dealt with enterprise integration and the business logic-driven hosting and choreography of event-driven workflows, acquired Mashery from Intel. Intel had previously acquired Mashery in April 2013 for about $180 million. Then, in June of this year, Red Hat, another company with strengths in integration and business logic, announced it would be acquiring API management pure-play 3Scale. And now, Google is acquiring Apigee.
To the untrained eye, the pattern isn't so clear. But to just about anybody that keeps an eye on the integration and API management sectors, it should be obvious.
Back in the old days of XML-RPC styled Web services (which are not very old) and beyond, the art of meshing large often dissimilar software systems involved a fair amount of business logic that lived at the heart of what would become known as an integration platform. Deep inside, often driven by Java source code that mirrored an enterprise's business processes, these platforms could support the sort of workflows whereby data flowing from one foreign system to another could be transformed and massaged for suitability to the recipient. And just some data's sudden arrival into one of these workflows was treated as an event that might trigger some other business process that was hosted by the same platform. Typically, wiring these platforms up to the various enterprise systems like those from Oracle or SAP required bespoke software connectors; essentially compatability shims that lived between the integration platform and the softwares that were being pulled into the integration mix.
If you were to diagram it, the brains (to handle the business logic) were in the middle with the connectors on the edge, living in the seams between the business logic and the foreign systems. Then, Web APIs came along and, to make a long story short, due to their reliance on existing HTTP standards (HTTP is the standard protocol that makes the Web tick), they started to take a lot of the bespokeness out of the bespoke connectors. Though very different architecturally from their predecessors, fundamentally, APIs didn't change the arrangement of the diagram. Where APIs were replacing connectors (and continue to do so), they were still pretty much at the edge, dealing with the seam. As the world began its shift to Web APIs at the edge, there developed a need for products and services to manage their sprawl and lifecycle which in turn gave rise to API management startups.
One API management pure play -- Mashery -- was probably the first to act on the opportunity. Back in 2006, when I founded Mashup Camp -- the industry's first event to focus exclusively on Web APIs -- one of the event's first sponsors to get in line to talk about what he was up to was Oren Michels; then the founder of Mashery. Clearly a visionary, Michels was talking about the need to manage Web APIs before most people knew what a Web API even was. So new was his startup that he was emailing me from his inbox at mit.edu instead of mashery.com. As a side note (and for those of you who like to connect the dots), the first Mashup Camp in February 2006 at the Computer History Museum in Mountain View is where I met and became great friends with John Musser who had just founded ProgrammableWeb.
As the API economy blossomed and the need for API management became more apparent, other pure-plays raced to help tame the edge. One of those was Apigee whose flagship offering is not surprisingly named Apigee Edge. The race included others like Layer 7 and 3Scale. But, as strong as these pure-plays were at what they did, they lacked a part of the diagram that was still important to enterprises; a platform of any sort to deal with business logic (be that for integration or even for a regular business application). As it turned out for their investors, this omission would serve them pretty well because as pure plays, they could be paired with platform providers who one-day woke up to the reality that they had better get hitched to an API management solution.
While Web APIs were becoming all the rage at the edge and guys like Oren Michels were right about the need to manage them, enterprises' need to accomodate the business logic part of the diagram was showing no signs of slowing down. Back in the integration world, a small handful of vendors -- Akana (formerly SOA Software), MuleSoft, and WSO2 -- who had found success in providing the logic platforms and connectors looked at the API onslaught and saw the opportunity for a natural marriage to offer what many customers wanted; a single throat to choke for both integration and API management. The result? In the 2012-2013 timeframe, they scrambled their engineering teams to add API management into their product and service portfolios; endeavors that all continue to this day (disclosure: MuleSoft acquired ProgrammableWeb in 2013). Despite routine derision of this marriage by the pure plays as a part of their competitive messaging, the trend that led us up to this week's acquisition of Apigee by Google clearly validates the early thinking that customers are better served by solutions that that can simultaneously deal with both business logic and API management.
While Akana, MuleSoft, and WSO2 chose to engineer their way to such diversification, the first integration vendor to buy its way into a marriage with API management was probably Axway when it acquired Vordel in late 2012. That was followed by the first acquisition of Mashery by Intel and CA's acquisition of Layer 7 in April 2013. In October of that year, Microsoft saw the potential in the marriage of platform and APIs and acquired Apiphany. In a bit of reporting for ProgrammableWeb that was eerily clairvoyant when it came to Amazon and Google, Michael Vizard wrote:
Microsoft immediately turned off the API management service; at least in terms of signing up new customers. Given that the acquisition of Apihany was led by the Microsoft Azure group the expectation is that the Apiphany technology will one day reemerge as a service on Azure. In fact, Microsoft’s end game appears to be an effort to develop an API ecosystem around Azure that will attract enough applications to give the cloud platform the critical mass it needs to compete with rival public cloud services from Amazon and Google. As cloud computing and the API economy increasing converge, major cloud platform providers are trying to ensure their long term viability by creating zones they can dominate within the larger API economy.
Google and Amazon have both famously tied the knot between their platforms and API management (although Amazon is still very early in its journey). But not before Intel realized it didn't own a real spouse for Mashery and set about finding one in Tibco, who, as more of a traditional integration company, lacked the prescience in the 2012/2013 timeframe to diversify by building or buying. Likewise, Red Hat may have waited too long to recognize the importance of API management to the customers of its various platforms (especially the Java-driven JBOSS). It dipped its toe in the water with an open source API management solution called APIMAN but ultimately resorted to buying its way into the business with its acquisition of 3Scale. APIMAN is being sunsetted and any of Red Hat's customers looking for ongoing support when it comes to API management will have to transition to the 3Scale technology. Such surprises can be painful and speak to the need to interrogate your solution providers to make sure they (a) have a very clear vision when it comes to the future and (b) are committed to that vision.
Meanwhile, Red Hat wasted no time in drawing attention to the kind of success that's produced when a single vendor can cover a customer for both platform and API management when it announced that Norwegian airport express train operator Flytoget signed up as a customer of both Red Hat's JBoss Fuse and 3Scale's API management technology "as part of an initiative to digitise and automate the company's key value chain."
Then, over the course of the last couple of years and in their efforts to marry their development platforms to API management, Amazon, IBM (Bluemix), and Microsoft (Azure) have signficantly ramped their API management capabilities (partially fulfilling Vizard's prohecy regarding Microsoft's acquisition of Apiphany).
Earlier this week, when I was at the Government API meetup in Washington, DC (a great meetup if you can ever make it), a group of us were talking about the pattern of API pure plays getting married-off to platform vendors as we tried to answer the question of who would propose to Apigee (it has been no secret that Apigee was looking for a buyer). We ran down the list of possibilities. SAP? Oracle? Both could benefit from a marriage to API management. Perhaps Microsoft or IBM? While they have pre-existing technologies, both are keen to gain more customers and have proven willing to do it through acquisition. The exercise was mainly one of looking for a platform provider of any type that was missing the API management puzzle piece.
Never did we guess Google.
But in hindsight, we should have. Google practically gave birth to the API economy when it launched the first Web API (Google Maps) in 2005. Very few companies understand APIs, and invests in them, the way Google does. Not just in providing them the way many other API providers do. But also in advancing the technology behind them. For example, gRPC and Protocol Buffers; both of which could shape the future of APIs. It was just last week that ProgrammableWeb wrote about Google getting serious about API management with the launch of its beta of Google Cloud Endpoints; a solution that can churn out an API for anything you've built on any of the Google Cloud Platform offerings (App Engine, Container Engine and Compute Engine). Applications? Microservices? It doesn't matter. They all need logic. So, very clearly, Google is positioning its solutions to be very prolific providers of APIs. But, whereas Google Cloud Endpoints primarily handles the development and provisioning part, what about the rest of the API lifecycle? Those APIs would have to be managed. So here again, much the same way that Akana, Axway, CA, MuleSoft, and WSO2 set themselves on a strategic course to marry platform with API management nearly four years ago (and others since), Google has recognized the strategic importance of a similar union.
Moving forward however, the acquisition raises several interesting questions and possibilities. For example, Apigee has previously partnered with Amazon to show how to use Apigee for AWS-powered applications. Given that Google Cloud Platform and Amazon AWS are now such fierce competitors in the cloud, will Google be so willing to partner with Amazon (or vice versa) on such endeavors in the future and where does that leave customers of the AWS-specific reference architecture offered by Apigee? [updated after original publication:] Another question, posed in one of the comments below is what this means long-term for Apigee's on-premise solutions given how Google's cloud positioning pretty much eschews anything on-prem. In response, another commenter pointed out how Google senior vice president Diane Greene mentioned in her announcement that Google remains committed to supporting an on-prem solution.
Additionally, one of Apigee's strengths was its independence. Most companies could do business with Apigee and remain relatively assured that Apigee would not go into competition with them. Given the many business sectors that Google currently competes in (or may venture into), there's now a stronger possibility that some of Apigee's existing customers and prospects could view Apigee as a foe rather than a friend. What then?
What do you think about the acquisition and the long term trend? Is this the end or are there more acquisitions on the way? Feel free to comment below and I'll be sure to respond.