Google to acquire Apigee(cloudplatform.googleblog.com)
cloudplatform.googleblog.com
Google to acquire Apigee
https://cloudplatform.googleblog.com/2016/09/Google-to-acquire-apigee.html
86 comments
Google didn't pay for the technology. Apigee has a good set of big enterprise customers that Google was missing on their cloud platform. As others mentioned, Google already have the tech: https://cloud.google.com/endpoints/
Google Endpoint was discussed last week on HN: https://news.ycombinator.com/item?id=12407061
Compare the feature set of Endpoints to Edge. There's more to API management than authentication and monitoring.
[deleted]
Was it really that much about customers? Apigee has less than 100 million in revenue.
2018: Support is discontinued. Please use our forums where intelligent bots will reply you.
2020: We are now discontinuing Apigee.
2020: We are now discontinuing Apigee.
2019: We used deep learning to automatically figure out what you wanted to call via the API. We also tried to update your code to use it, but your build is currently broken and your engineer is on a holiday and we estimate it will take 3 days to fix the build based on the average time between query and resolution time for your engineers based on their search history in our logs. We will do an auto-update when your systems are back up.
I thought the same thing. We saw this play out before with Parse. Not saying they play in the same space, but I think Google could just roll the Apigee features into Firebase and shutter the platform.
The good ol' MS motto *(back in the days..): Embrace, Extend and Extinguish.
https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
That's not the same at all. EEE was about adopting existing standards used by other products and then extending them with features other products didn't support.
~4 years is awfully sanguine.
I misread that as "to acquire Apple". Then I misread that again as "to acquire Apogee" (as in, the name 3D Realms went by from 1987 to 1996).
Now I'm wondering behind the reasoning of the Apigee brand. Was it an intentional play on Apogee Software of the 80s/90s? If so, why? Something about "playing with APIs" I presume, but that seems confusing.
Now I'm wondering behind the reasoning of the Apigee brand. Was it an intentional play on Apogee Software of the 80s/90s? If so, why? Something about "playing with APIs" I presume, but that seems confusing.
The word "apogee" literally means the highest point in the course of something. Apogee Software and Apigee both play off the english word meaning.
So there's that, and then the Apigee split out like Api-gee makes you think gee, that must have something to do with APIs.
Interesting. I wasn't aware it's an actual English word. I don't think I've ever seen it outside of the company name.
I keep seeing it as a really strange spelling of "a piggie" and then I think "there had to be a better name than that"
I thought I read apogee too. I remember their early 90s games like Rise of the triad and duke nukeem.
Apogee used to also be a compiler company, it's where the domain apogee.com has pointed as long as I can remember. They used to have a link to the shareware company iirc. Now it looks like they provide Java runtimes for embedded devices
Well considering Apigee is a public company with hundreds (thousands?) of large enterprise and has been around since the early 2000s... no?
It's a pretty decent name for an API gateway.
It's a pretty decent name for an API gateway.
Unless you're a timelord, the 1980s/1990s pre-date the early 2000s, so they must/could have been aware of the pre-existing Apogee brand when they decided on the name.
But as someone else pointed out, apparently "apogee" is an actual word in the English language, so they may have been entirely unaware of Apogee Software (or considered the brand sufficiently unrelated/dead not to cause any confusion).
The reason I'm asking is that to someone who doesn't know "apogee" is an actual word the choice seems as awkward as founding a technology company called "Atori".
But as someone else pointed out, apparently "apogee" is an actual word in the English language, so they may have been entirely unaware of Apogee Software (or considered the brand sufficiently unrelated/dead not to cause any confusion).
The reason I'm asking is that to someone who doesn't know "apogee" is an actual word the choice seems as awkward as founding a technology company called "Atori".
There is also Apogee Electronics the audio hardware company.
I also read it initially as "acquire Apple" and had to check the date...
Apigee is a pretty decent product if you are in the space. It's sort of kinda like a "CDN for APIs", if that make sense, which I've always thought is a great idea.
(Yes, I realize my analogy has limits. Don't get too hung up on it though)
I didn't realize they were a public company though.
(Yes, I realize my analogy has limits. Don't get too hung up on it though)
I didn't realize they were a public company though.
I think this is an excellent acquisition by Google, specifically for their cloud platform. It provides an excellent solution to the problem of managing apis and a tight integration with cloud platform will really make it stand out.
I think you work for apigee
Or he still has his stock options.
I wish. Can I get stock options for being optimistic?
Nah, only a useless job in mgmt or so. Maybe dogbert can help.
These various "API management" services have always struck me as value subtracting as much as value adding. Adding another moving part to a system doesn't make it more reliable.
One thing that has amazed me is that most of these services offer everything but the kitchen sink AND the one thing you need for a minimum viable product, which is the ability to charge for API calls.
One thing that has amazed me is that most of these services offer everything but the kitchen sink AND the one thing you need for a minimum viable product, which is the ability to charge for API calls.
What a bizarre acquisition. They say:
> A good API needs to [...] give developers the freedom to work in the development environment of their choice [...] a good API includes testing support
Those are two of the main reasons not to use Apigee.
> A good API needs to [...] give developers the freedom to work in the development environment of their choice [...] a good API includes testing support
Those are two of the main reasons not to use Apigee.
3Scale got acquired by IBM, and now APIGEE by google.
Time to buy Layer7 shares?
API Gateways are big deal in API first initiatives.
API Gateways are big deal in API first initiatives.
Mashery was acquired by Intel [1] in April 2013, Layer7 was acquired by CA Technologies [2] the same month.
[1] https://techcrunch.com/2013/04/17/source-mashery-is-selling-... [2] https://techcrunch.com/2013/04/22/ca-acquires-layer-7-techno...
[1] https://techcrunch.com/2013/04/17/source-mashery-is-selling-... [2] https://techcrunch.com/2013/04/22/ca-acquires-layer-7-techno...
Intel divested Mashery, along with Aepona and dropped their cloud services division.
3Scale was acquired by Redhat (not IBM): https://www.redhat.com/en/about/press-releases/red-hat-acqui...
Thanks for correcting.
My day job used 3scale. Actually it won out against apigee, mashery, and a few other big players. My day job liked a few others because they were associated to "big enterprise names" - especially since my day job is a big enterprise. I think 3scale were still kind of pricey, but way cheaper than the other big players...However, I give big kudos for 3scale support, especially during on-ramping.
IBM bought Strongloop last year as an API gateway play.
And https://github.com/strongloop-archive/strong-gateway was abandoned shortly thereafter.
The Strongloop and Datapower people are working on API Connect:
http://www-03.ibm.com/software/products/en/api-connect
It supports node.js and swift.
http://www-03.ibm.com/software/products/en/api-connect
It supports node.js and swift.
The major acquisitions in this space already happened...
CA bought layer7. Mulesoft bought programmable web. Intel bought and divested mastery. Microsoft bought Apiphany.
The last one standing is Akana, (formerly SOA Software).
APIgee was always a weird company to go public - I think it makes sense for them to be part of google. More of a feature that belongs in some other cloud management stack.
CA bought layer7. Mulesoft bought programmable web. Intel bought and divested mastery. Microsoft bought Apiphany.
The last one standing is Akana, (formerly SOA Software).
APIgee was always a weird company to go public - I think it makes sense for them to be part of google. More of a feature that belongs in some other cloud management stack.
Layer7 was acquired by CA Tech a few years ago
[deleted]
Fastly is the biggest one left independent I think. They've got some top clients like github.
They announced this a couple of weeks ago... im confused: https://cloud.google.com/endpoints/
Cloud Endpoints as announced is the second generation of Google's own system.
Apigee is a different company and set of products.
Apigee is a different company and set of products.
I wonder what the engineers on the Google team that just released that is thinking?
Apigee sent out the email today.
Well. At first I thought this was crazy, but then I realized Google was the only major cloud provider that didn't offer an API Gateway service... Azure and AWS both have one.
So, makes sense. They got them cheap as well, only a really small premium of the stock price.
So, makes sense. They got them cheap as well, only a really small premium of the stock price.
Google has endpoints, but it's pretty low level and a little hard to manage that way.
Never understood Apigee's core product. I like their whitebooks though. quite informative. So congratulations.
We use Apigee's Edge product. It provides API management tools like authentication, authorization, rate limiting, etc before the request hits your actual API. Its a pretty good product, if that isn't your core competency.
It's not a lot of people's core competency, which is exactly what makes API gateways so useful.
This way anyone can write some half-baked endpoint that returns some JSON, and you put Apigee or any of its competitors in front of it, taking care of the hard stuff like authorization, rate limiting, etc, without which you can have a really rough time.
This way anyone can write some half-baked endpoint that returns some JSON, and you put Apigee or any of its competitors in front of it, taking care of the hard stuff like authorization, rate limiting, etc, without which you can have a really rough time.
But apigee becomes a man in the middle, which is very bad for your security.
I imagine it's a tradeoff. It's worse for your security if you try to roll your own auth/auth solution and botch it.
Auth is a routine job, only a really silly developer manages to make simple token auth vulnerable. There's no a "tradeoff" in leaving auth to MitM because it's "hard", oh also there's bunch of libraries out there doing it for you on your servers.
Is it just me, or should API management be done through GraphQL? It doesn't seem like Apigee even uses GraphQL (unless I missed something on their website). Been looking at GraphQL recently, and it looks like it could be a solution. Any experience on using GraphQL in a prod environment?
EDIT: I think Apigee has a great product, not wanting to put them down.
EDIT: I think Apigee has a great product, not wanting to put them down.
We moved our entire api to Apigee at my previous job (500+ person fast growing startup). It certainly has value and was a great fit for us. Many aspects of the Apigee stack felt kinda weird and cumbersome though and I saw such a huge potential for improvement if you started with GraphQL as the base assumption instead of REST. So that's what we are doing at https://graph.cool/ :-)
We are currently in closed beta, but I'd be happy to personally onboard you or chat if that would be helpful. (contact in profile)
We are currently in closed beta, but I'd be happy to personally onboard you or chat if that would be helpful. (contact in profile)
Thanks for the feedback, makes sense to me. Although,I don't understand why mentioning GraphQL gets me downvoted. I'm trying to understand what advantages Apigee has using REST over GraphQL. No hating, just curious.
https://facebook.github.io/react/blog/2015/05/01/graphql-int...
"We plan to open-source a reference implementation of a GraphQL server and publish a language specification in the coming months. Our goal is to evolve GraphQL to adapt to a wide range of backends, so that projects and companies can use this technology to access their own data. We believe that this is a compelling way to structure servers and to provide powerful abstractions, frameworks and tools – including, but not exclusively, Relay – for product developersWe plan to open-source a reference implementation of a GraphQL server and publish a language specification in the coming months. Our goal is to evolve GraphQL to adapt to a wide range of backends, so that projects and companies can use this technology to access their own data. (...)"
https://facebook.github.io/react/blog/2015/05/01/graphql-int...
"We plan to open-source a reference implementation of a GraphQL server and publish a language specification in the coming months. Our goal is to evolve GraphQL to adapt to a wide range of backends, so that projects and companies can use this technology to access their own data. We believe that this is a compelling way to structure servers and to provide powerful abstractions, frameworks and tools – including, but not exclusively, Relay – for product developersWe plan to open-source a reference implementation of a GraphQL server and publish a language specification in the coming months. Our goal is to evolve GraphQL to adapt to a wide range of backends, so that projects and companies can use this technology to access their own data. (...)"
> As always, we'll make sure that these capabilities are available in the public clouds and can also be used on-premises.
Does that mean there's a chance Apigee will get open sourced? (fingers crossed)
Does that mean there's a chance Apigee will get open sourced? (fingers crossed)
$625 million in cash
Curious if they used cash from their domestic or international reserves.
Will have to be US cash because Apigee is based in the US.
They can use their Euro cash in Europe for acquisitions and not pay the US taxes.
Think Microsoft / Skype. Skype was based in Luxembourg.
They can use their Euro cash in Europe for acquisitions and not pay the US taxes.
Think Microsoft / Skype. Skype was based in Luxembourg.
They could sell bonds to Draghi and get paid to acquire it tax free.
If they use international reserves then they have to pay taxes on bringing the cash to the U.S.
[deleted]
So does this mean Apigee will be the captive API gateway for Google's extensive portfolio of APIs, or will the Apigee gateway still be offered as a product to put in front of a customer's custom API?
I think that it doesn't make a lot of sense for Google to use Apigee on its own APIs. They seem to do a pretty decent job of scaling, monitoring and securing them on their own.
What does make a lot of sense is a tool to give people who host on the Google cloud better control over who is using APIs they (the customers) produce. For example, you can imagine Apigee expanding to enable transparent scaling of (some) self-hosted APIs onto Google's cloud via intelligent caching.
What does make a lot of sense is a tool to give people who host on the Google cloud better control over who is using APIs they (the customers) produce. For example, you can imagine Apigee expanding to enable transparent scaling of (some) self-hosted APIs onto Google's cloud via intelligent caching.
It makes no mention of using it on Google's APIs at all.
Within the blog it elaborates on what they're doing by saying:
> Google cloud customers are already benefitting from no sys-ops dev environments, including Google App Engine and Google Container Engine. Now, with Apigee’s API management platform, they'll be able to front these secure and scalable services with a simple way to provide the exported APIs.
>As always, we'll make sure that these capabilities are available in the public clouds and can also be used on-premises.
If you click on the link and read the article it will give information behind the headline, possibly answering questions the headline brings up.
Within the blog it elaborates on what they're doing by saying:
> Google cloud customers are already benefitting from no sys-ops dev environments, including Google App Engine and Google Container Engine. Now, with Apigee’s API management platform, they'll be able to front these secure and scalable services with a simple way to provide the exported APIs.
>As always, we'll make sure that these capabilities are available in the public clouds and can also be used on-premises.
If you click on the link and read the article it will give information behind the headline, possibly answering questions the headline brings up.
I appreciate the summary but I was speculating about things that weren't said (in the article). Specifically, as you point out, the article makes no statement on whether they will dogfood Apigee for internal use, but recently they acquired Firebase where dogfooding it was a part of the play.
Meanwhile, there's these lines:
> Google cloud customers are already benefitting from no sys-ops dev environments, including Google App Engine and Google Container Engine. Now, with Apigee’s API management platform, they'll be able to front these secure and scalable services with a simple way to provide the exported APIs.
>As always, we'll make sure that these capabilities are available in the public clouds and can also be used on-premises.
It unnecessarily combines two different things in the same sentence; "you can continue to rely on your stuff running in Google App Engine and Google Container Engine"; and "you can front your stuff with Apigee Edge" -- yes, I can already do both of these things today. So what's the difference?
Meanwhile, there's these lines:
> Google cloud customers are already benefitting from no sys-ops dev environments, including Google App Engine and Google Container Engine. Now, with Apigee’s API management platform, they'll be able to front these secure and scalable services with a simple way to provide the exported APIs.
>As always, we'll make sure that these capabilities are available in the public clouds and can also be used on-premises.
It unnecessarily combines two different things in the same sentence; "you can continue to rely on your stuff running in Google App Engine and Google Container Engine"; and "you can front your stuff with Apigee Edge" -- yes, I can already do both of these things today. So what's the difference?
Buying offer is 17.40. Right now Apigee's trading at 17.42, short selling opportunity?
[deleted]
Apigee has a lot of smart engineers working on nodejs based open source projects and contributing to OpenApi spec (fka Swagger). Good to see that Chet K chose Google to acquire these talented engineers. And ofcourse the Apigee community is A++.
Hi firefoxNX11, it looks like you misspelled a link a year and a half ago and accidentally linked to a phishing site. You have been shadowbanned since, I saw you with showdead on. It looks like you have made constructive comments otherwise, perhaps a mod can help out!
I first read this as "Google to acquire Apple" and I found myself wondering if today was in the month of April.