Shaun Abram
Java and Technology weblog
Subscribe to RSS FeedMeasuring Developer Productivity
Most metrics for measuring developer productivity, such as lines of code or issues closed, are notoriously ineffective. But the research in the excellent State of Devops report shows that, rather than focusing on local metrics and individual developer performance, it is better to look at overall development and delivery practices. Specifically, there are metrics that predict and reflect a team’s ability to successfully deliver working software into production, including deployment frequency, and the mean time to restore service after an incident. This articles discusses why some metrics are useless, and takes a closer look at the recommendations in the 2019 State of Devops report.
Tags: accelerate, developerproductivity, devops, fourkeymetrics, stateofdevops
Report Summary: Accelerate State of DevOps 2019
This is an abridged version of The Accelerate State of DevOps Report 2019; essentially a cut and paste of the most salient parts. The original is about 18,000 words; This is about 2,500 words.
I highly recommend reading the original in its entirety, if you have time, and I’m a big fan of the Accelerate book too. As with all the other summaries I create, this just as as way to help me digest and understand an excellent article.
Tags: accelerate, devops, fourkeymetrics, jezhumble, nicoleforsgren, stateofdevops, summary
File, Block and Object Storage
I was in an AWS class today, where they were talking about S3, and how it is “object storage”. But what does that mean? One way to explain it is to contrast it with other types of file storage, namely File and Block Storage.
(more…)
Tags: aws, blockstorage, ebs, efs, filestorage, objectstorage, s3
Is Apdex useful?
I’ve been trying to figure out what SLOs to define for some services recently, and wondering if Apdex is a useful metric. (See my previous post on the difference between SLIs, SLOs and SLAs)
Tags: apdex, applicationperformanceindex, sitereliabilityengineering, slo, SLOs, sre
SLI, SLO and SLA
What are SLIs, SLOs and SLAs?
Service Level Indicators (SLIs) are metrics that you choose to measure the health and performance of your services. Service Level Objectives (SLOs) are the desired target for those indicators. Service Level Agreements (SLAs) build on this and include the consequences of not meeting those targets. All are fundamental to Site Reliability Engineering.
In this post, I’ll try to explain each in more detail, how they relate to each other, and some examples of each.
Tags: seekingsrebook, servicelevelagreements, sitereliabilityengineering, sla, SLAs, sli, SLIs, slo, SLOs, sre, thesrebook
SRE vs DevOps
I’m really enjoying the Seeking SRE book. Chapter 12 covers SRE vs DevOps; a community sourced compare and contrast type discussion.
My favorite description is from Thomas Limoncelli, who suggested that:
DevOps engineers focus on the SDLC pipeline with occasional responsibilities for production operations. SREs focus on production operations with occasional responsibilities for the SDLC pipeline.
Tags: books, devops, seekingsrebook, sitereliabilityengineering, sre
Blog post summary: Blameless PostMortems post by John Allspaw
The following is a slightly summarized version of this blog post from John Allspaw that I really like: Blameless PostMortems and a Just Culture
Tags: blameless, postmortems, RCA, rootcauseanalysis, summary
Book chapter summary: Postmortem Culture, from the SRE Book
I’m really enjoying reading the excellent “SRE Book“. Chapter 15 “Postmortem Culture: Learning from Failure” in particular, really struck a chord with me. The following is a slightly summarized version of it.
TLDR: Failures are inevitable, especially in distributed systems. To learn from them, document in Postmortems, avoiding blame, and share the newly gained learnings across your org.
Tags: blameless, postmortems, RCA, rootcauseanalysis, sitereliabilityengineering, sre, summary, thesrebook
Posting to LinkedIn
I find LinkedIn a useful platform for publishing content and reaching a wider audience than this blog does. I typically see better engagement on LinkedIn than I do from posting the same content on Twitter too.
But every time I go to post, I get confused between a post and an article.
Top 5 announcements from AWS re:Invent 2018
AWS re:Invent has just completed. It was a huge event with 50,000+ attendees across 7 of the biggest hotels in Vegas, and many new service announcements.
Serverless continue to get lots of attention with new lambda enhancements and better container support. The “hybrid” model of using your own datacenter in conjunction with a cloud provider has been fully embraced by AWS with the new “Outposts” capabilities. Machine learning also got much love with several new services using and supporting it. Read on for my top picks from this week’s announcements…
Tags: aws, awsreinvent, reinvent2018
Service Mesh: Istio and AWS App Mesh
One of the big announcements at AWS re:Invent this week was the AWS App Mesh.
Before talking about it though, let’s look at what the heck a mesh is anyway…
Tags: aws, awsappmesh, awsreinvent, envoyproxy, istio, reinvent2018, servicemesh
Talk summary: Realizing the Microservices Vision with Service Mesh by Arijit Mukherji
Some note on the talk “Fully Realizing the Microservices Vision with Service Mesh” by Arijit Mukherji of SignalFx at AWS re:Invent 2018 (DEV312)
Find the video at https://www.youtube.com/watch?v=eTHhsbKfpWg
Tags: awsreinvent, microservices, servicemesh, summary
Talk summary: SRE principles by Tori Wieldt @ AWS re:Invent 2018
I caught a talk by Tori Wieldt at the New Relic booth at AWS re:Invent on “SRE principles”. Even though it was a short talk in the expo hall, rather than a formal scheduled one, it had a ton of good SRE material.
Tags: aws, newrelic, reinvent, reinvent2018, sitereliabilityengineering, sre, summary, Testing
AWS Re:Invent 2018 Keynote announcements
Highlights from today’s 2018 AWS Re:Invent Keynote by CTO Werner Vogel.
Tags: aws, awsreinvent, reinvent, reinvent2018, werner, wernervogel
Intellij Maven folders
I haven’t been coding a lot recently, and when I spun up a new maven spring boot project and imported in to IntelliJ, I got confused about which folders are supposed to be marked as source (src, src/main or src/main/java?) and test (src/test or src/test/java?).