Integration with AWS Lambda

[bcelenza]

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?

[augustorosa]

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.

[Vittoriusly]

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)?

[bcelenza]

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

[charles-d-burton]

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.

[kennovak-zy]

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.

[QAnders]

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...

[rhermes62]

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).

[rverma-nikiai]

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.

[johnculkin]

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

[alvarow]

+1 on having it invoke Lambda

[bostrowski13]

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

[mikebaum]

+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.

[darionalanya]

+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.

[dvins]

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

[badgerparade]

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

[rts-gordon]

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

[bigdefect]

@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.

[rts-gordon]

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.

[shubharao]

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?

[rts-gordon]

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.

[isaac-mj]

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?

[canagey]

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

[turiphro]

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?

[dnalbach]

+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?

[marcomagdy]

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.

[clearwaterstream]

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.

[s-stefanov]

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

[marcomagdy]

@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.

[isaac-mj]

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)?

[marcomagdy]

The use case is definitely something we're planning to support. The first step is to get App Mesh -> Lambda first. After that, it's a logical step to do Lambda -> App Mesh.

Would this use case be covered in the current implementation of this feature?

The App Mesh -> Lambda is the one we're currently working on and will be launched first.

[dvins]

By the time AWS ever completes this we'll have gone Knative...

[barbaraokupna]

here is a roadmap - maybe useful : https://github.com/aws/aws-app-mesh-roadmap/projects/1

[clearwaterstream]

The issue is tagged with "Phase: working on it"

As per the FAQ on https://github.com/aws/aws-app-mesh-roadmap:

• Coming soon - coming up. Think a couple of months out, give or take.
• We're working on it - in progress, but further out. We might still be working through the implementation details, or scoping stuff out.

So it's "couple of month out" + "give" (i'm presuming) + "further out". Fingers crossed for seeing this released before the end of the year, or Q1 of next :)

If you need something now I would look at other options ...

[gvasquez95]

Any further progress on this subject?

[dvins]

It's not just this, #111 is a key part too.

[Stevef-aa]

With the introduction on Lambda Extensions I would expect this task to be simplified. Looking at the comments above there is a lot of pent-up demand for this capability so please can we have an update?

[CarlosDomingues]

@marcomagdy

The App Mesh -> Lambda is the one we're currently working on and will be launched first.

Could you share with us a little more detail on how that's going to work? Are we going to need an API Gateway or will a Virtual Gateway be able to trigger a Lambda directly?

Right now the API Gateway 30 seconds call limit is a huge deal breaker for AWS managed serverless adoption in my company, so if the second case could be supported that would be awesome.

[marcomagdy]

@CarlosDomingues I don't work at AWS anymore, so I can't comment much. I can tell you, however, that most likely it will use a virtual gateway and won't take a dependency on API Gateway.

[isaac-mj]

Hello folks, I just noticed that this issue was moved from Researching to Accepted. What does this mean for the feature? Are you not working on it anymore?

[dvins]

Six months and not a peep from anyone at AWS and going on three years since this ticket was introduced…

[michaelbrewer]

I am hoping for a ReInvent announcement on this one?

[vishnuvisnu]

Any update on this issue??

[herrhound]

No specific date yet, but this is definitely on App Mesh roadmap. Building the right experience for mesh to Lambda and Lambda to mesh communication is not straightforward. The next step for us is to post a proposed API design here to collect feedback.

[tomaszdudek7]

Any updates?

[dvins]

Find it rather astonishing, this issue, to integrate with AWS's own preeminent serverless Lambda capabilities is now three years old. On the roadmap itself (https://github.com/aws/aws-app-mesh-roadmap/projects/1#card-19515381) it has more upvotes than all of the items in We're Working On It, and is only a few dozen upvotes shy of having more votes than everything in the Researching column too. Yet it still languishes in Accepted.

[beam-freshket]

When will this one get worked on? I saw it on the roadmap with very high upvotes but it's not in the current work yet.

[herrhound]

@beam-freshket – it's not on our immediate roadmap, and we don't anticipate to release Lambda integration this year. The public roadmap is just one of the tools that we use to collect customer feedback on features. At every moment in time, we work on the top priority projects for our customers, and Lambda integration is not one of them right now.

[G31st]

The year is 2022... we have survived COVID... dodged WW3... heading into hyper inflation BUT still no lambda support ? PS there is still time to make reInvent:2022 !

[dvins]

Been following this critical feature request for a long time. After THREE YEARS of waiting for AWS to get into gear on this but seeing nothing other than waffling and often outright lack of response we finally gave up in May, and have since moved forward with a wholly different approach.