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.
It's a pretty decent name for an API gateway.
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".
API Gateways are big deal in API first initiatives.
[1] https://techcrunch.com/2013/04/17/source-mashery-is-selling-... [2] https://techcrunch.com/2013/04/22/ca-acquires-layer-7-techno...
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.
2020: We are now discontinuing Apigee.
https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
Apigee is a different company and set of products.
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.
They can use their Euro cash in Europe for acquisitions and not pay the US taxes.
Think Microsoft / Skype. Skype was based in Luxembourg.
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.
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.
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?
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.
EDIT: I think Apigee has a great product, not wanting to put them down.
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)
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. (...)"
So, makes sense. They got them cheap as well, only a really small premium of the stock price.
(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.
> 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.
Does that mean there's a chance Apigee will get open sourced? (fingers crossed)
