• Daniel Willis - Putting the R in Sports
• Mark Morris - You, Me & StatsD
• Sara Cowles - If you want to have an impact, Devops is not enough
• Jason Hand - The Emergence of ChatOps
• Matt Stratton - DevOps in the Machine
I hate computers. How many times have you heard those words? Or said them yourself. Systems crash and go boom all the time. The easiest thing to do is to blame the person touching the keyboard when it happens. Especially when that person touching the keyboard is you. But how do we build safer systems? How do we build humane systems, systems that actually engage and even delight the user? Sidney Dekker says "Safety improvements come from organizations monitoring the gap between procedures and practice". How can you build a system for safety if the way the system is designed isn't actually how it's used. Of course it doesn't work, you were doing it wrong. We have to stop shoving users into systems with procedures that aren't based on reality.
In this talk I address these questions through my experience building tools for developers. Every tool works in an ideal world and on my machine. But the hard part is building tools that "work" even when they don't. Understanding the gap between procedure and practice can be a real challenge, and if you don't approach that problem with a big dose of empathy you won't have much luck closing that gap.
It's an oft-quoted adage that too many cooks spoil the soup. But is this always true? At Etsy, we have roughly 40 Ops and Developers making upwards of 20 or 30 Chef changes per day.
In this talk, I'll look at the tools, techniques and workflows we leverage to enable tens of people spread across teams, timezones and even countries to work together to continuously deliver Chef changes with nearly the same frequency we ship code. Although the specific tooling discussed in this talk is designed to work with Chef, many of the techniques and practices I'll talk about are applicable to many other engineering disciplines - the importance of communication and visibility in a Continuously Delivered world, the importance of testing and metrics, and optimising your workflows to remove friction and enable agility while also satisfying the requirements of your stakeholders.
This talk will break down roughly as follows:
• A quick summary of Chef at Etsy - what we use it for, a quick guide to our workflow, and how we think about Chef changes internally
• Tooling & Workflows - the tools and practices we use to deliver our Chef changes, and how we monitor and test our changes.
• The roadbumps we've encountered along the way as we've scaled and evolved our usage of Chef and what we've done to solve those problems
• What next? We're not perfect, and we never stop iterating and improving our workflows. What are the pain points we're experiencing currently, and how are we looking to solve them?
• Jenna Pederson - Stop Blogging About Women In Tech
• Michael Lanyon - Effortless WebPerf Monitoring
• Larye Pohlman - Vulnerability
• Jason Clifford - GameOps
• Jason Walker - Empathy, Fairness, and Contentment
I'm a developer. I barely know what Nagios is, let alone how to set it up or configure new alerts. But I do know a lot about the application I'm working on, and I know how to code. By building a framework for easily adding new monitoring rules, the operations team at Swiftype has opened up application-level monitoring for the whole development team. I'll talk about the tools we wrote and explain how they allow developers to easily add new monitoring checks that probe our application (including web services, queues, and database) and alert the team by email, chat, or phone.
I'll show how to use the monitoring framework we wrote, but I'll also use this collaboration as a jumping off point to discuss how I think developers and operations can work together to build software faster and keep it reliable, based on our experiences at Swiftype.
At Bloom Health, we're operating in a highly regulated environment (including HIPAA & PII) while at the same time running our infrastructure in public cloud. This leads to a number of considerations and tradeoffs when choosing the various parts of our stack. I'll detail the considerations we've undertaken, the compromises and winding paths towards workable solutions, and the specific technologies we've found work better for us as in-house solutions versus those where we've found SaaS to be the optimal (or at least acceptable) choice.
The IT community in the public sector has a sizeable, but frequently forgotten influence on peoples lives. Have you tried to renew a license plate online recently? How about navigated https://www.healthcare.gov/ to get health insurance? Used online learning tools for a public educational institution? Have any of these experiences been pleasant, or what you would expect from a well run modern website? These websites are your tax dollars at work. Are there reasons why we maybe aren't seeing the cultural ideas of DevOps reaching public sector IT shops as quickly?
Public sector organizations differ greatly from private sector organizations with regards to structure, motivations and funding. Other factors such as government mandates for the existence of these organizations, tenured employees and reliance on antiquated domain specific applications can exacerbate the issues caused by these differences.
In the past year or so, we've seen how the discussions around DevOps in enterprise organizations have opened up discussion of many of these cultural ideas to more traditional corporate settings. For DevOps ideas to gain influence the thousands of public sector IT workers, we need to recognize that they too have a separate subset of problems and challenges and start a conversation about how to tackle these issues. This talk will seek to begin that conversation, explain some of the cultural differences between the public and private sectors, explain some of the challenges the public sector faces when trying to break down silos and explain why and how we should evangelize to public sector employees.
Devops has come a long way in the 5+ years since its inception. From simply breaking down silos and automating/measuring all the things, we’ve grown and started talking recently about complexity and inclusivity, burnout and empathy. We started trying to make people's professional lives better in the fields of development and operations; this expanded in two dimensions: both including more teams (QA! Databases! Even security!) and outside of the office, encouraging people to think about burnout and work-life balance.
What’s missing from this picture? Or rather, what’s next for devops? I’d like to propose that, as the lines between the “online” world and the “real” world blur and fade away to nothing, we expand our view of devops to cover this whole new world. Let’s expand our empathy beyond just the tech industry, following the examples of B Corporations who work towards social and environmental good. And let’s talk about how we can make the world better, more empathetic, and safer for everyone, online and off.
• How to make a shift from traditional model to DevOps? (Namrata Rao)
• Repository as an deployment artifact (Inny So)
• Developer Happiness at RedMart (Surya Dharma Tio)
• DevOps and the CFO (Benjamin Henshall)
This is a story of an Infrastructure team at Zalora that implemented DevOps using Haskell and Nix.
The story is about:
• drowning in inherent complexity of existing Puppet configuration
• establishing a functional programming community inside the company
• implementing configuration management using purely-functional language and package manager Nix and using NixOS as the base OS
• challenges of using new tools at scale
• building cloud infrastructure tools using Haskell
• building a code-driven deployment platform borrowing design practices from Erlang/OTP, Mesos and other successful distributed system frameworks, accommodating engineering team growth
• overcoming adoption failures and finally reaching operational happiness
This presentation covers the current state of the Devops movement as presented by one of the original "Core Organizers" of the movement. The presentation will look at some of the taxonomies that have been used to describe Devops such as CAMS and ICE. It will also cover the recent 2015 Devops Survey and we will end up with a discussion about how Devops is being adopted in the enterprise.
At Viki, we run a number of micro services that process thousands of requests per second in various geographical regions. Micro service architecture helps us break down the complexity of building a large distributed system, but also introduces the complexity of debugging an issue.
This talk is about log processing at scale - building an Elasticsearch cluster that can handle tens of thousands of events per second from all levels of a micro-service container based architecture.
My first exposure to a DevOps Days was in 2010. I was an early adopter of most of the tools, took part in the heated iClassify debate, was contributing to Chef before it had a name, back when it was still a pet project at HJK Solutions.. As things evolved, we tried the offshoots that we hoped would fill the gaps.. MCollective, opscode-agent, but really we were just trading one problem for another..
DevOps Days was started in this gap, and over the years I have seen more and more vendor and product encroachment, and fewer people (especially outside of SF) who grasp the roots and the spirit out of which this event was born.
I will be talking about the original spirit of DevOps Days, which i feel started in 1942, and has mutated into a flavor specific to our modern world. I will not be discussing any vendor products, and this is not a sales pitch for anything.