Understanding Feedback Loops in DevOps
Icon made by Freepik from www.flaticon.com is licensed by CC 3.0 BY Today I want to talk about what is probably the most misunderstood concept in DevOps terminology : the feedback loops. As defined originally in “The Phoenix Project” and further detailed in “The DevOps Handbook” – amplifying feedback loops is “the second way of DevOps”. Gene Kim explains in this post that “The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.” Process improvement is exactly what I’ve been doing for the last decade of my career. And what I’ve noticed is that whenever I start talking to teams about feedback loops I get 4 types of misunderstanding: Alert and notification systems are mistaken for feedback loops The importance of feedback loops is completely…
Speed or Quality? What is more important? Lessons from Japan.
We Don’t Do DevOps. In most of my encounters with new customers I take the time to explain that I don’t “do DevOps”. Yes, DevOps a convenient name tag. It provides an easy to present packaging that has been feeding me and my colleagues well for the last 5+ years. On the other hand – it definitely looks like the original meaning of the word (as originally coined by Patrick Debois) is continuously eroding. More and more folks in the industry are using it to refer to modern practices of system administration. Those that involve cloud, automation and – in the best case – also continuous delivery. That’s why I almost never relate to what I’m doing as ‘DevOps’. I rather use the term “Software Delivery Optimization”. We’re optimizing the time it takes to deliver software and the quality of the resulting product. By applying systemic analysis. By measuring and…
DevOps Transformation Plan
A few customers have been asking us for a simple, visual, down-to-earth plan for their DevOps Transformation process. We’ve created this infographic. Feel free to share and comment!
The System Of Continuous Migration
Introduction We live in a world where a commercial organization has to be in a state of constant flux. That is – if it wants to survive and prosper. This statement is even more accurate for IT companies. (And – as the popular saying goes – every company is an IT company today) One could of course argue that I’m suffering from a consultant worldview bias. After all – consultants are mostly brought in to help with organizational and technological changes. In the last couple of years we at Otomato have been involved in dozens of projects that all had ‘migration’ or ‘transformation’ in their title. So yes, definitely – change is all we see. But I’ve spent more than 15 years in IT companies small and large prior to becoming a consultant – and it’s always been like this. With ever accelerating speed. We’ve been changing languages, frameworks, architectural…
Dynamically spinning up Jenkins slaves on Docker clusters
Introduction: Being able to dynamically spin up slave containers is great. But if we want to support significant build volumes we need more than a few Docker hosts. Defining a separate Docker cloud instance for each new host is definitely not something we want to do – especially as we’d need to redefine the slave templates for each new host. A much nicer solution is combining our Docker hosts into a cluster managed by a so-called container orchestrator (or scheduler) and then define that whole cluster as one cloud instance in Jenkins.This way we can easily expand the cluster by adding new nodes into it without needing to update anything in Jenkins configuration. There are 4 leading container orchestration platforms today and they are: Kubernetes (open-sourced and maintained by Google) Docker Swarm (from Docker Inc. – the company behind Docker) Marathon (a part of the Mesos project) Nomad (from Hashicorp)…
DevOps is a Myth
(Practitioner’s Reflections on The DevOps Handbook) The Holy Wars of DevOps Yet another argument explodes online around the ‘true nature of DevOps’, around ‘what DevOps really means’ or around ‘what DevOps is not’. At each conference I attend we talk about DevOps culture, DevOps mindset and DevOps ways. All confirming one single truth – DevOps is a myth. Now don’t get me wrong – in no way is this a negation of its validity or importance. As Y.N.Harrari shows so eloquently in his book ‘Sapiens’ – myths were the forming power in the development of humankind. It is in fact our ability to collectively believe in these non-objective, imagined realities that allows us to collaborate at large scale, to coordinate our actions, to build pyramids, temples, cities and roads. There’s a Handbook! I am writing this while finishing the exceptionally well written “DevOps Handbook”. If you really want to know…
Thank you Intel Sports!
Mission completed! We’ve done a full month of getting the #Intel Sports developers up to speed with git. It’s always fun to train bright folks – and the engineers at Intel are certainly among the brighthest we ‘ve had the privilege to preach git to. While providing the training we’ve also developed a few ideas regarding git subtree and the plan is to share these ideas in a follow-up post to this one (which compares submodules to repo) Have a great weekend!
DevOps Flow Metrics – http://devopsflowmetrics.org
DevOps transformation goals can be defined as: Heightened Release Agility Improved Software Quality Or simply: Delivering Better Software Faster Therefore measurable DevOps success criteria would be: Being able to release versions faster and more often. Having less defects and failures. Measurement is one of the cornerstones of DevOps. But how do we measure flow? In order to track the flow (the amount of change getting pushed through our pipeline in a given unit of time) we’ve developed the 12 DevOps Flow Metrics. They are based on our industry experience and ideas from other DevOps practitioners and are a result of 10 years of implementing DevOps and CI/CD in large organisations. The metrics were initially publicly presented by Anton Weiss at a DevOpsDays TLV 2016 ignite talk. The talk got a lot of people interested and that’s why we decided to share the metrics with the community. We’ve created a github pages based…
Continuous Delivery as a Necessity – Anton Weiss interviewed for JAXenter.com
“The codebase is a minefield —there will be casualties” – JAXenter https://jaxenter.com/continuous-delivery-interview-anton-weiss-128491.html
Jenkins and the Future of Software Delivery
Are you optimistic when you look into the future and try to see what it brings? Do you believe in robot apocalypse or the utopia of singularity? Do you think the world will change to the better or to the worse? Or are you just too busy fixing bugs in production and making sure all your systems are running smoothly? Ant Weiss of Otomato describing the bright future of software delivery at Jenkins User Conference Israel 2016.