DevOps at IBM – The Goat Farm – Episode 9

How does IBM manage to run web sites for some the World’s largest sporting and television events? With the practices of DevOps of course! In this episode, Ross and Michael talk to Brian O’Connell of IBM.

Brian tells us of his journey to DevOps practices through stumbling onto the ideas of Chef and Infrastructure as Code. We talk about the cultural shift required when it comes to who owns delivery of changes and ownership of those changes. Brian also tells us how they leverage the “build, measure, learn” product development loop.

The sites Brian and team help run are some of the more high profile, and highly visited sites in the world. Brian talks about the challenges when trying to introduce DevOps to such high profile sites, and mistakes that were made along the way. We also talk about some of the tooling Brian and team use, and how they effectively deploy enterprise software packages.

Download MP3 – iTunesStitcherRSS

Show notes:


Brian O’Connell – TwitterLinkedInBrian O'Connell

Brian O’Connell is a Senior Technical Staff Member at IBM that leads a team focused on DevOps, predictive analytics, big data, and cloud technologies.

Brian joined IBM in 2001, starting as a software engineer. He built many software systems to support the continuous availability and events infrastructure.  His expertise includes architecting and developing scalable server applications, concurrency, advanced visualizations, and big data.

From 2007 until 2011 Brian was the lead infrastructure technology advocate and designer for the World Wide Sponsorship Marketing (WWSM) client. His role included strategic technical direction, evaluating technology pilots and the end to end delivery of highly visible web events. In that role, he successfully delivered all IBM sponsorship web sites including The Masters, Wimbledon, Roland Garros (French Open), US Open Tennis, US Open Golf, Australian Open, and The Tony Awards. Brian designed systems to manage the infrastructure and applications used by the client including a focus on defining plans, strategies and architectures for the installation, operation, migration and management of complex information systems.
Brian has had more than 250 patents issued, is an IBM designated Master Inventor and a Franz Edelman laureate.

Adrian Cockcroft of Battery Ventures – The Goat Farm – Episode 8

In this episode we talk to the famous (or infamous) Adrian Cockcroft of Battery Ventures. Adrian is known for his work at Netflix and his work to migrate them to a Cloud first strategy, then before that for his book on Sun performance tuning.

Adrian has been doing a lot of work talking to CIOs of large enterprises and helping them understand where ideas such as DevOps, microservices, Cloud are taking the industry. He allows tells us how he is helping CIOs realize how their IT organizations must transform to adopt these new ideas. This episode is all about how the horses are growing horns to become the unicorns.

(Editor’s note: We are really sorry about the audio on this episode. Adrian was in Portland, Michael was in Amsterdam, and Ross was in Minneapolis. While we could have cut a bunch of the bad audio, the content was so good we didn’t want to drop anything. Apologies.)

Download MP3 – iTunesStitcherRSS


Show Notes


Adrian Cockcroft – LinkedInTwitter

Adrian Cockcroft has had a long career working at the leading edge of technology. He’s always been fascinated by what comes next, and he writes and speaks extensively on a range of subjects. At Battery, he advises the firm and its portfolio companies about technology issues and also assists with deal sourcing and due diligence.

Before joining Battery, Adrian helped lead Netflix’s migration to a large scale, highly available public-cloud architecture and the open sourcing of the cloud-native NetflixOSS platform. Prior to that at Netflix he managed a team working on personalization algorithms and service-oriented refactoring.

Adrian was a founding member of eBay Research Labs, developing advanced mobile applications and even building his own homebrew phone, years before iPhone and Android launched. As a distinguished engineer at Sun Microsystems he wrote the best-selling “Sun Performance and Tuning” book and was chief architect for High Performance Technical Computing.

Taylorism, Hating Agile, and DevOps at CSG – The Goat Farm – Epsiode 4

It’s time for another episode of The Goat Farm. On this episode Ross and I talk about: Why do Managers Hate Agile?Taylorism, hiring and the problems with specialization, and we chat with Scott Prugh about his experiences with DevOps at CSG.

We also touch on the idea of running internal conferences to help spread the word of new technologies within the company, and Ross shares his excitement over the wildly successful DevOps Days at Target. Stay tuned for an upcoming episode where we will talk more about running your own events.

Download MP3 – iTunesStitcherRSS

Guest Info:

Scott Prugh, Chief Architect – TwitterLinkedIn

