AWS Lambda Tutorial | What is AWS Lambda | Features of AWS Lambda | Intellipaat

Hello everyone and welcome to today's session on AWS Lambda. Do you know friends that most of the businesses are switching to the cloud infrastructure and AWS is undoubtedly at the forefront of this movement even for new businesses, startups and also for educational purposes. Watch this video till the end to learn more about AWS Lambda. Now before we discuss our today's agenda do not forget to hit the subscribe button and click the bell icon. So first we will discuss about what is AWS Lambda. Moving ahead we will discuss about the concept of serverless. Then we will discuss an approach called serverless approach. Moving ahead we're going to discuss about serverless infrastructure where we are going to discuss a little bit about AWS Lambda. Then we are going to discuss about the features of AWS Lambda. Then we will discuss about e-commerce use case. And at the end we will conclude our session with the pricing of AWS Lambda. So let's start with what is AWS Lambda. Lambda is a compute service where you can run code without setting up or maintaining servers. Lambda executes your code on a high availability compute infrastructure while handling all compute resource management tasks such as server and operating system upkeep, capacity provisioning and automatic scaling and logging. You can execute code for practically any kind of application or backend service using Lambda. As a component of Amazon Web Services, AWS Lambda is a platform for serverless computing that is kind of event driven. It is a compute service that automatically controls the resources needed to run code in response to events. Now let's study about what is serverless. Let me give you a real-time example of Pizzeria. Suppose Pizzeria is owned by Uncle John. Uncle John has a strong sense of self. He has been running his Pizzeria for more than three decades. It was a place where many generations of the neighborhood's residents gathered with their families, shared laughs and even went on dates there. His Pizzeria, however, has recently faced some difficult times. Has informed you that his customer base is also shrinking. Nowadays, many of his clients prefer placing their orders online over the phone rather than in person. For instance, the brand new Chess Pizza has a mobile app with pizza reviews and online ordering as well as a chatbot for ordering through different messenger services. Although the majority of your uncle's customers enjoy his Pizzeria, his three decades old business has begun to dwindle. The pizza shop already has a website. But in order to process and store information about orders and pizza, it needs a back-end application. Basically, you can consider something like this. The website would have a typical three-tier application design with distinct routes for users, orders and pizza. It would also have webhook routes for payment processors and chatbots. The business layer handler function would be triggered by each route and processed data would be sent to the data layers file in the database and image storage. For any specific small application, this tragedy works perfectly, at least until a volume of online pizza orders reaches a certain point. It would be fine for your pizza API, then your infrastructure would be needed to be scaled. But because you don't want to replicate your database for the sake of maintaining data consistency, it's necessary to detach the data layer in order to scale a monolithic application. If you had too many users, your application might be replicated, but each instance would also have all of its services replicated, regardless of how much they were used. Now, we will discuss about the serverless approach, which will be used for Pizzeria when its number of users would have increased voluminously. Now, basically using serverless technology, which is the pay-per-use, it doesn't require renting or purchasing serverless applications, can be installed and run on the cloud infrastructure. Since serverless applications are distributed and event-driven, a different approach is needed when in developing them. Each component of your application is isolated into independent auto-scalable containers rather than having an API endpoint and your business logic on the same server. Your requests are handled by an API router layer in the serverless application, which only accepts the HTTP requests and routes them to the underlying business layer services. The API router in a serverless architecture is always independently managed. That means that application developers don't maintain the API router and it's scaled automatically by the serverless provider to accept all the HTTP requests your API is receiving. And you pay only for the requests that are processed. In case of your Pizza API, the router will receive all the API requests from the mobile and the web applications and if necessary, handle webhooks from chatbox and the payment processor. Now, the API request is forwarded to another container with the business layer service to be processed after it has been routed. The business logic of a serverless application is frequently divided into smaller units rather than existing as a single monolithic application. Each unit's size is adjustable based on your preferences. One function counts as one unit while a monolithic application counts as another. Most of the time, because you are paying for function execution, its size has little direct impact on the infrastructure cost. Owing one or a dozen of them costs the same because units are scaled automatically and you won't be charged for the idle ones. However, you can save money on hosting and maintenance for small applications and circumstances where you don't have much information by combining functionalities related to one service into a single business unit. One unit for processing pizzas and orders and one for payment and one for managing chatbot functionality and another one for processing images and files that would be a reasonable solution for your pizza API. The last part of your serverless API is the data layer which can be similar to the data layer in a scaled monolithic application with a separately scaled database and file storage service. It would be best if the database and the file storage were also independent and auto scalable. Another benefit of a serverless application is a data layer can trigger serverless function out of the box. For example, when a pizza image is uploaded to the file storage, an image processing service can be triggered and it can resize the photo and associate it with a specific pizza. Now, let's discuss the serverless infrastructure using the AWS. Your serverless pizza API needs infrastructure to run on. Serverless is very, very young and at the moment has several infrastructure choices. Most of these choices are owned by big vendors because serverless requires a big infrastructure for scaling. The best known and the most advanced infrastructures are our Amazon AWS Lambda serverless compute container, Microsoft Azure's functions and Google Cloud's function. AWS Lambda has the most mature serverless infrastructure available in the market, the stable API and many successful stories behind it. AWS Lambda is an event-driven serverless computing platform basically provided by the Amazon as a part of the Amazon required by that code. The most crucial component of the serverless puzzle is that you must comprehend Lambda because it houses your business logic. When an event trigger occurs, Lambda as an AWS serverless computing container executes your function. If multiple events call the function at once, it automatically scales and you must use AWS Lambda as a serverless compute container for your pizza API in order to create serverless application. An HTTP request, for example, triggers the Lambda function that receives as an argument data from the event and context a way to respond to the event. The information passed by the service that called your Lambda function is the event in your Lambda function. In AWS, a variety of events from common ones like an HTTP request via API gateway or file manipulation by S3 to store more unusual ones like code deployment, infrastructure changes and even console commands using the AWS SDK can call a function. Now, let's discuss few of the features of the AWS Lambda. AWS Lambda allows you to add and custom logic to your AWS resources such as Amazon S3 buckets and Amazon DynamoDB tables. So you can easily apply compute to store data as it enters or moves through the cloud. It is easy to get started with AWS Lambda. First, you create your function by uploading your code or building it right in the Lambda console. Then choosing the memory timeout period and AWS identity and access management role. Then you specify the AWS resource to trigger the function which can be a particular Amazon S3 bucket, Amazon DynamoDB table or Amazon Kinesis tree. Next feature is creating unique backend services. With the help of created the Lambda Application Programming Interface or API, the unique endpoints of an API are connected with the Amazon API gateway where you can use the AWS Lambda to develop new backend application services that are activated on demand. Instead of handling custom events on the client, Lambda handles them which helps them to avoid client platform variation to save battery and life and facilitate easier updates. Next feature is carry your own coding. There are no new programming languages, tools or frameworks to learn when using AWS Lambda. Any third-party library including native ones may be used. You can manage and share code including frameworks, SDKs, libraries and more easily across numerous functions by packaging it as Lambda layer. In addition to natively supporting Java, Go, PowerShell, Node.js, C Sharp, Python and Ruby, Lambda offers a runtime API that enables you to write your functions in any other programming languages. The next feature is completely automated administration. You can concentrate on creating unique backend services because AWS Lambda takes care of managing the infrastructure needed to run your code on highly available fault-tolerant infrastructure. With Lambda, you can never have to worry about resizing or adding new servers as your usage increases or updating the underlying operating system. When a patch is released, your code is seamlessly deployed by AWS Lambda who also manages all the administration, maintenance and security patches. Amazon CloudWatch also offers built-in logging and monitoring capabilities. The next feature is integrated fault tolerance. To help protect your code from individual machine or data center facility failures, AWS Lambda maintains compute capacity across multiple availability zones in each AWS region. Predictable and dependable operational performance is delivered by AWS Lambda and the service functions. Next feature is scaling automatically. Without any manual configuration, AWS Lambda automatically scales to support the volume of incoming requests and only executes your code when necessary. Your code can process an unlimited number of requests. Your code will typically begin running on AWS Lambda within milliseconds of an event. The next feature is access relational databases. To benefit from fully managed connection pools for relational databases, use Amazon RDS Proxy. RDS Proxy efficiently manages thousands of concurrent connections to relational databases, making it easy to build highly scalable, secure Lambda-based serverless applications, thus interacting with the relational databases. RDS Proxy currently supports MySQL and Aurora. You can use RDS Proxy for your serverless application through the Amazon RDS console or AWS Lambda console. The next feature is functions are packaged and deployed as container images. Customers can create Lambda-based applications quickly and easily using a familiar container image tooling, workflows and dependencies. Thanks to AWS Lambda support for function packaging and deployment as a container images. Customers also profit from Lambda's operational simplicity, automatic scaling, high availability, pay-per-use billing model and native integrations with more than 200 services. Now, let's see a use case where AWS Lambda is used across e-commerce applications. The first is migration, improving flexibility, availability and security by migrating an existing e-commerce solution to the AWS cloud and all while reducing costs up by 50%. The next is recommendations and personalization. The next is recommendations and personalization to improve consumers' interaction, increase conversions and generate more revenue, customize customers' digital experiences with personalized product recommendations and offers. The next is future-oriented e-commerce for greater business agility and innovation at scale. Replace monolithic e-commerce systems with agile microservices that can be individually changed, tested and reassembled. The next feature is digital live trading and augmented reality. While using AWS Lambda services, you can also incorporate this feature on the e-commerce application. So by redefining how people shop with interfaces that are designed for simple transaction via social, mobile and voice, you can easily reach existing and new customers where they spend time and shop for products. And the final is optimization of website. A quick, user-friendly, secure website is essential for retailers. With security measures to guard against common web exploits that could affect sites' availability, AWS Digital Commerce Solution automatically minimizes the application downtime and latency to ensure faster page loads and encourage customers to stay on the site longer and make purchases. Now, we'll discuss how the AWS pricing is calculated. For the vast majority of our cloud services, AWS offers you pay-as-you-go pricing model. With AWS, there are no lengthy contracts or complicated licensing requirements. You only pay for the specific services you use, similar to how you pay for the utilities like water and electricity. AWS pricing is flexible. There are no hidden fees or additional charges after you stop using the services. You only pay for what you use. So, you can see a table here. It shows that the first 6 billion GB seconds per month cost around 0.00001666667 for every GB seconds, which is equal to $0.2 per 1 million requests. Similarly, you can see the table and the pricing for the AWS. That was all for today's session. I hope so you enjoyed our session today on AWS Lambda.