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.

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. 

AWS Lambda is mainly used for automation. To simplify, in AWS Lambda, I define a function, and I can invoke that function or feature whenever I want and on schedule.

For example, if I have data to collect daily from different services, I schedule the AWS Lambda function to do that, and it does the job. That's one of the use cases of the tool.

Another use case for AWS Lambda is when you have multiple servers running and need to shut down the servers at night. You can configure an AWS Lambda function that would shut down the servers every night on schedule. You can also use it as a backend and invoke it through API, so you deploy your backend from an AWS Lambda function, then link it with the API gateway, then you can invoke your function through the API.

The product serves as a function as a service, a serverless environment, you can say. It's a serverless environment, or, as some people call it, function as a service, FaaS.

We have been using it as a mobile backend. We have a mobile frontend, a mobile application, which uses the AWS Lambda functions running in the cloud. It serves as an API backend for a mobile application that is running in the frontend.

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.

My prior company used the solution to perform event-based actions and notifications, process data in an S3 bucket, and send messages in the SQS queue. 

Our development team worked with 300 users across different departments to integrate the solution. 

We primarily use the solution for our backup coding for one of the ABDI services. We had a big job for the callout function, therefore we implemented Lambda here.

We have used Lambda for batch processing for specific schedules. We have used Lambda for different bot functions that run regularly, check certain things, and handle completes. In one of the implementations, we created Lambda using for the backend process. A majority of Lambda functions are used for backend processing, that is, for batch processes.

We use AWS Lambda extensively for our maintenance work, for our products, and in our daily actions. We try to move some data based on alerts in certain situations and events. For example, if we are using queues based on the queue methods, we prefer to trigger different Lambdas for different functions (to enable some functionality across products). There are also a few Lambdas for audits. There are a few Lambdas for backups and many other use cases. 

The product is primarily used to deploy code and provision a software solution to your clients when they don't have the time. You don't have to pay for the servers and the uptime.

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

We use AWS Lambda for jobs that we just want to offload to a cloud function. We are an educational institution, and if I want to upload an exam I generated for all my students, then I just write the script on AWS Lambda. That is, we use it for independent jobs that we can offload on their own.

We have some services deployed that we need to consume in Lambda because it's a faster and better implementation. We have a model that microservice in the product, which we implement in AWS. For that reason, we use Lambda.

Lambda can be used for automating AWS resources. 

It can also be used for automation outside of the cloud and for serverless applications. With Lambda, you can apply the code directly. 

Our company uses the solution as a function engine to deploy triggered events for customers. We have a team of twelve developers and our deployments have 1,000 to 2,000 customers during peak times. 

AWS Lambda enables server-less architecture for seamless orchestration. We use the solution for various orchestrations. This is very useful when you would need to perform orchestrations of the different applications together. Many organisations are using this solution for web and mobile applications at scale. 

The primary use case is processing data. We use the pipeline multiple places to process the data. Whatever JSON files we get, we have to standardize, enrich, and also format to the application.

I am using AWS Lambda for building web and mobile applications.

We have a DNS as a service and NAS as a service, which integrates, and we use Lambda functions there. We have a lot of applications that we use Lambda for. 

This solution is cloud-based. 

AWS Lambda is used to write developer codes in Python. It is a place we can run where we can run our codes.

We are primarily using AWS Lambda for real-time API services. We use AWS Redshift to support our Lambda code functions. 

This solution is cloud-based. 

My primary use case for this solution is usually for event-driven architecture. Since it's AWS, it's cloud-based. 

AWS Lambda is a Code as a Service product. It is used for running code.

Our website is hosted on AWS, and we use Lambda to create trigger points.

We use AWS Lambda for several things. We are using it, for instance, to do authentication of information from HTTP sites. We use it for alerting when monitoring the direct database infrastructure, and we use it for API transformation.

It is useful in many scenarios. For example, in a microservices architecture where serverless functionality is required, one can use Lambda.

We are using the latest version.

We use the solution for the building of small applications.

We mainly use AWS Lambda for data transformation and authentication.

We use AWS Lambda to automatically manages some compute resources.

It triggers and screens some of my services.

We use it for serverless functions.

I am using AWS Lambda to set up real-time notifications and backup transfers.

AWS Lambda is used for the whole surface, it does the backups, and schedules, and learns some of the core functionalities but it can depend on the topic or application. The solution is used to build APIs and many other functions 

It is used for capturing data through an API.