Welcome to the last buzzword part of this series. Let's dive right in.
Dev❤Ops
DevOps is a mindset. The term itself is a combination of the words/departments Development and Operations. The basic idea of DevOps is to tear down the silos in which those two departments often live. Instead of the developers slaving away for months on a new product and when finished tossing it over the silo wall to the operations team, with little more than a note saying "Please install and run - thx.", developers and the guys from operations should work together from the start. This way operations knows what's coming and can even actively shape what's coming.
From this point of view I sometimes think of DevOps as just an extension of the Scrum team with people from operations. But there's more to it, and this is where we make the connection to lean manufacturing and the Toyota Production System. Similar as to how scrum provides some more concrete guidelines on how to implement the agile manifesto, DevOps leads the way on how to tear down those walls, and it does this by taking inspiration from lean manufacturing / the Toyota Production System (TPS). In one sentence, I would say "DevOps is the application of the Toyota Production System to the cloud native world."
Sometimes I struggle a bit with the name DevOps, because from time to time it leads to people creating a new silo. "We need DevOps-guys!", rockstars who know everything about development and operations. Although both parties learn from each other, a developer is still a developer and an ops-guy is still an ops-guy. Both areas of knowledge are too large to know everything about both of them. Let's face it each on its own is too large for one person.
The Three Ways
of how we should implement this application.
The First Way: The Principles of Flow
This one is taken straight from the TPS-playbook: Work has to flow - we want a continuous flow of value to the customer. For this
- we want to make work visible, this is commonly done with a kanban board.
+---------------+---------------------------+---------------------------+-------------+
| Backlog | Dev | Ops | Deployed |
+---------------+---------+---------+-------+---------+---------+-------+-------------+
+ | ToDo | Doing | Done | ToDo | Doing | Done | |
+---------------+---------+---------+-------+---------+---------+-------+-------------+
| +---------+ | | | | | | | |
| | Feature | | | | | | | | |
| | 254 | | | | | | | | |
| +---------+ | | | | | | | |
| | | | | | | | |
. . . . . . . . .
. . . . . . . . .
The best way is to include the entire value stream from inception until the product is deployed. You can add QA, ... to the board.
- we want to reduce batch size, which leads to faster cycle-times and help us find errors faster. Again, nothing new to the TPS aficionado
- and as the TPS does, so does DevOps define types of waste we should eliminate. These are mostly the same with the odd one added to the mix:
- Partially done work, can become obsolete and can depreciate in value. The effects are similar to the ones of overproduction.
- Extra process, e.g. unnecessary documentation.
- Extra features, increase the complexity of the software/system and lead to additional work (testing, documentation)
- Task switching, especially in software development we need to get into a flow state to be productive. The negative effects of interruptions on productivity are well documented.
- Waiting, or as it is called in the TPS: time on hand
- Motion, TPS: movement
- Defects, the earlier we catch defects the cheaper they are to fix
- Non-standard or manual work, make dependencies on operations self-service and on demand
- Heroics
The Second Way: The Principles of Feedback
Cloud native apps are distributed systems and are therefore inherently complex. In complex systems, failure is inevitable. Therefore we aim to find errors early when they are easy and cheap to fix.
- Similar to the TPS' andon, DevOps wants us to react to errors by stopping the assembly line. It calls this swarming a problem. You can even go so far as to for example allow no pushes anymore until the problem is fixed. The idea behind this is that, new changes might introduce additional errors. A very important part is to learn from errors and create new knowledge.
- Telemetry and testing are our main sources of feedback. Telemetry can show us early if for example the load on the database servers has significantly increased since the last push, ...
- Stewart cycle: plan, do, check, act
- push quality to the source
- early feedback is tantamount to efficient bugfixing. Every developer prefers getting a bug report on something he's implemented yesterday, to getting yelled at for something he implemented months ago.
The Third Way: The Principles of Continuous Learning and Experimentation
Just receiving feedback is not enough, we need to act on it, learn from it. One of the most relevant influences on whether we can do this is company culture. This starts with "Don't shoot the messenger." and goes up until blame-less post mortems. If we feel safe, we are more likely to experiment, which leads to innovation.
Even more important than daily work is the improvement of daily work.
Conclusion
DevOps is a mindset and wants to bring developers and operations closer together. It makes heavy use of the ideas of the Toyota Production System.
We now have all the parts ready for the final comparison.
See you next time for the epic final battle of the buzzwords, which will win?
The Struggle
Still struggling with the amount of detail I should go into. There's so much more that could be written, e.g. how those types of wastes are dealt with, ... . But for the initial purpose of this series (the comparison of these buzzwords), this is not strictly necessary.
Take care and keep on struggling.
Top comments (0)