Build resilient systems at scale
28–30 October 2015 • Amsterdam, The Netherlands

organizational optimization sessions

13:45–14:25 Thursday, 29/10/2015
Sarah Wells (Financial Times)
Slides:   1-PDF 
You've heard all about what microservices can do for you. You're convinced. So you build some. Reasoning about your functionality is way easier: these services are so simple! Then you get to the point where you have 35 microservices, and all the monitoring and alerting tactics you used for your monoliths are a complete disaster. Something needs to change and this talk will explain what and how.
11:50–12:30 Friday, 30/10/2015
Frederieke Ubels (bol.com), William de Ronde (bol.com)
Slides:   1-PDF 
Bol.com has been growing bigger and faster for years, with all the growing pains of more people, a larger and more complex landscape, sharing codebases, more and more dependencies, and bottlenecks. You’re always waiting for somebody, and there’s always somebody waiting for you. To battle this we decided to enable everybody to implement their own vision on DevOps – a great journey towards autonomy!
11:50–12:30 Thursday, 29/10/2015
Lindsay Holmwood (Australian Government Digital Transformation Office)
Slides:   external link
"Fail fast, fail often" is a tech industry mantra. But what's the point of embracing failure if we're not learning anything from it? The language we use and views we hold when talking about failure shape the outcome of that discussion, and how we learn in the future. Let's talk about how to learn better about What Went Wrong and minimise blame in our organisations.
13:45–14:25 Friday, 30/10/2015
Slides:   1-PDF 
Find out how adding a robot to your chat channel can increase communication between team members and the tools they use. Featuring Hubot, the friendly open source robot from GitHub.
17:05–17:45 Thursday, 29/10/2015
Mark Barnes (Financial Times)
A throwaway comment at a work social turned into a handful of techies organising the FT technology departments’ first internal (and international) conference. This is about how we stole ideas for the format. What went wrong and what went very right. How we hope to do it better next time, and ultimately why an internal conference is a great idea for the culture in your organisation.
14:40–15:20 Thursday, 29/10/2015
Mike Amundsen (API Academy, CA Technologies)
Slides:   1-PDF 
Most of us know about Conway's adage "Any organization will produce a design which is a copy of the organization's communication structure." But Conway coined four laws in his 1968 paper "How Committees Invent." What are the other ones? Why are we not talking about them? And what do they tell us about optimizing teams in a distributed world?
11:50–12:30 Thursday, 29/10/2015
James Turnbull (Empatico)
Docker has been one of the runaway successes in infrastructure tools. Some of that is hype, but Docker has seen huge adoption by both developers and operations people. This isn't a talk about marketing or about using Docker. It's a talk about the lessons we've learned from building developer and sysadmin-facing tools.
16:10–16:50 Friday, 30/10/2015
Matteo Figus (OpenTable)
During this talk I’m going to speak about how we tried to approach components at OpenTable. After breaking our monolithic back end into smaller microservices, we tried to break the front end into smaller parts too: we tried to elevate components as services, in order to enable engineers to create and consume them via clear and well-defined contracts and interfaces.
13:45–14:25 Friday, 30/10/2015
Mark Heistek (ING), Taco Bakker (ING)
Slides:   1-PDF 
Continuous Delivery did not end as described in the Continuous Delivery book. Key learnings and experiences of implementing Continuous Delivery at scale are shared.
16:10–16:50 Thursday, 29/10/2015
Ryn Daniels (Etsy)
The principles of DevOps can be beneficial to everyone involved in software development, not just development and operations teams. This talk will discuss practical ideas for how DevOps principles can be used throughout an organization, and the benefits of spreading operational thinking further than just the Ops (or DevOps) team.