Solution & Integration Architect - AWS Cloud & Modernization at IBM
Dec 23, 2022
Lambda is the preferred compute option because of on-demand cost. We don't have to provision any hardware beforehand. We don't have to provision the capacity required for the services because it is serverless.
President at a computer software company with 11-50 employees
Jul 21, 2022
It is serverless and scalable. It can scale infinitely. You don't have to worry about the size of the servers that you're pre-allocating. You don't have to build server scale-out models. Auto scale and other similar features are just inherent in Lambda. So, for atomic and fairly non-persistent transactional units of work, Lambda works very well.
The utilization of containers is particularly beneficial in overcoming the size limitations imposed on Lambda functions which not only allows us to work around these constraints but also contributes to the improvement and maintenance of our code.
The solution is designed very well. You don't need to keep a server up. You just need some router to route your API request and Lambda provides a very well-designed feature to process the request.
The most valuable features are event-based triggers. They're really good for a reactive style when you want things to happen as soon as something else happens.
Solution & Integration Architect - AWS Cloud & Modernization at IBM
Dec 23, 2022
The first time Lambda is started up, it takes some time to spin up an instance for serving the consumer requests. AWS has been trying to solve this in a variety of ways but have not yet managed to do so.
President at a computer software company with 11-50 employees
Jul 21, 2022
My engineers work with it on a daily basis. I just don't have enough depth of knowledge about what kinds of edge cases they may have tried and found lacking. There may be some issues with some language support at one point or another because we couldn't get the underlying libraries in there. A lot of what we do is either in JavaScript, Python, or some of the non-compiled languages. I'm not sure if we've ever tried building a C# solution, for instance, in Lambda or a Java solution in Lambda. It doesn't mean those aren't its capabilities. I would rather refer to my engineers for where the boundaries are.
What could be improved in AWS Lambda is a tricky question because I base the area for improvement on a specific matrix, for example, latency, so I'm still determining if I can be the judge on that. However, room for improvement could be when you're using AWS Lambda as a backend, it can be challenging to use it for monitoring. Monitoring is critical in development, and I don't have much expertise in the area, but you can use other services such as Xray. I found that monitoring on AWS Lambda is a challenge. The tool needs better monitoring.
Another area for improvement in AWS Lambda is the cold start, where it takes some time to invoke a function the first time, but after that, invoking it becomes swift. Still, there's room for improvement in that AWS Lambda process.
In the next release of AWS Lambda, I'd like AWS to improve monitoring so that I can monitor codes better.
We need to better understand Lambda for different scenarios. We need some joint effort between Amazon and the users to have the users identify how they can really leverage Lambda. It's not about Lambda itself; it's about the practice, the guidance. There needs to be very good documentation. From the user perspective, what exists now is not always enough.
There's room for improvement in the solution's warm start, which refers to the minimum time it takes to start up a Lambda function if you haven't been running it.
Regarding layers, you need to manually zip and install them. This step needs practice, and you might need to do it three to four times to get a hang of it.
