Astrid Atkinson talks about what it means to manage distributed systems over long periods of time. She says she starts by thinking about the team, not the system. “Good teams and people are precious...building a good team is really difficult, a huge investment,” she notes. “Your job as an engineer is to make sure that adding scale doesn’t mean adding people.”
Achieve performance goals in the face of compliance issues.
Download a free copy of Compliance at Speed, an O’Reilly report by Mark Lustig that breaks down the IT issues facing finance, healthcare, and other heavily regulated industries.
Today’s technology should work and perform without issues. When we build systems that work and perform, nobody pays attention; when they’re slow and unstable, everyone notices. This sentiment was no truer than during last year’s Healthcare.gov debacle. Building systems that work and meet our user’s expectations is always the number one priority.
Regardless of who we work for, the challenges of performance and DevOps are universal. There is one constraint larger companies seem to face more often — regulatory compliance. As privacy concerns have become more pervasive, compliance affects all of our companies in one way or another.
Reputation is based on trust. If I’m looking up my credit card balance and I end up seeing someone else’s information, I’ve lost trust in the credit card company, and they’ve lost a customer.
Large banks and health care organizations have been dealing with compliance for years, but every industry has constraints. Online retailers need to meet privacy and security standards. The social networking industry faces regulations specific to consumer protection and the use of customer information. No industry is immune to meeting compliance, as emerging regulations, both domestic and international, create more challenges to achieving performance objectives each year. Any website that uses, stores, or processes personal or payment information must address these challenges.
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.
Why you should stop managing infrastructure and start really programming it.
Immutable infrastructure (II) provides stability, efficiency, and fidelity to your applications through automation and the use of successful patterns from programming. No rigorous or standardized definition of immutable infrastructure exists yet, but the basic idea is that you create and operate your infrastructure using the programming concept of immutability: once you instantiate something, you never change it. Instead, you replace it with another instance to make changes or ensure proper behavior.
Chad Fowler coined the term “immutable infrastructure” in a 2013 blog post, “Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components,” but others have spoken about similar ideas. Martin Fowler described phoenix servers in 2012. Greg Orzell, James Carr, Kief Morris, and Ben Butler-Cole, to name a few, have contributed significant thought and work as well.
II requires full automation of your runtime environment. This is only possible in compute environments that have an API over all aspects of configuration and monitoring. Therefore, II can be fully realized only in true cloud environments. It is possible to realize some benefits of II with partial implementations, but the true benefits of efficiency and resiliency are realized with thorough implementation.
As developers and designers converge, we're seeing an increased focus on the user's perspective.
Editor’s note: The O’Reilly Velocity Conference in Santa Clara was held last week. The event explored the essential trends driving web operations and performance forward. In the post that follows, Mark Zeman digs into recent changes he’s observed in one aspect of Velocity: the role, language, and metrics surrounding user experience.
I’ve attended four O’Reilly Velocity conferences over the last year, and I was struck by a notable shift in the conversations at Velocity in Santa Clara, Calif. Many speakers and attendees have started to change their language and describe the experience of their websites and apps from the user’s perspective.
The balance has shifted from just talking about how fast or reliable a particular system is to the overall experience a user has when they interact with and experience a product. Many people are now looking at themselves from the outside in and developing more empathy for their users. The words “user” and “user experience” were mentioned again and again by speakers.
Here are recent talks from Velocity and other events that highlight this shift to UX concerns. Read more…
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.
Tending the DevOps victory garden.
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 J. Paul Reed from DevOps in Practice, one of the selections included in the curated collection.
Any discussion surrounding DevOps and its methodologies quickly comes to the often delicate issue of organizational dynamics and culture, at least if it’s an accurate treatment of the topic. There is often a tendency to downplay or gloss over these issues precisely because culture is thought of as a “squishy” thing, difficult to shape and change, and in some cases, to even address directly. But it doesn’t need to be this way.
Sam Hogenson, Vice President of Technology at Nordstrom, works hard to make sure it’s exactly the opposite: “At Nordstrom, we value these different experiences and we value the core of how you work, how you build relationships much more than whether or not you have subject matter expertise. It’s a successful formula.” Another part of that formula, Hogenson notes, is the ethos of the organization: “It’s a very empowered workforce, a very decentralized organization; I always remember the Nordstroms telling us ‘Treat this as if it were your name over the door: how would you run your business and take care of your customers?'” [Nordstrom infrastructure engineer Doug] Ireton described it as a “have-coffee culture: if you need to talk to someone, you go have coffee with them.”