[ed: TL;DR Is your service more difficult to deploy to production with all best practices, real security, redundancies and backup - than it is to build? Then yo

[ed: TL;DR Is your service more difficult to deploy to production with all best practices, real security, redundancies and backup - than it is to build? Then you're not doing devops.] I don't think there's great consensus on what devops means. According to Wikipedia[w] the original definition was: "DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality." Which is a bit of a non-definition if you ask me. You can have that with traditional good system administration. I see it as two things: the change from how a service or product is viewed, to a more holistic, system oriented view: the acceptance that "the system" consists of the interaction of code, configuration, infrastructure and users (along with changing/evolving requirements, because: humans). And that one entity needs to own the entire process; the devops team. That team might change a bit in composition; but it means that rather than write some "application" and ship it to the customer on a floppy disk - most useful software is a process more than it is a product. The other part (which is connected) is that as software delivery is a continuous process, it becomes natural to incorporate/inform "development" from the ops side (12-factor apps, plan for dev/stage/prod deploys, make a program/service that is easy to monitor, test, run and manage -- not "hexedit configuration in this zip of executable and config data and run it with magic_jar_executable, make sure to restart it after it's written 48mb to disk"). And vice-versa: be more explicit in treating administration as a traditional software project; version control, tests, immutable deployment states with snapshot / rollback support. There's another group that seem to think "write software and throw it over the wall to the admins" is a perfectly sound model; all you need is better admins. And to be clear: bad admins is a bad idea we/they will break your fool-proof single fat jar/single fat c++/go executable with resources baked in. And good sys admins can work.magic with your broken software. But it's not devops when the two groups are on different teams, doing different things - throwing rocks, insults and build artifacts over the wall at each other. That still just "dev" and "ops" -- apart. [w] https://en.m.wikipedia.org/wiki/DevOps https://en.m.wikipedia.org/wiki/DevOps