11 ms·

AWS CodeDeploy

211 points by helper 12y ago

bmajz 12y ago
Interesting. Between Elastic Beanstalk, OpsWorks, and now CodeDeploy it seems like AWS is taking over every production developer workflow from the hobbyist on up.
- general_failure 12y ago
  I find none of them good enough for my workflow. I think heroku nailed it with their deployment approach for my case. Beanstalk worker tiers are a nightmare. You need to place all your workers in separate repos, for example for git aws.push style workflow to work.
  - bmajz 12y ago
    Good point. Plus Heroku just gives you so many more options instead of the 3-4 that ElasticBeanstalk provides, although Docker integration potentially changes the calculus significantly. Interesting that its taking EB so long to catch up to Heroku on that front.
  - nixarn 12y ago
    Yeah I was also hoping this would be more something along the lines of the Google App Engine. I like just writing the application's code not having to worry about the stack too much.
bkeroack 12y ago
Here's an open source tool that does something very similar (and you aren't vendor-locked into AWS): https://bitbucket.org/scorebig/elita https://bitbucket.org/scorebig/elita
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 ago
  If 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 ago
    I 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.
marbemac 12y ago
How does this compare to Deis? Does it serve the same use case, albeit locked into AWS? Discussion on Deis from yesterday: https://news.ycombinator.com/item?id=8591209 https://news.ycombinator.com/item?id=8591209
ryanfitz 12y ago
I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seconds and start working. This greatly helps with scaling up, doing rolling upgrades and also very easy rollbacks. 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.
- Zariel 12y ago
  Looks like an improved version of OpsWorks
  - ninjaplease 12y ago
    ...improved?
- conorgil145 12y ago
  I have the same opinion after reading over the product page and glancing at the documentation. At my org, we currently use a very similar method of deployment that AWS CodeDeploy seems to provide, except that we wrote it in house and use some python fabric scripts to do it. It sounds like AWS CodeDeploy would help us to "AWSify" this method of deployment and also have some nice benefits of health checks/rollbacks, UI based management, and a deployment history log. However, we would essentially still be maintaining/writing bash/python scripts to do the heavy lifting. However, we are in the process of moving to a method of deployment which uses SaltStack to prebake an AMI with everything that is required to run in production and then use Netflix's Asgard to manage the deployment of the prebuilt AMIs. We are very excited about this method of managing deployments to take advantage of AutoScaling groups and using a well defined/tested stack of tools. Interested to hear thoughts from others using a deployment approach that they think would benefit from AWS CodeDeploy.
djhworld 12y ago
Is this going to integrate with Docker? Would make a great orchestration platform
- jhappoldt 12y ago
  This is my question as well. It looks pretty low level so you should be able to leverage docker but I'm not seeing any specific tooling for it.
- seany 12y ago
  Isn't that kind of thing covered with docker on beanstalk essentially?
- grosskur 12y ago
  That was my initial thought, too. But it looks like the Docker-related news they hinted at is still coming: https://twitter.com/jeffbarr/status/529493907839533056 https://twitter.com/jeffbarr/status/529493907839533056
kabell 12y ago
BTW, we now integrate with this from CircleCI: https://news.ycombinator.com/item?id=8597439 https://news.ycombinator.com/item?id=8597439 There's some discussion in that post of how it compares to pre-baking, etc. Of course there are trade-offs either way. CodeDeploy does require that your are careful with your lifecycle scripts to make deployments as atomic as possible. At least they provide a good selection of default lifecycle events for you to take advantage of.
STRML 12y ago
While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. I can imagine how, for a new user, it's utterly baffling which of these options is the best for the longterm, with the least friction. I use OpsWorks quite a bit but have found it very challenging, and the feedback cycle when attempting to develop new cookbooks is excruciatingly slow. All I want, personally, is a system that uses a set of interchangeable scripts that represent dependencies, so my server configs can live in version control. It doesn't even need to run on multiple OSs (which seems to be a central tenet of Chef). It just needs to deploy/rollback with zero downtime, and ideally autoscale as quickly as possible. Is this it? Is there any way to know without spending weeks fleshing out how it works?
- sciurus 12y ago
  CloudFormation is really a different beast. It's focused on creating and managing related collections of AWS resources, not on application deployment. Anyone doing, well, pretty much anything on AWS should probably be using Cloudformation. http://aws.amazon.com/cloudformation/ http://aws.amazon.com/cloudformation/
