Transcript from the "Q&A" Lesson
>> Speaker 1: Does Lambda integrate with GitHub or version control at all?
>> Steve Kinney: Go on.
>> Speaker 1: So they've got their versions that are listed. But I'd be concerned about keeping potentially critical functions out of version control in their own repo, where we can roll things back.
>> Steve Kinney: So this is where some of the stuff like Terraform and CloudFormation becomes interesting, right?
[00:00:25] Cuz you can basically deploy your infrastructure from any of these files. So that's a much more useful way of doing it, rather than going into the UI, hope for the best, is not great. But that is definitely, it's one of those things where having reusable infrastructure and code, automated infrastructure, is great, right?
[00:00:48] And anything you can do in the UI, you can do from the command line. So the very first level is, could you set up a Travis job, or whatever, to, upon committing to master, deploys that through the command line, up to Lambda, yes, right? But then you get into the world where your world is run by a set of batch scripts, which is true, right?
[00:01:07] So the easiest way is the command line tool, some batch scripts, CI/CD. A more advanced way is then, when you get into Terraform and CloudFormation. Of being able to just push those things, and spin up the entire world, is probably a more robust, long-term way to do that.
[00:01:22] But again, doing it in the UI, super quick and easy, paste, hit Save, hit Publish. Doing it from the command line, there's that little bit more effort, right? If you're doing this all the time, the effort to get Terraform or CloudFormation is not unbearable. I mean, some people on my team will disagree with that.
[00:01:40] But it all depends on what level of effort you, putting a lot of effort now to save it later, totally worth it. And so you've gotta have to dial that in correctly. And that's always one of the hard choices of, next thing you know, you're writing your own blogging engine, [LAUGH].
[00:01:55] Cuz who amongst us, before you can write a blog post, you have to write a blogging engine, cool.
>> Speaker 3: Can you use CloudFront in front of your own servers?
>> Steve Kinney: Yep, so we pasted in that S3 URL, that could be anything, right? If you have static SS just sitting on a digital ocean server?
[00:02:14] Yeah, you could totally just point it there, and it'll cache those things, so on and so forth, right? You can actually have a Cloudfront distribution with multiple origins too. So you could say, okay, slash API goes here, so and and so forth. But yeah, you can put it in front of pretty much anything, and it will do its basic caching.
[00:02:32] And you can choose what you let through, and stuff like that as well.
>> Speaker 3: Do they bill you differently for that, if you're not getting it from S3?
>> Steve Kinney: They bill you, I believe, and don't quote me on this, it is data transferred through CloudFront, okay?
>> Speaker 3: Okay, [CROSSTALK]
>> Steve Kinney: Right, so they don't care where it came from. That said, I said before, when you go from CloudFront to another Amazon service, you do use that private set of tubes to get there. So it's also really great, even if you have CloudFront effectively as a pass-through, right?
[00:03:03] So for some of your APIs, you might not wanna cache stuff, you might always want fresh stuff. There are a few things you need, it's either got a super low TTL, right, time to live, right? That means if your server's getting hammered, and let's say, that data's not changing that often.
[00:03:17] You could have a CloudFront distribution on an API that has a TTL of one second. Which means, now, instead of getting 10,000 requests a minute, you're only getting 60 on that server, right? But even if you pass everything through, because it's on Amazon Network, it will get to other Amazon services faster, as well.
[00:03:32] Which is tangential to the question you asked, but yeah, cool, thank you so much.
>> Group: [APPLAUSE]