Ajit's key drivers of Amazon's DevOps success?
Cultural philosophy + practices and patterns + tools
Opinion: the first one is a big one. I've heard conversations about 'DevOps as a Service' or enabling DevOps by tooling and practice You need culture to make it stick. #reInvent
Cultural philosophy + practices and patterns + tools
Opinion: the first one is a big one. I've heard conversations about 'DevOps as a Service' or enabling DevOps by tooling and practice You need culture to make it stick. #reInvent
"Jumping into tools too early without the other elements of the 3-legged stool of DevOps (culture and practice) can result in dysfunction" #reInvent
Friendly reminder: Amazon used to have a monolith. It’s a good news story that an org their size was able to make such a drastic change towards DevOps. Really inspiring for others on their journey from legacy systems. #reInvent 
How do you start to decompose a monolith? Identify the products embedded and align small dedicated teams to them. #reInvent
Each team acts as a startup with a freedom to innovate and change things based on working with their customers.
As Amazon shifted from project to product alignment there were a number of benefits: faster delivery, cross-skilling, better customer alignment, easier updates and operations
Simplified: product aligned full-stack teams beak silos and eventually all of the downsides associated with them in an org eventually erode. #reInvent
A subtle element that Ajit brings up is that DevOps and autonomous teams need automation and guardrails to be successful. Easy methods of self servicing infra, deploys, observability, etc is essential #reInvent
Opinion: Not sure if Ajit will get into this but automated guardrails require “guardrail” product teams to build DevOps enabling services such as standardized templates #reInvent
Yup... Amazon has guardrail teams. The cool thing? The automated guardrails and templates that they build for themselves get incorporated into AWS services #reInvent
Opinion: I have a feeling much of this conversation regarding centralized enablement platform teams will have a strong correlation to @rusmeshenberg ‘s talk coming on Thursday
Ajit: Decompose all the things. This includes code, plans, teams, etc. Complex technology and people systems incite coordination and communication overhead the larger they get. #reInvent
Talking about the importance of “observability” in DevOps. Topic is getting a lot of attention lately. Those new to it, it’s “a measure of how well internal states of a system can be inferred from knowledge of its external outputs.” #reInvent en.m.wikipedia.org/wiki/Observabi…
Opinion: most talk on Observability is related to systems but it’s also important to have visibility into people and process. Transparency is a great thing #reInvent
Cool DevOps maturity visualization from Ajit. #reInvent
Interesting comment regarding organizational pitfalls in DevOps journeys: watch out for early shared service guardrail teams becoming new-age silos. Ajit has seen this happen with orgs that adopt a traditional SRE model. #reInvent
Opinion: Adopting SRE isn’t inherently anti-DevOps. Rebranding Ops as SRE is. Reminder: SRE adoption doesn’t require the original Google org model. Embedded SREs are definitely a thing. #reInvent
@threadreaderapp unroll
