AWS Lambda Reviews

AWS Lambda has serverless programming, like Logic Apps from Azure. You just configure the run-time and then they start coding. It is event-driven. It started with my obtaining Salesforce. Salesforce is a low-code and non-code program and totally SAS. Everything starts from the event, from the trigger. You get the trigger and you work at the program. You have some other models, maybe faster or fancier models. But in my opinion, this kind of program is started by locating the system and identifying where the trigger and entry point of the program are. Then you get the full advantage of the program. You don't need to worry about any infrastructure.

I think this is the future. Compared with the EC2, you don't have to pay anything if you don't run it. Otherwise, with EC2 when our client provisions the system and the instances, you always have to pay. There are other tremendous advantages, like flexibility. After you provision EC2 you can write something that does not totally follow the cloud convention. You use it to provision the container. With the program you need to have those 10 principles of cloud computing. Especially recently, within the past four or five years, I have gotten away from DevOps, or the software development life cycle. Even though I researched the product portfolio from DevOps and then the life cycle for DevOps, I try to position myself as an architect with hands-on experience.

In my opinion, Lambda is very similar to Salesforce, which is the original for the SaaS platform and is an extremely low-code environment. With Microsoft and AWS you can say, "Okay. You can choose whatever language you need to make it even more flexible." 

Everything is the cloud. Lambda is a fully managed service. If you want to do it either as a private cloud or on-premise, I'm sure you can do that, too. But I don't know how to manage the pricing structure. But then you've lost the point of Lambda because if you do not use it, you do not pay. Again, I just want to emphasize, I'm not a Lambda expert. But, logically thinking, the big advantage of serverless programming for the customer is that you just use it and pay. Pay and go. You don't need to provision anything.

All my experience with AWS Azure is on the public cloud. We do not get too deep. In IBM we do. When we do sales training we always get the private cloud on-premise. There are many reasons for this. One reason is that IBM lost the battle for the public cloud so we get into it much deeper. We go to the enterprise and we can deploy programs to your data center and offices. But for the tech data for AWS and Azure, we are all using the public cloud as a showcase when we talk to the customer and to the retailer.

The number one feature with AWS Lambda is that it is fully managed. From the developer's perspective, you get the coding much more easily. Now many situations are not using code. You plug in, assemble it, and configure it. Lambda makes it low-code. I come from being a Java certified developer for 15 years. You configure the environment for deployment just like in DevOps. That was always the most challenging part as a developer. You identified when to trigger it. If the program can't facilitate it, then 80% is gone. With 20% you just Lose Syntax. You can use Lose Syntax with any programming language as a reference finding out the variables, the statements, the loop, and what other kinds of things you can do. Just follow that to where you can plot it into your business system. 

They might think to have the business benefits say, "Hey, if you don't like it, no need to pay." So, potentially, you can save. If the future is going to be serverless, that's what I think the future of something like Salesforce will be. Programming is getting much easier and does not need a lot of configuration because step-by-step abstraction starts from the infrastructure service. You can replace your hardware, but you still need to do a lot of things in the abstract. The environment now is totally fully managed. I'm not sure if we're totally aligned there. I always talk against those aspects in the Salesforce situation. But I believe Lambda is a comparable peer, apples to apples.

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.

I have been using AWS Lambda for a few months.

I didn't explore enough information to evaluate that.

I didn't experience the scalability personally, only from my reading. Amazon takes care of the scalability. That's the right way. It's automatic and it's fully managed. That's one benefit of Lambda.

We have all kinds and sizes of resellers. There are large enterprises and small businesses. It's different. And some of them are product based, they are creating their own products. Some of them are consultant based. It's really different. Tech data is different vs. a business model.

I contacted support many times. My experience was very little and I just saw how Lambda was working, to try to understand if it is okay.

I don't actually use AWS Lambda. I'm a distributor. I try to explain solutions to the vendor. I previously used Salesforce Apex. I use the Azure Logic App service.

