Video recording and production done by DevOpsDays.
Right now, there is a lot of activity around deploying code to production. Puppet and Chef are fairly widely used and well established. Building custom VMs for cloning is also common. Other options include creating platform specific packages, such as debian packages. Now PaaS is emerging, along with tools such as Docker. Buildpacks, as created by Heroku, are starting to be adopted as the de-facto standard by most PaaS vendors, but there is not yet any open-standard and these work differently across PaaS services. OpenShift uses "cartridges", which is synonymous with buildpacks, but different again. This talk will be a whirlwind review of all these things and more. Leave your favourite rsync args at the door.
Many "Devops" discussions, both at technical and at manager level, quickly turn to automation and tooling: on-demand environments, provisioning, monitoring, automated deployment etc. Job descriptions for "Devops engineers" are also heavily oriented towards technology. But Devops is about much more than technology! Are we losing track of the people and practices components that are critical, and often much harder to implement, than putting some new tech in place? Or have we learned that smart tech makes people and process changes unnecessary? We'll talk about whether we're really losing track of The Big Picture here, and, if so, discuss suggestions and approaches to tackle this issue.
Everyone knows that ITIL was to be the cure for every ailment, but did you know that the founder of ITIL, Dr. John Stewart, invented DevOps? Well, the terminology was different. It was not a method (Agile or otherwise). But the concepts within Version One, ‘Software Lifecycle Support,’ predates Version Three lifecycle guidance, and conveniently, established many of the ideas we now see in DevOps.
Although the development methods in the book might seem dated in one sense, the book is about designing services more efficiently and collaboratively so that the right people get the right service at the right time.
Attendees will learn to draw from the original publication in context to the latest approaches for working with Agile developers. Learn to gain buy-in that DevOps is a cultural change worth pursuing.
DevOps has proven itself across many smaller organizations but large enterprises are usually slow to change. It can be a daunting task even identifying where to make changes since there are so many processes and organizational silos to get in the way. As a veteran employee of small, medium, and large enterprises I have figured out ways to drive organizational change based upon getting results. In this presentation I will describe my methods for creating change within and across organizations and provide specific examples of how to begin a meaningful shift towards making DevOps a standard practice within your organization. I'll detail some of the roadblocks to making DevOps a reality and explain how to overcome these obstacles.
Taking operations folks who've never dealt with the "unique" challenges of hosting and managing hundreds of Ruby on Rails applications and getting them up to speed is fun. We can't prepare them for every scenario, but we've come up with a "sandbox" Rails app that can simulate the most common outages we see, giving the new DevOpsling a chance to attempt fixing it without impacting any customers. We'll share the SadOps application and show how we use vagrant and other tools to make it misbehave, and how it fits into our new employee training program.
Why are there a number of organizations that refuse to evaluate, or even consider, the implementation of DevOps? In the modern era of IT, there are two movements that are changing the way we handle everyday operations. The first is the Open Source movement, which deserves an entire discussion of it’s own; the second is the propagation of DevOps throughout the entire industry. Unfortunately, many veteran IT professionals push back against the concept of DevOps due to the fact that they fear it. Throughout the years, especially in the late 90’s and early 2000’s, Operations Engineers were valued by the softwares and/or platforms in which they were proficient. If you knew HP Openview, Tivoli, or Nagios well, you were basically guaranteed a job. However, many IT centric organizations grew tired of being told how to do business by vendors and wanted to significantly increase productivity, so they began to leverage open source products, as well as write their own solutions. These actions then enabled organizations to implement Continuous Delivery and code cycles that no one would have dreamed of 10 years ago. This created the need for a new way of doing operations: Enter DevOps! A large, but unfortunate, side effect is that now have an entire generation of Operations Engineers that are lagging behind the industry, and fear that the DevOps movement is going to push them out of the industry. Learn why they believe this, why this doesn’t have to happen, how to prevent it, and the steps to take to fill the ever-growing void of DevOps personnel in the industry.