Monthly Archives: October 2014

DevOps in the Duck Production Industry

Posted on by
1

This is a collaborative blog post written by attendees at DevOps Days Belgium 2014. As such, feel free to repost under a Creative Commons Attribution-NoDerivatives 4.0 license. Please retain this header as well.

release-the-quackin-memeIn my 25 years of experience in DevOps, there has never been such a defining movement as DevOps for Ducks. Devops for Ducks is showing up in Gartner’s magic quadrant for the first time this year.  Traditionally, the problem with Ducks are that they are fowl and are not goats. DevOps makes everything better. Even food.

But as we look at the production of quality Duck in the world we begin to understand that it is fundamentally broken. That’s where DevOps comes in. DevOps, has the power to change how we produce ducks in several environments. It allows people to collaborate on the Ducks. Zhang Chi Woo of China, creator of the Duck Production System – or DPS for short — has revolutionized not only Duck production, but the entire way the world thinks about Ducks.

Metrics and Duck Logs

When initially planning the pipeline for Duck production, you must take the “Duckly Metrics Factor” into consideration. As the “DMF” is defined, it will provide insight into the duck and allow you to make sure it is DevOps.

Most importantly, no one should forget that if it walks like a duck, and quacks like a Duck, then it is certainly a Duck, so we should define a metric for how our production Ducks are walking and quacking. Try Graphite. Ducks love it. There is even a collectd plugin available for duck egg incubation systems (well the only problem is all the native dependencies it pulls in).

The recently created DuckCare system closely monitors all the Ducks and can notify based on key log entries. If a Duck needs attention care workers are dispatched right away through DuckDuty.

Deployment Pipeline

Whereas before we often had to wait for eggs to hatch, a process which takes valuable productive time away from the duck producing units, we now foster a culture of continuous duck production. This way of working will inevitably lead to things that break. But that’s ok. We don’t point the finger at somebody who made a mess of dropping duck eggs in the kitchen. In the DevOps culture, we do a standup, avoiding the sticky part of the floor, and then we all get a mop, clean up and go release some more ducks in the water.

An important part of the DPS, is constant exercise of Duck functional testing at any stage of the producing unit, because we all value quality. With visual duck analytics we see that people in the industry are finally getting all their ducks in a row. As in many things, visualizing your work is important, and visual duck analytics allows this.

Cross Duck Collaboration

At “Duckly”, we’ve been using Flowduck to speak to Ducks on a daily basis. It replaced the previously used HangDucks (which is just mean), Hipduck (which was nice at the beginning), IRDucks (which eventually made the ducks radioactive), Duckfire (OI!) and Duckmail (which is way faster than snail mail of course).

Collaboration becomes hard when trying to control more than 2 or 3 teams producing Ducks on a daily/decadely basis. That’s why we wrote “Duckme”. Duckme (http://duckhub.com/duckly/duckmemore). is an open-source DevOps-is-everything tool. It provides an easy and accessible way to create “Duck Correspondants”. Those DC’s, are in charge of making sure DuckDevs and DuckOps talk to eachother (and to ducks). Duckme provides a DUCKLESS API for sending eDucks and altering Ducks.

Duck Culture

You don’t need culture to produce ducks (especially DevOps). A toxic culture will also work just fine. Make sure you put high pressure on the Ducks at all times.

Ducker

As part of these worldwide changes to the flow of Ducks, new tooling for Ducks has evolved. Ducker provides the containerization of Ducks through lightweight methods known as Rubber Duckies. While the technology for Rubber Duckies has been around for many years, Ducker makes Rubber Duckies easier to consume through technologies such as DuckerHub. Additionally, Ducker overcomes the limitations of traditional Duck Virtualization Platforms (DVP), and Duck Configuration Management (DCM) systems.

Ducks For Developers

To make duck development accessible to all (DevOps), we’ve developed Duckrant. Duckrant lets you spin up virtual ducks, provision them and destroy them once you’re done (The virtual ducks, not the ducks themselves, mind you. WE LOVE DUCKS! is our moto.)

http://duckhub.com/duckly/ducks/ contains an unimaginable amount of base ducks for you to experiment on (e.g. Duck with Chef, Duck with Ducker, Basic Ducks and the notorious Duck Quickstart.)

Duck Future

With the growing movement of DevOps for Ducks (initially started by Patrick Duckois), it’s important that we begin to think about the worldwide implications of the free flowing of ducks. With the great ducks come great responsibility, and that is the great challenge as we begin to think more about what we call DuckOps.

Wax On, Wax Off

Posted on by
3

“Wow, you’ve run an ultramarathon. That must have been hard.”

“Kinda, I guess.”

That’s often how the conversation goes when someone finds out I’ve run an ultramarathon (any race over 26.2 miles). It’s an interesting conversation because people are often fixated on the execution of a single event in my life. An event that lasts 7.5 hours over the course of one day. What people don’t say is, “Wow, you trained for six months, five days a week, in the cold and snow, spending 7-8 hours a week running, cross training a fewtimes a week in order to run that far at one time?”

People are often focused on the event, and not what it takes to get to the event. Society focuses on the next great shortcut to achieve something better, cheaper, faster. The thing many of us don’t want to recognize is that the tried and true method of achieving something is hard work and perseverance. You can’t effectively run a marathon or ultra without putting in the hard work of training. You must spend hours a week training. You must slowly build up your miles. You must not over train or else you will get hurt. Sure, there are different methods of training, such as Crossfit Endurance which focuses less on running and more on building endurance, but you still have to train. Anything else will result in failure.

I’m reminded of The Karate Kid (the 1984 original). Daniel was bullied and felt he needed to learn karate. He found Mr. Miyagi, who was willing to teach him. Mr. Miyagi sets Daniel to work painting his house, waxing his car, and staining his deck. Daniel doesn’t want to be a servant; he wants to learn karate! In his overanxiousness to learn, he confronts Mr Miyagi about doing all these chores. We end up finding out that Daniel was learning karate all along.

And now, like with everything, people want the shortcut to DevOps. They want the secret sauce that they need in order to transform their business and IT. They want the certification they can earn in a few hours of work to prove they can DevOps. They get frustrated when we tell them there is no easy path. They get frustrated when we tell them that they need to just start doing something, anything to start improving their work. As with the runner, you just have to start running to start training for a marathon.

We now have over five years of history in the DevOps movement. There is plenty of information available for “how to get started”, but the single most important thing a newcomer needs to realize is that it takes a curiosity, a desire to learn, and a willingness to listen to other people that might be different than you. As Aneel Lakhani said in his below ignite talk, “…the single strongest signal that we have something to learn is the fact that a difference exists.”

And there’s the rub with the “classification of DevOps” that people are undertaking. This classification seeks to alienate groups because differences exist, not unite them because they have something to learn from each other. After reading the latest post on the subject, a friend tweeted about going through those exact same things in a 100 person company right now. If enterprises solve problems in their own little world of DevOps, how do we ensure that this knowledge flows down to the “non-enterprise” DevOps practitioner? This stratification divides us rather than unites us.

When we willfully disregard core tenets of the movement, such as Collaboration and Sharing, we are essentially back to where we’ve always been, and no one moves forward. That is why hearing the stories coming out of the DevOps Enterprise Summit is encouraging. Large companies are opening up and telling their stories of transformation. Large companies are proving that the ideas of DevOps work, no matter your size.