aws-app-mesh-roadmap icon indicating copy to clipboard operation
aws-app-mesh-roadmap copied to clipboard

Integration with AWS Lambda

Open akahen opened this issue 6 years ago • 55 comments

akahen avatar Dec 11 '18 21:12 akahen

Hey @akahen, thanks for opening an issue for this. Would love to hear more about how you would use App Mesh with Lambda:

  • Would you use the Lambda as a service, an ad-hoc/scheduled (mesh-aware) task, both?
  • Do you use API Gateway with Lambda for service request routing, AuthN/AuthZ, etc.? For a similar service in App Mesh, would you would want to keep it in place for ingress at the edge (i.e. Requests -> APIG -> Lambda -> Envoy -> Other Lambda/ECS VirtualNodes)?
  • Something entirely different?

bcelenza avatar Dec 12 '18 20:12 bcelenza

I would love a use case of APIgateways and lambdas to give you the answer above. Many api gateways against many lambdas with S3 /cloudfront frontend. This is a pretty common pattern.

augustorosa avatar Dec 16 '18 19:12 augustorosa

Mainly APIGateway + Lambdas and AppSync.

Are you planning to add a wrapper like X-Ray? Or go really down-level and talk with the Nitro/Hyperplane team (the "Mesh everything" world)?

Vittoriusly avatar Dec 21 '18 16:12 Vittoriusly

We'd love to hear more customer use cases before narrowing down on the approach, but both ideas are interesting!

bcelenza avatar Dec 26 '18 17:12 bcelenza

I think giving Appmesh the ability to directly invoke a lambda would be extremely powerful. For instance I've used Kong in the past to invoke Lambda on an HTTP request and used it as an arbiter between services that run in lambda and those that run in docker or some other long running process. The implications of having a mesh that can interface EKS/Docker/ECS directly with Lambda are huge.

charles-d-burton avatar Jan 02 '19 17:01 charles-d-burton

We have an API server with many endpoints. It's currently implemented as a monolithic service, and we are transitioning it into a set of micro-services, each of which handles a subset of the API's routes. Some of the micro-services are implemented in containers, and many will be implemented as lambdas. So having requests routed to both containers and lambdas is super-useful.

kennovak-zy avatar Jan 05 '19 21:01 kennovak-zy

