DevOpsDays Kiel

So, DevOpsDays again - but this time in Kiel.

Some notes from the first day:

• From 0 to DevOps - Coping with Continuous Delivery to the Cloud by Oliver Siebenmarck, IBM:
• In the old days it was "Dev versus Ops". Now the culture is changing towards a shared ownership of test automation, continuous integration, continuous delivery and continuous deployment.
• Lessons learned from a project he worked on:
• It's about communication.
• It's not about the tools.
• DevOps is not No-Ops.
• Automation is dangerous. My first reaction was that he is completely wrong with that, but he restricted his statement to continuous deployment. But still I think the statement on its own is wrong ... the tests gating the deployment should have been improved.
• Automation is your friend.
• Write good documentation. Hmmm ... at least partial disagreement from my side, as I think outdated documentation is even worse than no documentation - e.g. you should establish a good self-explanatory coding style instead.
• Keep on learning.
• ITIL and DevOps can be friends by Jan-Joost Bouwman, ING:
• Transformation of the IT department towards agile and shared responsibility among Dev and Ops.
• Make ITIL processes as lean as possible.
• In order to still be able to respond to incidents, approximately 30% of each sprint is reserved for operational tasks.
• Problem management tasks are managed as user stories within the product backlog.
• What agile/Scrum can learn from ITIL:
• Customer focus and reliability.
• Feedback loop (mostly concerning incident management).
• Uniform process.
• Discipline.
• What ITIL can learn from agile/Scrum:
• Need for speed.
• Customer focus by adding value.
• Limiting work in progress.
• Feedback loop (concerning what customers really want).
• Continuous Testing for DevOps: Evolving Beyond Automation by Wayne Ariola, Parasoft:
  A business-focused talk covering some numbers about impact of faulty software, the evolution of the software development lifecycle and the need for test automation and continuous testing.
• Learning to fall by Rafael Ördög, Emarsys:
  Immediately after lunch I'd have needed an exciting talk, but I got a high level talk on scaling issues and distributed transactions. It turned to become interesting, when the saga pattern as a way to guarantee distributed transactions was introduced: Split a long running transaction into several independent tasks and associate compensating actions for rollback to each of them. If the compensating actions are idempotent, they are repeatable, which is nice if you did not receive any acknowledgement.
• DevOps and sharing (slides) by Marta Paciorkowska, Acrolinx:
• DevOps is not only about technology.
• Obstacles when adopting DevOps at her company:
• Mindset. Rejecting changes.
• Overwhelming amount of tools.
• No one wants to do the boring tasks.
• Using outdated software/technologies and the lack of documentation for that.
• Lack of resources.
• No bigger picture.
• Other people.
• Possible fixes:
• Respect people's preferences and their strength. Leverage that when distributing work.
• Fight the hesitation (empathy). Develop the mindset.
• Build a long-term plan.
• Listen to complains.
• Motivate colleagues.
• Ignites:
• Keep it simple, stupid! (A reminder to myself and a surprisingly accurate analogy to how (not) to build sustainable systems) by Moritz Rogalli, Init AB:
  He showed his way towards KISS.
• The (Un)Surprising Truth About DevOps Culture by Manuel Pais:
• Introduced different types of organizations (power-oriented, rule-oriented and performance-oriented).
• A different context requires different DevOps means, e.g. depending on the type of organization you are working in. You need to identify that.
• Ops requirements have to appear within the product backlog.
• Devs should monitor apps.
• Devs should deploy apps.
• CAMS.
• 3 Open Space sessions with 3 parallel tracks for each session.

And my notes from the second day:

• The Challenges of Adopting DevOps by Bianca Heinemann, IBM:
  Culture, cloud, network, budget, tool and app ... I neither fully agree with the selection of challenges nor with the statement that you have to define everything upfront before you "implement" DevOps.
• Docker Container Lifecycles - Problem or Opportunity? by Baruch Sadogursky, JFrog:
  An interactive poll among the audience showed that just a few companies do Docker in production. The talk advertised the good Docker repository support in JFrog Artifactory and how it supports promotion pipelines from image builds in development to image deployments in production.
