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. 

We need to invest time in learning the tool's language variant. We have encountered instances of downtime as well. 

There are several things that can be improved, including:

• It has limited access to disk space, as it does not have full access to underline VM
• Lamba functions have cold-starts that can cause some delay
• It is hard to troubleshoot and monitor Lambda functions

There's always room for enhancement in terms of resource allocation and management for high-demand applications.

Performance issues can arise depending on how you allocate resources within Lambda. For example, if you're running a new application with a significant load, you need to be prepared for potential bottlenecks. 

It's essential to control network interactions and optimize for the type of application you're running. Lambda is excellent for small and lightweight applications, but for more resource-intensive tasks, you might need to look at other AWS services or a more distributed storage environment.

AWS Lambda could greatly benefit from enhancements in handling large-scale applications to support heavy workloads. This is actually feasible, but there is a need for further development in this area. 

Additionally, improvements in resource control optimization are crucial. For instance, enabling users to run data-intensive applications using a limited number of resources without compromising performance would be a valuable addition.

My opinion is that the integration could be improved in this solution. We have had some difficulties integrating the EC2 module, but we found a solution for that by ourselves. I would say the integration needs to be improved.

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.

We face some problems with the event-driven execution model.

The tool changes its UI every month which is very frustrating for me. I don’t know why AWS keeps changing the UI. They can’t stick to a specific one.

I don't have much experience after six months. I can't speak to the pros and cons. 

I have seen some drawbacks with certain integrations. 

AWS Lambda should support additional languages.

We must at least know the basics of languages like Python or Java to implement automatic processes and daily schedules. We must learn the Lambda function and the languages to use the tool.

The solution should continue to streamline integrations with AWS services. 

At one point, there was an issue receiving support for a new version. Support was behind by two versions and this presented challenges, but they caught up over time. 

I would like to see a find and replace function as part of Lambda's future releases. Currently, if we want to replace a code, we copy the code into Notepad, then find and replace it, and then copy that to Lambda. This would improve the editing function of the product.

Lambda would benefit from a debugging feature as well. For example, if you want to debug code running in Python and deployed in Lambda, it would be beneficial to have a debugging feature.

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. 

Lambda can only run for a maximum for 15 minutes. If you have a job which requires running for more than 15 minutes, you cannot use Lambda for that use case. 

I can only speak from the user experience. Salesforce integrates SharesPost efficiently. How? They say, "Okay, I invented another language called Apex. Forget about anything else. This is my language." The benefit of this language is that everything is simplified. Your system is super easy to maintain. But AWS then assures you that they are flexible, that they have a collection of 10 or 20 languages, and you just choose your environment and range. That's the reason I appreciate Salesforce. They always make things easier. They have their loop reasoning because they are a different kind of company. Microsoft and AWS really get the full spec. They want to own the business. But Salesforce data wants the simplest way.

So, this is my understanding and unique experience.

I think that perhaps Lambda could explore its functionality more.

There's room for improvement in the testing setup. Attempting to test it through the AWS CLI also posed issues, and when trying to test the Lambda function on my local machine, I encountered difficulties in obtaining comprehensive logs or error messages to diagnose what might be going wrong.

It can be a bit difficult to switch between accounts when creating services for customers. 

I can't recall any features that might be lacking. For us, it works quite well, however, it depends on what a company needs.

We'd love to see more integration potential in the future.

The execution time could be better. One of the major limitations is the time period because it doesn't give you more than seven minutes. So, before thinking about Lambda, you should think through your use case and ensure it's a good fit. Otherwise, you can use batch, step functions, or other methods. 

Reports and the monitoring board could also be improved in terms of alerts. The threshold alerts are there but can be improved. It takes some time to get used to these methods and get the hang of them. 

AWS Lambda can improve its file system-based sharing capabilities and restrictions.

They should work on the solution's stability and pricing.

There were some timeout issues with AWS Lambda as the options provided didn't suit our business cases. In the next release, AWS Lambda should include integration with an IoT.

I would like to see the five zero four AWS Lambda invocation fixed. This is basically a time-out error. Having consistency in this aspect will enhance how robust the solution is for us.

I would like the layers to have a bigger volume. I would like to be able to add more. I don't want to be limited by the layer. 

In addition, writing temporary data to Lambda is not straightforward. Sometimes I use the S3 for that. I found it a little bit challenging. 

Lambda has limitations on the amount of memory you can use and is not a good solution for long running processes. If the amount of data is reasonably small, it will run and transform successfully. If you have tons of data coming in, it stops working and you have to restart it.

The orchestration and coordination between different Lambdas could also be improved.

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.

Memory limitation is one of the weaknesses of AWS Lambda and as a result, we have to use several Lambda, instead of just one.

Recently, I met with an Amazon employee, who is responsible for Lambda as a product. It appears Amazon has some plans with Lambda, so I don’t have to add something to the additional features.

The runtime for the solution can be improved.

The only issue is that if you have Lambda in one AWS account and want to utilize it in another account, it can't be done. It's a limitation of the solution. S3 bucket provides that option with its resource access management. If you have a Python library and want to package it, you have to create the package of those libraries. It requires changing the conflict file and the patent library to create the package because the configuration is a little difficult for beginners. They should simplify package creation and configuration. Writing test cases is a little difficult because of the memory and short duration. Your computation has to be finished within that time limit. 

The 60 seconds limitation with the consumption of the service is really restrictive for a service and the solution can be improved by eliminating that.

There is room for improvement in user-friendliness. When comparing this solution to others it is not as user-friendly.

AWS Lambda could be improved with better stability. 

