Build apps, not infrastructure
Jimmy Schementi
@jschementi
Have you ever...
Changed code
directly in
production?
$ ssh myapp-prod-box
$ vi /app/server.js
Cowboy Coding
Application (feature)
vs.
Infrastructure (chore)
Prioritizing
infrastructure
makes it easier to
ship features
Think of
infrastructure
as a
product
you provide to
yourself
What features do we want?
- Deploy a brand new app to new servers
- Deploy existing app
- Scale an app
- Spin up a brand new environment
- All automated
- Doesn't make you broke
$ git push heroku master...
-----> Node.js app detected
...
-----> Launching... done
Application
Containers
Isolated the application’s view of the OS
Dockerfile
FROM centos:centos6
RUN yum install -y npm
COPY . /src
RUN cd /src; npm install
EXPOSE 8080
CMD ["node", "/src/index.js"]
Feels like something's missing...
Riker
Heroku-like application deployments for Amazon Web Services.
You're the captain, make Riker your #1
$ pip install riker$ riker config$ git clone git@github.com:heroku/node-js-sample.git$ cd node-js-sample$ riker deploy$ riker open
What does that do?
- Configures your AWS account to use Riker (first time only)
- Creates a base AMI (Ubuntu 14 + Docker) (first time only)
- Deploys your app (first time launches new instance)
- Saves new AMI
- Configures Route53 and gives you URL
Deploy apps
written in any
programming
language
(uses Heroku Buildpacks)
Production-ready
riker deploy --scaleProvisions load-balancer and auto-scaling for each app
Use AWS to manually scale or automate it with CloudWatch
Manages rolling deployments
New instances only available after passing health check, old instances then fall out.
Deploy a static website to
S3
$ mkdir static-website && cd static-website$ echo "Hello, World" > index.html$ touch .s3 # tells Riker to deploy to Amazon S3$ git init && git add -A && git commit -m "Initial commit"$ riker deploy$ riker open
Future
- Support more clouds (eg. DigitalOcean)
- Dockerfile support
- Use more of AWS
(Beanstalk, CodeDeploy, EC2 Container Services, etc...)