Our Chef-based stack(s) are open source and hosted on github. We are thinking of packaging them in a form that is convenient to run in a local Vagrant box or something of that sort, so that you can easily test your app without wrecking your production environment first.
Regarding cuisine vs. Chef Solo... I think it mostly depends on what your scripts do. In my opinion, Fabric/Cuisine make it absurdly easy to execute commands against a remote server and most of the time that's enough for a decent deployment. Chef's execution API is, to put it mildly, clumsy. I cringe every time I have to type something like:
execute "#{virtualenv_dir}/bin/pip install -r #{requirements_file}" do
user deploy_user
group deploy_user
end
IMO Chef shines when you have to move a lot of config files and generate node- and role-specific configs. I feel it's a lot simpler to just have recipe-specific files and templates packaged with the recipe and move them over with commands like cookbook_file and template.
Right now we are using both the technologies. Our stacks are Chef-based since we want people to be comfortable with reading (and possibly modifying) its code. We also reuse a lot of the Opscode recipes which simply do not exist for Fabric/Cuisine. Fabric and Cuisine have their place when we bootstrap a server and prepare the Chef environment and at several odd places where they keep things running together.
I'm all for server tweaking and I do it all the time, but sometimes it gets boring. I could probably do something better than configure php5-fpm for the thousandth time.
Right now, Stackful.io takes the pain from that when it comes to Node.js development. You just pick a server size and hit a button. 2 minutes later your machine is ready to rock and you can deploy your app with a simple Git push.
We are planning on doing the same for the other major web technologies. We have some pretty good progress with a Python stack and a PHP one is in our queue.
Thousands times this. I've seen situations like that in all sorts of businesses and software projects aren't unique in their inability to deal with complexities and bad communication.
On the other hand, learning to manage software projects gets you an almost unfair advantage at managing "simpler" and more mundane projects where everyone and his mother underestimates the complexities and all the ways things can go wrong.
> learning to manage software projects gets you an almost unfair advantage at managing "simpler" and more mundane projects
I'd add that learning to write software also gives you an unfair advantage in managing the "complexities" of all other processes you'll encounter in day-to-day life, to the degree that it's (at least for me) incredibly frustrating going through life seeing inefficiencies and "incompetence" (not meant as an insult) everywhere around you.
Sound advice. I didn't mean to go to the SQL vs. NoSQL war zone and I have nothing against SQL DB's. All I wanted to say is that I find the current Redis solution easier to implement than the [clumsy] one I did in the past.
Yeah no worries! I didn't imply you meant that :) Like I said I use redis timeseries exactly like you.
The pros are that it's very easy to setup etc (no schema definition, very practical API, easy to query), the cons are that you are limited by the memory space (but like you wrote, not an issue in your cases) and that it's harder to make more elaborated reports.
Yes, thanks to the websocket support that landed in recent Nginx releases.