Salesforce does not have so many options to choose from, such as Java or C++. Salesforce said, lets invent a language. They call it "invent" but actually they just made a simplified edition of Java and eliminated a lot of complex features. Now all the syntax is the same. Salesforce is a business company. They focus on business solutions development and they make the customer's lifecycle development simple. AWS really does not stick to any business because they are a technology company.

Let me explain the similar things that Lambda has to Salesforce. When you get the event you have to see our form. With the sales approval process, if you have the 50% to get to the half million and above, you need the vice president to get the approval. You can use this trigger based serverless program. All you want to do is to write down the logic and then put it under the trigger of whenever a certain number changes in the half billion, and then you need to do the multiple steps.

This kind of programming is easily defined in the business. All you need to do is get the logic done, get it tested, see the steps you are doing, and then fix up the errors. As for Lambda, as I said, I've just experienced two very simple examples in the AWS, but they were the same thing.

Logic App and Lambda should be doing the same thing - fully managed coding. You focus on the logic triggered by the certain events. And there are other additions within the Lambda family. It can be scheduled as a batch job. I don't think it's originally lack of motivation from the serverless. The serverless is from the trigger.

The initial setup is straightforward. If you follow a 30 or 45 minute lab, it seems pretty clear.

Everybody should check out AWS Lambda. That's why I didn't explore much and it was at the top of my list. This is a fully managed model. The number one. This is for the future. In the future, many of the EC2 applications may be replaced by Lambda. If I started something from scratch, I would try to use Lambda. It's much simpler. It can simplify a lot. If you add the scalability into the picture, it could have 80% or 90% of the complexity. They are very important. All the servlets are very important from a cloud computing perspective.

On a scale of one to ten, I would rate AWS Lambda an eight.

I am a fan of the no-code, low-code if you consistently improve to make it even simpler. Maybe they could do something to simplify the language. I'm not sure if Lambda has the code for the Microsoft Logic App, which means they can eliminate most of the code and everything becomes drag and a drop. Because they eliminated those "if errors." They have those kinds of functions. I think mostly because I have not explored the whole portfolio of AWS. I believe there is a full suite of them.

I believe their full suite of the service is complemented with Lambda. But I do believe the competition is going to make it simple with low-code, no-code. There is no-code, low-code and also no infrastructure. That is going to be the key. Also, maybe you can have the Lambda ecosystem and have some component of the module built above the Lambda so that people can make graphing and plotting even easier. This is not just any software, you get the module there which is much better. But AWS is big enough to neutralize the ecosystem. I believe it will come but the people don't have the patience to start from scratch these days.

I have used AWS Lambda for simple messaging for SQS, creating a cron job, and delay messaging. Creating a cron job ensures emails are automatically sent to users at a specific time we set. For example, a mail would be sent automatically instead of manually to a user whose subscription is about to expire.

AWS Lambda functions have many versions. Sometimes, it takes a little time to load and run the commands in AWS Lambda. We can write anything as code, but the solution will not give proper error information. It is a little time-consuming to understand where the error came from.

I have been using AWS Lambda for one and a half years.

The solution's initial setup is easy. You can easily code in AWS Lambda if you have good coding experience in any coding language.

The solution is free of cost for the first year, and after that, it becomes expensive.

If you are using AWS Lambda for the first time, you need to know about AWS. You need good coding knowledge to work with AWS Lambda. If you want to code a node, you must know about node and node syntax. If we are using AWS Lambda with Python, you have to know about Python. It is easy to learn AWS Lambda if you have good coding knowledge.

Overall, I rate the solution a seven out of ten.

AWS Lambda is good because if you chop up your application into small pieces and that is something that can be accomplished as a Lambda-based solution on the cloud, you will save on the cost of your applications.

The reason Amazon AWS has provided AWS Lambda is to allow people to write small pieces of application tasks that will run on Amazon's own internal servers.

