The facebook system actually sounds really solid, especially the "boot camp" thing that so many companies fail to have, however it's probably pretty expensive.

The facebook system actually sounds really solid, especially the "boot camp" thing that so many companies fail to have, however it's probably pretty expensive. Choosing between fast, cheap, and good, Facebook is choosing fast and good. For many, cheap and good but slow is more desirable. One of the risks to consider with a "devops" oriented approach is that you may become more dependent on it than you want. Often, applications split things into a few different categories depending on how tweakable they need to be. There's code, configuration, app administration, and data. Code shouldn't need to change often. Configuration may need to change when the environment changes. App administration (eg creating new accounts) needs to change often, and data is always changing (or at least growing). The risk is that developers will design the system so that only developers can administer it. Configuration, the settings that may need to be tweaked by sys admins long after the original developers have left the project, may wind up in the code or sometimes lumped into the database alongside end-user options. It's not a reason not to take this approach, just something to consider when developing internal processes and culture.