Skip to content

A good metric for noisy neighbor identification is high CPU steal. Some references:

State is when everything gets complicated. For [Camille] Fournier, one of the important aspects to think about when building distributed systems is where you care about coherent and consistent state, parts where you don’t want to lose data or have people seeing different state. For these parts she generally favours using transactions and a traditional relational database. One example is order handling, in which you want to make sure that you will be able to fulfil all orders. In other parts you may care less about consistency and it’s not a problem if people see slightly stale data, or you can lose data, because it can easily be recreated. Here Fournier thinks NoSQL-databases are perfectly usable.

--Jan Stenberg

Experiences Working with Real World Distributed Systems

 

In this first post of a series exploring containerized CI solutions, I’m going to be addressing the CI tool with the largest market share in the space: Jenkins. Whether you’re already running Jenkins in a more traditional virtualized or bare metal environment, or if you’re using another CI tool entirely, I hope to show you […]

via Containerized CI Solutions in AWS – Part 1: Jenkins in ECS — Stelligent

The latest AWS Security Whitepaper, dated June, 2016, shows changes in AWS's adherence to standards associated with compliance. Some older, superseded standards were dropped with replacements. Also, some new standards were added.

Here is a summary, with "-" indicating removal and "+" indicating addition:

In this highly recommended episode of DevOps Cafe, John Willis interviews Damon Edwards about his #DOES15 presentation, "DevOps Kaizen: Practical Steps to Start & Sustain a Transformation".

YouTube video of the DOES15 presentation. Slideshare deck.

A few takeaways:

  • High performing companies are different because they have the ability to improve by learning fast
  • Plan, Do Study, Act and Observe, Orient, Decide, Act are important variant descriptions of feedback loop techniques
  • Organizations are unable to improve because:
    • knowledge work isn't visible as it would be on a factory floor. It's locked in people's minds.
    • people don't understand the whole process for developing and delivering a feature, but only their own, limited context
    • "silo effects" act to keep organizations from understanding how to optimize to develop solutions for business goals. Everyone stays within their own limited scope.
  • Organizations often have a "big bang" transformation dream. Generally through, after some initial improvement, the magnitude of the required effort leads to fear, then panic. The initial goal is aborted and victory is declared after a few small improvements.
  • Instead of big bang approaches, decompose the effort into smaller, achievable goals, even micro goals, that build confidence with success.
  • Develop an organizational wide focus on service delivery metrics:
    • duration and predictability of lead time from inception to delivery
    • mean time to detect issues
    • mean time to repair issues
    • focus on quality at the source to minimize rework
  • Use a graphical representation to retrospectively describe a project. By doing so you will understand interactions across the organization to deliver a concept to a customer facing reality.
  • The retrospective analysis provides a horizontal description, across "silos," rather than focusing on each organizational component in isolation. Identify wastes, inefficiencies, and bottlenecks. Also, identify where "heroic" intervention is needed, since it's a constraint that can't be counted on. Then identify countermeasures.
  • Use improvement story boards focusing on:
    • targets,
    • improvement metrics,
    • work to be done,
    • current status,
    • blockers
  • The kaizen continuous improvement process can be an overlay for any delivery methodology

I'd consider watching the Youtube video, then listening to the podcast. Great content.