What is best in life?

One of my favorite movies from my childhood was Conan the Barbarian. That movie has a scene where Conan is asked, "What is best in life?" 

Not sure the outcome of Conan's philosophy is congruent with a sustainable business model but it makes great theater!

Yesterday I participated in a roundtable discussion with my companies new CEO. It was a chance for him to get to know employees and get first hand feedback. He also used that forum to pitch his vision. He made the convincing argument that what our customers really want is a wonderful experience. The reason why people go to Disneyland, loyally shop at a particular store, Facebook, etc. is because of the experience they have. People want particular goods or services. But they crave having a unique and rewarding experience. That gave me a new perspective on how I judge my work. Does what I do on a day to day basis contribute to or detract from an excellent customer experience? Does what I do on a day to day basis contribute to what is best in the lives of our customers?

Continuous Delivery at Ancestry.com

I work for an organization whose main product resides in the “monolith, over-the-wall, deploy once a quarter” world. We are in the process of migrating to the “SaaS, Dev/Ops, CD” world. This migration has proven non-trivial to say the least. Ancestry.com recently completed a similar process which is detailed here http://www.youtube.com/watch?v=DoSrsjimXjE. I found the presentation to be very informative and decided to blog about key learning’s I had. Hope you will find them useful as well. (The slides are a bit ahead of the audio).

The first ~16 minutes is a review of Opscode Private Chef. I’ve used Chef and it’s an excellent tool. But I’m going to focus on the challenges and learning regarding the migration from one set of practices to another. There is a lot of good stuff in the Opscode portion (“infrastructure is code”).

Ancestry’s definition…“Continuous Deliver is reliably releasing high quality software fast through automated build, test, configuration and deployment.” Fast is critical because they want to increase the rate they can deliver value to the customer. You will see this theme repeated during the presentation. http://www.youtube.com/watch?v=DoSrsjimXjE&t=17m3s

Key benefits of CD: Increase flow of value to customer, Increase feedback rate, Lower risk due to smaller batch sizes. http://www.youtube.com/watch?v=DoSrsjimXjE&t=18m1s

“Doing CD right means being agile, not just doing Agile.” I call this ‘what’s right, not who’s right.’ http://www.youtube.com/watch?v=DoSrsjimXjE&t=18m39s

CD eliminates “Emergency” deployments and all the bureaucratic rigidness it entails. http://www.youtube.com/watch?v=DoSrsjimXjE&t=26m17s

"Ultimately, what [CD] enabled, it enabled the development teams to own their services and applications from cradle to grave." (Emphasis added) http://www.youtube.com/watch?v=DoSrsjimXjE&t=26m58s

"Because the infrastructure was working on [the developers] behalf, they were able to focus on the service itself, and focus on owning that, and providing what the customer really needs and wants." (Emphasis added) http://www.youtube.com/watch?v=DoSrsjimXjE&t=27m06s

“Extending Agile into the enterprise put pressure on ops to change their methods and practices too.” We are lucky here as our Ops team is already (trying) to work under the Agile model. Getting better at it, too! http://www.youtube.com/watch?v=DoSrsjimXjE&t=27m57s

“Engineering Productivity” The bridge between ops and dev.  EP consists of AppOps, CD Tools and Test Infrastructure teams. EP’s mission is to accelerate development. There is a need for a third group to act as a buffer between Ops and Development. At ancestry this group does a lot of the Opscode Chef work. Our organization is attempting to have ops file both the operations role and the AppOps role with mixed results. http://www.youtube.com/watch?v=DoSrsjimXjE&t=31m15s

“Adopt a service model that enables development to do what they need quickly and easily, getting infrastructure out of the way. Rule #1: Developers don’t want to mess with or own ops infrastructure. Rule #2, If you don’t provide infrastructure and services to enable Rule #1, then developers break Rule #1.” The key to having these two rules obeyed is a CD platform (SaaS). http://www.youtube.com/watch?v=DoSrsjimXjE&t=32m40s

"Store your infrastructure code in source control." Enough said. http://www.youtube.com/watch?v=DoSrsjimXjE&t=35ms20

You can’t do CD without automated configuration and automated deployment. Ancestry uses Opscode Chef for both. Not having those automated tools makes you slow. Slow means you’re not doing CD. http://www.youtube.com/watch?v=DoSrsjimXjE&t=37m50s

All new services are configured with a fully provisioned CD pipeline, from build through production. Not the other way around. http://www.youtube.com/watch?v=DoSrsjimXjE&t=39m50s

"Deployment is monitored and overseen by the team itself." Clearly the development teams have accountability for production systems. They don’t go into exactly how that is done, unfortunately. My guess is that development has responsibility for a portion of production monitoring. http://www.youtube.com/watch?v=DoSrsjimXjE&t=47m54s

There it is. The entire presentation is well worth the time if you are doing CD and Dev/Ops and is highly recommended.

About

Welcome to Melting Pot Ops! You're probably wondering what this is all about, let me try to tell you.


We're a team of eight Systems Administrators/Operators/System Managers. We come from a variety of technical backgrounds, and have varying levels of experience. But that's not really where the melting pot bit comes in — we're trying to bridge the gaps between traditional operations and DevOps, between old-school sys-admins and infrastructure as a service, between hand-built and maintained systems and automated configuration, between waterfall planning and agile processes.

We try to think a little differently. We want to explore new ideas and new ways of doing things. Mostly though, we want to provide rock solid infrastructure, monitoring, and service management to our dev teams and to our end users.

As you read Melting Pot Ops, you might see:

• Reviews of books, courseware, hardware, and software that we've really liked.
• Experience reports for things we've tried (both successes and failures).
• Recaps of presentations we've made in house and at conferences.
• Random other stuff as needed — we'll try to stay away from lolcats though.

One of the reasons we decided to start this blog, and that our management decided to approve it, was to get feedback from the big blue room outside our cubicles and data centers. Please feel free to drop a comment or two as you read. We hope this becomes a conversation.

Thanks for coming by to visit. We hope you like what you read and come back often.