The most valuable feature of AWS Lambda, from a conceptual point, is its functions. For example, it's mathematical templates into which you can write, and create your solution. You write small pieces of a solution under given parameters.

I have been using AWS Lambda for approximately two and a half years.

Scalability is an in-house feature of AWS Lambda, it can scale well.

My team in the company is using this solution. I do not know how many other teams in the company might be using it.

We plan to use the solution in the future because there is always a use case for it.

I rate the scalability of AWS Lambda a ten out of ten.

I rate the support from AWS Lambda a ten out of ten.

Positive

We did not use another solution prior to AWS Lambda.

The initial setup of AWS Lambda is easy, it can be done with a couple of clicks.

We use Amazon's CodeBuild, which does the deployment for us, and we use CodeDeploy to write our software application, which submits the code into our Git DevOps operation. From there it gets built and deployed automatically. It's similar to a CICD operation.

We have seen a return on investment using AWS Lambda. We don't have to pay for the solution, such as whatever logic that is implemented. If we had to build it ourselves as a microservice, we would be paying for the infrastructure.

There are other similar solutions, such as Google Cloud Platform or Microsoft Azure. They might be better for small tasks. Everyone can use the cloud providers' solution rather than building their own infrastructure. Any cloud provider has benefits.

I would advise others to try the solution.

I rate AWS Lambda a nine out of ten.

Usually, it is for small transactions. They're very atomic transactions. For example, we built a solution for an ad platform where an electronic ad runs for about 15 seconds a piece. Every time one of the ads runs, we have to record where did it run, how long did it run for, who was in the room, and how many people. There is a bunch of data around that. We typically send that transaction through an Amazon Kinesis pipe into a Lambda function, and then Lambda will take it and store it in S3 or target it to Redshift or put it in some kind of data store. That's one example of what we would use it for. That's a typical model for Lambda. 

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.

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.

It has probably been five or six years since we've been migrating functionality from EC2 instances to Lambda.

Its stability is really good, and it is also highly available. The stability is inherent, but it also naturally gives you a high availability model because you don't have to have multiple EC2 instances running in, for instance, different regions. It is baked into the model. So, you can allow for inter-region Lambda functionality. It all becomes very highly available across Amazon's footprint.

It is endlessly scalable. In terms of its users, Lambda is typically baked into the middle of an application somewhere. Our ad platform solution is a fully-automated IoT solution. So, there are no people involved. The whole thing is automated from end to end. So, sometimes people don't even come into the equation.

We probably do or have dealt with their support, but that would be at the end engineer level. It is not something to which I would have much visibility. 

It is straightforward in my understanding. From the engineering perspective, I haven't gotten feedback that it is at all burdensome.

You're not paying for a server if you're not using it, which is another reason I like it. So, you're not paying if you're not using it. It scales, and you're charged based on usage. It all depends on the use case. Some can be extremely inexpensive if you have very low volume transaction rates. That way, you don't have to fire up and absorb the cost of the servers just sitting there waiting for a transaction to come through. You're only paying when you use it. So, depending upon the use model, Lambda could be highly efficient relative to an EC2 solution. You don't have to have things reallocated.

Understanding what your use model looks like is the key. All these cloud providers have so many different ways of implementing a solution that you really have to understand the near-term and long-term picture for that solution. What does it look like? When you're first building it, there might be a more expedited way to get it off the ground, but that may not scale properly, or your cost can get out of control. So, it is very important to align the right set of features within an AWS or Azure environment for not just getting the initial MVP built but also making sure that you're building it in a way that allows scaling and optimization of the cost model over time as the application scales. There's no one answer. The way you build the solution in the cloud is very dependent upon what the use case is.

From my perspective, not being at the engineering level, I would give it a nine out of ten. There is always room for improvement, but it has been a terrific advance over what was previously available just having to build everything in EC2.

AWS Lambda is a serverless architecture. So, you can use three languages like Java, Python, and Node. You can write your code in any language. The main use is if you have a team and your team has one Java developer, one Python developer, or one JavaScript developer. You all want to work together and in a single project, you can use multiple languages, by any of the users.

