In the beginning was the session of John Allspaw and Paul Hammond during the 2009 Velocity Conference, showing how cooperation between Dev and Ops at Flickr allows 10 deployments a day (Header image of this post is extract from this presentation, and it shows how Leonard Nimoy was important for us even if I started this post on February 6th and forget about it after…).Following that, there was the first DevOpsDays conference in Gent at the end of 2009.
Behind the promise of reconciliation between evolution and stability objectives, reconciliation between devs and ops, some saw technological solutions enabling to shorten the lead time of go lives, and even to go live without human intervention.
Others saw the opportunity to realize the promise of the last 20 years of the agile movement (yes I start to count at the beginning of the discussions about the lightweight project management method and the emergence of XP… already 20 years…).
Others questioned the skills that sys admin will need to acquire to be able to consider infrastructure as code.
Others imagined that the devs will need to change and acquire a good understanding of the behavior of their code in production, that they must integrate exploitation constraints into their code, like the ability for their apps to react to failure, to scale in or scale out, the ability to update or upgrade without services interruption…
Others thought that the change should be from the entire system, that we need to reconsider the way we envision software evolution, and information system evolution, looking at it feature by feature – using not only the idea of Minimal Viable Product (MVP) at the beginning of a project but the idea of Minimal Marketable Feature (MMF) during all the lifecycle of our information systems.
Others thought that cloud technologies was an enabler to our way to envision information systems, and obviously others are working on those technologies to enable those transformations.
Others argued that if they want to recruit new people in their team they need to transform their organization because new generations will not accept the constraints of silos that prevent collaboration.
All those point of views demonstrate the complexity of the devops subject and the impact on different domains in the organization: tools, method, organisation and culture.
It was really interesting to observe the diversity of all those views during the Devops CIO’s breakfast organized by Red Hat in Paris on February 6th, my role was to shed some light on the subject and to facilitate the discussion between participants.
Now that eNovance is part of Red Hat, the challenge to transform organization’s culture (internally and externally) continue with the Red Hat Cloud Innovation Practice and the size effect and open source culture allows exiting discussions with my peers.
est un livre de 
