What does DevOps actually mean from our point of view?
TL;DR: “Working together without being huge assholes to each other” or, nicer put, breaking away from silo thinking for individual departments, better communication between teams and an iterative approach.
If you want to know the story behind this quote, or if you want to trace the history of DevOps in detail, you can read more here.
Click here to go to the next question!
DevOps is neither a job title nor a toolset! To understand what it is instead, it’s worth taking a quick look at the past: originally, it actually “only” meant the idea of better collaboration between dev and ops teams.
Patrick Debois, Andrew Shafer and other “pioneers of the DevOps movement” began using agile methods from software development to optimize other areas of IT in 2007, based on the question of how one could actually make IT infrastructure more agile.
“Working together without being huge assholes to each other” was the premise John Allspaw and Paul Hammond used to present their idea of good collaboration between development and operations at flickr at the Velocity conference in 2009. Patrick Debois finally took this as an opportunity to organize the first official “DevOpsDays” – and the rest is history.
Today, however, DevOps is much more than that. You don’t need a development department to practice DevOps – a philosophy has emerged from the original ideas, which generally stands for breaking down silo thinking, better communication between teams and ultimately an iterative approach.
What are the sub-aspects of DevOps and which of them might already exist in your company?
The whole thing is a 3 step process:
1. Efficient and standardized automation
2. Efficiently incorporate feedback into 1st stage
3. Establish and promote learning, error and communication culture
We explain this in detail below. Click here to go to the next question!
Pretty sure you’re familiar with the lying DevOps 8 – which is meant to clarify that DevOps stands for an ongoing process. In our opinion, the individual aspects can be understood even better if you look at the system of the “Three Ways” [the whole thing was developed by Gene Kim, Jez Humble, Patrick Debois and John Willis].
The first way
The first path describes the performance of the value creation process.
Sounds sophisticated – but in the end it only means how good the pipeline is, for example, with which new code is rolled out, or with which in-house infrastructure is automated.
Important factors here are fixed standards and efficient automation processes.
The second way
An important difference from the classic waterfall model is the incorporation and reinforcement of feedback loops in the first path. Using ourselves as an example, this means periodic “orcharhino meetings” of consultants, support, QA department and engineering team. In this way, test and direct customer feedback very quickly lands directly with the people responsible for implementation. Bugs können wir damit schon vor dem Release beheben (natürlich immer 😉) und neue Featurerequests unkompliziert einarbeiten.
The third way
In order to finally arrive at the third path and ultimately the complete DevOps principle, the element of DevOps culture is still missing. The most important aspects here certainly include good communication, a good error culture, a functioning learning culture and, of course, a good team structure.
Among other things, regular cross-team workshops are part of our learning culture, which at the same time strengthen the team structure.
For example, a team of consultants, internal IT, and the development department built a kind of self-service portal for servers and applications at a cloud provider. This portal is used not only for our orcharhino tests, but also for the deployment of our training labs or new customer PoCs.
Does DevOps make sense even without a Dev department?
A definite win! From the original ideas, a philosophy has emerged that generally stands for breaking down silo thinking, better communication between teams, and ultimately an iterative approach.
And ATIX has mastered DevOps?
That’s right – we live DevOps in-house every day. From many customer projects we have additional experience values for do’s and don’ts.
What can ATIX do for your existing or planned DevOps culture?
We help them with the introduction of a complete DevOps strategy, but also with partial aspects. We not only develop strategies that fit your requirements, but also help you with the (project) technical implementation.
For a first non-binding and above all free step, you can book a DevOps consultation via our contact form below.
How can you get a free DevOps consultation with our experts?
You enter your contact details in the form below – we’ll take care of the rest.
We will contact you and arrange an appointment with one or more of our consultants.
Feel free to contact us for a free DevOps consultation without obligation. We will contact you and together we will discuss
all of your specific DevOps questions for 1 hour. If we can satisfy you we will be glad to
arrange a long-term cooperation.