One area of improvement is to include support for more programming languages. AWS Lambda does not support a lot of programming languages. You have to write the Lambda functions in a certain programming language. We are using C++. My developer knows a couple of other languages. Python is his favorite language, but Python is not supported in AWS Lambda.

AWS Lambda needs to improve its stability. 

I want to see support for longer applications. I need the 15-minute time-out window to improve.

AWS Lambda's cold start needs to be improved. It has to warm up first, and so, the response time is slower.

Another challenge I've noticed is that there is a limit to the environment variables such as the 4 KB limit. Although, the advice is to use parameters or other things to store the details when the limit has exceeded the data, this adds additional intensity to the application. If the size limits for environment variables can be revealed, it would be helpful. Even if we have to pay for it, at least we would know that we are not dealing with latency. So, I would like to see the size of the environment variables increased.

AWS Lambda's GUI could be improved with a twist or tweak in its look and feel to make it more impressive.

The feature to attach external storage, such as an S3 or elastic storage, must be added to AWS Lambda. This is its area for improvement.

The metrics and reporting for this solution could be improved. 

Lambda could be improved in the sense that some of the things done with Lambda function take some time. So the performance could be better and faster. 

It would be ideal if we could use the solution across different platforms.

The integration could be better.

The user-friendliness of the solution could be improved. If it was easy to run with the same function in other platforms, other environments, that would make it more portable. That would be really good. User-friendliness and portability will be the two factors that need the most improvement.

The startup time sometimes needs to be faster, so that is one area of improvement. The startup time of each function can be slow. When it works the first time, it takes a little bit of time, so there's a minor delay. That could be improved.

The support of additional languages would improve the solution.

There are sometimes issues following an update.

If you want to run processing data, which takes less than 15 minutes, then you can use Lambda. However, if it is a specific ETL process or a long-term one, then AWS Lambda is not a good option.

The longer Lambda runs, the higher is the cost incurred because the cost is based on runtime.

At times, it hard to know when Lambda should be used and when it should not. So in the future, if there are serverless extensions, it would be fine.

Lambda didn't use to support all the capabilities, if you wanted to initialize it before started serving the requests, it is not possible. In the most recent upgrades, they have added this feature. There is nothing missing. If there is something missing, AWS has other solutions that covers it. I look at Lambda as a piece of AWS, working in conjunction with other solutions.  

AWS Lambda has some size limitations in the code line, you can't do a couple of functions to do the job.

AWS Lambda could be improved by increasing the size of the payload. Also, sometimes Lambda doesn't implement well for bigger solutions. 

There are certain limitations to some services in Lambda which will have to be overcome over time. Primarily, I think there are two aspects of the product that are in most need of improvement.  

One is, of course, the customization. The process of customizing should be simplified.  

The other is specifically in the area of integration. The configuration requirements for the services which would be desirable to integrate with Lambda are not always as easy to utilize as they should be. For example, the opportunities we have to integrate solutions with the world outside of the cloud are not well supported. These integrations are supported well inside the cloud but some clients need to support solutions outside the cloud. If somebody has that need we should be able to deploy integrations with products and services outside the cloud as well. 

So those are the two drawbacks and potential areas for improvement area which I would like to see corrected in AWS. Those features need to be updated because the current functionality of the product is not competitive enough today with other products in the category. I think with time they have to improve and add new features or offer other ways of integrating new services.  

From a very high-level perspective, it is a good solution, however, there are certain limitations. This becomes challenging for us. Specifically, a limitation is Lambda cannot continuously execute for more than 15 minutes. That could be one limitation. On an implementation level, there are certain limitations that I know about yet would not be the best person to explain as I am not technical.

The execution timeout can be increased so that if we have a lengthy process, it will not fail before their timeouts. We've had to revamp the way that it works due to that 15-minute timeout limitation.

We don't have the inbuilt modules in AWS Lambda. If more modules were built into or integrated with AWS Lambda, that would help developers to code.

I believe Lambda security needs to be improved.  

The overall performance of this solution could be improved. We would also like to have better integration with other AWS features. 

Its performance can be improved. There should also be more dynamic security permissions.

Lambda's dashboard could be more user-friendly and customizable. I want the dashboard to have more information to quickly identify what functions and events are running. Also, we want to be able to add more trigger points, push notifications, and events. For example, we have a shopping website, so we want to create some events to trigger batch notifications like SMS.

The product could make the process of integration easier. 

The could be more integration testing. The internal is great with Lambda, however, I have to make sure I have done my tests on a related machine before deploying.

The deployment process is a bit complex, so it could be simplified to make it easier for beginners to deploy. 

I wish to see better execution time in the next release. 

Its price should be improved. Its pricing is on the higher side. 

I am not sure if it currently supports the Go language. If it doesn't support the Go language, they can introduce it.

The automation with other Amazon products could be better. 

The security needs to be improved.

I would like to see more integration with other platforms.

I would like to see some better integration with other providers, like Cohesity, Druva, and others. I also think the Lambda interface could be better.

The kind of scenarios we can leverage in Lambda can be difficult. For example, we have a lot of their servers that provide APIs. Before, the APIs were hosted by a server. We have identified that some of them can be hosted in Lambda. That's a challenge as we're yet to think of our scenario and match our requirements in order to really leverage Lambda. That's more on us than the solution itself.

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.

1. Cannot checkout code from GitHub but Jenkins can.

2. No shell script supported.

3. CodePipeline cannot send notification to Slack, but we can use Slack API and Lambda Function.

AWS Lambda could improve by having no-code or low-code options because currently, you need to be able to write code well to use it.

The running time of AWS Lambda runs fine. It takes around five minutes but it would be great if that time could be extended.