 A third evolution. I mean, I think you just talked about it. Going to serverless, FAA, from pass to fast. Doesn't sound good, doesn't it? I'm now using a fast. They've actually done a term for that, a spectrum of compute. Yeah, yeah. Oh, someone told me something the other day, which I thought was a bit strange, but maybe quite apt, born in the cloud. Because I guess the trouble with serverless and lambda is that you kind of have to architect your application this way from the beginning, right? You can't migrate your Windows 95 to lambda. No, no. Please don't. OK, I think we're still filtering in. Hey, someone can sit in my chair. It's warm. So you don't have to stand. Shall we just close the door? You're excited? Can someone just shout around the corner saying, it's starting, it's starting. Oh my god. I didn't close the door. OK, oh, there's a free seat right here. Just don't be shy. So does this work? Yeah, kind of. So I work with Daniel over there, who also helps organize stuff. And yeah, I think I feel like an astronaut, because I think we're using lambda technologies at work in a pretty hardcore manner. And I guess I'm just going to share what I'm learning. I've learned over how long we've been doing this, Daniel, like three months, couple of months. And where our work is spooled is a company called Spools. It's like the Netflix for Indian content. And this is a way of describing it. And what we've engineered using lambda functions is a content provider uploads the film to S3 that triggers off an encoding job to take a clip of that video and then furthermore crop it. And right now we're at about 10 lambda functions for the whole video ingestion process. And even though it's not quite production yet, I mean, well, it is production. I think it's a moderate success, somewhat. I mean, we've made some mistakes. And this is what I'm going to share with you. Oh my gosh, I didn't start the timer, 15 minutes. So yeah, this is why I titled it from the trenches. It's just like war stories. But I guess your grandfather one was a lot better than this one. A lot better, hopefully. So I can't actually see the screen. OK, so Yoss sort of introduced us to lambda functions. One thing, I think, here in the hate over there, he was saying that it's proprietary. No, no, no. This idea of function running in the cloud is pioneered by Amazon. But there are the Microsoft version, which is just damn similar. I mean, they're all very, very much the same, in my opinion. IBM OpenWISC, Google, whatever that. And the way that I think of lambda is basically just manage code environment in the cloud. And hopefully you guys got that at least tonight. Another thing that this is a stupid analogy so you can just shoot me down. I'm a bit of a Unix old school sort of guy. Who's used Plan 9? Just me. Just me. But I'm a big fan of the Unix philosophy, doing one thing and one thing well. I think that buys into the whole idea of lambda functions. But furthermore, I mean, everyone's familiar with this sort of fine grep. Do you guys use Unix? Oh, god. Oh, god. But it's pretty much like Unix, but on steroids, I would say. And also, it's unlike pipes. Like for example, when you're doing with Unix pipes, handling error cases is quite tricky. And the cool thing about Amazon Lambda, I think, is that you can actually save the event so you can replay them, which is pretty interesting. And then everything is event-driven, which is actually pretty crap on a Unix system. Events is a bit of a nightmare. So yeah, this is what I told you guys already. Oh, sorry. So somewhere out there, hopefully, I won't defocus. So yeah, we're using Lambda at work. And furthermore, we're also using DynamoDB. This is important because when you're using DynamoDB to use things, you're probably going to end up having to use JavaScript. I'll probably get onto that. And we probably made a one mistake because we split up all our Lambda functions with serverless framework, which Joss was speaking about briefly. You can combine things, which is probably a bad idea. But now we've invested in doing separate things. We probably made a mistake there. There are several ways to deploy your Lambda functions. You could just use the AWS CLI, but it's quite naive. You have to do everything manually, zip it up, and then you do deploy somehow. But serverless is not just a way of describing this way of computing. Serverless is actually a company that provides tooling. And that's what we use. There's another one called Apex Run. And this is the main tools that you use to deploy your Lambda functions. The other one we're using is the core serverless. It's an NTF project called Lambda Locom, which for if you're running a single Lambda function, serverless seems to be overkill for one function. Lambda Locom just allows you to run your Lambda locally with what you would like to do, the PNJS or the handler, and one event. And that's it. And you won't have to do a whole overhead of your serverless with YAML files. The important thing to realize is that when you're developing, serverless especially gives you tooling to develop locally, which is really important, because you might be on a crappy internet connection somewhere in Asia. Another important tool, which I like about the whole Lambda thing, is you can, which I do pretty much on all our Lambda stuff, you can SNS subscribe. So basically, when a movie flows through this sort of 10 Lambda functions, I can have good visibility of all the events that are happening just with a subscribe, like an email subscribe, which I find quite useful. So yeah, the cool thing about Lambda on AWS at least is that you get free logging. So every time that Lambda function runs, you have a great log. Every time you console log, you have a great log of what actually happened. There is a bit of a downside to it. There's a little bit of delay. You're probably familiar with it. But I find the log very, very useful, because you don't have to worry about instrumenting your program so much. It's just there, and it's very robust. Another good thing is that it makes you think in these sort of events, which you can basically store as files.json, and then you can use that as test cases. You can use it to make sure that your functions are idempotent. I never know how to pronounce that word. Did I say it correctly? Idempotency. And another thing is that you might be worried about the long iteration cycles, but when you do it locally, it's quite fast. And it's got like added benefits with serverless that you can set up web endpoints really, really easily with it, which is damn useful. So the not-so-good thing is that I guess this applies to the whole cloud thing. I mean, I don't know about you, but I'm really lazy when it comes to defining policies. So for example, I start writing a program, and then I deploy it, and it doesn't work for whatever permission error. And then I have to add it back, add the permission in there, and then run it again, add the permission. I wish there was a way of sort of running the function. And then depending on what resources it used, it would just come out with a policy that it recommends I use with my function. Does anyone else find policies just painful? OK, there's one other person. So the next kind of painful thing is that you do have options as Yoss pointed out of using Python or Java or what is the other one? There's probably another one. But you really need to use JavaScript, because it's the most native one. You're dealing with SNS event JSON. You're dealing with using doc clients on DynamoDB. You really do want to use JavaScript. And when you use JavaScript, you painfully realize that you have to learn promises as what we had to do to make everything synchronous and kind of manageable. Who's familiar with JavaScript promises? Well, I found it quite a steep learning curve. And it's kind of like I didn't want to use too many libraries. But I guess the good news is that our new node versions will have better like async await things to help you code in JavaScript. There's things like, yeah, you're kind of limited by cloud formation, which can be quite slow, like not everything you can define in cloud formation. So that kind of limits you. You just need to be aware of it, really. And one thing that we found with the serverless, I mean, is there anyone know how to solve this problem? Is that it's polluted our S3 sort of namespace with all these serverless things? Because it uses S3 to stage the deployment. And also, YAML, I hate that format. Is it just me that hates that format? The minute you just get like one like wrong indent and you're screwed, hate it. But that's why you have to use Python. Yeah. I hate Python for other reasons. Oh my gosh. Why do you use JSON instead of JSON instead? Yeah, like Apex Run uses JSON, which is nice. I mean, any JSON files are still available. Yeah, I know what you're saying. But mm, mm, mm, mm, mm, mm, mm, mm, mm, mm, mm, mm. OK, so all right. So yeah, Amazon at JS SDK. It's a bit of a nightmare. I want you to mention that also a big benefit of obviously using JavaScript is that you can start doing your front end, which is naturally probably going to be a web application and, again, in JavaScript. So other things that really, really annoy me is that you can't put too much stuff in your handler. It's a bad idea. Don't do it. You're kind of going to need to keep your hand quite slim, in my opinion, and keep maybe the functionalities in a separate JS file, which you can test and do separately. The really, really bad thing is that there's no debugger as far as, is there a debugger? Fuck. My boss, I had an ex-boss, a really good guy. He always used to say to me, if you're on a project and there's no debugger, think about leaving that project. It sucks not having a debugger, especially when JavaScript probably does have the best debugger in this industry, arguably. I'm sure just Amazon just need to basically get it out of. I'm hoping Amazon have the solution. I hope they have the solution. But it is really quite painful right now with no debugger. So this is why I say keep your code separate so you can test it out of the context of your handler. It's slow logging. I mentioned that. When there is an error with your handler, it can be quite tricky to just go to the exact log. I mean, I don't know if you have a nice workflow, but when you're running lots of landers, hundreds of them, and there's one error, it's really difficult to track it down in CloudWatch. There's someone know a way of doing this, because it really irritates me. Another thing I don't really like is that you typically use JavaScript. I'm quite new to JavaScript. Like, for example, Sebastian is a pro. He's a ninja. And then when you upload the node modules, you know how it is. It's like, I get nervous. I get into sweats. It's like, what's there? You don't have good visibility. Is it out of date? Because with the cool thing, what you want to do with lambda functions is just deploy and forget. But with 400 megabytes of node modules, scary stuff. I'm hoping Amazon will solve a lot of my complaints with step functions is a way of saying if this lambda function fails, do this. It's a way of orchestrating your lambda functions, which is sorely needed. Because if you're doing it with your head all your time, your head will go sore. X-ray is supposed to be like a debugger thing. But when I looked at it, it didn't actually help me. But there are like, what do you call it? Startups that are kind of solving this problem, I think. But I'm just reluctant to use a startup solution sometimes. You know how it is. So yeah, to conclude, I'm sorry, guys. It's 2017. You all have to learn JavaScript. You've got no choice. Who's one of these Java stalwarts here? I feel sorry for you. I'm sorry. I'm so sorry. I do recommend serverless, even though it's a little bit annoying. I don't think there's anything better than it. If it is, just let me know. I did link, oh, crocky, I'll put the presentation below on the video or something like this. But there's a link to serverless examples, which are a really good way to start. And despite my complaints, I think lambda is definitely like a step up from ECS. ECS is a nightmare, in my experience. And I personally have given, written a couple of stupid, what do you call it, websites that use lambda functions in the back end. For example, this one. This one is a lambda function that has phantom.js as a binary that basically, if I put a URL there, you can't see. Hopefully nothing too embarrassing. It basically uses phantom.js, retrieves that, outputs that to PDF, and embeds it in there. So now you can tell your boss, I can print the internet now. Just give me a URL, boss, I can do it. So that's using a lambda function. And it's pretty quick. I even did a stupid video about it. So you can do these little things. And I love it because you can just sort of like, fire and forget. Oh, this is a little-known feature about the sort of integrations you can do with lambda. This one is integration with SCS. So if you email that, I'm probably the only one who has this complaint. Do you ever get emails and then only look at the text part? I don't read HTML email. I just. It's 2017. Does anyone read text email? Anyway, this project, which no one seems to care about, I don't know why, because it's awesome. It rips out the HTML part, so it just shows you the text part of the email. Are you doing anything of that kind? No, it's an iPhone, Doug. What the hell are you on? It does have an ancient browser, though, called Safari. Heard of it? OK, I got one minute left. Yeah, so I think it's, I like it because, yeah, you can write something, you can deploy it. And I don't know about you guys if you've had little side projects, but this feels so much more relaxing. You do a side project, you deploy it into a lambda function, you just know it's going to work. It's going to work into the future. And that's just like, well, that's how I feel about it. Yeah, that's pretty much it, guys. That's all I had to say about serverless. I really want you guys to get onto it. So I'm very happy to hear from you if you have any question about it. Because the sooner I genuinely feel that it is like some sort of advancement in computing technology. So the more Singaporean businesses and more Singaporean peeps start using it, I think it will make us smarter than the next silly country. OK, any questions? Oh, yeah. What's the most complex lambda function you've deployed in? How much does it cost you to run this? Oh, I could probably show you even now, shall I? No, it's, no, what would you say is the most complicated one, the video encoding DRM one? That's quite complicated. Actually, if you look at all the functions in this virtual machine itself, none of them are complicated. Because what was said in the beginning, you could split everything into any kind of function that you could solve. Every function is kind of easy to understand on itself. And so I just start to cheat them all together. Yeah, that's the good point. I think the first one that you gave was the most complicated one, the first one. And that's one of the questions of the binaries. So our first question is to actually extract video metadata out of an appropriate file. FF probe. So we use a mix of the FFM and FMF to get back the dimension of the source file to kind of perfectly guess how much black board is off the left, what's in the right, what's in the middle of the left. So an SPO is called the knowledge of data function that triggers a system code to run FF through the FMF to get all these information and solve back the dimension. I think that's the most complex in CPU terms. Oh, you're worried about the cost, right? Yeah, the high-precision CPU, but it's got to be an instance for running a lambda function. The lambda function ends up cheaper. I don't know. But you can't run long-running. You can't do long-running. Yes, I don't want to do it. Sorry, sorry. Yeah, high-precision. You've got to remember that lambda functions are limited, not just the environment, which is like 500 megabytes. So you can't really do a big video. I think the max is like five minutes. You can run it, keep it going. And then I realize that it's very quiet. Yeah, so you don't do long-running things. If you have a complicated lambda function, probably doing it wrong is what I would say. Keep it simple. Yep, sorry. Like in my project, any publicly exposed APIs that do some sort of significant computational stuff that would. Oh, like the fact that you had to protect your. Yeah, I imagine. We do, and we use just a basic authorizer. I think the max is just a callback from the video recorder that's basically taking something and start storing it in a way that's a few minutes second for it. Yeah, that is not something. We just basically use a name, column, password. Yeah, so that's not public facing in that sense. No, like if someone is sitting on a line, and he's sitting on the edge. Well, my print the internet thing is open to the world. And yeah, it's kind of expanding on the other question from before, did you ever run it through? No, I haven't seen any remotely significant costs for the lambda. I mean, maybe, what was that say? Maybe later? Maybe later, sure. But like, I mean, anyone who's ever spun up at EC2 and forgotten about it, I mean, dude, it's orders of magnitude. Yeah, like, I've done that. No, to be honest, I haven't seen. This is what I really struggle with. People ask me about the cloud. Everyone asks me, what is the price? What is it going to be? I can't really tell you, but I know it's going to be a ton less cost than your probably existing infrastructure or the way you architect it currently. No, it will cost only 10 for the amount of time. Yeah. So if you have a job that needs a CPU 100% 247, that's at that point when I know more the right stuff. In our case, when a movie is a film, it's important to know something. That's not something that happens, let's say, when you really receive a lot of content at the end of the day, I don't want to get an EC2 for 10 as the reason to move from an EC2, we had an EC2 before, no more EC2 for 100% function. Yeah, the costs are pretty dull. You've got to try it out. In fact, if you manage to make an expensive lambda function, you've got to share the code with me. It would be interesting how you did it. Any more questions? Oh, sorry. Share the transition. Well, I sort of hinted about this earlier. You kind of need to architect. I think this phrase born in the cloud, you have to architect for the lambda function to begin with. There's no real migration path in my opinion, unless everything's maybe broken up into JavaScript functions already, which is probably unlikely in your app. So yeah, I wouldn't say there's a, is that, did I answer your question kind of? Yeah, you need to re-architect, sorry. Yep. How is the accession handling? Accession handling is, it works. It's just like JavaScript, I guess. You can, I'm not a huge error person, but the way that I usually write them is, because we're using promises, but it's a promise reject. And then it depends actually if you're doing like, if you have like your lambda attached to HTTP event, you have to worry about your HTTP responses. But normally you just do a call back with your error, and then your lambda function just ends, boom. So yep, it's pretty simple. I like it. I'm excited about it. Why do you put on the JavaScript what's wrong with it? Why should we not use the other languages? Because they're not as, let me know, let me know. No, what do you have for Christ's sake? Who invented this UI, some idiot? I think JavaScript, I have the feeling that it's way more native and better supported than the other languages. I just have that feeling. It's probably, it's not based on anything. And it makes it easier to deal with JSON, it makes it easier to deal with the DynamoDB. I mean, has anyone used DynamoDB without using something like Dock Client? Because that's insane. Because it's horrible to use without the AWS Dock Client abstraction, in my opinion. You have to worry about types all the time, which is boring. OK. Any other questions? Oh, yeah. OK. So how easy is it to set up your Lambda serverless functions on backends that are sort of, like, maybe like a CDN would do it. Like, you put it closer to your users for different users. Oh, well, you know what you call it. It's pretty straightforward to attach to HTTP event. You get an endpoint, then you put that behind CloudFront. I've done that pretty much with all my demos, yeah. Because the CloudFront gives you the SSL with your domain. Sorry. It gives you a domain. And then, obviously, you set up your CloudFront not to cache on the post and the other, to whitelist the headers, right? So you're putting CloudFront in front of Lambda? Yep. But what about running, like, because you're just what about Lambda on different? So in some data center. So can you run it for Singapore user in Singapore? Can you run it for the US user in the US? You could do, I guess. There is CloudFront at Edge, but OK. Yes? There's something called Lambda Edge. But it's very limited. I think it's not worth getting too excited about. Don't get excited about it. There is new technology called Lambda Edge, which is in beta or something like this. And that is a game changer when it actually works. Because the idea is that every CloudFront pop around the world, there's a ton of them. There's a zillion. The idea is that you can run your Lambda function on that pop. Never mind a region on the fricking pop. So now, your user experience for your users potentially all around the world is like 20 millisecond roundtimes on something actually happening. That is phenomenal, in my opinion. It's usually the user experience for something happening, API something, is like 200 milliseconds. I mean, that's a big. That's Lambda Edge with Lambda Edge. Yeah, it won't. Lambda Edge right now is for just rewriting headers and things like that. Kind of boring stuff. But maybe it will get more amazing or something like this. I think, like, Fastly is doing something like this, I heard. I was watching some YouTube video. So I think the future is JavaScript running on the edge, JavaScript running on the browser, JavaScript everywhere. Isn't it exciting? It's kind of scary, actually. But yeah, good work, Sebastian, with that JavaScript thing. It was a good bet. OK, that's enough. Thanks, guys, for coming once again. The videos are going to be online. Oh, jeez, I must not forget this. If anyone wants to talk about something somewhat interesting, ideally for me, something that you've just learned from work, something practical that's not.