- kxo 12y ago
  How about an Amazon-managed Docker (not shit ElasticBeanstalk) infrastructure/config management system? If they handled things like EBS integration, orchestration, ELB integration, and all of the usual stuff, I'd be sold in a second.
  - STRML 12y ago
    From my understanding, after talking to them at Web Summit, something like this is in the works. And they're aware of how incredibly complicated the AWS console is becoming. I don't know how or when they plan to address it, however.
    - mentat 12y ago
      They promise lots of things (like cross region VPC peering) to person to person at Summits...
danielhunt 12y ago
Region Unsupported CodeDeploy is not available in EU (Ireland). Please select another region. Supported Regions US East (N. Virginia) US West (Oregon)
demircancelebi 12y ago
I am having a hard time to understand how CodeDeploy will change my current deployment workflow (which consists of git aws.push basically). Can someone here enlighten me?
deverton 12y ago
This looks a lot like Marathon [1] though without some of the resource abstractions that Mesos [2] provides underneath. 1. https://mesosphere.github.io/marathon/ https://mesosphere.github.io/marathon/ 2. https://mesos.apache.org/ https://mesos.apache.org/
caiob 12y ago
As a beginner I have a hard time understanding all these services that Amazon provides. I know I should probably be using them, but I don't know which one.
- Stoo 12y ago
  What is it you're trying to do? It might be worth taking a look at the storage provided by S3 and how you'd go about hosting a static website (if that's something you might need). Or set up a free micro EC2 instance. That will give you a linux box which you can play around with.
jihip 12y ago
I really think Heroku nailed the deployment model. I just push my code, and then the code is deployed. It would be nice to have staging baked in.

211 points by helper 12y ago

bmajz 12y ago

Interesting. Between Elastic Beanstalk, OpsWorks, and now CodeDeploy it seems like AWS is taking over every production developer workflow from the hobbyist on up.

general_failure 12y ago
I find none of them good enough for my workflow. I think heroku nailed it with their deployment approach for my case. Beanstalk worker tiers are a nightmare. You need to place all your workers in separate repos, for example for git aws.push style workflow to work.
- bmajz 12y ago
  Good point. Plus Heroku just gives you so many more options instead of the 3-4 that ElasticBeanstalk provides, although Docker integration potentially changes the calculus significantly. Interesting that its taking EB so long to catch up to Heroku on that front.
- nixarn 12y ago
  Yeah I was also hoping this would be more something along the lines of the Google App Engine. I like just writing the application's code not having to worry about the stack too much.

bkeroack 12y ago

Here's an open source tool that does something very similar (and you aren't vendor-locked into AWS): https://bitbucket.org/scorebig/elita https://bitbucket.org/scorebig/elita

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 ago
If 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 ago
  I 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.

marbemac 12y ago

How does this compare to Deis? Does it serve the same use case, albeit locked into AWS? Discussion on Deis from yesterday: https://news.ycombinator.com/item?id=8591209 https://news.ycombinator.com/item?id=8591209

ryanfitz 12y ago

I've only briefly read over the documentation, but this service seems to not follow deployment best practices that aws and others such as netflix have been talking about for years. Specifically the pattern of pre-baking an ami with your current version of the app you are deploying and any other needed software completely installed on the ami and then having an autoscale group be able to boot that ami up in a few seconds and start working. This greatly helps with scaling up, doing rolling upgrades and also very easy rollbacks. 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.

Zariel 12y ago
Looks like an improved version of OpsWorks
- ninjaplease 12y ago
  ...improved?
