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/
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.
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.
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.
Gee makes me think Ghee which makes me want Indian food. Indian food comes from India where we outsource software development and APIs are used in software development.
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
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".
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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)
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.
"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. (...)"
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.
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.
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?
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!
Aw man I bought a bunch of these shares last year at $7 and sold for $7.90 after a few months. I was happy about it. Wish I held onto them, it's trading at $17 now!