All of the features are very good and useful.

The most valuable feature for example Java needs a server, so you need to host your application somewhere. AWS Lambda is itself serverless, and it is connected to the API gateway, and you can directly call the API through the API gateway and connect through AWS Lambda.

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 have been working with AWS Lambda for the past two years.

The stability overall is good. As I mentioned before sometimes you get a couple of time-out errors that need to be fixed.

It is highly scalable. You can use any of the features I mentioned, and you can write a number of functions in one project. We already use around twenty-five functions in one project.

The initial setup is difficult. You need a lot of the code background. You should be at least five to ten years as an experienced developer.

If it is a single deployment it will not take very much time. However, it does take more time as you increase code and volume.

The clients have seen a return on investment.

The price is expensive and is based on usage. The more users you have the higher the cost.

I would rate AWS Lambda an eight out of ten.

We are building a Twitter-like application in the boot camp. I have used Lamda for the integration of the post-confirmation page in the application. This will help you get your one-time password via mail. You can log in with the help of a post-confirmation page. We didn’t want to set up an instance specifically for confirmation. We used the Lambda function so that it goes back to sleep after pushing up.

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 have not faced any stability issues with the tool.

I know that AWS has flexible support but if I encounter any problem, then I just Google it. I get a lot of support from Google, YouTube videos, and Discord channels.

The solution’s initial setup was neither easy nor complex. I started learning about cloud services about six to seven months ago and already had a background in it. However, the implementation was not easy since a lot of errors just popped up. I had to check the CloudWatch logs and look into the bugs in the code. It wasn’t interesting. The deployment took around two hours to complete.

I would rate the solution a ten out of ten. The solution works fine for us and we didn’t require the need to maintain it. I didn’t face any problems working with the product.

We primarily use the solution for integration purposes. We use it very closely with Jira, for example. 

The workflow is the best thing about the product. When the integration happened and from where to where is something we can see automatically and navigate the workflow. 

From Jira to AWS Lambda, we're sending data. When we go from Jira to AWS, through webhooks, we are sending data to the Lambda function. From Lambda, they're navigating Jira. Whenever the manual rework is done, they need to perform some job bundles from the AWS to the Jira only. They can operate from Jira to AWS and AWS to Jira, which is great.

The initial setup is pretty easy. 

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. 

I started using the solution six months ago. 

I'm not aware of any issues with stability. It's been issue-free so far. 

The solution can scale. We can add more users to it. We have ten to 15 people on the product right now. They are developers. 

I've never needed to reach out to technical support. I haven't had any issues. I can't, therefore, speak to how helpful or responsive they are. 

We found the setup to be straightforward. It's not complicated at all. 

It took me one day to get everything up and running.

I'm not aware of the exact pricing. I don't handle any licensing. 

Our company is looking into ServiceNow to see how it handles integrations. 

We are a customer and end-user. We use the cloud for integration purposes. 

I'm not completely into AWS Lambda just yet. What I can say, integration-wise, Lambda does not require any username or password from the Jira once they start talking to each other. It's integrated very well. 

I'd recommend the solution to others. 

I'd rate the solution seven out of ten. It is a very new tool for me; I need to do some more research on it to really understand it fully.

I have found this solution very useful. By using Lambda, we can use Python code and the Boto3 solution. 

The triggering feature is also valuable. For example, if we are using Kafka, we need to be aware that the language comes in Kafka when we write in Python, and that we are transforming our data into the meaningful server and dumping that into the S3 bucket.

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.

I have been working with AWS Lambda for one year.

The solution is stable. There are times when we do need to refresh when we make changes and deploy them. This seldom occurs.

We have five developers using Lambda. 

Technical support can take a long time to respond. I would rate their service a seven out of 10.

Neutral

The initial setup of AWS Lambda is simple.

I would rate this solution a seven out of ten overall.