Brian Anderson
Plan to learn faster
See your product's big picture and streamline experimentation with user story mapping.
Download a free copy of Building an Optimized Business, a curated collection of chapters from the O’Reilly Web Operations and Performance library. This post is an excerpt by Jeff Patton from User Story Mapping, one of the selections included in the curated collection.
This is my friend Eric, standing in front of his backlog and task board in his team room. He’s a product owner working hard with his team to build a successful product, but right now it’s not. That doesn’t worry Eric, though. He has a strategy for making his product successful. And so far it’s working.
Eric works for a company called Liquidnet. Liquidnet is a global trading network for institutional investors. Long before Eric came to stand in front of the board in the picture, someone at his company identified a group of customers Liquidnet could serve better, along with a few ideas of how to do that. Eric is part of a team that took those ideas and ran with them. That’s what product owners do. If you thought they were always acting on their own great ideas, well, you’re wrong. One of the hard parts of being a product owner is taking ownership of someone else’s idea and helping to make it successful, or proving that it isn’t likely to be. The best product owners, like Eric, help their entire team take ownership of the product.
Applied DevOps and the potential of Docker
The cultural impact within a software engineering organization can be dramatic.
Editor’s note: this post is from Karl Matthias and Sean P. Kane, authors of “Docker Up & Running,” a guide to quickly learn how to use Docker to create packaged images for easy management, testing, and deployment of software.
At the Python Developers Conference in Santa Clara, California, on March 15th, 2013, with no pre-announcement and little fanfare, Solomon Hykes, the founder and CEO of dotCloud, gave a 5-minute lightning talk where he first introduced the world to a brand new tool for Linux called Docker. It was a response to the hardships of shipping software at scale in a fast-paced world, and takes an approach that makes it easy to map organizational processes to the principles of DevOps.
The capabilities of the typical software engineering company have often not kept pace with the quickly evolving expectations of the average technology user. Users today expect fast, reliable systems with continuous improvements, ease of use, and broad integrations. Many in the industry see the principles of DevOps as a giant leap toward building organizations that meet the challenges of delivering high quality software in today’s market. Docker is aimed at these challenges.
Deploy Continuous Improvement
Balancing the work it takes to improve capability against delivery work that provides value to customers.
Download
Building an Optimized Business
Download a free copy of Building an Optimized Business, a curated collection of chapters from the O’Reilly Web Operations and Performance library. This post is an excerpt by Jez Humble, Joanne Molesky, and Barry O’Reilly from Lean Enterprise, one of the selections included in the curated collection.
In most enterprises, there is a distinction between the people who build and run software systems (often referred to as “IT”) and those who decide what the software should do and make the investment decisions (often called “the business”). These names are relics of a bygone age in which IT was considered a cost necessary to improve efficiencies of the business, not a creator of value for external customers by building products and services. These names and the functional separation have stuck in many organizations (as has the relationship between them, and the mindset that often goes with the relationship). Ultimately, we aim to remove this distinction. In high-performance organizations today, people who design, build, and run software-based products are an integral part of business; they are given — and accept — responsibility for customer outcomes. But getting to this state is hard, and it’s all too easy to slip back into the old ways of doing things.
From Industrialism to Post-Industrialism
Leveraging the power of emergence to balance flexibility with coherency.
Download
Building an Optimized Business
Download a free copy of Building an Optimized Business, a curated collection of chapters from the O’Reilly Web Operations and Performance library. This post is an excerpt by Jeff Sussna from Designing Delivery, one of the selections included in the curated collection.
In 1973, Daniel Bell published a book called “The Coming of Post-Industrial Society”. In it, he posited a seismic shift away from industrialism towards a new socioeconomic structure which he named ‘post-industrialism’. Bell identified four key transformations that he believed would characterize the emergence of post-industrial society:
- Service would replace products as the primary driver of economic activity
- Work would rely on knowledge and creativity rather than bureaucracy or manual labor
- Corporations, which had previously strived for stability and continuity, would discover change and innovation as their underlying purpose
- These three transformations would all depend on the pervasive infusion of computerization into business and daily life
If Bell’s description of the transition from industrialism to post-industrialism sounds eerily familiar, it should. We are just now living through its fruition. Every day we hear proclamations touting the arrival of the service economy. Service sector employment has outstripped product sector employment throughout the developed world. 1
Companies are recognizing the importance of the customer experience. Drinking coffee has become as much about the bar and the barista as about the coffee itself. Owning a car has become as much about having it serviced as about driving it. New disciplines such as service design are emerging that use design techniques to improve customer satisfaction throughout the service experience.
The Puppet design philosophy
Explore the declarative, idempotent, and stateless Puppet DSL.
Before we begin to explore practical best practices with Puppet, it’s valuable to understand the reasoning behind these recommendations.
Puppet can be somewhat alien to technologists who have a background in automation scripting. Where most of our scripts are procedural, Puppet is declarative. While a declarative language has many major advantages for configuration management, it does impose some interesting restrictions on the approaches we use to solve common problems.
Although Puppet’s design philosophy may not be the most exciting topic to begin this book, it drives many of the practices in the coming chapters. Understanding that philosophy will help contextualize many of the recommendations covered.
How to create a Swarm cluster with Docker
Using Docker Machine to create a Swarm cluster across cloud providers.
Problem
You understand how to create a Swarm cluster manually (see Recipe 7.3), but you would like to create one with nodes in multiple public Cloud Providers and keep the UX experience of the local Docker CLI.
Solution
Use Docker Machine to start Docker hosts in several Cloud providers and bootstrap them automatically to create a swarm cluster.