conorgil145 12y ago
I have the same opinion after reading over the product page and glancing at the documentation. At my org, we currently use a very similar method of deployment that AWS CodeDeploy seems to provide, except that we wrote it in house and use some python fabric scripts to do it. It sounds like AWS CodeDeploy would help us to "AWSify" this method of deployment and also have some nice benefits of health checks/rollbacks, UI based management, and a deployment history log. However, we would essentially still be maintaining/writing bash/python scripts to do the heavy lifting. However, we are in the process of moving to a method of deployment which uses SaltStack to prebake an AMI with everything that is required to run in production and then use Netflix's Asgard to manage the deployment of the prebuilt AMIs. We are very excited about this method of managing deployments to take advantage of AutoScaling groups and using a well defined/tested stack of tools. Interested to hear thoughts from others using a deployment approach that they think would benefit from AWS CodeDeploy.

djhworld 12y ago

Is this going to integrate with Docker? Would make a great orchestration platform

jhappoldt 12y ago
This is my question as well. It looks pretty low level so you should be able to leverage docker but I'm not seeing any specific tooling for it.
seany 12y ago
Isn't that kind of thing covered with docker on beanstalk essentially?
grosskur 12y ago
That was my initial thought, too. But it looks like the Docker-related news they hinted at is still coming: https://twitter.com/jeffbarr/status/529493907839533056 https://twitter.com/jeffbarr/status/529493907839533056

kabell 12y ago

BTW, we now integrate with this from CircleCI: https://news.ycombinator.com/item?id=8597439 https://news.ycombinator.com/item?id=8597439 There's some discussion in that post of how it compares to pre-baking, etc. Of course there are trade-offs either way. CodeDeploy does require that your are careful with your lifecycle scripts to make deployments as atomic as possible. At least they provide a good selection of default lifecycle events for you to take advantage of.

STRML 12y ago

While this looks nice, part of me can't help but be annoyed by yet another deployment option on AWS. We now have CloudFormation, Elastic Beanstalk (which can take many forms, including Docker), CodeDeploy, and Opsworks. I can imagine how, for a new user, it's utterly baffling which of these options is the best for the longterm, with the least friction. I use OpsWorks quite a bit but have found it very challenging, and the feedback cycle when attempting to develop new cookbooks is excruciatingly slow. All I want, personally, is a system that uses a set of interchangeable scripts that represent dependencies, so my server configs can live in version control. It doesn't even need to run on multiple OSs (which seems to be a central tenet of Chef). It just needs to deploy/rollback with zero downtime, and ideally autoscale as quickly as possible. Is this it? Is there any way to know without spending weeks fleshing out how it works?

sciurus 12y ago
CloudFormation is really a different beast. It's focused on creating and managing related collections of AWS resources, not on application deployment. Anyone doing, well, pretty much anything on AWS should probably be using Cloudformation. http://aws.amazon.com/cloudformation/ http://aws.amazon.com/cloudformation/
kxo 12y ago
How about an Amazon-managed Docker (not shit ElasticBeanstalk) infrastructure/config management system? If they handled things like EBS integration, orchestration, ELB integration, and all of the usual stuff, I'd be sold in a second.
- STRML 12y ago
  From my understanding, after talking to them at Web Summit, something like this is in the works. And they're aware of how incredibly complicated the AWS console is becoming. I don't know how or when they plan to address it, however.
  - mentat 12y ago
    They promise lots of things (like cross region VPC peering) to person to person at Summits...

danielhunt 12y ago

Region Unsupported CodeDeploy is not available in EU (Ireland). Please select another region. Supported Regions US East (N. Virginia) US West (Oregon)

demircancelebi 12y ago

I am having a hard time to understand how CodeDeploy will change my current deployment workflow (which consists of git aws.push basically). Can someone here enlighten me?

deverton 12y ago

This looks a lot like Marathon [1] though without some of the resource abstractions that Mesos [2] provides underneath. 1. https://mesosphere.github.io/marathon/ https://mesosphere.github.io/marathon/ 2. https://mesos.apache.org/ https://mesos.apache.org/

caiob 12y ago

As a beginner I have a hard time understanding all these services that Amazon provides. I know I should probably be using them, but I don't know which one.

Stoo 12y ago
What is it you're trying to do? It might be worth taking a look at the storage provided by S3 and how you'd go about hosting a static website (if that's something you might need). Or set up a free micro EC2 instance. That will give you a linux box which you can play around with.

jihip 12y ago

I really think Heroku nailed the deployment model. I just push my code, and then the code is deployed. It would be nice to have staging baked in.