It has become a market buzzword, so when people refer to it nowadays they might mean anything. But I think originally DevOps had the simple premise of "you write it, you run it".
Previously, it was common in large organizations for one team to write system software (Dev) and an entirely different team to operate/support the software in production (Ops). This led to designs which were easy for Dev but hard for Ops or vice versa, depending on the organization. For instance, Dev might design a system with 3 different databases (following the Right Tool for the Job principle) without considering how much manpower it will take Ops to keep 3 databases running, patched, secured, etc.
DevOps aims to solve that problem by exposing Dev to operational concerns and Ops to Dev concerns. The idea being that since DevOps is responsible for both, they will design systems that are as easy as possible to maintain for both Dev and Ops concerns.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It has become a market buzzword, so when people refer to it nowadays they might mean anything. But I think originally DevOps had the simple premise of "you write it, you run it".
Previously, it was common in large organizations for one team to write system software (Dev) and an entirely different team to operate/support the software in production (Ops). This led to designs which were easy for Dev but hard for Ops or vice versa, depending on the organization. For instance, Dev might design a system with 3 different databases (following the Right Tool for the Job principle) without considering how much manpower it will take Ops to keep 3 databases running, patched, secured, etc.
DevOps aims to solve that problem by exposing Dev to operational concerns and Ops to Dev concerns. The idea being that since DevOps is responsible for both, they will design systems that are as easy as possible to maintain for both Dev and Ops concerns.