There are a variety of services available for deploying an application. There are managed environments like Firebase or Heroku and more hands-on environments like DigitalOcean. After a little background, Kevin introduces Amazon’s RDS product and discusses why he’ll be using Elastic Beanstalk to deploy the application to RDS.
(upbeat music) That was the spin through the data model. But 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 on AWS? You tried, tried a little bit. That's okay, totally fine. 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. 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 100 different ways you could screw it up. So what we're gonna do is go through one pipeline to get a node.js app deployed on AWS, using a combination of Elastic Beanstalk, which is essentially managed Amazon EC2 instances.
And they're talking to an RDS database on the back end, and that are part of an Auto Scaling Group that we can configure to add more instances to our application, if necessary, to handle bursts in traffic, and can scale down based on our requirements, as well. So I'll talk a little bit about the production environment that we're gonna create at 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.
So we'll kind of do it together over the course of the exercise, hopefully, with the magic of television, we cut 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. That is the desired end state for today. Alright, let's do this thing. So first we'll kind of talk about the stack that 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. There's stuff that is completely 100% managed, and you're really only interacting with it via API. Things like Firebase, which you see on the far right of the screen. Firebase, you use an STK to sync data to their back end, and you don't actually manage any infrastructure at all, you're just using their back end 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 back end 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 in to, as if you were managing a fleet of physical servers.
Sort of more towards the middle is something like Heroku, where you are running an actual web application, but it's on a fully managed stack, 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, and you say "Heroku, here's my application, run it for me." And that works out really well. And kind of in between is this guy, this weirdo called Amazon Elastic Beanstalk.
And this is sort of the Amazon answer to Heroku, but it's much closer to managed infrastructure on your end, than it is to Heroku, where there's sort of a veil of secrecy which you can never penetrate. So the environment for this application that we're gonna try out is a combination. The two technologies are Elastic Beanstalk and 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 configurate, you're just running EC2 instances that you can SSH into, that are just Linux servers that are ultimately under your control. There's some management software that is running on them. And the way that you interact with them 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 on something like Heroku. Also, because it's part of the Amazon ecosystem and you can manage it through the administrative interface, it's easier to make Elastic Beanstalk play with other Amazon resources. And I finger quote easy because, if you've ever been in the Amazon administrative interface before, you will realize that nothing is every easy, ever.
But if once you do figure it out, it is actually pretty cool, sometimes. The way that you can set up your DNS with Route 53 and use S3 buckets and CloudFront for your static assets. There's lots of cool stuff that you can do, but the learning curve is incredibly high. And RDS 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 manual service, which has been working out pretty well.
So this is kind of the topology of the solution that we're gonna create, today. So the key technologies in the Amazon world, that we're going to be employing, are an Elastic Load Balancer, an Elastic Beanstalk Environment, which provisions Amazon EC2 instances within what's called an Auto Scaling Group so we so can define rules that say "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 outside world.
And then the Elastic Load Balancer will delegate those HTP requests to instances within our Auto Scaling Group, which, again, is managed by Elastic Beanstalk. And then all of our EC2 instances are talking to an RDS instance, that we also create within our Amazon account. So, again, at a high level, Elastic Load Balancer is shunting off HTTP traffic to all the different EC2 instances within our Auto Scaling Group, all of which are communicating with an RDS instance on the back end.
So that's what we're trying to create, at least today, at a very high level.
Note: This course was created by Frontend Masters. It was originally released on 12/28/2016. We're pleased to host this training in our library.
- Serving HTTP requests with Express
- NPM scripts and Grunt
- NPM scripts and Elastic Beanstalk
- The database
- Sequelize and PostgreSQL
- Production environment
- Elastic Beanstalk and RDS
- Provisioning an environment
- Sass and Sass alternatives
- Building with Vue.js
- Real-time user interfaces
- Production monitoring
- Google Universal Analytics