AWS Lambda Reviews

We primarily use AWS Lambda for our APIs. Most of our transactions flow through the API, which is managed using API Gateway and AWS Lambda. Our development team works on the API.

We use AWS Lambda because it provides a solution for our needs without requiring us to manage our infrastructure. With the tool, we only pay for the resources we use. Additionally, it is straightforward to implement and integrates with other services like API Gateway.

The tool's serverless nature has had the most significant impact on our workflow. I find it particularly attractive because it eliminates the need for managing servers. In my previous experience, managing upgrades and updates was quite challenging. 

The solution's integration process with other AWS services was relatively easy. We primarily use AWS services such as EventBridge for scheduling processes and log management. 

My primary use case for AWS Lambda involves real-time data and media processing. Specifically, I use it to process user-uploaded content, including filtering, resizing, and applying effects to media files like images and videos. Lambda triggers these operations immediately upon file upload, ensuring minimal latency. One of the key advantages of using Lambda is its automatic scaling, which adjusts based on the volume of uploads. This means it can handle spikes in traffic without the need for provisioning and managing dedicated infrastructure, allowing for cost-effective operations during periods of high demand. Additionally, by leveraging Lambda, we can quickly deploy new processing workflows without affecting the existing infrastructure.

AWS Lambda has greatly improved our organization by driving significant cost savings and enabling more efficient resource utilization. Its pay-per-use pricing model ensures that we only pay for the compute power we actually use, which helps optimize our budget. The generous free tier is particularly beneficial for smaller applications or low-traffic periods, allowing us to reduce costs even further. Moreover, Lambda eliminates the need for provisioning, maintaining, or scaling servers, which not only reduces operational overhead but also frees up our team to focus on more strategic tasks. This serverless architecture has enhanced our agility and scalability, as we can now quickly adjust to changing workloads without worrying about infrastructure management.

I am currently using it mostly for our APIs. We don't really use any instance or any soft host for it. We just use purely serverless for our API operations. 

Before that, my previous company used it mainly for step functions. Some of our processes would trigger step functions, which in turn would trigger a series of Lambda functions to process the data.

The convenience is a valuable feature. If you start the traditional way, you need to spin up an instance or host a container, which can be a lot of effort. Lambda allows you to focus on the code itself. You can easily integrate it into API gateway, making the convenience probably the best part.

I use it for event-based retrieval. This is just to process for trigger purposes.

It has access to various other AWS resources like S3. You can use it to configure event-based triggers or conditions. You don't need to configure the servers; it will automatically execute the job and go idle. In that regard, Lambda is good and serves the purpose.

Integration capabilities:

They have the built-in IDE, so everything happens without integration issues. 

AI-features:

Just the Amazon Q [Amazon Simple Queue Service (SQS)] will also be there, like a pop-up in the AWS console. We can use that for Lambda as well, but no other integration. I wish there were AI integration for the code, like CodeWhisperer. That would be a good add-on.

There's a lot of use cases. The solution is used for immediate processing, so it's used everywhere. When data comes in, you process a Lambda function to tag it and categorize it. I've used Lambda functions to process inbound videos to make them smaller. I've used a Lambda function as a serverless backend for a customer-facing app, so I didn't have servers running.

With a highly variable load, our idle cost is pretty much zero, and we haven't had any scale barriers, so we've scaled smoothly.

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 mostly use the solution for data dips or integrations with third-party applications.

The fact that it is serverless is really important. I can then deploy a microservices architecture. It is quite quick and nimble. The most useful feature for me is the API call, as well as the integration and its flexibility.

I use AWS to host our app space within my university, APU. My infrastructure is based on the AWS cloud, and most of my compute workloads are primarily based on Lambda. This setup facilitates all transactions that require engagement from multiple stakeholders, including staff, faculty, students, and administrative staff. I have in-house applications, both mobile and web-based, that engage with Lambda to provide the required scalability, especially during peak hours of university timings. Lambda is a highly utilized service for me.

The most important feature of Lambda for me is that I don't need to manage any resources. I don't have to set up an AWS stack or developer tools, as they are provided by AWS by default. This means that if I need to set up Lambda, it's a matter of minutes to deploy my code, which facilitates my CI/CD pipelines. Time is an important optimization for me, and Lambda is economical. Additionally, it is highly available and sustainable, unlike EC2, which is a single point of failure. Lambda saves me time in configuration and deployment and gives me confidence in its high availability and scalability. I have done my workload migration from an on-premises environment to the cloud, significantly reducing my capital expenditure. The automation improves my planning for product releases and hybrid connectivity. Also, content delivery has improved, and application latency has decreased.