Comment by joshpadnick | Hacker News Reader

Comment by joshpadnick | Hacker News Reader

I was always weary of Heroku because it's exactly what @hunvreus said: a black-box. Very appealing when you're strapped for resources in the beginning, but increasingly frustrating as you scale. Case in point: http://rapgenius.com/James-somers-herokus-ugly-secret-annota...

That being said, it seems like the model itself is not flawed, just the execution. I've met many developers, especially in the Node community, who fundamentally believe they as software engineers should not have to spend any time learning devops.

My position is that a good software engineer today should be familiar with the full stack from frontend (SPA, javascript, html, css) to backend (sql, basic db admin, db design) and devops. Obviously, you can't become an expert in everything, but the knowledge level required to become "proficient" in these areas seems pretty achievable if you're well-versed in software engineering fundamentals.

FWIW, it took me about 4 weeks to get a "startup-ready" fully open source 3-tier stack running in EC2 with full automation using Chef (which is a whole other topic) plus continuous deployment using Jenkins. Ultimately, we'll pay more for EC2 per month upfront, and I had to absorb the upfront time hit, but now that we're setup, it's extremely easy to tweak things, and we have complete transparency.

+1

I'd like quote Adrian Cockcroft: "the undifferentiated heave lifting". However, the heavy lifting is the daily operation work, not the knowledge to scale your app, HA/DR, CD/CI, etc.

Compared with the black-box model of Heroku, I vote for infra-as-code+desired state, e.g. you order, we cook.

Disclosure: I am the founder of visualops.io, a white-box devops automation service for AWS.

you mind sharing your chef recipes? did you use chef to automate jenkins too? there are too few good chef examples on the web....

@pswenson, I used Chef to automate setting up the server with Jenkins. This included automated security updates, awscli tools, nodejs, and even hubot so that we can trigger builds from HipChat (we still need to write a custom hubot listener to handle that, though).

I also took advantage of AWS IAM roles so that the server is pre-authenticated for certain S3 buckets.

PM me at josh dot padnick at gmail /period/ com with some background on what you're trying to do and I'll see what I can share. For many reasons, I can't make our Chef code repo public, but maybe I can share some code samples.

Edit: Regarding Chef, for more info you might check out http://www.slideshare.net/JoshPadnick/introduction-to-chef-a....

As far as online examples, yeah, the learning curve does kind of suck. Also, if you're starting from scratch, SaltStack may very well be a superior technology (don't know enough about it). I think the key with Chef is to learn how to read the docs, using the application-cookbook pattern (where you never touch the cookbooks you download online and instead customize them by "wrapping" them with your own custom-defined cookbooks.

It's also helpful to use very thinly designed roles, and define special cookbooks as your actual roles. This way you can version-control them.

I basically learned by reading the same material in multiple places, especially in books on Safari Books Online, and IRC was also a huge help b/c the community was VERY helpful.

I think Chef is a classic case of where the technology is somewhat inelegant and perhaps bloated, but a mature community is there and it's battle-tested so once you suffer the pain of ramp-up you get a huge benefit.

HTH

Reply on news.ycombinator.com