Luke Kanies, founder of Puppet, will discuss some of the major trends in systems and infrastructure, and why all the big vendors are so skittish and all the customers are so confused.
When you ask speakers to "define devops" today, you invariably get a variety of angles. Culture. Empathy. Respect. Silo-busting. But all of these words point to a bigger change under way in our organizations: the workplace is being remade so that it's more humane for those of us in IT jobs.
In this talk, I'll start by confronting the elephant in the room: working in technology today, even for the hottest Silicon Valley startup, can be downright humiliating and Dilbert-esque. Whether you're a software developer struggling under the weight of trying to make your "agile story point quota", or a sysadmin getting woken up at 3 a.m. for senseless alerts, there's not much to like in the working conditions of the average IT worker. I should know: three years ago, I got fed up and left IT for a while.
I'll delve into the origins of the lack of humanity in IT workplaces today, with a few anecdotes about my own dehumanizing experiences at companies both large and small. Along the way, I'll talk a bit about the experiments we're conducting at Chef (the company) to try and make software development and operations a more pleasant experience. I'll wrap up by talking about some tangible changes you can make in your own company to make your own job and working environment more humane.
At Fictive Kin, we take our distributed team as seriously as our distributed systems. With 12 partners spread over 5 timezones, two continents, four countries and a total of zero offices, we've faced nearly every challenge there is (and created a few of our own along the way) when it comes to making distributed teams and workflows function over the last four years we've been in business.
Along the way we've launched applications that have nearly a hundred thousand users, ones that now have databases nearing a half-terabyte in size, another that has been mentioned on prime-time television by former Presidents of the United States, not to mention the wildly successful Brooklyn Beta conference that we put on in New York every October for over a thousand attendees from all over the world. Let's talk about how we manage to do all that and maintain our friendships, sanity, work/life balance, and still have some silly fun along the way.
The term "microservice" is being thrown around a lot in operations and developer circles. This talk will go through specific challenges (both social and technical) we faced breaking a monolithic Rails application into several smaller services written in Ruby and Go. I'll aim to present our experiences, both good and bad, from a devops perspective.
What would happen to your system if one of your app servers died right now? What about your database server? What if they're just slow? Does your application handle it gracefully? Does your development team get paged? Are you sure?
Netflix famously uses their Simian Army to test these scenarios in production, but setting up that automation might be far down the priority list of a growing startup.
In this talk, we will discuss how PagerDuty started injecting failure into our production systems with minimal effort and the full support of the development teams. We will discuss why you should start proactively injecting failure and the exact steps you can take. We will go over the importance of setting an agenda, keeping a log of the actions taken, and todos that were uncovered. We will talk about why I think your metrics should be linkable, and why you should leave your alerts on during these planned failures. Finally, we will talk about the benefits your company will get from causing all this chaos. At the end of this talk, I hope to have inspired you to go start breaking your production systems, on purpose.
Companies like Netflix, Google and Amazon are leading the way with Continuous Delivery. Most of us don’t work in a company like them. We don’t have a simian army. We don’t have a canary testing process. Working out where to start can feel overwhelming. This talk will provide simple tips and tricks for improving delivery without investing lots of time up front creating complex deployment frameworks.
Culture and process is as important as tools and automation. This talk will give real-world examples of introducing the principles and practises of Continuous Delivery to existing development and operations teams, and some of the difficulties encountered along the way.
This talk aims to demystify Continuous Delivery and make it accessible. The audience will learn why Continuous Delivery can help them and how to take their first steps on the road to improving their delivery.
The CFO pulls you into their office, where she tells you that you are now responsible to build a mission-critical system that will drive a billion dollars in revenue, the previous outsourced team having failed in their quest. You have no staff, no infrastructure, and you have 8 weeks to deliver.
Elsewhere, the lead solution architect for a major application tells you that it is impossible to fully automate their deployment, that some human intervention is always required, because it is too complicated for software to handle, and only a human can truly comprehend their platform.
At a different company, a Vice President says they spend upwards of three months performing deploys for their critical integration system, performing site flips when ready. They were certain this was industry leading performance.
For the past 6 years, in various roles, I've travelled much of Canada trying to help large companies get faster and more consistent at building, integrating and deploying software from requirements through development and operations.
In this talk I will highlight various stories and observations of how motivated teams in large enterprises are adopting Agile and DevOps in the face of Waterfall processes, ITIL methodologies, 1500-page runbooks with excellent screenshots, dogmatic architects, and project managers with Gantt charts of holy writ. I'll explore the lessons I have learned and provide some ideas for those looking to change their companies from the inside with Lean, Agile, DevOps, and Cloud.
I'm going to share the experience I've had leading the charge to establish (what I think is the first step in leaning an Enterprise) Continuous Integration as a standard practice for our application development teams. While working closely with Dev and Ops Teams to establish the pipeline, I quickly realized that the appetite for such change was high - Dev teams wanted empowerment and Ops teams didnt want to support 'button pushing'. In parallel, the Dev teams were asked to practice Agile (in the form of Scrum) and the level of change the organization was undertaking was all of a sudden enormous. This is the story of how we were able to successfully achieve the impossible.
Bringing DevOps into enterprise operations environments is difficult at the best of times. There are entrenched procedures, processes and job definitions and the old adage that if it ain’t broke don’t fix it.
This case study describes what happens when the boundaries between operations, development and management starts to blur. By introducing a little bit of log aggregation using Elasticsearch, Logstash and Kibana both development and operations teams along with application manages, find new ways of collaborating and fine tuning application, server and storage performance.
Have you written workstation automation scripts, only to find they only work for a limited time until the software bumps a major versions, or you find it just doesn’t work correctly on that one coworker’s machine? What about having completely different workstations and software versions for the various projects a team works on? The answer to this, and more, may lie in containerizing your workstation.
In this Ignite style Lightening Talk, we’ll discuss the promise and pitfalls of using Docker containers as underpinning for developers, ops, testers and others workstations.
We're in 2014 but ask a recruiter, a QA and a Dev what DevOps is and you'll get different answers, still.
As someone who has consistently fallen between the pigeonholes of Developers and Operations Engineers, my biases are even and I'm ready to converge on the core, misinterpreted values of DevOps as a practice, not as a role. Tools, pipelines and Jedi mind tricks are equal players when it comes to a necessary DevOps dance. It's not about being a hero, it's not about fixing everything for everyone. Accept the world is bad, and make it better, not perfect. And if that doesn't work, let developers operate their own code in production.
This ignite talk answers: what should we do? why? in what order?
We'll start with measurement. Measure outcomes. Measure your process. Make this information visible to the whole team. How are we performing on KPIs? How long from code to release? Enable devs to view the world as it is.
Allow more experimentation: Enable a short cycle from dev to users, that way developers can see the impact of their changes in reality. Enable small releases that change little to see the impact on KPIs.
Rapid deployments don't happen without automated testing. If we can't verify the software automatically, what does testing each release cost? What would it cost to automate the testing? Have existing investments in automated testing payed off?
Despite the increasing popularity of DevOps, most organizations are still divided into functional silos. Each silo is focused on their specific goals, which often conflict with goals of other silos, causing everyone to lose sight of the primary purpose of the organization.
This ignite talk will discuss some issues with silos, common complaints when organizations try to introduce a DevOps culture, and how an organization must change its mindset to make a successful transition.