Hello and welcome to secure JavaScript programming with Vladimir de Turckheim. In this video, we will do some refreshers and introductions to serverless JavaScript. Serverless JavaScript is still pretty new. Server, we're running server-side code can be fully abstracted. Historically, when you run a JavaScript code or JavaScript node server, you run that, well, on a bare metal server or something like that. Then comes container as a service where instead of handling the host directly, you would provide a container and there will be a hosting solution ending that for you. As a higher level for that is Platform as a service. For instance, one the big leaders of that is Heroku where you just provide your codebase and you can actually link a GitHub repo and Heroku will know what to do with that. You can have your database or things like that already handled, but there is still a server. Heroku use Linux container technology under the hood and instantiates your code in a server. Well, there is a server in serverless, it's just subtracted that you don't have to update. The idea with serverless is can a Cloud provider give you all the bricks you need to build an application without thinking about OOPs at any time? Instead of thinking about having a database, you would get a Cloud storage. If you're using things like Firebase, they might even handle the authentication part for you. You need a real-time database, Firebase provides that for you. If we go to Google Cloud engine, they've got a lot of systems available. If you need to run applications, if you need to run a Kubernetes instance, or if you want to run databases and you don't have to think about databases, they will handle that for you. Same thing for AWS, they actually have storages. If you need a fetch system, you've got one, and database system. What's interesting with AWS, and Google, and Microsoft is that even if they provide their own database software such as DynamoDB for one, SQL, BigQuery for the user, well, it's still possible for you to get plane owned old databases, but handled by the Cloud provider. You don't need to do the OOPs under the server, but let's say you really want a MySQL database or postgreSQL where you can actually ask AWS to handle the creation and the administration of the database for you, and you won't have to update the base servers and things like that. You already abstract a lot of services. The next level that was actually coming was, can they abstract the architecture of your application? Instead of providing a full application, you can provide functions. We love a personal warning. I don't think serverless is fit to replace [inaudible]. It's actually very great when you did some certain resources with a lot of scaling for certain features for certain functions. Let's say you have a file uploading system, and you want to check for viruses in the files. Well, parsing your file upload to a three through a Lambda to do the antivirus check is actually a great idea. Replacing your express backend with AWS Lambda is counterproductive because functions have a cold start program, so if you want good performances, you need to make sure that they have a habit to survive. You end up with productions where people just have a crontab that do request to web functions to make sure that they don't cold-start because when they cold-start, they have to restart the wall environment. Also, in my personal opinion, it's actually not very smart to use Google or Node.js with AWS Lambda or any function as a service provider. Why is that? Because Node.js has been designed to handle multiple requests in a single thread. Apart from Google, most situations where you write functions will not share the same thread for multiple invocations and you will have multiple processes per invocation. You will end up either in a very weird situation where you don't know how to debug multiple elements in a single process because there will be side effects between two transactions in the same function, or here we'll use the word interest of using an asynchronous server side runtime. That was for my old-timer ranting about that, and my trial is saying that if you want one thread per request, you can use PHP which is a great language. What are the most popular serverless technologies in term of function as a service? Well, Firebase is really popular, especially across mobile development teams. Cloud Functions is a Microsoft solution. AWS Lambda is the flagship product of the serverless generation. If I'm not mistaken, they were the first to bring that to large-scale. Of course, Microsoft has solution for that on Azure Cloud. As of everything on Azure Cloud, it probably has a very good user experience, but I'm less familiar with this one. In this video, we will focus on Google Cloud Engine and AWS Lambda. Let's go through the process of creating your Lambda in AWS. Well, you just create function. Let's create from scratch, myjsfunction. Then here, they ask you about the runtime you want. You can run the.NET Core, Go, Java, Node.js. You can notice that in the latest supported you have one Node.js but you have also other supported with Node.js 10 and 12. Well, you need to make sure if you use outdated versions of the runtime that your Cloud Function provider provides patch for the vulnerabilities that might happen in the versions. I don't know, actually this is patterns of the past, I have met a lot of situation where function as a service provider did not have patches for vulnerabilities in Node.js and actually you could not do anything else than going on the versions they gave you. Hopefully that was in the past and now you can also provide your own runtime for AWS Lambda, which is basically providing your lane a container image and you can choose your version. Let's choose Node 14 because it's the latest version and here is a permission part. As this is a Cloud technology, everything must be linked with permissions because Lambda and a function runs within the scope of your Cloud organization. Meaning that it might have side effects and it might have access to the API of the AWS with high privileges if poorly configured. You need to audit and make sure that you're not giving the rights to your function to actually create other functions creates, tolerate, leak things, or even worst create user on your AWS organization. One of the main security issue with serverless is actually role authentication. Here we will use the blueprint, with basically Lambda permission, and we will expect AWS to provide us the right thing. Let's not go to agent setting and I have to move my video feedback because I was hiding the button even on my own screen. Now we wait. Very user-friendly interface for our AWS Lambda. If you have already played with that, you know what I'm talking about and we've got the function designer. Because it's a JavaScript function, one of the question is, how do you trigger it? There are multiple ways to trigger the function. For instance, it could come from a load balancer, it can come from CodeCommit if you're using Git on AWS, it can come from a Kinesis worker or it can be from S3 or something in SQS and there are also other partner things. However, if you want to turn an HTTP code into a function code, what you want to do is API Gateway. You want to say that it is an HTTP API, because we are terrible here, we will open it to the world. We have the name and we can add the trigger. Once again, we wait for AWS Lambda to provide us what we want. That's why usually, because of all these caveats, it's actually recommended to use scripts to generate all of that infrastructure as code because you can reuse code and you can make sure that you don't spend too much time configuring stuff because it says reusable code. Now we've got an editor. Of course, we can upload the function from code, from the zip file or from AWS S3, there is no direct Git integration. But they already wrote a piece of code where here in the case of AWS Lambda, you actually have an abstracted event. Let's do just a log function and then let's respond with the event. Test. Care, probability again in front of the table. Now it failed. Why did it fail? Unexpected token tool. Of course, I forgot to put a comma. Here we have the result, the response. It's as if it forgot to take my edits. I'm not exactly sure why it did not work as I wanted, but here it's deployed. Now we should be able to access our API through this. Let's click on the link and we have the results. That is actually the event that is passed to the function. Because if you remember that was a code of my function, it's about responding with the event if I can find it. Here it is, responding with the event. What's interesting is that AWS have abstracted in their own standout way, what's an HTTP request is. It's abstracted into this event thing. As you can see, I have nowhere to see my logs. That's actually because I miss a logger service and I'm not exactly sure what to do. That's right now because that's actually, what was it? Oh, monitoring. You can monitor those things, but you can also push the logs to AWS logs service and that's becomes even more complicated. In terms of UX, AWS is interesting because they abstract HTTP request. If we go to Google site of the things and create a function there. Let's use their defaults names. Because of my accent, you probably know that I am not in the US. Here, you see that the trigger part is less complex than AWS. It's less complete, but it's also less complex. I just put HTTP. We want it open and we want to require HTTPS. They create us a URL. If we go there, they tell us that there's nothing there because it hasn't been created yet. That's the interesting part. Right now by default, they give you an outdated version of node, but you can probably update. You have the notion of entry point where you can actually choose the name of the thing where you get in. You've got a package to JSON. Actually when you create a Google Cloud Function, you need to enable build system because there will be a package PM installed build item by default here. The other interesting part is that actually they tell you that this is pretty much the same thing as an express middleware. You've got a wreck, and erase objects that implement the same API. We don't really care if that's supposed till we get to end points, we will just say that each will by default do message and otherwise returns a message we want. Now we just want to wait for the function to be instantiated. If you are amazed by Google going fast compared to AWS in creating the object, well, you can consider that it may just take more time. Probably messed up something here. That's embarrassing. The log part is actually very easy and more straightforward. You can see that the logs are already available here and that Google actually has a more streamlined but less complex UX here. Here we are. If I put message equals hello Infosec. Each y it's hello Infosec, because our Cloud Function is deployed. Once again, you have seen in that case there were less thing to worry about because the permission things were by default limited and it doesn't have access to make Cloud organization or what might happen in AWS, which is a much more complex Cloud solution. That's a very dense video, but I have the feeling that going, one full course about AWS Lambdas with that serverless in general because I may choose a lot of cougar in this course without introducing what serverless is and how it works might not be the most actuate way to go. Also, if you want to simplify your serverless development, you can definitely use the serverless framework, which is a technology partner of AWS Lambda. They actually already have prebuilt scripting for deployment making the pain of creating a Lambda much lower. Thanks so much for these videos. See you soon, when we will get in depth about serverless security. Have a great day.
