386 karma · joined July 21, 2009
Slightly off topic, I'm a big fan of continuous deployments, but 500 deployments a day seems excessive. Assuming an 8 hour work day, thats more than 1 deploy every minute. Its great that this system works that seamlessly, but are there really benefits with deploying that frequently?
From their blog posted last month:
As we started transitioning hosts and services to our own data center, we quickly realized we'd also need an efficient process for installing and configuring operating systems on this new hardware.
Im not positive, but it sounds like a fairly recent switch from a cloud provider to their own datacenter. If thats the case, Id expect a number of outages to come in the following months.
While I do think you were already gone, it sounds like you handled things horribly during this 6 month period. You should have cut off all contact with the other person and started job hunting.
I would stick to doing whatever will give you the most confidence when talking to companies. If that is studying data structures/algorithms then keep doing that. If its launching a side project focus on that instead.
Remote: Yes
Willing to relocate: No
Technologies: JavaScript, node.js, iOS, Swift, Objective-C, RESTful apis, angularjs, ansible, docker, extensive AWS experiences
Resume: https://s3.amazonaws.com/fitz-docs/resume/rf-resume.pdf
email: ryan.fitz1@gmail.com
github: https://github.com/ryanfitz
twitter: https://twitter.com/theRyanFitz
--
Hey I'm Ryan. Im a tech lead, full stack developer and Techstars graduate. I’ve built and launched multiple iOS apps which have been featured in the App Store. I have extensive experience building highly available, scalable and cost effective systems on AWS.
The CodeDeploy service seems to operate by you manually launching base ec2 instance with a code deploy agent and then this agent will checkout your git code on the live instance, run any provisioning steps and then if things break somehow rollback all that work, still on the live instance.
I'm sure this is still a big improvement to companies who are manually sshing into servers and running deployments by hand, but as someone who pre-bakes ami's and does rolling upgrades with autoscaling groups this service seems like a step backwards.
The reason you want a fully created ami is to greatly cut down on the time it takes to accept new traffic. Lets say you get a spike in traffic, if you have a fully baked ami your autoscaling group can get an alert of the increase in traffic, launch a new instance and that instance will start handling traffic around 60 or so seconds. If you booted a generic ami and then provisioned the box you could easily be looking at 10's of minutes before it could handle traffic depending on the complexity of your app. This could easily lead towards long periods of down time.
DocumentDB seems much more similar to mongodb and appears to have a very flexible query ability. In my opinion, one of the best features with DynamoDB is you can tune the number of reads/writes each individual table requires. This lets you scale up and down your database and greatly helps keep costs down. This is a feature that only a hosted database service can offer. I haven't yet read any pricing info on DocumentDB, but hopefully they offer a similar feature as this is really where a hosted database service can shine.
[1]https://github.com/Wantworthy/dynode [2]https://github.com/ryanfitz/vogels
I created a /tokens endpoint, where I POST the auth credentials and in return I get back a newly generated auth token. In my opinion this is a nice RESTFul solution.
I have been doing continuous deployments baking ami's with asgard for a couple of years now and have had great results.
Fullstack developer with 10 years of experience. Worked with many startups, having launched products both on the web and mobile (ios).
Specialties: Highly scalable and reliable applications (powered by AWS), distributed systems, RESTful apis, service oriented architecture, JavaScript, node.js, objective-c, backbone.js, AngularJS, jQuery, DevOps, puppet, redis, DynamoDB, postgresql, elasticsearch, AWS, project management
* Github: https://github.com/ryanfitz
* LinkedIn: http://www.linkedin.com/pub/ryan-fitzgerald/3/8a8/a82
Netflix has talked about a similar approach. The basic process is to have volumes from existing AMIs already mounted to your buildbox. Then when you kick off a build it checks out your code, compiles and installs it on one of those volumes, runs puppet in a chroot on the volume to do any needed configuration. Finally you unmount the volume and create a fully bootable AMI. I scripted this up in python and the baking process takes around 60 seconds.