 I can use this one, right? Can everyone hear me? Hello. All right. Welcome, everyone. Thank you for joining this session. Today's session is about serverless. I heard about this terminology a few years ago in one of the AWS events in Singapore. A lot has changed since then. What started as a sort of a mere mention in one of the IoT demos has become one of the most widely used terminology in the tech world. More and more people are redesigning their applications as a set of independently maintained functions rather than a monolith. So one fine day I said to myself, like, enough is enough, you need to look into serverless a bit more. All you have done so far is just to add it in your CV. Not good. So this is where my mystical journey in the world of serverless started. And today you guys will join me in this mystical journey. So this is my interpretation of how the serverless world looks like. And the goal for today is to conquer this terrain in eight steps. This is us. So first thing first, let's talk about the cloud platform. I'm starting with AWS mainly because AWS they are the market leaders and have a comprehensive serverless stack. But we can also start with Azure or Google Cloud, whatever you are comfortable with. But for this session we will start with AWS and then slowly move to... And we only have 25 minutes. This time we will make sure that I will sort of create within 25 minutes. So I will try to cover things quickly. If you have any questions, let me know. Maybe we can talk afterwards in detail. So of course the first step is to create your account. So if you don't have your AWS account already, you can create one. You'll get a free here for one year. And even if you already have an account, you still can use Lambda and all the other services. I mean, pretty much without any cost, unless and until your goal is to take over the internet. So once you have your account, this is where we can go to second stage, which is to explore like that. So that actually brings us to what is serverless. Serverless is a computing model that actually abstracts your platform, your infrastructure, your operating system and lets you focus on the functionality. It's sort of a kind of a misnomer. I mean, it doesn't mean that you don't need serverless anymore. You still do. But the thing is, you don't see that we don't maintain that. And they are usually paired up by a paper used model and the offering varies from provider to provider. And in order for you to build your application, test your application and deploy your application, there are serverless frameworks out there. Some of the famous ones are OpenFast, tubeless, AWS M and serverless framework. We will touch upon serverless framework and AWS M in the session. So quickly about the pros. I mentioned about the cost because it's a paper used model. So you are only paying for the execution of the function. So in most of the occasions, it's pretty cost effective. Maintainability aspect, you don't need to maintain the servers, the upgrades, the packs and everything. So it makes the operational side of things pretty simple. And last but not the least is the scalability. Almost all the providers, they support auto scaling. So you can manage the high demand with the concurrent instances and they also sort of guarantee the availability as well. So possible use cases are IoT, image, video processing, analytics, machine learning to understand user behavior and predictive analysis and virtually anything. Whatever you can do as a standalone application, you can do it by combination of serverless technologies. All right, so this is the design of the cloud function, which is sort of the centerpiece of overall serverless architecture. And there are three main components in the cloud, in the design of the cloud function. The source, the application, the device, or the service that emits events or allow you to hold for information. And then there is a function that actually executes your logic. And in between, there is an event mapping and the trigger mechanism that actually links source with the function. And all these three things are sort of governed by some sort of permission model. So when we look at this genetic model and try to sort of map it to AWS, your source can be S3, Cognito, for more of a push kind of a mechanism or DynamoDB streams or NSS for more of a pulling model. And your functions are the function that you will write in your AWS and Lambda service. And this trigger mechanism is kind of a, is where the AWS Lambda service comes into the picture. And the permission model is your IAM roles that you assign to your services. And talking about Google Cloud, source can be your bucket or your HTTP request. And your functions are the Google functions and this events services is the Google Cloud service. And their permission model is different from AWS. It's not as comprehensive as of now, but it would be sort of too premature to sort of do a direct comparison between Google Cloud and AWS because Google Cloud is seven beta, but they have a permission model on the basis of the other projects they have and the owner of the services. All right, so now we have a basic idea. So this is where we can go to a third stage, which is to create our first Lambda. For that, okay, I will go to AWS and so you can go to AWS management console, you can create a function, but before that we can do just one more thing, sorry about that. So this is the demo. So the problem for this session is a really simple one so that we can cover it in 25 minutes. The problem that we will follow throughout this session is a really simple one. You add a document in your S3 that will trigger an event which your Lambda function will receive and then create an entry in the Google table. So this is like a very, very basic document approval solution that you have. You are putting your documents and then there is a corresponding entry into the table so that the viewers can look at the table and see what other documents they want to approve or reject. So having said that, we can go back. So this is where we can create our first Lambda function. I'm not good with names, so I will just stick with demo one. Runtime, so this is one difference between Google Cloud and AWS. So far, Google Cloud only support Node.js. In AWS, you have Python, Node.js, Java, C-sharp. I'll stick with Node.js, JavaScript for life. And role. I will just use the existing role but make sure that you choose the right role because roles are basically that will govern what sort of things that you can or cannot do with your Lambda service. So in our application, it's a really simple thing. My Lambda service will talk to DynamoDB and it will also do some login in the CloudWatch. So I need access to DynamoDB and CloudWatch. So it's a really small sort of a permission set that you can create. All right, so let's try to create a function. All right, so this will take us to the detailed page and again, the permission that you have on the resources, you can see them here on the left-hand side. So right now, our function, this is the default function. It's not doing anything. So this is the actual entry point of your code and it actually takes two parameters. Event that contains the information of the event and the context contains the information of the context in which your function is running. So let's say if you need to do some specific calculation like how much time left for your Lambda function to execute and all that, so you can get it from the context. This is another thing which is the third parameter that you can add, which is callback. Callback is something that you can use to pass some information to the caller. All right, just to save some time, I have the code here. Let me just copy this so that it's easy. All right. So I have this code. We will do a quick code walkthrough later. Let me add another file. All right, so not as going on here, but the design is simple. So you have your index.js that will be responsible for sort of gathering the event information and passing some of the dependencies and the review manager is the class which is responsible for the bulk of your business logic. That class will be responsible for adding entries into the identity table or do some fancy checking if you want. The reason we need to do this separation is because it is a best practice so that you can easily test your business logic without worrying about too much about the dependencies when you're doing unit tests, you can log them. I will show the code later. All right, so this is the basic application code I have added here. You can, one thing that you notice here that here I'm sort of relying on this environment variable so you can provide some environment variables so that whatever your sort of code is expecting. So this is the name of the table. I can choose pending approval. Tags you can use to organize your functions. You can add some description. Make sure that you choose the memory carefully because the more memory that you use, eventually you will pay more. And here are the timeouts that you can set. It's a pretty sort of a small lambda function, so three seconds will be fine. And then there are other settings that you can look into based on your needs. We will not touch on the concurrency but understanding the concurrency is important as well. So by default, it's for one particular region. You have this unreserved code of concurrent connections which is 1000. So even if, let's say if you have four functions running so all of them will use it. It's not like every function can use 1000 concurrent connections at the same time. But if you... So this is where it is important to tweak the performance. If you know there are functions that will be called a lot like maybe they are linked with the API gateway and there are a lot of calls coming in then maybe you can use unreserved concurrency for that particular lambda function. But for this first hello world lambda function will keep the settings as it is and try to save it. Okay, save now. Good thing about lambda that you can do some quick testing without even generating the actual demo. So let's see this thing in action. So I now have this function which actually expect as S3 event. So the thing is it is a push event and whenever in AWS if you are working with the source which is pushing the event your lambda is not responsible for actually managing or creating the event trigger or trigger mechanism it is the responsibility of the source to give you the details of where to fire the event. So I can just go there in the properties and if there is a sort of option here event and I can create a new event like notification. I'm only interested in the document that I'm uploading and then there is an option you can send it to SNS, SQS and lambda function and just select the lambda function that we have created recently. So now we have made everything so it's time to see whether it works or not. So let me just apply. This looks appropriate. Don't ask me what I'm doing. I have this tool finding a tool. So now I can see this entry added here. So this is proof that it worked. So we have created our first lambda application but there are problems with it. The problems are that it's not sort of visible to create your lambda functions using AWS console maybe most of the time your user will not have the access to the AWS console anyways. So the other option that you have is that we can use AWS serverless application model. So serverless application model is the serverless framework that can allow you to build your serverless application and test it locally and then you can deploy it. So let's see this thing quickly. How much time I have? Alright so let's move fast. Alright so this is the port I have. It's the same port that I actually copy paste. So I have the source here and then I have some unit test here and the most important thing for the SAM application is the template YML file. This template YML file is actually the recipe that you give to your cloud formation service to actually create your stack. Our stack is really simple. We are only dealing with one resource and which is lambda service. So this is the detail that I have here. So whatever you, we have just, so whatever you can do in the AWS console by just clicking on the links, you can pretty much do the same thing here in the template and just give it to cloud formation and then it will create lambda service or any other thing that you need there. You can also provide the policies that you need or the events you are interested in. I have this readme file so this port is all on GitHub. I will share the links later. So you can just follow these links to set it up easily. So there are two commands that you can run to deploy your application using SAM. One is to package it and so it will package your code and put it in S3 bucket and then deploy it by referencing to the new template which will be generated by the package one. Both of these commands are sort of a record over cloud formation, AVX. All right, I can run this thing. So this is, I am doing a package command first. So now actually giving me an indication that your package is successful you can deploy it using this command and you can just do that by this. And the second thing that I am using is false demo tool stack and I mean based on your network condition it will probably take few seconds to few minutes. We can move on. So now AWS SAM is a better way if you compare with the console. But still the problem is like if you are working in a team it is not feasible to give everyone sort of this option to deploy. It would be hard to manage incremental changes. So this is where we come to the third stage which is some sort of continuous integration. And this is where we come to AWS code pipeline. You can create your own code pipeline so you don't need to publish and deploy things from your death machines. You can create your pipeline and then you push the code to GitHub or whatever source code management tool that you are using and then let the AWS stack sort of handle everything. So for that I have created this pipeline. It's a really simple one. So I already have the source code on my GitHub. It's actually looking at the GitHub my source and then if there is any change it will trigger a code build and the code build follows the recipe that I have here. So this is another, it's sort of the same code. The only difference is I have this build stack final file. So this is sort of a file that you will give to your code build and say how you want to build it. I mean you can do the same thing with Jenkins or any other thing but that's AWS way of doing it. So the only advantage of using code build is you will only pay for the bids. You will not pay for the whole servers. So whatever we want to do using the command line tool we can just put it here. I can do any install, I can run my unit test and then I can just do a package command. And then finally, drug formation. So this is much better than just directly using AWS app. So now we have like one really, really simple application which is sort of continuously integrating and you can see the results. On top of it you can go and you can use the version and the aliases that you can create in your Lambda functions so that you can create some aliases where some of your services are dependent on your staging, great changes and some of your services are relying on your dev changes. So far so good but this is a problem because right now what we are doing is like we are mainly focusing on AWS. So that actually brings me when I first started doing this thing I started with AWS and then I start sort of thinking that there must be other ways that we can do this thing. So the first thing that I sort of saw is serverless framework. Serverless framework is more of a infrastructure provider diagnostic framework that you can use. So when you are setting it up you still need to do some specific settings as for the platform that you are talking but it gives you sort of a wrapper and sort of an abstraction over a lot of the provider related stuff that you do. So the example is that this is the same code that I have. The only difference is that instead of the template I have the serverless file which is sort of more detailed than the cloud formation template file and it contains a lot of information but it is pretty consistent. So if you are sort of new to serverless serverless framework is sort of a good option. Yeah there are pros and cons of using SAM over serverless but I need to start with I think it's a good idea to start there. Okay really quick I am running out of time. So serverless and then after serverless I start looking cool serverless is working fine so what else. But the problem with serverless is even though I am using serverless not the SAM or the cloud formation I am still focusing on AWS. So another thing I want to explore the same solution in some other cloud platforms. So this is where I started looking into Google Cloud. So Google Cloud is the same solution that you can do in Google Cloud. You add a document in the bucket which sort of triggers your cloud function and then you do a entry in there at the store. So this is the code. It's pretty much the same code that we are just using different APIs. And the only difference between AWS and cloud is that AWS relies on your package to your zip file. Here in Google Cloud it actually looks like your NPM package. So if you define the entry point in your package or just when that would be good enough. So I found it pretty cool. It was fine. So I already have a function there which is working. Cool and if you want to know details I have this whole setup here for all the demos that I have shown so far and I will show the details later in the links. All right, coming back just one last thing. So this has nothing to do with lambdas or serverless. It's just to give you guys a bigger picture. So serverless is not always about cloud functions. So that's one of the proper solutions of the thing that we were discussing about approval model can be implemented using stack functions which is sort of a more detailed way. So again when you think about serverless architecture think beyond the cloud functions. So there are things that there are platforms that are already creating sort of aggregated or sort of higher level services that you can use the building blocks and create something more. In AWS this is a stack function that you can sort of create a visual programming and create sort of a workflow based solution. Microsoft Azure has a similar sort of a solution as well. So that was the stage 8. So we are pretty much done now. So yeah that is like my 8-stack sort of traversal of the whole train of serverless work. Yeah, and this is just a start. I mean, so I'm exploring new things just to figure out what new I can learn. So this is just a quick retrospect of what I have learned so far. Size of the package is important because it is a limit that varies from provider to provider. The requirement option whether to put it on the bucket whether you are just uploading it is important. Execution timeout is also important like what sort of functionality you are trying to execute in your serverless function. In the soft limit on AWS is 5 minutes and on Google it's 9 minutes something. Choose your options carefully how much memory you are allocating the CPU resources because it will actually translate into how much money you will pay. And what sort of other resources you are using because it will add your billing as well. And choose be really very careful in choosing a global scope because most of your functions will run concurrently maybe on different instances so it's better to keep them stateless. If you want to manage state maybe you can do it by putting it in some data storage or in some other way but be careful in using global scope. And plan for the resiliency. It's easy to overrun the lambda functions or your cloud functions if you start calling them. So your costing will become like a huge blow to your business. So make sure you have a proper strategy for the attacks like the DOS attacks and all that. And you manage like how you manage throttling and all that. So these are things are also really very important. Cool. All the source code is on also versus serverless. You can start there. There's a unique file containing all the information you can start from scratch and it will help you create the application. I've already started creating some videos from my source versus serverless series. Episode 1 is already up but I will add more episodes as I mentioned into the serverless board. That's it. Thank you so much.