Thanks BTW for understanding - that's my intention here, which is to call out bad companies for doing egregious sorts of things (along with me being pretty frustrated in general, which could've been in poor form but whatever)
Forgot to mention: I don't expect anything positive to come out of it. I just want it to be a fair warning to anyone who would think about interviewing with them.
There was never an interview where you meet with Canonical execs. There was an interview panel where I met with higher ups and whatnot, but not at the executive level. That was a completely, 100% hidden step in the process depending on where they think you lay in the hierarchy (probably decided after the interview - the job I was interviewing for wasn't originally written for a senior level hire.)
I don't blame them for not having a paycheck, I blame them for handling this incredibly terribly. If I had known there was even an exec-level review of my application, I would've acted otherwise. I don't burn bridges often, but given the amount of bullshit that exists in the tech industry, I'm okay with calling it out and risk burning bridges than to keep mum and allow shitty practices to continue.
Everything was assured - I turned down other offers either due to some bad timing or seemingly worse fit, related to waiting for this particular position to get back to me. Of course, no one should ever turn down other jobs unless you have an official offer letter in hand, but even then, an employer can rescind the offer even if you sign the paperwork.
* No web UI. This may be a blocker for business folks who want to update a blog. This is a blocker for folks who are using devices like iPad's to update blogs (which is a huge reason why I moved away from things like Octopress and moved toward things like Ghost or Wordpress.) This may be a blocker for folks who don't always have the tools on whatever machine they're using at the time in order to generate the site.
* No imposed structure. It's easier to impose a web UI form that locks folks into certain workflows than it is to just give them a git repository with all sorts of stuff strung about, with no apparent structure other than the FS structure.
IMO, Amazon gets 'DevOps' right. It's mostly just called 'ownership' over in Amazon. (source: I used to work in Amazon as a systems engineer)
You still have specializations - SDE's, systems engineers, DBA's, etc. However, if you write code and it ends up in production, you are responsible for the proper function of that code in production. As a friend of mine put it in terms of developers who don't want to be on-call: 'what, you don't trust the quality of your code?'
DevOps is simply a nicer way of just saying, "own your damn code." The corollary to this is that the organization must help you in getting to that state where you can effectively own your code - this means collaboration (so that you build maintainable systems) and building tools that enable fairly frictionless code ownership.
Security is about mitigating risk, not about eliminating it.
Keep up with CVE's, don't provide a wide attack area (so lock down interfaces to your machine and don't expose much to the world), and keep blast radii as small as possible (so even if your machine does get owned, you can possibly restrict it so it doesn't automatically mean they gain access to other systems in your network.)
Oh, and model the threats to your network/application. Make sure you're securing against the right threat. As an example, anti-malware is wholly ineffective against social engineering - maybe it's more productive to train employees and make sure that each employee doesn't have total access to all privileged systems.
FWIW, if you do need ELB support right away (and keep in mind that you'll have to look at it from each server's point of view), you can probably use https://github.com/opscode-cookbooks/aws (and use the elastic_lb resource), and hook it into your own cookbook for setting up whatever ELB's you want (then set up your custom cookbook repo for your stack.)
(I'm trying to say that this platform is incredibly flexible, and you can reuse what's already out there. If you need support for X, Y, or Z, then you can likely write in support with Chef.)
Sort of, but not exactly. It's not API compatible with Chef server, and I believe you don't get the nice search syntax for grabbing node information across your fleet that match some kind of criteria. But you still do get info on your other machines, and you do get nice orchestration across your fleet.
You can use TCP/UDP/GRE for your traceroute packets with the -P switch:
traceroute -P udp <hostname>
This is super useful if you're probing a network that's hostile to ICMP packets - it's a lot more reliable than ICMP in many scenarios, from my experience.
The reasons that other folks have mentioned (static files, nginx is built for lots of HTTP requests), as well as basic load balancing between several 'worker processes'. Sometimes you'll want to have several app server processes running with several ports open, and have nginx load balance between all of those processes (then load balance again at a higher tier between all of the different nginx processes.)
Kick off Puppet/Chef runs? It's not too hard to automate these tasks, either (or even put a fancy interface around it, though of course this takes a bit more time.)
It's also a bit insulting when you say that we 'in fact [do it] by hand', because sysadmins, as a whole, strive to not do that. Fine, I can see myself logging into a box and typing 'chef-client' or 'puppet' by hand - but this is too much work to be done by hand. That's why we automate. I don't know why you have this idea that we simply want to make things harder just for job security.
I'm a fan of both of those systems, because it's easier to express system state with them (and clearer, too), versus using shell scripts or what have you. I'm definitely not advocating using it as a way to deploy software, but it's definitely possible to do so (I'd likely build system packages, throw them in an internal repo, and use yum/apt to ensure software packages are up to date, or at a certain version.)
It's not the only solution, though. I've worked at shops where there have been exceptional software deployment pipelines that are absolutely not tied to a configuration management system. I'm also not a fan of using Chef or Puppet for doing a git/svn repository checkout of software.
Again, I want to reiterate my point: it's still not about the tools, but about identifying the problem you need to solve and discussing possible solutions to the problem. There's no right answer.
NT? (edit: you mean non-technical? I'm definitely not non-technical - I work as a systems engineer by trade.)
And, yes, you don't need to use Chef or Puppet to solve the software deployment problem. You use it to ensure system state, so you know you can throw software on top of it without any problems. (this can go on into a debate about golden images vs. configuration management, but I think this is a different discussion.)
That's probably true as well, though... I've been in shops without Chef or Puppet, and it's really not a big deal for me, either. The thing that stood out was the justification for not choosing Chef or Puppet, not really the fact that they weren't using it.
Author here. They do, though for a certain set of problems, you can get away with using things like Chef for coordinating lots of information between a lot of machines.
My point, however, was that tools should never be the focal point of solving a problem - if you recognize the problem first as a distributed locking problem, or as a configuration problem, then you can start deriving a solution (and maybe that solution might have Zookeeper in it, maybe you'll write a new piece of software, maybe you'll use Chef, etc.)
You can use LDAP logins and passwords with SSH by using pam_ldap - but since you only allow SSH keys, it'll be a non-starter for many orgs to use your product.
So, tell me - what would this tool offer over, say, RunDeck or mcollective? Why only use SSH keys? (What if I'm using LDAP across all of my machines?)
I'm not trying to knock your product - I really do hope you get Kickstarter funding! But I just wanted to say that, to me, as a systems engineer, I only see a pretty interface, but not much value add over the other two products mentioned above
I also feel that comparing Commando.io to Puppet, Chef, or even Capistrano is disingenuous - Puppet and Chef are configuration management systems that are meant to keep your systems 'in policy', and Capistrano is meant for repeated tasks over SSH (mainly for deploying software, but it can be used for other things too.)