This is very interesting, and I am surprised it didn't happen a long time ago. The Lambda function integration opens up lots of new ideas when building API backends ready to be consumed by clients apps like, for example, a client-side Javascript application.
On the other side it seems like other extra functionality is limited and very AWS-oriented. If you are looking for an open source gateway that can be expanded with extra functionality, and potentially sit on top of the AWS-> Lambda integration, take a look at https://github.com/Mashape/kong (I am a core maintainer too, so feel free to ask me any question). Kong is accepting plugins from the community (http://getkong.org/plugins), which can be used to replace or extend functionality beyond any other gateway including AWS Gateway.
I think AWS is going after the Parse / Heroku market here, the combination of Lambda and this gateway make it more suited for that kind of implementation, they are missing out on the larger features that enterprise needs - the blog post doesn't really go into detail on how SOAP conversion works, and I doubt it's a cakewalk.
It's in legacy API services that places like Mashery and Apigee make all their real money, and I can't see large enterprises shifting their legacy services to EC2. It's quite forward looking. The satire on how EC2 may be deprecated is really not far off from where things are heading.
I always find it quite funny when only single OSS projects are mentioned as alternatives, there's so many more full-featured projects out there: Tyk (https://tyk.io) API Umbrella (http://apiumbrella.io/) and ApiAxle (http://apiaxle.com/) to name some. For more fine grained approaches there's also Vulcan (http://vulcanproxy.com/)
I have worked with L7 for a client which offers something similar. The whole thing was painful in a way.
The SOAP to JSON conversion is easy for baby SOAP or JSON requests using transformation. For larger ones they turned out to be complex.
Once you start with client started with using the "SOAP" converted to JSON apis, there were new feature kind of requests. Now the problem is somebody needs to be dig into that old code mess of SOAP web services. Or write new services and split requests between old and new services.
There will be performance issues because of the no of transformation doing on top of the request. Ultimately has to write plugins on top write performant transformation in a single piece.
Personally SOAP to JSON conversion will not be as simple as move to AWS, although I will assume Amazon will do far far better job on this than others.
vulcan is not for api management and beside that quality > quantity
What do you mean ? With vulcand you can implement your own middleware similar to kong. Also, it is written in go and you can use all existing go libraries.
Also, how can you gracefully reload kong if you need to add/remove/change a plugin ? With vulcand you just replace the binary, and send an USR2 signal to the running process. It will fork, wait for all connections to drain, and remove the old process
For deployment, again, you need to sync all lua files, with vulcand you just ship a compiled binary.
Kong doesn't have a notion of servers for each API, you need to forward requests to a haproxy or another load balancer for this. Also, I can see that backends are added by their DNS hostname. In order to achieve HA (backend redundancy) is there any way you can do it, assuming that nginx is caching the upstream dns values ?
About performance, I can see you are advertising about 1000 r/s using kong, and you need 3 machines for this (kong, cassandra, haproxy). I benchmarked vulcand and obtained about 12000 r/s on a more modest hardware.
"What do you mean? With vulcand you can implement your own middleware similar to kong."
Nginx is not an API management layer, right? It doesn't have the necessary features, but it's extensible so someone could build them. Mashape did, and they released the result as Kong.
Vulcand is in the same position as nginx. It could be a good choice for building an API management layer on, but it doesn't provide one out of the box.
> How can you gracefully reload kong if you need to add/remove/change a plugin?
You can gracefully reload Kong by executing "kong reload" (http://getkong.org/docs/0.3.2/cli/#reload). It pretty much works the same way: fork, wait for existing connections to drain, and remove the old master process.
> For deployment, again, you need to sync all lua files, with vulcand you just ship a compiled binary.
Kong has a few distribution options (rpm, deb, Docker, etc) that simplify the process (http://getkong.org/download/), so unless it's being built from source, the deployment is straightforward.
> Kong doesn't have a notion of servers for each API, you need to forward requests to a haproxy or another load balancer for this. Also, I can see that backends are added by their DNS hostname. In order to achieve HA (backend redundancy) is there any way you can do it, assuming that nginx is caching the upstream dns values ?
You are correct. Kong supports either a DNS or IP address for a backend service, and starting from 0.5.0 it will be possible to add more DNS addresses or IPs per each API. That will make Kong work in load-balancing mode (https://github.com/Mashape/kong/issues/157).
> About performance, I can see you are advertising about 1000 r/s using kong
Kong is basically built on top of nginx (a very solid core), and it can achieve a similar performance to nginx because all the data requested from the external datastore is being cached in memory. So pretty much the latency it's going to be nginx + Lua execution overhead (which is minimal, thanks to LuaJIT). I will run a better benchmark and write a blog post soon, trying to cover both single-node and multi-datacenter setups.
> and you need 3 machines for this (kong, cassandra, haproxy)
An external datastore (Cassandra - with plans to support PostgreSQL) is required because Kong has been built to scale multi-node and multi-datacenter in order to handle pretty much every use case and plugin/middleware. In very simple single-node use cases, Cassandra can live in the same instance along with Kong. I would say that in this regard Kong is inspired by a different philosophy (start small, grow big, even supporting hybrid cloud/bare-metal setups). Having an external datastore also means that Kong could support some pretty cool plugins, like multi-datacenter service discovery, API billing coordination, multi-region health checks, etc. For example today it is possible to rate-limit requests in an eventually consistent replication fashion across multiple data-centers.
On the other side it seems like other extra functionality is limited and very AWS-oriented. If you are looking for an open source gateway that can be expanded with extra functionality, and potentially sit on top of the AWS-> Lambda integration, take a look at https://github.com/Mashape/kong (I am a core maintainer too, so feel free to ask me any question). Kong is accepting plugins from the community (http://getkong.org/plugins), which can be used to replace or extend functionality beyond any other gateway including AWS Gateway.