This is a good start but where Chef ends up sucking a bit is when you want to deploy a bunch of different apps in a SOA type of arrangement and don't want to duplicate code. I.e to deploy another ruby app you have to basically copy and paste this cookbook or you can try to switch to the 'application' cookbook which is chock full of magic and wonder and doesn't really look like any other chef code.
Chef really needs some dependency injection type stuff like what juju has going on. So something can provide a 'load balancer' and your app can optionally use a 'load balancer' but your app doesn't need to hardcode that it's using nginx, or ha proxy, or elb, or whatever in it's cookbook.
If you have a very similar apps, write a "library" cookbook that does the work that's common to deploying those apps. Any values that differ across the apps should be set by attributes. Next write "wrapper" cookbooks for each app that set those attributes and include the "library" cookbook.
Chef really needs some dependency injection type stuff like what juju has going on. So something can provide a 'load balancer' and your app can optionally use a 'load balancer' but your app doesn't need to hardcode that it's using nginx, or ha proxy, or elb, or whatever in it's cookbook.