We have a ton of Lambdas running in basically three "layers". External (API's, datatransformation, validation), Internal (backe-end) and "workers" (schedulers, calling other API's, etc.). We trigger Lambdas through APIGW and SQS mostly but a lot of Lambda Invoke and some S3 as well. Our main problem is that it is becoming "messy" and difficult with versioning as we really have no way of handling versions other than creating multiple SQS queues and/or S3 buckets (or in some cases write a "µService Lambda" to handle the routing.

So, for us it would be mostly about triggering µServices (=Lambdas) and Tasks, but as we are very familiar with (and love!) Lambdas we'd be happy if it is implemented in all parts (as a choice). Being able to fire Request->APIGW->Envoy would also be a good case for us as we have quite a few "ANY" API's where we handle Auth/Authz in the APIGW Authorizer Lambda so that would need to stay and trigger prior to the Envoy...

QAnders avatar Jan 08 '19 07:01 QAnders

Our team currently has API Gateway that routes to several different lambdas that have several nested layers. We are migrating some of those lambdas to Fargate/ECS and would love to use App Mesh with to manage all of the communication between the microservices.

In order to do that though, we need to be able to have APIGW -> Envoy and APIGW -> Lambda -> Envoy support. As QAnders@ mentioned, having API Gateway in the mix allows us to perform authentication (via custom authorizers, Cognito user pools, or vanilla IAM) and integrate with our existing system.

Given the general "newness" of Fargate and App Mesh, I expect many teams like ours would be coming out of the woods to migrate from Lambda -> Fargate/ECS to mitigate some of Lambdas current pitfalls (cold start times especially in VPCs, concurrent request handling and deduping due to container request level isolation, difficulty of change management for larger more complex systems, etc).

rhermes62 avatar Apr 11 '19 16:04 rhermes62

We are looking for solutions to call a virtual service in app mesh directly through aws lambda. Is this usecase a subset of this request? If there are existing approach, can the team please share the same.

rverma-nikiai avatar Apr 22 '19 11:04 rverma-nikiai

Would love to see something that fixes the issues that Charles described.

johnculkin avatar Apr 23 '19 00:04 johnculkin

+1 on having it invoke Lambda

alvarow avatar Apr 26 '19 19:04 alvarow

we could definiitely see a use case for lambda's behind an API Gateway

bostrowski13 avatar May 28 '19 13:05 bostrowski13

+1 for this feature. Currently our application uses both Lambdas and Containerized microservices. I have been searching for a framework that would allow service discovery across both these types of microservices. What I have found so far is a framework called, Gloo. This framework pretty much solves the problem (also using envoy by the way), but introduces a third party API Gateway into the mix. I'd be very interested to use stock AWS Services to achieve the same result as I am leery to introduce a third party mesh into our application. I'm glad to see that this is in the roadmap, if only in the researching phase.

mikebaum avatar Jun 11 '19 11:06 mikebaum

+1. We have a lot of workloads in containers today that really are either static content or simple stateless microservices that could easily run in Lambda. It would be great to have a service mesh across functions and containers so we can provide the same security tools/layer regardless of where the code runs.

darionalanya avatar Jun 25 '19 16:06 darionalanya

Really disappointing this does not have higher priority after six months. :-(

dvins avatar Jul 15 '19 23:07 dvins

+1 We have a mix on fargate containers and lambdas and it'd be great to have service mesh that covers both.

badgerparade avatar Aug 15 '19 10:08 badgerparade

@akahen Is there any new messages of App Mesh Integration with AWS Lambda?

rts-gordon avatar Sep 19 '19 05:09 rts-gordon

@CHCP Thanks for your continued interest. Our roadmap project continues to be up to date on the features we're actively working on. If you have any additional input on your use case, please do let us know here so we can incorporate it into our research.

bigdefect avatar Sep 19 '19 22:09 bigdefect

Hi @efe-selcuk , thanks for your reply. We have launched many microservices in AWS lambda, they need service call with each other. The best way is use AppMesh in Lambda, otherwise use APIGateway or Step Functions for service call, it is not good enough. So would you like to let me know: when AppMesh available in Lambda? Thank you very much.

rts-gordon avatar Sep 20 '19 11:09 rts-gordon

Hi @CHCP we will update here when we start working on this, we are targeting this feature for next year at this point. Can you please elaborate on what features you need beyond what you can get with API Gateway?

shubharao avatar Sep 20 '19 23:09 shubharao

Hi @shubharao , I want some features with "AppMesh in Lambda" such as: service registry, service discovery, Circuit Breaker. It is enough in the early. Thank you very much.

rts-gordon avatar Sep 23 '19 09:09 rts-gordon

Hi @shubharao, do you guys have an update for us in terms of when you will start working on this feature OR the app mesh features that will support?

isaac-mj avatar Jan 17 '20 15:01 isaac-mj

Does anyone know a date when the feature will be launched where AppMesh can directly trigger a Lambda?

canagey avatar Feb 09 '20 07:02 canagey

I'm a bit confused, since some AWS-authored posts mention AWS Lambda as one of the supported use cases. For example:

"App Mesh dynamically scales to hundreds of thousands of pods, tasks, EC2 instances, and Lambda functions, adjusting configuration changes accordingly as instances scale up, down, and restart." https://aws.amazon.com/blogs/compute/learning-aws-app-mesh/

Are these blog posts wrong?

turiphro avatar Feb 17 '20 10:02 turiphro

+1 For using AppMesh with AWS Lambda & API Gateway.

Cloudfront hosted React SPAs using Lambda/APIG services is our business' primary production application pattern (like @augustorosa noted over a year ago). AppMesh could make a huge difference for us with service to service Lambda communication, and we'd love to use it. We are using private VPC APIG endpoints and Lambdas, which contributes additional latency. Chained invocation of Lambda/APIG REST endpoints (especially private ones) have significant performance penalties. It seems like AppMesh could make these Lambda to Lambda invocations much faster by bypassing the APIG and directly resolving the service URLs to the individual Lambdas, while still allowing the Lambda code to use the full service URLs.

We would also love to mix and match Lambdas with ECS services sharing the same URL and compare performance.

Is the roadmap prioritized top to bottom? Meaning, since "Integration with Lambda" is at the top of the Researching column, does that make it the next feature to work on? Or is it an unordered list?

dnalbach avatar Mar 03 '20 17:03 dnalbach

We are actively working on this. We have opened an initial PR in Envoy's repository for Lambda integration. Once that PR is merged (and a couple other follow up PRs) we'll be ready to expose the functionality through App Mesh's API.

marcomagdy avatar Mar 07 '20 07:03 marcomagdy

Presently I'm using [Lambda A] -> Invoke() -> [Lambda B] for synchronous flow (request-response). It bypasses the API Gateway. It's not too bad, but as per Security Overview of AWS Lambda the traffic will leave the VPC boundary.

For asynchronous flow, I use [Lambda A] -> SNS -> [Lambda B]. I found it to be more flexible than Asynchronous Invocation, due to better retry policy.

For local testing (local lambda inter-communication), I'm routing Invoke() requests via Amazon Lambda ASP.NET Core App Mesh. This works for ASP.NET Core apps only ...

That's a temp solution. Ideally, AWS App Mesh would be a much better solution. The traffic stays within a VPC and is low latency.

clearwaterstream avatar Apr 06 '20 21:04 clearwaterstream

@marcomagdy Any update on this? I saw the PR was merged.

s-stefanov avatar Apr 07 '20 10:04 s-stefanov

@s-stefanov things are progressing for sure. That PR was only the first one :) we've been working on others and they've been merged as well. We are working on the App Mesh side of things now to expose that functionality. So, stay tuned. Even though the thread might be silent, rest assured, we're working on it. It's a top priority.

marcomagdy avatar Apr 08 '20 16:04 marcomagdy

Hi guys - From a use case point of view. We would love to see the two following use cases supported:

  1. Lambda -> AppMesh service
  2. AppMesh service -> Lambda

Particularly, the first use case seems more of a show stopper. We have a mix of microservices running on Lambda and Fargate (to be migrated to the Mesh). However, the only solution to call these Fargate microservices from the lambdas is deploying an ALB + Virtual Gateway (one of the biggest benefits of AppMesh is removing LBs).

Are there any other workarounds to this problem without additional infrastructure? Would this use case be covered in the current implementation of this feature? Any idea of timelines (Q3/Q4)?

isaac-mj avatar May 22 '20 21:05 isaac-mj