Video recording and production done by DevOpsDays.
The UN Food and Agriculture Organization (FAO) is a sprawling organization that monitors all aspects of food, agriculture, forests, and fisheries worldwide. Its main product its diverse and deep datasets. Unfortunately, those datasets have too often been inaccessible outside of the originating department, let alone to the rest of the international community. Data.fao.org is an ambitious effort to provide the rest of the world with an API for FAO's datasets. Supporting this effort is an array of complicated web services and presentation layers.
However, all this work will work will be nought if this infrastructure doesn't remain "up" and accessible. I will present how we are using collectd, JMX, statsd, logstash, and Graphite to monitor the data.fao.org infrastructure. This has been done entirely with open-source tools, which while powerful, but are woefully lacking in documentation. This presentation will go into detail how we use these to monitor our infrastructure.
How to make meaningful comparisons using the wildcards and the averageSeries, movingAverage, and timeShift functions in graphite
What the values from statsd actually mean
How to filter out distorting values
Why the 90th percentile matters
Using JMX everywhere w/out application slow down
How to fight bureaucracy and CYA w/ graphs
Speaker: Bryan Berry, Senior Operations Engineer, UN Food and Agriculture Organization Rome, IT Host of the Food Fight Show, the Chef community podcast foodfightshow.org
A look back at the last 10 years of open source monitoring and trending tools. An analysis of recent shifts in tide away from monolithic monitoring suites towards composable parts. And in conclusion a rant on the state of visualization in our existing toolset and, in the speaker's opinion, what needs to change before we get to our "happy place".
Speaker: Jason Dixon obfuscurity.com/ twitter.com/obfuscurity
PaaS has been striking fear in to the heart of many a developer, with its "noops" connotations and flashy, irritating marketing. I would like to present open-source PaaS as an enabler of devops and not the enemy. Businesses are using PaaS to reduce the feedback cycle time on their ideas - so we don't waste our effort building platforms and services that aren't useful.
Developers and operations can use PaaS to deliver value quickly, and then develop their PaaS as required. PaaS enables many aspirational patterns such as deploying early to a production-like environment, Infrastructure as Code and using a single deployment mechanism. I will be exploring the PaaS implementations I've been delivering for various organisations and the positive and negative ways that a PaaS can impact team collaboration and delivery.
PaaS is not a silver bullet. Teams still need to collaborate to deliver services to ensure expectations are met; PaaS does not equal infinite scalability, availability and functionality. Compliance and security issues do not magically disappear. Consuming closed-source PaaS may hinder future capabilities and delivery. However, PaaS also isn't a magical foreign land; we can build, maintain and develop PaaSes using the tools we all know and love. I will look at the use of Chef, Vagrant, Git, Graylog2 and others. You'll be surprised how familiar a PaaS actually is.
It's our responsibility as people tasked to deliver services to use the right tool for the job, and I think PaaS will be playing an important role in the lives of developers, operations and businesses in the future. We should look at how we can get the most out of it.
Speaker: Colin Humphreys
"DevOps Culture" is usually referred to in public conversations as a binary thing. It's either something your organization has or doesn't have. There are plenty of examples of where a young company was born with a strong DevOps Culture. But what about everyone else? What about all of those companies with legacy people, process, and technology? How can they turn their long suffering legacy culture into a DevOps Culture?
This presentation provides a look at the "levers for change". These are the levers that I've seen companies successfully use to introduce and improve upon DevOps culture through influencing desired behavior and discouraging unwanted behavior. From policies, to metrics, to skills building, to innovative uses of tooling, these are tangible practices ("levers") that can get an organization self-organizing in the right direction without lofty management decrees or, in most cases, significant investment. Each of these levers can be used individually or in unison. It's up to you to decide which ones to pull depending on which way you want to move your organization.
This presentation will survey these practices and their effects from from multiple points of view: -Levers to change Developer behavior -Levers to change Operations behavior -Levers to change Management behavior
The presentation describes one start-up project and the way we solved problems and moved things forward to handle 70 000 requests per second from the initial 5 000 - with the same hardware. For developers - applications are the essence, but there are a lot more additional pieces that could influence reliability, accessibility and performance of applications. It will be explained how and why we attracted development guys to the world of monitoring and metrics, the sphere which was considered solely operations playground, how we combined different metrics: business, application, hardware, 3rd parties and metrics from the cloud to reach our goals, which tools and practices proved to be effective and which not.
Speaker: Mantas Klasavičius
System administration or operations has been slow to change over the past 20 years, due to the lack of a global culture. In this talk Mark Burgess asks why it took the DevOps movement to rediscover some well-known truths about infrastructure management that were known to isolated pockets, and what the future of operations has to be -- both in relation to developers and to end users as we grow into the 21st century.
You can not prevent failure, you got to embrace it. Failing quickly is essential for your organization to learn and adopt, avoiding failure is living in fear and being defined by our fears. The idea of devops is that the individual is able, willing and accountable to fix a failure.
In order to drive a cultural change as a leader you have to reward fixing and owning failure instead of preventing it [the order is important! carrot first, stick to reinforce]:
You have to reward being accountable for a failure. You are not working if you are not failing at something.
You have to enable people to fix failure. Do not give people oven mints to handle radio active waste, get the right support structure, tool and most importantly training and time.
You have to set the expectation that "I am the expert". The individual has to be able to understand, able to engage in each part of the system from typing in an editor to evaluating production system stats.
It is a change, like the natural ebb and flow of life. For a devops team you rewarding generalist over specialist. At the same time you will compartmentalize system with needs of specialist to a very defined, simple and well tested interaction to minimize the risk of unexpected behavior. In my presentation I will provide specific examples of driving a culture change in an organization at the time of rapid growth for exactly the purpose of enabling such growth.
Speaker: Peter Halacsy was the co-founder or prezi.com and today as a CTO he manages a diverse engineering group in 2 continents. He grew a small university project from Budapest to a prospering business in the Silicon Valley. To drive such rapid expansion, the organization had aster the ability to learn and adopt as new challenges were presented at different stages of the growth, as well as at entering into new markets.
A wide array of emerging technologies and processes has led to continuous delivery as the current summit of software development processes, but what lies ahead? Grounded in my own background and current work with continuous delivery, I will explore a number of ongoing concepts and new ideas that are evolving out of old and new techs and how they could change how agile development and release works in the next couple of decades.
These are some of the concepts I will be exploring: - Dependency management and modular development - Infrastructure as code- adding infrastructure to your pipeline - Semi-fluid dependencies- getting the best of static and fluid dependencies - Cloneable pipelines- make copies of your pipeline - Pre-flight pipelines- catch red pipelines with cloned pipelines - Evergreen trunks- keep your pipeline always green with a clone army - Quantum pipelines- a rapid feedback technique for evergreen trunks - Downstream pipelines- test against your consumers - Swarm builds- centralizing incremental development - Extreme integration- rapid feedback about interactions with trunk - Cloud IDE- moving pipeline development to the cloud - Social development- development for everyone