DevOps presentation notes

presentation.txt

DevOps

Wrong ways to think about DevOps:
There is no devops.exe - you can't 'install' DevOps
It's not a THING, it's a way of getting things done
You can't ask the team to 'go get some devops'
DevOps is much more than just Developers and Operations. The term has long ago transended dev and ops. Evangelists know this, but not everyone else

DevOps is a transformational process


Messaging:
	DevOps messaging on the sales side is different to Practitionlers (Dev, Ops), Leadership, Champions
	Change comes from groundswell and leadership backing
		Need to have buyin from people doing the work, can't mandate "devOps" (collaboration) - have to get people doing the real work excited
		Pushing DevOps down doesnt work - People doing the work will say 'here comes another bull shit mandate'
		https://www.arresteddevops.com/devops-culture-change/
		On the flip side, people doing the work won't always be equiped to sell it to leadership

How do you Sell DevOps?
	Talk about results: time to market, ci/cd, metrics
	devops is bathwater in which all of these things are babies.
	Tools can faciliate devops

DevOops - what exactly are you trying to solve?
	ask more questions
	drill into what "we want DevOps" means
	DevOps is a bunch of lego pieces that you as a professional arrange to solve company specific problems - Alex

Adoption:
	devops is an extension of the agile movement (per many industry leaders) - shot itterations, cycles, etc.
	mindset that it all leads to devops - "once you see the way, you see the way in all things"
	Dont meet people half-way. Meet them where they're at.

Where can you learn more about DevOps & SRE?
	Events.
	Meet people inside your company who are teaching devops inside your company
	you can't sit behind your desk and learn devops.
	Hands down - meetups and your local devops days will be the place where you learn the most.
		Listen, share, do the 'hallway track'
		Get to bigger conferences
		Make friends. Meet real practitioners. You can get inside peoples heads, get feedback on your thoughts.
	Blog posts are good, but it's just not the same.


Bridget - DevOps is not something you'll find on a balance sheet


Does Operations engineer do DevOps? Sure.
How about support engineers when they deal with tickets? Sure

-------------------

WTF IS SRE::

SRE is the natural evolution of DevOps

DevOps - Bringing application developers and Operators together
SRE - moving the conversation from local optimizations to larger systems thinking
understanding and optimizing modern applications across the entire (eco)systems
from security practices, to observability, to compliance, to culture

Security - DevSecOps
Observability - core of SRE
Multi-cloud 

Historically - In my experience - DevOps has been about breaking down the silos, or perhaps just poking a tiny hole,to fit a
straw in, and over time making that hole big enogh for a handshake. This aspect of devops is often about building a ground 
swell, working with engineers.

A lot of this work takes space during your discressionary time, or initially as part of keeping the lights on, really it's all
one big shadow IT project working AROUND the process and incompetent implementation of process tooling. Over time, it's
nurturing that relationship into a hole big enough for a handshake, and eventually breaking down the wall completely.

SRE - is much more about shifting things left. Automation and chaining processes is almost taken for granted.

Shift learning left as well.
	SRE and observability is about learning how your product will behave when it fails BEFORE it fails.


< Add cost of learning graph > from cost of detecting failures in test vs prod.
	If you can get very good and very quick at detecting failures, you can change quicker.

This is where scrum comes in. If you can change cheaply, and safely, you can gain a lot of benefits and knowledge.
...............
The code looks like it works
	how will you konw it doesnt?
	how will you operate it in production?
...............
In my experience:
	Legacy devops is more about pets and building bridges
	Modern devops is more about ephemeral and immutable automation and building bridges
	SRE is moving towards resilience and recovery at scale, and just as much about building bridges as devops is

	In either case, infra or code, you need monitoring and metrics. 
	Always.
	Without metrics and metrics, it's clueless leading the helpless.

	Supporting infra that's ready to die (die=distributed, immutable, ephemeral) is a lot easier that feeding and caring for a pet 

	immutable - cant change the system once it's been deployed. No SSH, no kubectl exec, no changes on disk.
		once a system is deployed, you can't touch it.
		all of your changes are in source control
	Ephemeral - short lived infra that serves the purpose and dies. Short lived secrets. No major planning needed.
		your infra is cattle, but your passwords are pets? bad
	< another idea > - who is responsible for these aspects? DevOps or SRE? Either. Whoever can build it, help architect it, and train others.

...............
Things every should know
	security - everyone is competent enough and knows enough.
	response - everyone knows where it's written down, and knows how to execute it. It's been used and tested.

(camels nose - if you allow the camels nose into the tent, pretty soon you'll have the whole camel in the tent)