Scott is responsible for the overall Platform Architecture and Development in North American Cable. Scott led the architecture teams in developing many of CSG’s next generation assets including Product Configurator and Order Capture.  Scott has been instrumental in leading change at CSG implementing Lean, Agile and DevOps practices.  These changes have resulted in 90% reductions in release impact. Scott is a Lean Practitioner and certified as a Scaled Agile Framework Program Consultant. Previously, Scott was CTO of Telution and built the core runtime and billing architecture for the COMx product suite.

Here is Scott’s talk at the DevOps Enterprise Summit 2014

 

We don’t need no manifesto…

“If you don’t eat your meat, you can’t have any pudding. How can you have any pudding if you don’t eat your meat?” –Voltaire

3229643937_13bddcbf8e_oRecently there was a post on O’Reilly Radar that cited an “identity crisis” in the world of DevOps. The post called out a number of issues: namely that there are cliques in DevOps, there is nothing new in DevOps, and there is no product messaging and positioning in the world of DevOps. It ended with the call for DevOps to define itself through a manifesto, similar to the Agile Manifesto or maybe even The Cathedral and the Bazaar.

There has long been a desire to “define DevOps”. Every few months a blog post pops up that says, “Define It,” and goes on to slam the “Knights Templar of DevOps” for holding on so close to the lack of a definition. What many of these “revolutionaries” are not aware of is that the need to define DevOps has already been addressed. The de facto definition exists on Wikipedia, and it was agreed upon by the “Knights” that Wikipedia would hold the definition. This allows the definition to evolve and change over time as the industry evolves and changes. (At this point I should mention that there are no “Knights Templar of DevOps.”)

This also prevents one person or company from being the “definer of DevOps.” It gives ownership of the definition to the community. Compare that with something like ITIL, where the definitions are owned by a company and haven’t evolved much since 2007.

The definition on Wikipedia also gives guide rails for individuals and companies to work inside. If a manifesto is needed, the manifesto is up to the individual organizations that wish to transform themselves. A one-size-fits-all manifesto, as some have asked for, really isn’t effective. Each organization is different, and the guide rails give you the guidance needed to define what works best for your organization.

The DevOps Community has seen tremendous growth over the last several years. 2013 and 2014 were defining years for the community. Looking at the growth of DevOps Days, there is a clear inflection point in 2013 that shows tremendous growth in the conference series.

Screen Shot 2015-01-15 at 7.38.18 PM

Having participated in 9 DevOps Days events myself, I can attest to the fact that the growth of the community is nothing short of phenomenal. At many of these conferences I have attended, over 70% of the attendees were new to the DevOps community. Other DevOps conferences have also popped up, such as Camp DevOps and DevOps Enterprise Summit. Couple this with many conferences now having DevOps specific tracks, and I ask, “What cliquey echo chamber?”

And speaking of the DevOps Enterprise Summit, if DevOps is so poorly defined, ambiguous, and amorphous, how can there be an entire conference focusing solely on success stories of large Enterprises? The last thing enterprises want to implement is something that is untested and unproven. Yet somehow many have begun a DevOps journey and have been successful at it.

DevOps is a cultural and professional movement. It is not a product, solution, or something you can buy off the shelf. As such, it’s rather obvious that there wouldn’t a product messaging or marketing positioning. Product and marketing positioning is obviously important when you are  tryingto sell something. It is irrelevant in the context of a community oriented movement focused on transformation.

One of the most  fascinating changes I have seen over the years in technology is the interest in other areas outside of technology. When you look at transformation, it’s important to look outside of the bubble that you live in for ideas of how to change. Yes, DevOps is often focused on ideas that have been discussed at length in other circles. That is a refreshing change in some circles of tech that think that they are the end-all be-all of significant ideas. “Nobody can teach me how to do this better,” was a common refrain when I entered the IT industry, and it still is today. When I did my MBA, the most amazing experience was learning something outside of technology, and thinking about how I could take this learning and make our industry better. Looking outside, learning, and bringing that knowledge back into the community is a defining feature of DevOps.

While the original post makes some interesting points, it seems to be proposing solutions to problems that don’t exist. In some cases, these supposed problems are defining features of the movement (lack of a firm manifesto; no product definition; old wine, new skin.) which has built a vibrant and effective community that is fundamentally transforming the way companies do IT, in spite of any challenges it faces as a growing movement.

