Come Talk to Us at Velocity & DevOpsDays
It’s that time of year — we’re headed down to sunny California for Velocity Conf and DevOpsDays. Join us at Velocity this year for some can’t-miss culture talks and a rollicking good time at Booth #519.
It’s that time of year — we’re headed down to sunny California for Velocity Conf and DevOpsDays. Join us at Velocity this year for some can’t-miss culture talks and a rollicking good time at Booth #519.
It was time for the small company I worked for to pick new content tools, and we were in a meeting to hear from the project lead.
She gave a great talk, explaining the benefits and tradeoffs of each tool. Her slides had cat pictures. She was funny and self-deprecating. But the Q&A afterward was tense. The underlying note of each comment was, “I don’t mind change as long as it’s happening to anybody else.”
Afterward, we joked about the meeting.
“It’s hard,” she said. “People like their tools, and you’ve got to tell them they might have to change something, and …”
“Nerd rage,” I finished for her.
“Right. Nerd rage.”
Does anyone in IT make $100,000 — or more? Data gathered for our 2013 State of DevOps Report, published in partnership with IT Revolution Press, indicate that you’re far more likely to make $100,000 to $150,000 per year at companies that recognize the value of DevOps.
If you choose to learn and focus on DevOps practices, you’ll be right in line with a major trend in system administration. You’ll be part of the growing band that knows IT is at its best when it’s an integral part of business strategy – not when it’s relegated to the role of supporting player.
Becoming a highly valued member of a DevOps organization is not as simple as getting facile with more languages and tools — though these skills certainly help. Nor is it about checking off boxes to get management off your back. It’s about engaging fully in the business strategy,
listening to the needs of both internal and external customers, and coming up with technical solutions that answer those needs. Do this for a few years, and your expertise will have management coming to you for guidance and advice.
Demand for people with DevOps skills is growing rapidly because businesses get great results from DevOps.
Organizations using DevOps practices are overwhelmingly high-functioning: They deploy code up to 30 times more frequently than their competitors, and 50 percent fewer of their deployments fail, according to our 2013 State of DevOps survey.
With all this goodness, you’d think there were lots of DevOps engineers out there. However, just 18 percent of our survey respondents said someone in their organization actually had this title.
Why is that?
Release management best practices have evolved over time as software tools that manage and automate parts of the process appear. As a result, established structures are ever changing. An example of this is a 2007 piece on Buildmeister about best practices that were inspired by ITIL, the ISO standard IT Infrastructure Library.
We go to a lot of events. No, really, we go to a lot of events, and take it from us, DevOpsDays is one of the very best. It’s a chance to share and learn about making systems that run smoother, faster and more intelligently – and improve our lives, too.
This year, we’re sponsoring DevOpsDays Austin, held April 30 and May 1 at The Marchesa. Both days are filled with sessions you’re sure to find valuable. A couple of highlights:
May 1, 9:15 AM: Patrick DeBois, organizer of DevOpsDays, will talk about the future of DevOps. Hint of what’s to come in this tweet.
May 1, 9:35 AM: Gene Kim, champion of DevOps and assiduous studier of high-performing IT organizations, offers his perspective on “How Do We Better Sell DevOps?”
Come visit us at our sponsor table, where we’ll have plenty on hand for you. Pick up a copy of our 2013 State of DevOps Report - you’ll find all kinds of interesting facts about how DevOps practices make organizations more efficient. Ask us for a Puppet Enterprise demo. Don one of our famous t-shirts. Or just hang out and chat about all things DevOps and Puppet.
Speaking of Puppet, we’re holding an entire day of Puppet content at PuppetCamp Austin on April 29, right before DevOpsDays. We invite you to register.
There is a fascinating article in a recent Ars Technica on why Facebook creates its own hardware and how it avoids virtualization on its servers. Facebook just unveiled its first data center that has only its own custom hardware, designed per the Facebook-founded Open Compute Project. Facebook answers the “What is virtualization” question by saying, “Something we here at Facebook don’t need.”
Second of two parts. Written by Max Martin. Originally published on Linux.com, republished with permission.
In the first part of this tutorial, we showed how to use Vagrant to automate and manage local virtual machines for a software development environment. We defined a simple Vagrantfile to specify certain attributes for a VM to run a simple web app, and got it running using Vagrant’s command line tools. In this part of the tutorial, we’ll be using Puppet to define and automate the configuration details for our VM. This way, whenever we start up the dev environment with vagrant up, it will be set up to run our web application without any additional manual configuration.
I found Damon Edwards and Anthony Shortland’s video presentation on DevOps a refreshing change. They see DevOps as a larger, more comprehensive service delivery platform and view the DevOps toolchain as the practical way to make that service delivery platform work. Their excellent diagram divides a service delivery platform for DevOps into four quadrants, with Infrastructure and Applications on the Y axis and Build and Deploy on the X axis.
First of two parts. Written by Max Martin. Originally published on Linux.com, republished with permission.
Setting up a development environment for a web application can seem simple—just use SQLite and WEBrick or a similar development server—but taking shortcuts can quickly lead to problems. What happens when you need to onboard new team members? What if your team members are geographically distributed? How do you prevent bugs from creeping in when the production environment’s configuration drifts away from the development environment? Even if you’ve managed to set up a picture-perfect development environment, what happens when a developer inevitably breaks its configuration?