DevOps
DevOps has been one of my core skillsets since I learned it had a name. Here are some of the projects I've worked on recently in a DevOps role.
Every developer should be able to ship to prod
I first started working with Aaptiv as a consultant. At the time, the company consisted of 5 people. The backend API for the app ran on Heroku. Over time, the number of customers grew as did the number of employees, and the size of the app. Somewhere in that span, I transitioned from consultant to employee, and we decided to transition from Heroku to AWS to leverage the cost savings for our growing team.
The migration took over a year. Partly because we switched from ECS on EC2 instances to become early adopters of a new AWS product: ECS Fargate. The other part of the long transition was due to an uncompromising commitment to make deploying on AWS as easy as deploying to Heroku for our developers.
That meant 1 file.
Any developer should be able to deploy a new app to production by including 1 file in their repo. It did not matter if they knew what subnets to use. It did not matter if they knew which VPC to deploy in. It did not even matter if they knew what a VPC was...
The result was this:
Any developer should be able to deploy a new app to production by including 1 file in their repo. It did not matter if they knew what subnets to use. It did not matter if they knew which VPC to deploy in. It did not even matter if they knew what a VPC was...
The result was this:
releaseBranch: 'master',
releaseFamily: '1.1.x',
containerCounts: [
'dev': [
'minimumCount': 1,
'desiredCount': 1,
'maximumCount': 6
],
'staging': [
'minimumCount': 15,
'desiredCount': 20,
'maximumCount': 30
],
'prod': [
'minimumCount': 15,
'desiredCount': 20,
'maximumCount': 30
]
],
scaleOutThreshold: '.190',
scaleInThreshold: '.150',
alarmStatistic: 'Average',
cpu: 512,
memory: 2048,
scheme: 'internet-facing',
containerPort: 3000,
healthCheckPath: '/health',
healthCheckGracePeriodSeconds: 50,
agentLabel: 'nodejs',
CrossEnvAccess: 'true',
releaseFamily: '1.1.x',
containerCounts: [
'dev': [
'minimumCount': 1,
'desiredCount': 1,
'maximumCount': 6
],
'staging': [
'minimumCount': 15,
'desiredCount': 20,
'maximumCount': 30
],
'prod': [
'minimumCount': 15,
'desiredCount': 20,
'maximumCount': 30
]
],
scaleOutThreshold: '.190',
scaleInThreshold: '.150',
alarmStatistic: 'Average',
cpu: 512,
memory: 2048,
scheme: 'internet-facing',
containerPort: 3000,
healthCheckPath: '/health',
healthCheckGracePeriodSeconds: 50,
agentLabel: 'nodejs',
CrossEnvAccess: 'true',
Any developer could ship to production using security groups, SSL, auto-scaling, and built-in alerts using just that file.
And cost savings? Yeah. We captured cost savings. Over $10k per month of what it would have cost to run the same infrastructure on Aaptiv.
And cost savings? Yeah. We captured cost savings. Over $10k per month of what it would have cost to run the same infrastructure on Aaptiv.
The underlying technology consisted of bash and python scripts to generate CloudFormation templates, all powered by a Jenkins CI/CD server running on an EC2 instance with webhooks triggered by Github. One of the key metrics for success was how often developers pushed to production. A higher level of confidence in their ability to deploy/rollback resulted in more frequent deploys.
All of this was accomplished while managing the increasing demands of a successfully growing business.