• Promote Docker images across stages. Do not promote Dockerfiles and run "docker build" in each stage.
• Labels in Docker repositories are not immutable by itself, e.g. the 14.04 label of the official Ubuntu Docker image will point to different images over time (due to security patches). The image hashes are immutable.
• With "docker tag" you can just address a single repository. JFrog Atrifactory offers virtual repositories to address different repositories across stages. You can promote images between virtual repositories.
• The Artifactory Query Language supports searching images by their metadata.
• Collect all the things with Beats by Philipp Krenn, Elastic:
• Short intro into the ELK stack.
• Beats is written in Go and is meant as a complement to Logstash. Beats offers different shippers to collect and ship data either directly to Elasticsearch or let Logstash enrich the collected data.
• It's all based on a framework, and here is an interactive generator to create your own shippers.
• Here is a quickstart setup to start playing around with ELK and Beats.
• War Games - flight training for DevOps by Jorge Salamero Sanz, Server Density:
• Humans in DevOps: System issues often become human issues due to alerts, incidents, pressure of time etc. See also here.
• Expect downtimes: Prepare and practice, respond, do postmortems.
• They established a general process to respond to incidents, which includes logging the incident, joining certain chat rooms and following checklists. Especially with the last I totally agree: At my former employer we had good experience using checklists - we called them standard operating procedures.
• They introduced war games, in which they actually walk through the incident response processes on realistic replica systems or by utilizing infrastructure mocks. So, they practice, and they check the process for its validity. They can go even further by combining failure scenarios to get used to such quite rare, but fatal situations.
• Results for the humans:
• Increased confidence.
• Reduced panic.
• Improved coordination.
• Established trust relationships.
• Improved time to resolution.
• They also worked on the following:
• Optimizing the on-call design.
• Prioritization of alerts.
• Optimizing notifications (concerning amount and content).
• Rethinking Performance Engineering in the DevOps World by Felix Willnecker and André van Hoorn, fortiss/University of Stuttgart:
• Performance = timing behavior + resource utilization.
• Use performance models to simulate changes in infrastructure, code or user behavior.
• Opportunities from DevOps:
• Automation.
• Tooling adoption.
• Modern technologies (e.g. using cloud services).
• Opportunities from software performance engineering (SPE):
• Mature approaches and tools.
• Challenges for the integration of SPE and DevOps:
• Fast feedback expected, but performance evaluation takes time (e.g. stress tests).
• Keep up with more frequent changes.
• Modern technologies can be challenging by itself.
• Optimistic approaches like A/B testing might not be able to be performed on business-critical systems.
• There is also a DevOps Performance Working Group.
• Working in and with Open Source Communities by Bernd Erk, NETWAYS:
• Communities are controlled by people, not by leaders.
• Communities look differently from the outside and from the inside.
• Four stages of community building:
• Pseudo-community of people sharing a common value to get something started.
• Chaos by growing demands.
• Emptiness, as you have to deal with weakness of yourself and others.
• Respect and empathy.
• Disagree with ideas, not with people.
• Bring in new members.
• Be as flexible as possible, but take over responsibility.
• Take care of the internal culture and respect it.
• Don't be a control freak. Be transparent.
• Measure progress.
• Value and mention the community members.
• Meet in person as much as possible. Communicate a lot.
• Establish a code of conduct, take care of it and comply with it.
• Be polite to everyone, but don't accept harassment.
• Ignites:
• Scalable and clean build environments with Jenkins and Docker by Stefan Kahlhöfer:
• Increased number of build jobs.
• Less dependencies between build jobs.
• Integration methods tested so far:
• Docker Plugin.
• CloudBees Docker Custom Build Environment Plugin.
• Custom bash script developed by themselves.
• He also mentioned Yet Another Docker Plugin, which looks promising, but he has not tested it yet.
• Praise the "overwrite" - Why boring approaches are awesome! by Florian Sellmayr, ThoughtWorks:
• Build something simple.
• Reduce moving parts.
• An Open Space session.

Here are some pictures taken at the DevOpsDays Kiel.