3 ms·
This could be a big deal in terms of raising the bar for deployment practices. Right now "nobody ever got fired for" setting up deployment via rsync and some a
by samstokes 12y ago
This could be a big deal in terms of raising the bar for deployment practices.
Right now "nobody ever got fired for" setting up deployment via rsync and some ad-hoc shell scripts. That works for a single host, although it's not great for reproducibility. But as soon as you go to multiple hosts you need some degree of orchestration, monitoring, and integration with your load balancer to avoid downtime.
CodeDeploy offers those benefits, so if it turns out to be even slightly good, it could become the "nobody ever got fired for" choice, for any non-trivial app running on AWS.
- rev_bird 12y agoIf the job is "get an app onto a bunch of boxes and load balance the healthy ones," I feel like AWS has already been doing that for a long time – deploy your code to a box, create an AMI from the box, and use it as a launch configuration for an auto scaling group. New code=new box=new AMI, and then you don't have to worry about the mechanics of moving code to a bunch of boxes at the same time. This seems like a tiny step forward for orgs who are deploying code to boxes that they never take down, but for the orgs that have been doing it the AWS-prescribed (immutable) way, I'm having trouble seeing how this is useful at all.
- samstokes 12y agoI think immutable infrastructure is probably the way forward, but it's not yet easy enough to be the default for lazy people. tiny step forward for orgs who are deploying code to boxes that they never take down That's exactly why this is a clever move - it's a better way to do what you already know how to do. This should get more teams using responsible deployment practices. If you have to first learn a whole new mindset about infrastructure, most people just won't bother, and will keep on rsyncing.