Every synthesis of old ideas and new approaches makes some people uncomfortable and others skeptical. Results are what drive adoption, and the results from a DevOps practice are well-documented at this point. Instead of seeing challenges and hoping for a central authority to solve them, let’s continue on the path of sharing our best ideas with one another and constantly improving.

Thanks to Pete Cheslock, Bridget Kromhout, Stathy Touloumis, and George Miranda for the feedback on this post.

Get Your Head Out of Your aaS

3815168722_faee10cf62_bI’ve been floating between the worlds of Cloud and DevOps for a while now and it is interesting to see the Cloud world finally start to realize the real value is in DevOps. It’s great that more people are starting to pay attention to this cultural and professional movement. What is not great is how the Cloud experts tend to get wrapped up in some debates that are trivial and meaningless, in the larger scheme of things. Take for instance two persistent debates I am seeing over IaaS vs. PaaS, and then which PaaS is better. I hate to be the one to break it to these camps, but it doesn’t matter; at the end of the day you are selling plumbing fixtures that crap flows through.

To understand what I mean, lets take a step back. In 2008, I started pursuing my MBA at The Ohio State University. One of the core requirements of the degree was Operations Management. In Operations Management, you learn manufacturing optimization through ideas such as Lean and Six Sigma. The book “Learning to See” was part of the course material and it focused on optimization of manufacturing processes through visualization, also known as Value Stream Mapping. As the course progressed, I had a personal epiphany. As we kept walking through manufacturing processes, and Value Streams, what I quickly realized was that the work we did in IT was all about manufacturing a good or service someone would be consuming. Automation in the IT world is about (or should be about) optimizing these Value Streams and (hopefully) eliminating waste from the system. My Operations Management course really taught me to see (pun intended) and to think differently about how we worked in IT.

I took this new found knowledge back to my work where it was summarily ignored by my boss and coworkers, and lacking support I shelved my ideas. Little did I know many of the Lean principals I had learned would be at the forefront of how IT is changing today, and was already being changed at that time in 2008, I just didn’t know it.

When somebody asks me what DevOps is, I often respond with the simple idea that “DevOps is about increasing the flow of work through IT.” I borrow this idea heavily from “The Phoenix Project“, but I find it is the most simplest way to capture the essence of this cultural and Imageprofessional movement. And that is where Value Stream Mapping and the ideas of Lean come into the conversation. Books like the “The Phoenix Project“, and notable DevOps contributors such as John Willis expound the values of these techniques to optimize the IT Manufacturing chain, be it Development work or Operations work.

Value Stream Maps are relatively simple. They identify the flow of a raw material through Screen Shot 2014-04-03 at 11.07.33 PMvarious processes that add value. They also identify areas of waste in the system, and they help in building the Future State Map, or the Value Stream that you want to achieve in the future after optimizing the system. The most basic and valuable thing about Value Stream Maps is how they allow you to easily visualize your work, and once it is visualized it is easy to understand and optimize.

If you look at the first current state map, you can easily see how relabeling the boxes to reflect common IT tasks, say in a server build process, makes this a powerful tool for IT. Replace the box names with another process – maybe code build, testing, and release – and you see once again how Value Stream Mapping is a key tool in fixing our broken IT.

Now that we’ve established a method for the optimization of our IT processes, let’s go back to thinking about Cloud and the debates around Iaas, PaaS, and the PaaS vendors. Take the second Value Stream Map. Say this diagram more accurately reflected server builds and the time it took to install an OS was one hour. We optimize this process through our IaaS based Cloud, public or private, and get the time down to 5 minutes. That is awesome, we’ve saved 55 minutes and really optimized that process. Go team!

If “premature optimization is the root of all evil”, then local optimization is the Devil’s half brother. In the above example we saved 55 minutes, but the total time of work flowing through the system is still 67 days, 23 hours. And that is where we come back to Cloud. IaaS is a local optimization. It is great, it is awesome, but it is a very small piece of the puzzle. PaaS is another local optimization, but instead of optimizing one process it optimizes three or four. Which is great, but many IT organizations are going to “adopt Cloud for business agility and speed, then be sadly surprised when their local optimization does little to fix their screwed up system. Cloud can be a great enabler, but it is only a small piece of the larger system. It is high time more of us focus on the larger system.