This course has been updated! We now recommend you take the AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course.
Transcript from the "Elastic Beanstalk & RDS" Lesson
[00:00:00]
>> [MUSIC].
[00:00:03]
>> Kevin Whinnery: That was the spin through the data model. And now we're gonna get into one of the parts that I think might be new to more folks in the room. Who here today deploys code like on AWS.
>> Speaker 2: Tried.
>> Kevin Whinnery: You try it a little bit, that's okay, totally fine.
[00:00:27] So what we're gonna go over here is a stack that we can use in AWS using a few of their more popular product offerings. To stand up this application in production. Now this is definitely a piddly process. The reason why I think not too many people have deployed code into production on Amazon is because it's kind of a pain in the butt.
[00:00:54] There's a lot of different things you have to learn. There's a lot of steps that you can screw up. There's security groups and IM users and configurations and command line interfaces. And there's a hundred different ways you could screw it up. So what we're going to do is go through one pipeline to get a no JS app deployed on AWS.
[00:01:19] Using a combination of elastic stock which is essentially a managed Amazon instances. That and that are talking to an RDS database on the back end, and that are part of an auto scaling group that we can configure to add you know more instances to our application if necessary to handle bursts in traffic.
[00:01:44] And can scale down based on our requirements as well. So we'll talk a little bit about the production environment that we're going to create a high level. Talk about some AWS terms and then what we're actually gonna do is step through the provisioning of a new environment which is gonna take a while.
[00:02:04] So we'll kind of do it together over the course of the exercise. Hopefully with the magic of television we can cut this up a little bit later because each step does tend to take a little while. But the goal is for everybody to get the current running version of their application deployed onto their own personal AWS account.
[00:02:26] That is the desired end state for today. All right, let's do this thing. First we'll kind of talk about the stack we're choosing, kind of where it sits on the spectrum of possible production deployment environments for your web application code. There's kind of two ends of the spectrum that you might be familiar with.
[00:02:51] There's stuff that is completely 100% managed and you're really only interacting with it via API. Things like a Firebase which you see on the far right of the screen. Firebase is you use an SDK to sync data to their their backend. And you don't actually manage any infrastructure at all.
[00:03:13] You're just using their backend as a service. There have been other things like Parse and Convey and lots of other vendors in this space that have tried to remove the need for a backend in your application at all. On the other extreme, there is virtual hardware that you manage yourself, like Digital Ocean, Virtual Private Servers or Amazon EC2 instances, which are servers that you configure and deploy code to and SSH into as if you were managing a fleet of physical servers.
[00:03:50] More towards the middle is something like Heroku, where you are running an actual web application. But it's on a fully managed stack, like you can't SSH into the server, which is running your code. And the way that your code is run is actually completely abstracted to you. You say Heroku, here's my application, run it for me.
[00:04:12] And that works that works out really well. And then kind of in between, is this guy this weirdo called Amazon elastic bean stalk. And this is sort of the Amazon answer to Heroku but it's It's much closer to managed infrastructure on your end then it is to Heroku where there's sort of a veil of secrecy which you can never penetrate.
[00:04:40] So, the environment for this application that we're gonna try out is a combination or the two key technologies are Elastic Beanstalk Amazon RDS or Relational Database Service. So Elastic Beanstalk is interesting in that it's more configurable than most other platforms as a service. At the end of the day, even though you're using Elastic Beanstalk to configure it, you're just running EC2 instances that you can SSH into that are just like Linux servers that are alternately under your control.
[00:05:15] There are some management software that is running on them. And the way that you interact with them is can be a little wonky sometimes. But ultimately you have a lot more control over the actual hardware that your code is running on than you would in something like Heroku.
[00:05:32] Also because it's part of like the Amazon ecosystem and you can manage it through the ministry of interface, it's easier to make. Elastic bean stock in play with other Amazon resources and I think your quote easy because if you've ever been in the Amazon administrative interface before you'll realize that nothing is ever easy ever.
[00:05:54] But if once you do figure it out like it is actually pretty cool sometimes. The way that you can set up you know your DNS with route 53 and use S3 buckets in cloud front for your static assets. There's lots of cool stuff that you can do but the a learning curve is incredibly high.
[00:06:15] And RTS is a pretty good service. It's a performant way to run your database. It's obviously highly available. And it has managed software updates and snapshots. So a lot of the questions about reliability of your database kind of go away by using this this managed service, which has been working out pretty well.
[00:06:37] So this is kind of the topology of the solution that we're going to create today. So, the key technologies in the Amazon world that we're going to be employing are an Elastic Load Balancer, and elastic beanstalk environment which provisions Amazon, EC 2 instances within what's called an auto scaling group.
[00:07:03] So we can define rules that say, all right once the instances in our application are at 60% usage of CPU, that's the time to spin up another instance of the application. So the elastic load balancer is what will accept incoming HTTP traffic from the from the outside world.
[00:07:26] And then, the elastic load balancer will delegate those HTTP requests to instances within our auto scaling group which again is managed by elastic being stuck. And then all of our instances are talking to an RTS instance that we also create within our Amazon account. So again at a high level elastic load balancer is shutting off HTTP traffic to all the different EC2 instances within our auto scaling group, all of which are communicating with an RTS instance on the backend.
[00:08:05] So that's what we're trying to create at least at a very high level.