Gene Kim will present his findings from an ongoing study of how high-performing IT organizations simultaneously deliver stellar service levels and deliver fast flow of new features into the production environment. To successfully deliver against what on the surface appear to be conflicting objectives, (i.e. preserving service levels while introducing significant amounts of change into production), requires creating a highly-coordinated collection of teams where Development, QA, IT Operations, as well as Product Management and Information Security genuinely work together to solve business objectives.
Gene will describe what successful transformations look like, and how those transformations were achieved from a software development and service operations perspective. He will draw upon fourteen years of research of high-performing IT organizations, as well as work he's done since 2008 to help some of the largest Internet companies increase feature flow and production stability through applications of DevOps principles.
A lot of Dev and Ops people look at their security teams with disdain: "Those guys are arseholes. All they ever do is sit in meetings and tell us no." They know there's no way Security will ever embrace DevOps. In turn many security folks see the emergence of DevOps as the inmates being put in charge of the asylum. It'll all end in chaos and disaster.
So who's right? Can DevOps and security co-exist? Can they be friends? We will take a deeper look at:
What DevOps means for Security
How DevOps can be sold to Security
How DevOps changes the risk landscape for the better
How those Security folks might know some things that could make DevOps better
You'll see how DevOps and Security can have a long and prosperous friendship that makes more awesome.
Building applications in Ruby is fast and fun. Features fly, progress is quick and everyone's happy, until you have to deploy. While services like Heroku make deployment easier than it ever has been before, there's only so much they can do for you, and no-one is happy when customers can't use your application!
This talk will go over steps developers can take to protect against common production errors as well as more advanced techniques to keep your application running smoothly over the long term.
At GitHub, we've been growing pretty quickly and that sort of growth presents a lot of challenges. We were feeling the pain of trying to teach everyone (developers and designers alike) how to get GitHub and all our other projects running on their laptops. The process was failure-prone, complex, and time-consuming. So, last summer, we created the first iteration of The Setup — GitHub's method of managing laptops without getting all authoritarian about it. We quickly realized that other organizations needed and wanted this environment, so we started back with the basics and re-architected The Setup into Boxen. The same tool, the same method, but written for modularity and general consumption.
We’ve since released Boxen (as of January 2013) and other organizations are using it to great success. This talk explores our design choices with Boxen, how we use Boxen internally, our recommended design patterns for managing Boxen-driven automation, and some new goodies coming down the pipeline for Boxen.
No one wins an award for having the most popular status site. I'll show you the top practical techniques we (37signals) use for keeping our sites available at all times, even during scheduled maintenance! From hardware choices, to network topology, to high availability services, it all matters. I'll introduce tools like intermission and mysql_role_swap and show you how we've used custom alerts and dashboards built on top of statsd + nagios to intercept problems before they impact users.
On June 1, 2009 Air France 447 crashed into the Atlantic ocean killing all 228 passengers and crew. The 15 minutes leading up to the impact were a terrifying demonstration of the how thick the fog of war is in complex systems.
Mainstream reports of the incident put the blame on the pilots - a common motif in incident reports that conveniently ignore a simple fact: people were just actors within a complex system, doing their best based on the information at hand.
While the systems you build and operate likely don't control the fate of people's lives, they share many of the same complexity characteristics. Dev and Ops can learn an abundance from how the feedback loops between these aviation systems are designed and how these systems are operated.
In this talk Lindsay will cover what happened on the flight, why the mainstream explanation doesn't add up, how design assumptions can impact people's ability to respond to rapidly developing situations, and how to improve your operational effectiveness when dealing with rapidly developing failure scenarios.
Chargify.com's customers rely on us to process payments for them 24 hours a day. We do not have any planned maintenance windows: we're simply expected to be up all the time. We recently migrated from a private datacenter to EC2, moving all our operations and data across the country with zero downtime. All thanks to a combination of highly-automated configuration with Chef and specialized DB tools like Tungsten.
You'll learn about our pain points in planning the switchover, like:
Cross DC communication & VPNs
And most importantly, how we addressed every one! I'll demonstrate how we rebuilt our entire infrastructure platform from the ground up: New system images with all new cookbooks that were deployed into our existing operation without any interruption. Finally, I'll discuss testing our stack and how we replicate it among various environments and plan for future expansion.
So...Continuous Deployment. You hear that you should be practicing continuous deployment, but nobody every pointed out that there are many different ways to do it!
This talk compares and contrasts different kinds of continuous deployment strategies. Implementation, requirements, tradeoffs will be covered. Case-studies, examining different strategies practiced at companies such as Facebook, GitHub, IMVU, Heroku and CircleCI.
You want to test your cookbooks? Cool. Where do you start? In this talk, I'll walk you through step-by-step the process for executing test-driven development on a cookbook. From real-time feedback with guard and terminal-notifier, to chefspec, fauxhai, and foodcritic, quickly learn how to apply both basic and advanced tests in your infrastructure.
One of the reasons for the DevOps movement is that all developers should carry pagers and be on call, right?
Well, not quite. However, there is a common area of conflict between operations and development teams about site outages related to application-related issues that developers know how to debug and fix much faster than operations typically does.
In this talk, I'll discuss some companies that have successfully implemented developers on call" policies and what that means. I'll also discuss the business value, why it matters, and how it helps create a collaborative culture of sharing.
Ops at GitHub has a unique challenge - keeping up with the rabid pace of features and products that the GitHub team develops. In this talk, we'll focus on tools and techniques we use to rapidly and confidently ship infrastructure changes using Campfire and Hubot as our primary interface, and the benefits we've seen from this approach.
Sure, the TDD cycle is red-green-refactor but what exactly are we refactoring? We just wrote the code, it's green, and it seems reasonable to us. Let's move onto the next test. We're have a deadline, remember?
Whether we're working with code we just wrote or opening up a project for the first time, being able to listen to the hints the code is trying to give you about how it wants to be constructed is the most direct path toward successful refactoring. What the code is telling you nuanced however: no code smell is absolute and none in itself is an indication of a problem. How do we know we need to refactor? What are the code smells telling us to do? How do we balance our short terms needs of shipping our software with the long term maintainability of the code base? In this talk we'll talk through some of the classical code smells and dive into examples of how to put these smells to work for you.
Most Ruby code makes heavy use of mutable state, which often contributes to long term maintenance problems. Mutability can lead to code that's difficult to understand, libraries and applications that aren't thread-safe, and tests that are slow and brittle. Immutability, on the other hand, can make code easy to reason about, safe to use in multi-threaded environments, and simple to test. Doesn't that sound nice?
This talk answers the question ""why immutability?"", covers the building blocks of immutable code, such as value objects and persistent data structures, as well as higher order concepts that make heavy use of immutability, such as event sourcing and pure functions, and finally discusses the tradeoffs involved in going immutable.
Wild test suites often contain inefficient or ineffective tests. Working with a code base full of these beasts is frustrating and time consuming. This safari will help you identify and hunt down common testing anti-patterns. Afterwards you’ll know how to approach a test suite full of beasts without losing your mind or your life.
Whether your application is concurrent or not, there's insight to be gained from Ruby's threading support.
This talk demonstrates building a light-weight sampling profiler in pure Ruby. The techniques are simple enough to integrate into almost any application, and fast enough for even a production environment. If you've ever wondered exactly what your application is doing at any given moment, this will show you how to find out.
Along the way we'll expose gotchas and pitfalls of thread introspection on the many versions and implementations of Ruby. Based on experience implementing thread profiling for New Relic, we'll also touch on how to debug and work around problems when they come up
The ruby standard library is full of great code. It's also full of dragons. I'll show you some of fun parts, parts that you may not be using and may not even know about. I'll show you that you don't have to install everything on GitHub to build your application. I'll also look at some of nasty parts, and how to put a training collar on some of those dragons.
Look, I know you love your sprinkler timer, with its endearing little dials and simple, easy-to-use interface, and its killer dot-matrix LCD.
We thought we could do better, and we thought Ruby could help us. With the awesomeness of things like the Raspberry Pi and maybe a little Arduino, who's to say I can't use Ruby to water my lawn, remind me to fertilize, or let me know where I could save a little water?
We’ll take you on a quick tour of the automated sprinkler system world and the problems it has, and how we’re solving them with Ruby, Raspberry Pi, and about 24V of DC power. We promise not to electrocute you, but we can’t guarantee you won’t get a little bit wet.
Reading of the CRuby source code can provide unparalleled insight into the Ruby language. During this talk we will add new native Graph data type to CRuby. The new Graph data structure will be simple but on par with other native types such as Array or Hash. This talk will demonstrate that it is easy to experiment with CRuby and extend it. We will also demonstrate the speed advantage of using C to boost Ruby performance. We will implement a few of the greatest hits of graph algorithms: Breath First Search, Dijkstra, and Minimum Spanning Tree.
Devops Borat said "is turtle all way down but at bottom is perl script, but in the case of Cloud Foundry there's Ruby at the bottom. Rails is the right choice for building a web site, but the elegance of ruby can be applied to many other things including a Platform as a Service. A full deploy of Cloud Foundry requires many different kinds of nodes, with multiple Sinatra apps, event machine based daemons, shared ruby gems, and small amounts of code in other languages like Lua, Go and C where it makes sense. I'd like to take you on a tour of an open source codebase and project that really shows where you can go with Ruby.
This session is a jolly romp through the realm of practical data privacy using pure Ruby. We'll start by looking at how to obfuscate data using Ruby's OpenSSL bindings, exploring the possibilities of symmetric and public key cryptography as well as the role of hashing algorithms.
Once the basic principles have been established we'll turn our attention to designing databases with a strong privacy component, using Sequel to demonstrate how encrypted keys can be used to support privacy in the relational model. There will be some meta-programming involved which should also be of interest to ActiveRecord users. This will naturally lead into a brief discussion of the seeming difficulty of searching encrypted data along with a strategy for making this practical.
We'll round out the session by turning our attention to the transport layer with a simple scheme for securing web application sessions using a custom Rack middleware.
The discussion will be backed by code examples inspired by real-world systems.
I wrote the first wiki in a week. Why has it taken me a year to write another? Short answer: when something is already surprisingly simple its hard to make it simpler.
This last year I set out to do for numbers what I had done for words, give them depth and meaning that ordinary people can depend on every day. A wiki, like a glossary, defines the terms we choose to use. A data-wiki makes those choices more complex. Its no longer one click to check a definition. Its more like one more study to check a dataset, to see if the data says what we think it does. Not a simple process.
My quest has been to make knowing and using data an everyday thing. This means the study of data must be an everyday thing too. To this end I've pushed visualization, I've pushed domain specific markups, I've pushed streaming measurements. But through this I've retained wiki's greatest strength: the ability to create with those who we have just met and don't yet have reason to trust. Finding trust on the modern web may be this year's biggest accomplishment.
The basic premise is that we should be spending significantly more time thinking than we do programming and there are wide reaching ramifications to this point. Subtleties in how our non programming coworkers perceive some of us wandering around the office pacing or arguing at the white board are all to be covered as well as discussing the body of research that supports the ideas behind thinking more and working less.
GitHub loves Ruby. Many of our products, tools and infrastructure are built with Ruby.
In this talk, we will look at the libraries, practices and conventions that GitHub uses with Ruby. We will survey all of the repositories maintained by GitHub to get insight into how it is used, and we will also examine some of the areas where we opt to not use Ruby.
Good integration tests are hard. There are many approaches for fully testing server and client libraries for those HTTP APIs - all with various tradeoffs and problems that come up. Some are obvious, some are a little more tricky.
I'll run through some approaches and problems I've come across developing server/client HTTP APIs while developing in a highly distributed systems setup at Engine Yard.
"Postgres has long been known as a stable database product that reliably stores your data. However, in recent years it has picked up many features, allowing it to become a much sexier database.
We'll cover a whirlwind of Postgres features, which highlight why you should consider it for your next project. These include:
Using other languages within Postgres
Extensions including NoSQL inside your SQL database
Accessing your non-Postgres data (Redis, Oracle, MySQL) from within Postgres
It's true that goods are better distributable when they are in packages. That is the common view of what Ruby gems and Rails engines are: packages for distribution. This perception misses the great value that comes from packaging without distribution. That is what makes component-based architectures: a helpful tool for organizing growing codebases. We'll talk about how to do this with (and without) Ruby on Rails.
Ruby makes it a bit hard to do packages right: you really can't hide anything. Rails doesn't want you to do it. I don't care. We'll do it anyways and it will be awesome!
I am a developer, and I have Type II BiPolar and ADHD.
It's not something we talk about, but BiPolar, depression, and ADHD runs rampant in the developer community - they tend to correlate with higher intelligence. Many of the symptoms of this conditions make for great developers, but also cause incredible damage. We recently lost one of our co-workers because of untreated mental illness.
I want to share my story - and let people know that it's okay to talk about these things, that it's nothing to be ashamed of, and how to get help, and how to help those around them.