, 37 tweets, 14 min read Read on Twitter
Excited to be livetweeting @jezhumble's brand new talk on DevOps and Cloud Native at #CloudNativeLondon!
@jezhumble Netflix did the shift from traditional ops to "NoOps" which... didn't actually remove the need for ops, just ops as a separate department. #CloudNativeLondon
but what it did highlight was that instead of having ops departments, we have started having _platform_ engineering departments separate from product dev teams. #CloudNativeLondon
Does DevOps mean "teach ops to code" as one #DevOpsDays Portland attendee thought after attending the event?

Is it just renaming your ops teams? #CloudNativeLondon
Instead, let's take a step back and look at the DevOps movement/community of practice - about building and scaling rapidly-changing, distributed systems. #CloudNativeLondon
Three elements: measuring software delivery performance, the difficulty of designing cloud platform architectures, and culture/org structures that can make things work better. #CloudNativeLondon
To Google, DevOps is a cultural movement to increase velocity, improve service reliability, and build shared ownership. #CloudNativeLondon
.@jezhumble is now summarizing the key metrics of development/deployment/operation from @devops_research's survey: availability, lead time, change fail, deployment frequency, and time to restore. #CloudNativeLondon
Performance on these key 4-5 metrics predict very well commercial/business goals.

This year there were 4 clusters: elite, high, medium, and low (similar to last year). And the results remain different by orders of magnitude across categories. #CloudNativeLondon
But how do people actually get better? What should they adopt to help them?

Broadly, 4 categories: transformational leadership, technical practices, lean product dev, and lean management.

And these things lead towards improvements in org culture/independence. #CloudNativeLondon
If people have on-demand self service from their cloud provider, they do better. but often organizations put barriers in the way to self-service, and we're back to the land of raising tickets for resources. #CloudNativeLondon
Enterprises have dramatically different situations than startups; there's much more complexity, legacy stuff, and 70% of our budget is spent just keeping the lights on.

How can we also do CI/CD? #CloudNativeLondon
Onto subject 2: cloud architecture.

So @jezhumble joined @18F, which had just gotten access to AWS Govcloud. and it was a mess even a few months in, because people had just spun up things every which way. #CloudNativeLondon
18F wound up building cloud.gov on top of PCF on top of AWS in order to have a better understanding/mapping of applications to resources, and garbage collecting/chargeback for infra. #CloudNativeLondon
Beyond any immediate challenges of ability to safely manage blast radius, make changes, and have safe multitenancy...

how do we actually make sure we can _hire_ new people to work on it for the future rather than having knowledge locked away? #CloudNativeLondon
How long does it take to deploy a code change from it being committed?

[ed: it's shocking how many people don't know what their lead time is in the audience - 10 people in the room, only, raised hands] #CloudNativeLondon
Lead time is incredibly important for security posture in the age of mass exploitation and wormable code. This is no longer an agility risk, it's a security risk. #CloudNativeLondon
The new separation of responsibilities isn't dev and ops, it's platform teams building/maintaining/operating (with service ownership) the PaaS, and making the application/deployment as easy as possible for app developers (who also build/maintain/operate theirs) #CloudNativeLondon
Can you fix common dependencies in one place, without each app team needing to manually take action? Yes, with PCF etc. #CloudNativeLondon
We need to manage complexity by limiting options. Give people a fixed menu of supported runtime stacks. #CloudNativeLondon
Shared outcomes wind up constraining our architectural choices. What makes a PaaS as effective as possible?
(1) make changes independently
(2) not need tight communication coupling
(3) deploy/release on demand
(4) test in prod
(5) deploy without downtime. #CloudNativeLondon
This isn't a matter of cloud or not-cloud -- you could get these outcomes with a mainframe, or fail at them on Kubernetes. #CloudNativeLondon
The JAM stack: javascript, APIs (on Cloud Functions etc), and static markup, rather than having fancy HTML generation frontends.

It's incredibly scalable, minimizes attack surface, and decouples presentation/services. #CloudNativeLondon
but you don't get to do resume-driven development and put k8s on your CV.

and you have less control over things like deployment strategy/canarying, scaling strategies, etc. (but maybe that's a good thing!) #CloudNativeLondon
Finally, high-performing teams. It's a lot harder than putting smart people in a room.

Autonomy, lean management/dev, continuous delivery, and mission/psych safety. #CloudNativeLondon
But a lot of practices make it harder to achieve autonomy.

Outsourcing of test/operations, heavyweight change process, etc. hugely negatively impact performance. #CloudNativeLondon
Context is critical. How can someone who *isn't* on your team possibly understand the impact of your changes? Far better to have someone on your own team look at it than have an outside "reliability expert" do it. #CloudNativeLondon
Make sure you at least have a _clear_ change process, if you must have a change process. #CloudNativeLondon
Working in small batches is important. More than 3 days = too big.

We have to be able to see the flow of work through dev into production.

and we need to gather customer feedback & experiment. (yes, real customers, face to face). #CloudNativeLondon
and do we finish what we've started, or do we allow work in progress to spiral out of control? #CloudNativeLondon
The best quality measure is "percentage of time spent doing rework" [ed: and I'd go further to say we have to also include toil in rework] #CloudNativeLondon
hashtag-include-project-aristotle.h about psych safety improving teams [ed: which I have my own quibbles about when it comes to false conflation of psych safety and diversity, but broadly, yes, don't yell at people when they make mistakes] #CloudNativeLondon
Reward people who bring to light failures, rather than punishing them c.f. @rynchantress's three-armed sweater.

Ask "how can I help?" rather than "how could you let that happen?" #CloudNativeLondon
Improve peoples' working relationships by *practicing* with exercises like DiRT (disaster recovery testing).

Only 40% of DORA survey respondents actually do DiRT at least annually. [ed: we have _so_ much further to go with chaos engineering...] #CloudNativeLondon
You can't just install k8s and start installing apps; you need key tech and management capabilities, psychological safety, and changing your organizations.

And you need a managed platform as a service with golden paths. [fin] #CloudNativeLondon
[ed: I'm going to have _so_ much fun riffing off this talk for my keynote this evening! so thank you @jezhumble, and I miss having you as a coworker SOOO much!] #CloudNativeLondon
.@jezhumble debunks the "separation of duties" myth that you need a separate ops team to run your code.

You need (1) code review, and (2) automatic deployment scripts of golden binaries.

That's it. You don't to pay extra humans to be change advisory or ops. #CloudNativeLondon
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Liz Fong-Jones (方禮真)
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!