 Have a positive team, please feel free to speak your own direction, better than I wish. Okay, let's get the speaker set up here, come back here. Alright, I'm glad there's a full house, because I'm pretty excited to talk about this stuff. Had some ideas, they might not be original, but I hadn't seen them before. Quick background on where I come from, I spent two years in Zalora doing DevOps. Before that I was in California at DeviantArt doing DevOps. And before that, playing with servers in my room, setting them up on the floor. And now just floating around a little bit. So why JavaScript? We're back-end guys, JavaScripts for the front-end, right? I mean, aside from the Node.js, a little bit. And I asked someone, a guy I know, who's pretty good with security, to go through what I was doing. And he said, what's this for? And I told him about the talk, and he said, JavaScript web services, isn't that a little 2008? And I said, well, maybe there's a kind of a unique angle on this. So I'm going to do a live demo. It runs a little bit in the background. So I'm just going to start it off now, and then we can come back to it in a second. All right, so let me get my access key here. Oops, I've lost my mouse. There we go. Anyone have a name for a network you want to set up? What? Fubar. Can't really see the screen. All right, we'll just set the password to the same thing. OK, and leave that running. Go back to the presentation. OK, so is anyone on call right now? No? OK. People take on-call rotations. There's some people here who actually have to keep things running 24-7. OK, good. Yeah, so page-a-duty alert. You get this, you're out to lunch. Hopefully you have your laptop on you. If not, it's not going to be fun when you're trying to SSH into your servers on your phone. And I think we can do a little bit better than this. There's an AWS mobile app. I haven't really used it much. The main problem with this is that your infrastructure is unique and you can go and look at some things from here, but you really want to quickly get to what you need to fix. So the solution is to just always have your laptop. Just take it everywhere. But I think we can do a little bit better than that. Even if you have your laptop, you go into AWS and this is the interface that you have by default. Which is good, but it seems to be designed around provisioning and buying things. I think that's sort of the motivation that the designers of this have. So we want something a little bit nicer. I thought this looked really sexy when I saw it. This is a product mesosphere. It's a data center operating system, but we want something like a dashboard like this, but it would be nice to customize it for your particular infrastructure and also to be able to not just view things, but go in and fix things as well. So that still brings up the question, why even talk about JavaScript? We can build web apps for this. We know how to build web apps. We can put the web app in the data center and have it do things. But the reason is that managing servers sucks. It's not fun. It's fun in the beginning. When you first get a few hundred servers to play with, it's really exciting. But then after you get woken up for the third time that night, it's not so fun anymore. So servers are sort of an artifact of what we do. Nobody cares about it. They care about the data. They care about the sites running. They care about what's actually happening. So if we can limit the number of servers we have, then we're better off. So just a quick JavaScript refresher. I don't know if everybody here is also kind of a developer, how much DevOps has really caught on. Basic JavaScript here, we're going to put some text on the page. The JavaScript SDK. I didn't know this existed till recently, but you can pull this onto a page and actually make requests to AWS from JavaScript. And some of you might still be thinking, this is still crazy. Why would you want to do this? So bear with me. But first an example. So here is first lines here, setting up the configuration with your access key and the secret key, which you should never reveal to anybody. The region that we're in, we're going to instantiate an EC2 object. And since I had to make this key read only, we can't actually provision anything with this. I didn't want to go home and find a bunch of weird stuff happening to my account. But we can run like a read only method here, which is describe the account attributes. And then if we get the result, we're just going to put it on the page. So let's hope the network's working. And run this. And there it is. Okay, so these are the defaults for an AWS account. As far as I know, number of these BPC, not very interesting, but it is communicating with Amazon. Right. So security. Yeah. Don't hard code credentials. And I just broke that rule. Don't store credentials in local storage. As far as I know, most browsers are still storing these unencrypted. So if you have some kind of encryption set up, maybe that's okay. But also don't load third party JavaScript onto the same page. So just imagine for these rules that you've built, some kind of administrative interface on a web page that you've either locked down somehow or it's just local, just on your network. There's actually some really interesting attacks that can be done, even if you think your variable with the password is out of scope to other code. There's ways to load the function as text and parse through it and so on. So you really don't want to load anything from somewhere else. Do create accounts with limited access. Hopefully that works for the credentials I put up that it can only make a few read-only calls to EC2. I'll find out later. Do set CloudWatch billing alerts as a final backup because it seems to be that what I've heard of most when AWS accounts get compromised is Bitcoin miners are running as many instances as they can. I don't know if that's still financially viable or not. And do send everything over SSL. This is a little bit unintuitive at first. Why would that matter? But a man in the middle attack technically could put in some script to take the credentials and then send them off somewhere else. But SSL is expensive and it takes time. But as of last month, it doesn't anymore thanks to Let's Encrypt, which is really nice. You can see here this is running a couple days ago. It takes about five seconds and you have an SSL certificate. No account sign up, no nothing. So check it out. It's really nice. But we still have some problems with... So let's fix the problems in this script. And there's a simple way to do it. So this is a problem. It's insecure. Does anyone have an idea of how we might solve this? I'll give you a hint. It also takes care of making your page a little bit more lightweight by not loading the SDK. Yeah, move it server-side. So I've just contradicted myself a little bit. But fortunately, AWS has something called Lambda, which I don't know if anyone's used it yet. I just used it for the first time just a little while ago. So you see here basically the same code. I could switch in and show you this live, but I'm having a hard time seeing the screen. So hopefully this is just as good. You'll notice a difference with the code here is that we don't have the credentials in here anymore. And that is because each Lambda function can be assigned a role. So you create a role for it and you define what it can do and then you don't have to worry about hard coding credentials anymore. And then you get an endpoint for it, which is a nice, ugly endpoint, which hopefully nobody will see. And then we can use that in the code here. So now the code is no longer loading any libraries. This is just a normal Ajax request using pure JavaScript. So this is going to make a call to that endpoint, get the JSON back, parse it and put it on the page. So it's basically the same code as before, but without making the call here, the call is just going to the HTTP endpoint, not to Amazon directly. And there you go. So the idea is that if you have some administrative functions that you want to run, but you don't want to run a server for it just for that, because if you're running a server, you have to keep that server running as well. Other than a little bit unpredictable latency in my testing, it was up to like a second to load sometimes. This is a nice way to do that. So this is good for just the AWS stuff, but how do you communicate with the servers? Because a lot of the interesting stuff actually happens on the servers, unless you're purely using AWS services for everything, which some people do and that's fine, but I like to actually be able to try out kind of newer or weirder tech that I need an EC2 instance for. And JavaScript can't open arbitrary connections, so you can't open an SSH connection. But recently, Web Crypto came out, and so I'll show you if the demo worked correctly. It looks like it did. Okay, so now we have this host. Let me go log in. Let's take a look at the IP here and go into my EC2 account just for this. See what we've got. So now we have a fresh EC2 instance. Well, you might not be able to see this, but this IP should match up with what we're seeing here in the console. And this is one of the new Nano instances which does have half a gig, as Alex was saying. The key here is that we have, I think this is it, a little daemon running. That's the system de-general. Here it is, this thing called kernel, handling the communication. So what this did was, this was a static page with the AWS SDK. It took the credentials, it made the call to start up an EC2 instance, and it used webcrypto to generate an RSA key pair before it did that. It took the public key and put it into the user data on the instance. So when the instance came up, it had a start-up script to take that public key and start listening. Well, first, it got itself a dynamic DNS name and then it got itself an SSL certificate because certain things won't work like Chrome will block things from unsecure origins when you're dealing with webcrypto or certain other things. So it got its key, it got the SSL certificate, and it started listening for a signed request from the browser. So the browser took the private key, signed the request, which was setting the password, sent it to the instance, the instance validated the signature, set the password, and then from then on it's just like a normal web application. So some cool stuff that we're starting to get to do in the browser with things like webcrypto and things like that. That's it for the demo. If you want to look at any of the code for this, the actual code, the JavaScript side of it, it's a couple hundred lines of code and then there's 200 lines of Haskell for the daemon on the server. You can go take a look on the GitHub account and if you have any interest in this stuff or you're working on something like it, because it seems like these ideas sort of all arrive to people at the same time. Yeah? This is similar to New Relic. Sorry? Similar to New Relic. I guess, yeah. I think it's closer to something like, I mean New Relic's monitoring and so on. So you install an agent on the servers. This is, this was kind of an idea to see if we could have something that would also manage the servers as well. So that's an ambitious project. I don't know if I'll go that far with it, but I thought it was cool that you can actually now, you know, boot up an EC2 instance and get it running and provisioned just from your browser. So yeah, you can take a look at the code there and ask me questions. If anyone's interested in this stuff, I'd love to talk to you about it because I'm sure that other people are working on it themselves. Sorry, SDK support only for EC2 instance? No, no. No, it has a lot more. If we, I think I can click on the link here and show you, it's quite, I think it, I would imagine it covers everything. But maybe there's a few new, new services that it doesn't cover. Looks like I finished a little bit early and I don't see Alex here, so I guess I could take a few questions if anyone has any. Well, thanks. Thanks for your time.