How Google's Acquisition of Apigee Was Just a Continuation of an Existing Trend

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 a 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 instead of 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.

David Berlind is the editor-in-chief of You can reach him at Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.




Nice insight! I am been following Apigee since the Sonoa days and believe the acquisition makes a lot of sense, especially to help Google drive into the enterprise space. 2 questions:

1) Would it put a question mark behin Apigee's on-premise offering? Google is know to not believe anything not in the cloud.

2) Would Oracle acquiring Amberpoint back in 2010 qualify as an early version of the trend you cite?


Hi @spacelord and thanks so much for replying. In answer to your questions, 

1. I think that's just another question worth asking at this point. I am trying to think of an on-premise solution offered by Google and I cannot think of one. That doesn't mean that one doesn't exist. It's just that one doesn't come to mind at the moment. 

2. The question you're really asking is whether the acquisition of an older SOA governance solution like Amberpoint qualifies and I just think that depends on your point if view. There's a POV that Services Oriented Infrastructure (SOA) is synonomous with RPC-styled Web services and that Web APIs are something so entirely different that they can barely be discussed in the same breath. It's no surprise that SOA Software changed its name (to Akana). It didn't want the SOA stereotype to sully it's positioning in the API space. If this is your POV, then I'd say the answer is "no" because you've already drawn a line in the sand and one doesn't necessarily carry over into the other.

But, my personal POV (and I'm sure I'll get some grief for this) is that Web APIs and the older XML-based APIs are both APIs and that the general architectural concept works off the idea that a software component can be turned into a networkable service to which other software can outsource their tasks. To me, they both fall under the rubric of service-orientation and a lot of people get hung up on semantics. "SOA" turned into a label that it should never have turned into because as a concept, I think Web APIs do a better job of capturing the spirit of service orientation then the older XML-RPC styled APIs do. One need only look at the microservices discussion to agree. Ultimately, microservices are services. Most of them are abstracted by RESTful Web APIs. Are we to suggest that is NOT a services oriented architecture? This is one reason ProgrammableWeb's data model is agnostic to these sorts of semantics. 

So, back to Oracle, if acquiring Amberpoint also helped the company to set itself on a strategic path to manage APIs of any feather, to govern service regardless of type, then I'd say yes, it fits into the trend. For example, though we don't hear much about it, Oracle actually has an API management solution. I haven't looked closely, but I'll bet that while it can stand independently, it's also pretty well tuned to Oracle's other solutions. Check out the path in the URL for its home page:

LOL! It's under "SOA." So, what I don't know is how or if Oracle's acquisition of Amberpoint is connected to Oracle's launch of it's API management product (Oct 2015). If they're connected, then absolutely, I think one could say that Amberpoint deserves to be on the timeline because it put Oracle on the path to where it is today. 


On the "on premise" solution - there's the Google Search Appliance, but my understanding is that it is being sunsetted.


Thanks for the very, very kind words, David. And, as always, your insight into how the pieces are arranging themselves. 

When we started Mashery I had a bit of an idea of what we needed to do, but a big part of my "vision" was formed by the amazing people I talked to during our early years. Some of them invested, some joined the Mashery team, and others became customers. But two who were in neither camp stand out.

The first is John Musser, who you mention. Rafer and I had previously founded a directory business, so we understood the value of a comprehensive directory to a developing ecosystem, and expected to build one as part of Mashery. But then I found out about programmableweb and this John Musser guy and reached out to him. My first trip on Mashery's dime was to Seattle to see John, who generously offered to meet with me and answer all of my questions even though our respective visions had no shortage of overlap.I quickly realized that Mashery and the entire market would be well served by leaving the directory business to John, and over the years we built a wonderful friendship (and I learned something every time I talked to him).

The second, of course, is some guy who had enough vision to start doing events around APIs and founded Mashup Camp, which spawned thousands upon thousands of hackathons in every corner of the globe. For someone new to the API world, it was amazing to be able to attend an event where likeminded people coming at the API concept from all different directions could compare notes and learn from each other. Cheers to you!


Hey Oren (@michels),

Thanks for writing in here. On the Google Search Appliance, I considered that.... but then I recalled reading that it was being withdrawn from market (as you suggested). Then again, as pointed out by another commenter (@Nick), Diane Greene said that Google is committed to supporting on prem "as always."  

Thanks for your kind words too. I agree on John and am thankful to have had the torch passed to me as we take ProgrammableWeb to the next level. So much has changed since those days. We have much work to do and a lot of it is at the foundational level. For example, we've been very busy building out our understanding and record of SDKs that go with all the APIs and we're tuned in like we've never been before to all the API versioning that's happening. So long as there are multiple versions of an API available to developers (not just older versions, but newer pre-release ones too), it changes the idea of having a single record for the closest-production API. So, we're modernizing our data model to reflect the maturity of the API lifecycle. 

I'm not sure that we spawned thousands upon thousands of hackathons ... but those sure were the early days of hackathons and I can't be thankful enough for the number of enduring friendships with brilliant people that came as a result of that work. And, had we never done that, I would not be here today at ProgrammableWeb.  It's crazy how one decision (thanks to an after-hours conversation with Google and Flickr) can change your entire life.


Regarding question 1, not so sure that the picture is that black-and-white.

First of all, Google seems to understand that for many enterprises (and that's where Google has to catch up), hybrid cloud is there to stay (at least for now). Hence their increasing involvement with OpenStack which is the main open source private cloud play.

Besides, their strategy to world domination is not to exclude other architecture options than public cloud, but just making it easier with their own solutions. So for instance for container orchestration, they have successfully managed to make Kubernetes the main contender, partially by embracing other platforms than just Google Cloud. Of course hoping that a large percentage of potential customer still uses GCP as their public cloud choice,

Given the clear synergies of API Mgmt and container orchestration/service discovery, they have announced that they will integrate Kubernetes and Apigee while making it work both in the public cloud and on-prem. see below.

From the google blog:

"Looking ahead, Kubernetes will be integrated to help enterprises get better control and visibility into how their internal systems talk to one another, an additional part of deploying services. As always, we'll make sure that these capabilities are available in the public clouds and can also be used on-premises."



@Nick, thanks so much for writing in with these great points and thanks for pointing out Greene's statement regarding on prem solutions (I've updated the post accordingly!). Although I'd point out that Greene wrote "As always, we'll make sure that these capabilities are available in the public clouds and can also be used on-premises."  On the one hand, "as always?" or is it really more recently in recognition of your point regarding the enterprise need for hybrid cloud support?  That said, she did say "public clouds" which leads you to believe that, at least in this case, she intends to remain cloud agnostic (as should be the case when Kubernetes is involved, right?). 

On the "black and white" issue, I don't think I meant to imply that it's strictly a black and white question to the exclusion of all other questions. There are of course many more permutations and possibilities when you consider the great many situations where API management naturally fits like a puzzle piece to a much larger picture that's ultimately more complicated than the one I painted. But, the question still remains given the long-term trend of API management companies getting married off to one platform provider or another.