 I'm going to, can you hear me? It's okay. That's not recording one. All right. Okay. So I'll try louder. So I'm here to talk about, so in a way the talk that was there before, so that it'll be completely opposite things. So we'll talk about AWSM, and we'll talk about why probably sticking with one is good enough. But nevertheless, this is very introductory talk. So I myself started my journey on AWSM, so in terms of starting serverless applications while learning. So it's still one-on-one. But the goal is that the people who are using some other frameworks, and even those who are starting with serverless. So the goal is that this should help you. Okay. Okay. So it's 2019. So I believe we start with serverless, but we don't have to talk that serverless as servers, right? So let's skip to that part. So, but what is happening is just in case of serverless, like last year is that instead of talking about that, we are not talking about lots of other things that what is really serverless. So whether it is a methodology, or whether it is a utility computing, or whether it is a way of working. So I think there's lots of confusion there. But this is a slide which I saw in the reinvent last year. So I think this is what AWS view is, perhaps. So in this slide point of view, AWS defines the serverless as an operational construct. So basically it doesn't mean that there is only just one. It isn't a back and right, like one service is a serverless and another is not. So it is like there's a degree of serverlessness. So the things that require more operations, like on-prem or zero on serverless, and the things which don't require any operations at all are more serverless. Okay, but I think those are very big things. We'll talk about from the serverless application view from a developer's point of view what it means. So I think this is something that I've seen most of the experts how they define it, which roughly categorizes a serverless application into three parts. So first is the function as a service. So this is the lambda. So this is the core of a serverless application. This would be something that is where your business logic would reside. Then there will be a set of events which would trigger this function as a service, which could be when you put a file in your S3 bucket or probably even in terms of when you use an API gateway, when you make an API call from your browser. And thirdly is the back-end as a service. This is where you use other services that, along with your serverless application. So for example, we were talking about databases, SQL. So this is where the choice of the back-end that you use matters for your serverless application. So if you use a regular relational database, you'll have problems because of the way the connections are managed. So in terms of the connection pooling and all, it is more suitable to traditional way of developing applications. So this is where probably things like DynamoDB and the things which are defined as serverless help. So now we talk about AWS Sam. So this is a framework for building and managing serverless applications. So when you begin with serverless application, there is lots of things. So you begin with Lambda or you begin with, you go to the UI. But I think this is again coming from the previous talk. This is maybe a different point of view. I think you need a framework to make sense of it all. So this is where the Sam framework, which comes out of AWS helps. Now what is Sam? So basically it is two things. This leads a template and a CLI and a set of tools which help you manage. So firstly, we talk about templates. So this is where, as we'll see later in the demo, you'll define all your serverless resources, whether it is your event or whether it is your, the Lambda that you're going to use, which runtime you're going to define and also which other services you're going to use. And next is the CLI. So this is like 10 plus commands which this framework provides, which should cater to the entire Dev's lifecycle of when you develop an application starting from scratch and then, let's say, testing it on your local and then testing on the cloud and then followed by deploying and publishing it to the repositories. So this is what the template looks like a bit more. This is what, basically, in these few lines, this framework allows you to define a pretty much a kind of a web application which can respond to an HTTP call through API Gateway. So we'll go through this. So what you see on the top is basically it's a transform. So basically, Sam is based on cloud formation. So it's what the second line does is that it basically says that this is based on cloud formation but there are some extra resources which are defined by Sam framework. So this second line tells the translator of the Sam framework to translate this template into a cloud formation template. But it makes us easier. So for those who will focus only on the serverless application, it makes it easier as we'll see in some of the things that we can define here. Next is then you define the resources. So this is what we saw in the slide on the serverless application. So basically, you'll have your function as a service, which is lambda. So what you have on the top is hello word function. This is the name of your function. You'll define the type of the resource. Where is the binary of that function residing? What is the method which lambda should call for handling the request when it comes via HTTP and the runtime? So lambda itself won't do anything unless you have an event which could trigger it. So this combination would always be there unless you're invoking it manually. So that will be always this combination of functions and events. So this is where the event is. It's an API gateway event. It's defined very simply. So basically what we're saying is it's a restful path. So when we call with a hello name, so it would pass on the parameters to your lambda function as we'll see in the demo later. So this is the function and the event part. And then you can define a number of resources. So this is again the... So when you see this naming convention of AWS serverless, this is where the SAM is trying to make it simplified for you compared to when you will do the same thing in cloud formation directly. So what it does is that this simple table whose name is hello world table, so I would make a DynamoDB table with an ID as a primary key. That's it. And then you can add a number of columns. So that's where you go. So this is how the template looks like. Then a quick view on what are the serverless specific resources with which SAM enhances the cloud formation. So these are the... I think we already saw three of them in the previous slide, the function, which is the lambda, the API, and the simple table. The next two are a little bit more advanced. So this is on the application and layer version. They are the resources which promote reusability. So for example, the one on the AWS serverless application is where you could access another application published by someone else in the serverless application repository. And the one on layer version, this was introduced in re-invent last year. So this is where you could reuse libraries that are common for your organization, for example, authentication sector in a number of applications. So now we talk about the second part. So the event sources. So as I said, your functional service would always need an event. Otherwise, it is useless. So this is a list of typical sources from where this event can come. It's almost like all the main AWS services, but most typical ones which we'll use in this demo are the API and S3. And what you see on the right side is the example of defining this event. So for example, an event of type API, you define the URL where, when this URL would be hit, your lambda would be called. And the same thing is for the second one, you give the event the name of your bucket. So whenever an object will be created, irrespective of whichever mode of request the event would be called. And the S3 event would be automatically passed to your function. Okay, so this was the template part. So now the second part of the SAM is the CLI commands. So basically I've tried to divide them into the different categories as and when you're developing. The three on the top, the init, validate and build, those are the ones you're going to use when you're going to initiate your service application through SAM, followed by the second group of commands. Those are going to come handy when you're going to test your service application, especially locally. So a bit of history about SAM. So when this framework was started, it was started as SAM local. So it was the main goal of the framework was to help you test your service applications locally without pushing on cloud. But it has now been extended to many other things. And finally the package and the deploy. These are the ones we will use to deploy the application from your local machine to cloud. Yeah, so having gone through it, so why SAM? So this is really a very personal point of view. So basically I think that most people when they start using service application, they use the service framework, which is cloud agnostic and which is the one which started this way of frameworks. And then you have lots of language-specific frameworks like Apex, which was mentioned. But I think the one advantage with SAM is that it's part of the AWS ecosystem. So this is why it has very close integration with AWS services. Then we talked about service application repository and even cloud nine. So let's say if you build there, it now automatically comes installed with SAM and you could do your development directly there. So this is why if you're sticking to AWS, then it makes sense. It is basically just cloud formation underneath, but it's serverless friendly cloud formation. So you have one less thing to learn, so you don't have to start learning a new thing from scratch. So the third thing is the local testing and debugging. So it allows you to test locally. It's not only about defining application, but also you can test it locally. And finally, I think this is something very interesting is that you can have very complex Lambda deployments in two lines of the code. So I'll talk about it in this slide. So this is the way of when you're pushing your, when you're going live with your serverless function, these are the different deployment preferences that you can give the function. It is, so for example, when you say the linear X percent in Y minutes, what it would does is it will make a stepwise, the stepwise request of your functions would be catered by the Lambda. So there will be two alias. There was a version one and a version two. The only 10% in the initial 10 minutes will be catered by version two. So it is basically a safer way of deployment than the default one, which is all advanced. And the next is the canary release, which is not stepwise, but at least in two steps. So for example, if you define canary 10% in 15 minutes, it would route 10% of new traffic to new version. And then 15 minutes later, the entire. And then actually you can do lots of interesting things. You can put hooks along with it. And you can make it really automated to give the go to make this deployment after 15 minutes based on the yes and no answers that you will give in your hooks. Okay, so I think that was most of the 30 part. We'll try to share a demo of how it actually looks like. I don't know if there is any question before. Okay. So as I said, so what we would, yeah, basically before that, for the installation part, it comes along. The prerequisites for SAM CLI installation is you need the AWS CLI and Docker as well, because it uses Docker for the local Lambda invocation. So what could be done with Firecracker on the, on the cloud is done by Docker when the invocation is made for your function. So let's begin. So as usual, whenever you're with Sam and you begin your application, you'll start with something like this. So Sam in it, this would make a skeleton. This would provide you an skeleton of the, you know, for what you can use for your application. Sorry, I think I have to make my font a little smaller. This is okay. So, oops, sorry. Yeah, so this is what it would look like. So when I did a Sam in it, it creates a skeleton application for using Node.js as a runtime. So we can have a look at it. So basically what it has is the, for the app.js would have my Lambda function. The template YAML is the one which would be having the config, the Sam template we talked about. So what does it look like? So it's sort of very readable because there are lots of comments actually. So because this comes directly from the skeleton. So but it's more or less similar to what we saw in the previous slide. So what you have is your, this headers for the transform followed by some global. So this, whatever you define in global would apply to all the functions that you would declare in this template. Then you have your hello world function, the type. It's a serverless type resource of function. The code you arrive at, the code resides, app Lambda handler is the function which would be invoked when an event comes, the runtime, environment variables which you can access when you're in the runtime of the Lambda. And finally the event. So this would create the, this would create an API gateway for you for the hello request for the get mode. And here is the outputs. So I don't know too much Node.js. So what I would try to do is I'll try to make it for Python. But just before that, a quick view on what init can do. Basically init as I said by default gives you a Node.js application but these are the different runtime options you have. So you can choose a language of your choice as we will do now where you can define your language there and it would make a skeleton for that language. So let's try to make it for, let's try to tell init that we want a skeleton for Python. So let's do it. So what it does now is that instead of Node.js it has made the, but overall the structure still says the same. So you have your replication and then the code residing there. The template would be very similar to what we saw before. Still we can have a look. So yeah, so it's very similar. The only thing that has changed is the handler and the runtime. So rest the entire, what this template is trying to do is it'll set an API gateway which would trigger the function that you have configured there. So I think next step is to build it now. So basically the here as well Sam provides your advantage. So basically there is no, I mean there is no Python in place. I only have Python 3 here. So you know if I try to do a Sam build it would fail unless I either, so one solution I have is either I go to a virtual environment or I install the Python 2. I do a sim link, but I don't want to mess up the environment on my machine. So what it provides me is that the functionality it provides me that it can do even a build using the Docker container that Sam comes with. So if I do Sam build using container so what it would do is it will fetch a container image with the Python 3.6. So I think I forgot to show you. So this is what you'll see in the requirements.tech. So along with Python there is the Python library request, which is, okay, sorry. So I think I'll move quickly. So we have the Sam build done. What we could do next is, yeah, so what we could do next is to start to test my function locally. Probably I'll do only the local part. I won't push to the cloud because I think that is the easier part. So what this does is that it has, it is basically try to mimic API gateway on my local machine. So on this URL basically if I try to hit this URL it will locally make a Docker container with my lambda function and try to call it. So let's see if it works. So this is the cold start on your machine. So basically it's trying to, what it has done is that it is fetched an image and try to instantiate it. Place your lambda runtime into it and call it. So basically this is what the function output is. Sorry. What it does is basically is nothing but tells you your own IP. So I think it's not very interesting. But it's good enough for the demo. So next is what you can do is that you can also, this is further with the local testing part that we were talking about. What you can do is you can create, it provides a small utility to create an event so you don't have to go to the console and copy paste the events and which you can then use for testing locally. So for example what this has done is that generate event, it has generated an API gateway event and I've routed it into API event and this is again how I can test it. So what I'm trying to say is that invoke my hello world function which I deployed through my SAM template and with this event. So still the results come the same. So instead of coming via the API gateway route it has triggered the function directly. So I think I won't go into this because I've lacked of time but this isn't yet another way to test. This is where you can have an end point of lambda and run end number of unit tests. So this would avoid having a container for each call being generated. So quickly the last point is that is that how you can push it to the cloud. So for this we use the package command so where you tell the output file which will be the package YAML and it will automatically take the template YAML that you have. So basically what it does is it basically transforms the template that you had defined earlier and pushes your code to the 2NS3 bucket which can be taken in the next step and we will do the deployment. So this is what you see here in the code URI. So now finally is the time to deploy my... So what I'm doing here is the... After the packaging is done I'm taking the output of that package. Okay, it'll take just one minute. This is the last step. So what it does is basically it... So it is creating my stack with the package YAML and basically now it is pushing it into the cloud. This is the last line obviously. So while it is making the cloud after that you could... It would... Through the output you can get the API URL and you can hit it. So whatever the results you were getting locally so those would work as well. So what it has done is that my function has been deployed on this... On this API gateway, so on the cloud and you can... Then you can hit it and you can... You're getting this function... You're getting this as well from the cloud now. All right. Sorry, I think I ran out of time but if there is any question, can I help? Okay. All right.