Get Started for FREE
Sign up with Facebook Sign up with X
I don't have a Facebook or a X account
 Your new post is loading...
Your new post is loading...
Scoop.it!
From
medium
Review for Accelerate — The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations with thoughts, highlights, and lastly a recommendations 
No comment yet.
Sign up to comment
Scoop.it!
As DevOps has matured, so has the reading list on advanced topics. We talked to practitioners to come up with our must-reads.
Scoop.it!
DevOps emerged as a culture and a set of practices that aims to reduce the gaps between software development and software operation. However, the DevOps movement does not explicitly define how to succeed in these areas. In this way, DevOps is like an abstract class or interface in programming. It defines the overall behavior of the system, but the implementation details are left up to the author. SRE, which evolved at Google to meet internal needs in the early 2000s independently of the DevOps movement, happens to embody the philosophies of DevOps, but has a much more prescriptive way of measuring and achieving reliability through engineering and operations work. In other words, SRE prescribes how to succeed in the various DevOps areas. For example, the table below illustrates the five DevOps pillars and the corresponding SRE practices:
Mickael Ruau's insight:
DevOps SRE Reduce organization silos Share ownership with developers by using the same tools and techniques across the stack Accept failure as normal Have a formula for balancing accidents and failures against new releases Implement gradual change Encourage moving quickly by reducing costs of failure Leverage tooling & automation Encourages "automating this year's job away" and minimizing manual systems work to focus on efforts that bring long-term value to the system Measure everything Believes that operations is a software problem, and defines prescriptive ways for measuring availability, uptime, outages, toil, etc.
Scoop.it!
This evolution of the Wikipedia definition is indicative of the evolution of DevOps itself and how the industry views DevOps. Other than the replacement of the esoteric portmanteau, which had everyone going to Dictionary.com, the key points to note are as follows:
This is recognition of the fact that the goal of DevOps has changed from being just speed, to being speed, reliability, and quality (#faster and #better). Of course, I would be remiss not to mention what I believe is the most concise definition of DevOps ever written; I saw this first on a T-shirt at the O’Reilly Velocity Conference back in 2013: “DevOps—taking the SH out of IT!”
Scoop.it!
Optimize your time and learn faster! I've read The DevOps Handbook, filtered the information, and have summarized all the key points for you.
Scoop.it!
DevOps is a fast growing field – a movement. Like any new technological advancement or new ‘movement’ that takes the Application Delivery world by storm, learning about DevOps is like drinking from a firehose. My series on Understanding DevOps is geared towards executives, decision makers and practitioners who are new to the field, are learning the terminology and attempting to cut thru the fluff and hype and get to the meat and potatoes (did I miss any idiom?). My attempt is to do exactly that – present a tool and technology agnostic description of the field and advances thereof. I will from time to time talk about technologies and tools that are relevant to the field of DevOps, but will try to keep an un-biased perspective (Full disclosure – I have worked for IBM in the past, and currently work for Delphix).
Mickael Ruau's insight:
The series so far: Understanding DevOps:
Adopting DevOps:
DevOps books I have written:
Scoop.it!
Comment le Chaos Engineering a permis à OUI.sncf de mettre à l'épreuve son monitoring et d'évaluer son niveau d'observabilité.
Scoop.it!
From
medium
Thoughts, take-aways, and a recommendation for “The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations“
Mickael Ruau's insight:
The Phoenix Project is a fictional story about a struggling company and their transformative success. The DevOps Handbook is manual for putting the changes in The Phoenix Project into practice. The author’s make strong claims about increasing probability and success in the marketplace. Naturally all business desire those outcomes. The books is light on the data side, but rich with personal experiences, case studies, and anecdotes. The author’s split DevOp’s practices into three ways:
DevOps encompasses far more than simply breaking down the barrier between development and operations. It’s a philosophy built on feedback loops. Each of the three ways is a feedback loop in its own way. First, lower lead times with continuous delivery so ideas make it to production faster. Second; improve telemetry throughout the process so failures are more quickly recognized and resolved. Third: build organizations that leverage these feedback loops and empower everyone to improve in their daily work. Four: (yes) profit. The book is divided into three parts, one per way. Each part documents the relevant technical practices with supporting case studies and experiences sourced from industry professionals. It’s no surprise that companies like Netflix, Amazon, and Etsy are referenced often. The author’s note that three ways are not a linear progression. Every team may have bits and pieces of each. This is where the DevOps handbook shines. It draws a roadmap across them all so improvement focused teams may fill their gaps.
Scoop.it!
Automate your infrastructure deployments and configurations with these Infrastructure as Code tools.
Scoop.it!
Jointly written by Scrum.org and the DevOps Institute, this paper looks at how modern IT operates and how the different parts of the organization can work together to deliver working software with greater agility.
Scoop.it!
![[INFOGRAPHIE] Petite histoire de la méthode DevOps | Devops for Growth | Scoop.it](https://img.scoop.it/RRMqyEpyG7wFxmlt_DwHfTl72eJkfbmt4t8yenImKBVvK0kTmF0xjctABnaLJIm9)
En quelques années, la méthode DevOps, qui vise à améliorer la mise en œuvre et la qualité de projets informatiques, a connu un développement fulgurant. Découvrez l'histoire du DevOps en quelques dates !
Scoop.it!
Chaîne d'outils Devops - WikipédiaLa chaîne d'outils Devops est une collection ou une combinaison d'outils qui aide dans la distribution, le développement et la gestion d'applications tout au long du cycle de développement (logiciel). Chaque entreprise qui utilise la méthode DevOps la coordonne.
|
Scoop.it!
High performing organizations don't trade off quality, throughput, and reliability: they work to improve all of these and use their software delivery capabilit…
Scoop.it!
Tayllan's adventures through the worlds of Web Development, Software Architecture, DevOps and SRE!
Scoop.it!
Mickael Ruau's insight:
The following is an excerpt from the The DevOps Handbook, a massive hit and must-read for everyone involved in decision making within a technology organization².After the near-death experience of eBay in the late 1990s, Marty Cagan, author of Inspired: How To Create Products Customers Love, the seminal book on product design and management, codified the following lesson: The deal [between product owners and] engineering goes like this: Product management takes 20% of the team’s capacity right off the top and gives this to engineering to spend as they see fit. They might use it to rewrite, re-architect, or re-factor problematic parts of the code base…whatever they believe is necessary to avoid ever having to come to the team and say, ‘we need to stop and rewrite [all our code].’ If you’re in really bad shape today, you might need to make this 30% or even more of the resources. However, I get nervous when I find teams that think they can get away with much less than 20%.
Cagan notes that when organizations do not pay their “20% tax,” technical debt will increase to the point where an organization inevitably spends all of its cycles paying down technical debt. At some point, the services become so fragile that feature delivery grinds to a halt because all the engineers are working on reliability issues or working around problems.
Scoop.it!
From
www
When we first penned the eight laws of developer platforms back in 2013, we didn’t chisel them in stone. We always knew they were a living document. Five years and a dozen investments later, in companies like LaunchDarkly, HashiCorp, and PagerDuty, we recognize these laws as not just investing criteria that led us to some of the most successful developer-centric businesses, but also as practical case studies for developer-focused entrepreneurs who want to do the same. Founders today face a completely different reality than founders had to navigate six years ago, and these three trends have impacted the way entrepreneurs build companies in today’s era of enterprise IT
Mickael Ruau's insight:
Amendments to the eight developer laws:
Scoop.it!
From
xebialabs
The DevOps Release Timeline is a guide for your team’s first DevOps sprint. We’ve broken this timeline into 5 steps over a two-week period.
Scoop.it!
From
xebialabs
Getting new software to your users without interrupting their experience is hard; how do you upgrade an application that’s inactive use?
Scoop.it!
Des Devs s’arrogeant la place des Ops, des Ops acquérant des compétence de Dev… Dans cette session, nous vous proposons ainsi d’explorer ces profondes mutations culturelles et techniques, et nous vous partagerons quelques recettes pour le plus grand bénéfice des OPs… comme des DEVs. Comme l’écrivait Audiard, « Quand ça change, ça change... Faut jamais se laisser démonter » !
Mickael Ruau's insight:
La mise en oeuvre du continuous delivery engendre de nouvelles pressions sur les Ops, l’infra et l’opérabilité d’une application se bâtissant désormais au rythme croissant des itérations livrées. En parallèle, les patterns d’architecture évoluent eux aussi : résilience et scalabilité se traitent désormais de plus en plus au sein même des applications, ramenant progressivement l’infrastructure au rang de commodité… Enfin, les équipes de Devs n’ont de cesse de réclamer plus d’autonomie et une ergonomie plus adaptée à leurs besoins : les acteurs du cloud et de solutions star comme Docker ne s’y sont pas trompés en proposant des produits qui leur parlent directement : la tentation du NoOps grandit peu à peu…
Scoop.it!
« La Servuction, c’est la manière dont un prestataire manage son entreprise et surtout son client afin de délivrer son Service avec la meilleure Qualité possible, tout en respectant ses objectifs économiques. »
Mickael Ruau's insight:
La différence entre Servuction et Production est managérialeEn Production (industrielle), l’entreprise a pour vocation de mettre en œuvre un système de fabrication interne qui permette la mise à disposition de produits avec la Qualité voulue pour répondre à un marché. Si une opération de fabrication dysfonctionne – une machine en panne, un ouvrier qui ne maîtrise pas le poste, … – alors la Qualité n’est pas au rendez-vous. Dans la fabrication d’une voiture, le client-consommateur n’est pas partie prenante : ses qualités intrinsèques, sa personnalité, son investissement, n’influencent pas la qualité du véhicule produit. La Qualité, le contrôle de gestion, en bref, le système de Management d’un système de Production est indépendant du client (même s’il vise à répondre à ses désirs) : il ne gère que des ressources internes. En Servuction, tout se complique : s’il faut également gérer les ressources internes, le client a aussi un rôle à jouer dans la « fabrication du service ». Et cela peut entraîner de nombreux déboires si le client, en tant que « ouvrier du service », est mal managé. Les déboires classiques du management se retrouvent alors dans la relation avec le Client :
Scoop.it!
1h d’indisponibilité = 1 M€ de perte Découvrez comment Voyages-sncf.com s’est appuyé sur la démarche DevOps pour innover et garantir un Time To Market concurre…
Scoop.it!
This session will walk you through a practical framework for implementing measurement and tracking of your DevOps efforts and software delivery performance that will provide you with data you can act on! These KPIs include metrics related to your software delivery pipeline and technical progress, as well as cultural indicators and business impact. In addition, we will cover common use cases and real world examples for implementing these metrics to drive DevOps success, as well as best practices for how to address certain challenges and problematic areas along your process that these metrics may bring to light.
Scoop.it!
The research recommends this action plan to more fully implement agile and DevOps:
|
Accelerate puts a finger on measuring software delivery performance. This a fuzzy problem since feel like part of a high performing, but it’s challenging to compare performance across teams for a multitude of reasons. Their measurement works around these problem with directly observable metrics and inferred metrics. They break software delivery performance into four metrics: