Video recording and production done by DevOpsDays.
richard haigh: Times series Data
Hervé Leclerc & Stéphane Goudeau: Cloud& devops: Imagine a new world ...
Andy Burgin: How to make a kickass devops meetupgroup for 20€
Nicolas Charles: Working together - a dance analogy
Oliver Jacques: Chatops
What if you're not the CTO and you want to improve your quality, performance and stability.
This is my story of working within low buy-in, legacy, siloed organizations to break down barriers, blur borders and eliminate constraints. I’ll also tie in material from ‘Driving Technical Change’ and ‘Building a DevOps Culture’
- tribes and guilds vs teams
- winning trust and building confidence
- simple risk and roi
- low impact tools
It's a wonder we can make decisions at all, as technology workers or otherwise. Unlike language and grammar, our intuitive grasp of probability and statistics is atrocious. We're also subject to all sorts of common cognitive biases and bad heuristics that lead to errors and missteps in decision making.
Why are we so easily fooled by retail pricing? Why do we overestimate the chance of memorable disasters and successes recurring? Why do many post-mortems fail at providing true understanding due to their reconstruction as a sequence of predictable events?
In this talk we’ll be covering the cognitive biases behind these questions and others, along with relevant examples from the life of a technology worker such as candidate interviewing, post-mortem analysis and service availability.
With bringing the business into devops the development and operations have to approach to the customer ́s point of view. Usability, customers ́ expectations and fears have to be combined with operational management objectives and the technical feasibility. An effective communication without “buts” and with minimised misunder- standings will be in high demand to make this philosophy successful. The more people are combined in a communication process – especially if the types of characters are as different as they are in bizdevops – the more difficult it becomes to keep the flow active and helpful. To face these demanding tasks you have to look back to the roots of communication skills and personal attitudes.
In this session you will see
- why the attitude of “I am okay – you are okay” (Thomas A. Harris; psychiatrist) is neccessary in interdisciplinary teams full of diversity
- how the knowledge about the communication square (Friedemann Schulz von Thun) will help to minimise misunderstandings
- why it is important to build an atmosphere of respect and tolerance
- why changing personal attitudes is the only way to work on stereotypical
- why diversity requires the willingness to consider different perspectives on a
In this session you will identify some examples of your own daily work and will get an idea how to work on these problems apart from technical skills and organisational demands.
In the DevOps community, we're mainly focused on what actions to implement to be "DevOps" compliant, how to implement them, and with which tools. We forget too often the WHY, why DevOps is vital for modern companies and why the actions we are trying to experiment with and implement are important.
This talk will present a reflexion about "Why DevOps is important" and "Why CLAMS is important" with examples from my experience.
At BlaBlaCar, we were blessed with a good basis for DevOps: Agile Teams with full stack developers, as well as an early focus on automation. We also have our specifics, such as a strange addiction to physical servers, leveraging the cloud only when elasticity is required.
This talk will cover the practices that have worked for us. Some were implemented early, enabling us to reach goodies such as 10 builds/day Continuous Delivery, and good relationship between our Dev and Ops communities. Some others had to upgraded as our team was growing, our services becoming more exposed, and our architecture becoming more complex.
DevOps is all about getting Devs and Ops guys to effectivly work together. With things like better monitoring, automation, config management etc. we can now speak the same language when it comes to technology. We have continuous integration and sometimes even continuos deployment, and could be rather satisfied that we develop and deliver software like never before.
And all is quite nice, as long as everything runs as expected.
But then disaster strikes. It is in the face of failure that our abilities to effectively communicate and deal with problems are put to the test.
All too often, things go downhill very fast, when someone screws up.
This talk will explore typical anti-patterns in dealing with failure and discuss the patterns that will help you stay on top of the problems and learn the most out of mistakes and failures. You will learn tools and techniques that help you avoid the blame game, keep communication between Devs and Ops and inside the teams flowing and help everyone to a common understanding of what happened why - and how to prevent this from happening again in the future.
You will also learn how to reduce the risk of things going wrong not by more testing (though testing is important) or more specs but by getting the right bunch of people talking in the right way.
This talk is for everyone who is not living in a perfect world, but in a world where mistakes happen.
Guillaume Lederrey: Automating Jenkins
Mauro Trione: Data on demand
Arneaud betremieux: Deploying
Sylvain Révéreault: How to reconcile ITIL and devops
Guilhem Lettron: Devops role: spock
Renaud Boutet: Hello, we are logmatic
SAP is an industry heavy weight: founded in 1972, 70.000+ employees in over 50 countries. We sell business critical enterprise applications to our customers, ERP system that process pay slips, corporate financial statements, critical stuff like that.
Over decades we sold on premise software to our customers. We released updates once or twice a year. Major product releases each x-years.
But since a few years the company set itself the goal to become a cloud company.
This implies dramatic changes to the organization and it’s processes and beliefs.
In 2012 a small internal cloud based ride-sharing service (TwoGo) was ordered to become an official SAP product.
As becoming an official SAP product doesn’t sound that hard when you’ve already the service running in-house:
Development done and ongoing, Operations up and running, quality hiccups cured…opening the service shouldn’t be that hard.
Unfortunately large companies like SAP don’t work like that. Large/traditional companies have gazillions of processes, regulations, standards which must be fulfilled and documented before you are allowed to release as an official product.
The aim of this talk is to tell the story how we as a small team managed to change the huge SAP.
As DevOps might be “natural” to start-up like companies, it’s a huge paradigm and cultural shift in companies like SAP which used to be successful with their way of doing things since decades.
We developed and pioneered new processes inside the company and with applying DevOps and Continuous Delivery as first SAP product ever we now (since Oct. 2014) delivery daily to our customers, making us the fasted delivering product of SAP.
Britain has a long history of manufacturing, and whilst the decline of the sector is well documented, applying the basic principles of traditional manufacturing to the “whitecollar” office environment is the new manufacturing. This talk will take you through the basic building patterns of manufacturing, looking at vendor selection/audits, the QA process, understanding of basic costings, discovering if the “products” are low volume, High mix, or low mix high volume and what the implications of design for manufacture would be in such an environment. Also, how to apply these basic patterns to the modern software driven “Office ” world. This is part one of a two part talk, the second one being “Preparing the Enterprise for Manufacturing”.
The dynamics that the devops culture bring to teams and organizations challenges the traditional process associated with software delivery.
In this talk we'll explore how to please the ITIL and ISO gods while maintaining an environment which enables fast release cycles and negligeable friction for engineering teams.
We will review the two main traditional constructs that are expected from IT service management frameworks: the change acceptance board and configuration management database and see how a lean process can be carried out to maintain a similar approach without introducing unfamiliar tools or methodology to engineers.
This presentation is loosely based on Jared Diamonds Pulitzer Prize winning nonfiction "Guns, Germs, and Steel: The Fates of Human Societies". The concept that certain gaps in power and technology between human societies originate in environmental differences, which are amplified by various positive feedback loops. In this presentation we will first level set on the core definitions of Containers and Microservices. We will also discuss another technology called Data Gravity and how the convergence of the three will create a positive feedback loop that will change how we do computing. Of course, Devops and culture will be a core theme to this presentation and an attempt will be made to conclude a consistent tie back to the aforementioned title of this presentation.