Video recording and production done by DevOpsDays.
DevOps is often heralded as the solution to all the problems within IT - planning, slow delivery, large team, etc. All solved via automation. However, once the dust settles and the new tools are implemented, the more challenging problem begins. Implementation of a DevOps type practice requires change and adaptation of the practices within the framework of the existing culture, and these challenges are often overlooked or poorly addressed. This talk discusses many of these challenges as observed in small and large companies alike, how to plan and execute successfully.
James Fryman is an Information Technologist who builds, designs, curates, and evangelizes automation in all layers of the IT stack. Over the last decade, James has held roles in Information Technology that includes the domains of Information Security, Service Delivery, IT Operations, Development, and IT Management. He has learned through these experiences the importance of automation in all facets of Information Technology to accelerate delivery, reduce human errors throughout an application lifecycle. Currently, James works at GitHub assisting in the development and curation of systems scaling within the Operations group. He is also a frequent speaker on the topic of automation at conferences throughout the world.
Automation is a great example for improving work processes with the help of technology. In case of automation, the means and gains are obvious: the task is done without human intervention. As not all work is amenable to automation, we need to be conscious about what other options we have.
In this talk, I'd like to draw attention to a another powerful tool: decoupling. Decoupling means making things independent from one another. It can apply to work tasks when designing processes or writing run books. It can apply when designing new systems or evaluating technology choices. It materializes in the example: what do you need to do if a hard drive of your server breaks. Who is involved?
The goal is to make the audience conscious about decoupling and giving a framework to question the status quo and find potential for further improvement.
Felix Hupfeld is one of the creators of XtreemFS, the open-source fault-tolerant distributed file system, spent several years at Google to accompany Google's tape backup system from pre-production to mind-blowing scale, and returned to Berlin to join in founding the software storage company Quobyte. Quobyte's Unified Storage Plane enables everyone to run professional storage infrastructure on standard hardware.
At Shopify, we've been working with Docker since January 2014. As of this summer all Shopify store traffic (~200K RPM) is served from Docker containers. This talk covers some of the challenges we've had to deal with to deploy Docker:
The datacenter operating system we're building towards to provide a PaaS within Shopify.
What a Docker-powered PaaS means for our development and operations teams.
Orchestrating and deploying 100s of containers across hosts.
Docker is still early in the adoption curve, and there aren't a lot of people publicly talking about their experiences integrating it into their environments. We would like to share how we're linking Docker into our organization.
Simon Eskildsen is part of the Infrastructure R&D Team at Shopify which is responsible for exploring and implementing new technologies to improve the development process at Shopify. Shopify's Infrastructure team has spent the majority of 2014 working on integrating Docker into the Company's infrastructure, to run most of Shopify's core platform and the surrounding apps.
Sometimes the network infrastructures are not one of the common environments you are used to work with. Think of swimming data centers, far away from the shore serving a high demand of modern web applications to be used by passengers. How do you maintain and operate an application stack like this if remote access can break every minute and deployments become a nightmare? How does a datacenter with an unreliable network connection works with cloud services? What are the challenges from the DevOps perspective? Join us to learn how we use Docker, Chef, AWS and friends in such a challenging business case.
Joern has been developing, debugging and designing software for more than ten years. At kreuzwerker he is responsible for architecture, new technologies and concepts. A computer science graduate, his professional interest is in the use of functional programming languages and the architecture of distributed applications. In his diverse projects he has gained solid experience with operating systems (primarily Linux and Mac OS) and has created various databases from different paradigms. He masters C, Ruby, Java, Erlang and a little JVM LISP. He is thus as much at home in infrastructure and service clouds (preferably AWS) as on the command line.
Over half a million accommodation properties worldwide rely on Booking.com infrastructure to facilitate guest stays. Yet the challenges of scalability and reliability have not hindered the rapid pace of development and change of Booking's massive web and mobile presence.
In this talk, I will present the underlying infrastructure technologies that have enabled hundreds of measurable and monitorable live traffic impacting changes to be made on a daily basis. Alongside this will be presented some of the technical innovations that have enabled scaling for year-on-year growth every year for the last decade.
I will also cover how focusing relentlessly on the customer has helped to bring development and operations together behind a common goal. Finally, I will touch on how company culture permeates right through to how we develop and deploy software as well as how we interact on a day to day basis.
Daniel Parry has spent many years driving DevOps integration forward, firstly at the University of Cambridge, working on projects that received national news coverage and then at the UK's leading provider of online self service knowledge solutions. He now works as a sysadmin at Planet Earth's #1 accommodation site, striving to make DevOps work in a hugely challenging and stimulating environment.
The Talk motivates people to do DevOps. I will describe some of our experiences of Hypoport of starting DevOps in the small and scaling it into the whole IT organization. I'd like to describe how with some simple steps the acceptance of DevOps can be greatly increased in an organization. I will describe how the different roles of developer and operator can contribute what they do best while working for a common goal. How do we do that? We start a new project or new service as a the common baby of dev and ops right from the beginning. There is no coding without the operational impact in mind.
Benefits to listeners: The goal of the talk is to be motivational while sharing our best practices and lessons learned. It will give practical ideas and steps for more
In this talk we explore in detail how efficiency and effectiveness are related to DevOps and the traditional separation of Development and Operations.
Companies are usually aiming for high efficiency and predictability. This seems to make sense in the first place, as no one wants to be inefficient, right? But wait a second, the ask for efficiency might actually be a source for a permanent conflict with the DevOps idea.
The focus on “synergy effects” and “good utilization” – which is a focus on efficiency – is often one of the main motivations for creating silos in the organisation, for the classical separation between Dev and Ops. Quite often those structures are neither effective nor efficient in the long run.
On the other hand, with DevOps done right one can achieve a high level of effectiveness: Horizontal scaling, that is, increasing for a team their coverage of the value stream from idea to production, brings naturally the focus on doing the right thing for the customer. Furthermore, by improving the efficiency of an effective process, DevOps can enable companies to be ahead of their competitors.
What I can learn in this session?
You can gain a better understanding how the DevOps approach yields to good organizational setups.
You learn some good arguments, why the traditional approach is suboptimal, and understand the mechanics that lead to ineffective and inefficient structures.
You learn good arguments for selling DevOps better
You learn ideas which help you to make the right choices in your DevOps journey.
Alex works as an Agile Coach for HERE, a Nokia business, in Berlin. His journey in the IT industry started 20 years ago as a programmer. Over the years he assumed many different roles (tech lead, team lead, release manager, lean manager) in different companies and organizations.
Alex main focus is to deliver value to production quickly, so he was working on evangelizing and introducing Continuous Delivery, DevOps and Agile Testing in enterprises. From 2008-2010 he was leading the release management of the eBay company mobile.de in Germany, the largest online market place for selling vehicles in Germany. In 2011 Alex joined HERE, a Nokia business, in Berlin/Germany, and was leading a delivery team for three years, which is responsible for multiple REST services hosted in the cloud. In March 2014 he switched to the role of an Agile Coach and Change Agent for HERE.
While DevOps is primarily a culture change, it is undoubtedly assisted by technology and tools, especially in larger enterprises. From collaborative planning to automated problem detection, technologies and tools can help to connect individuals, smooth workflows streamline interactions, establish common language, and much more, to accelerate application delivery and unify service delivery teams. This 5-minute Ignite talk will highlight 10 important functional areas where technology and tools can assist a DevOps transformation – all without any product names or brands!
On the one hand, people love Icinga/Nagios based monitoring systems for their simplicity and large community. On the other, they hate them for their inadequacies in scaling, inelegance in configuration and meeting the need¹s of today¹s IT architecture.
Last year, the Icinga team decided to deal with these long-standing deficiencies and build a more open and flexible core. The goal was a core that is not only easy to use, but also easy to tailor to different environments, supporting APIs and other components typical to modern infrastructures.
This talk presents the results of this endeavor Icinga 2: A new monitoring system in the works that supports distributed modules, outdoes on performance and integrates well with tools such as Logstash, Graphite and Puppet, common to modern architecture.
Bernd Erk, Bernd works at NETWAYS, a company dedicated to open source solutions in Germany and active in the monitoring community since the nineties. After dropping out of the Nagios Community Advisory Board, Bernd was involved in forking Icinga with a group of community members. With a passion for modern IT architecture and all things open source, Bernd is involved in several projects like Icinga and OpenNebula.
I want to present a simple yet fully functional way of sharing secrets in a team and using them in a configuration management tool. The approach builds on the Unix philosophy and combines multiple tools in an easy way and should be applicable by any team with very small effort, yet still provides reasonable security.
The procedure is used in production and has proven itself well for our team of three involved people.
I'll demonstrate the approach in a format that's both Ignite-compatible and is close to live-coding demos.I want to present a simple yet fully functional way of sharing secrets in a team and using them in a configuration management tool. The approach builds on the Unix philosophy and combines multiple tools in an easy way and should be applicable by any team with very small effort, yet still provides reasonable security.
The procedure is used in production and has proven itself well for our team of three involved people.
I'll demonstrate the approach in a format that's both Ignite-compatible and is close to live-coding demos.
abstract Incidents in software operations cannot be prevented. This is why we put responsiveness over prevention. In an ideal world we would all use tools like the Netflix Simian Army that puts your operations in a constant failure situation, which keeps everybody in perfect shape for incidents. In a less ideal world it is not easily possible to take down random parts of the production infrastructure just to test the incident readiness. But it is possible to get many of the benefits by a much simpler approach. Just by coming together and discussing certain situations following a specific set of questions. I call this the 15 minute incident workout. It doesn’t get you to a world championship but it will keep you fit for daily business.
Jörg is a developer, devops and manager at Hypoport AG in Berlin. He is working on EUROPACE an internet-based finance marketplace. For more than 15 years he has been working in different roles in IT consulting and software development. He is always interested in all kinds of new approaches to software development and operations. He likes to share his ideas and opinions at conferences and user groups.
So you've bought yourselves a top of the line devops appliance. Everything is great. But, from what you've heard from Twitter, the next thing you need is a security. My talk is about the next steps. To get from zero to well at least better than most of the industry.
Security from the application side, the CI/CD side, and the network/infrastructure end. Topics such as
making builds more trustworthy.
IDS that isn't a complete waste of €100,000.
detect XSS with this one weird trick.
the one firewall per child project.
They'll be humour, cat GIFs and some cool technical ideas.
One of the important ideas behind DevOps is that people from development and operations should work together, just like the Doctor (a Time Lord) and his human companions work together to solve the problems of the universe. We're moving away from a model where control was centralized in the hands of a few, like the way the spice was tightly controlled in Dune, and we're sharing more of the responsibilities, like how the Stargate SG-1 team collaborates with the Tok'ra, the Asgard and others. We also work to automate processes and manage configurations, not unlike how Asimov created his 3 laws to make sure that robots, like our servers, were well-behaved and performing according to some standard rules. This is a fun session, but it focuses on real lessons from DevOps as told through science fiction.
One of the development practices, that operations can benefit from is Test Driven Development. I'd like to emphasize benefits of this approach and give you a feeling how TDD looks in Bash, (shortly) demonstrating building blocks for writing Bash scripts and function libraries in test-driven way and showing how they can interplay.
Sharing is one of most important aspects of DevOps. I want to talk about our approach of sharing production metrics with everyone in the company by putting up TV screens displaying nice dashboards in our Munich offices.
I’m going to give an overview of the requirements, involved tools like icinga, graphite, grafana and describe some of the challenges and (sometimes surprising) results.
Thomas Falkenberg is a performance engineer and DevOps promoter who loves pretty dashboards and new ideas. He works at PAYBACK GmbH in Munich.
DevOps is indeed a really good way of operating today’s applications but what does it really means for the sysadmin? What needs to be learned, what needs to change in the way we manage systems and communicate, where is the starting point? Based on the learnings from a project with a large European customer we will discuss the best practices learned and the issues encountered. We will also talk about the tools and languages used and the learning curves depending on which platforms is used. We will illustrate our sessions with examples using the industry standard like Chef, Puppet or PowerShell targeting the different platforms like Windows and Linux.