@mipsytipsy
The Death of DevOps Has Been
Greatly Exaggerated, but Platform
Engineering Is Here To Stay
DevOps Days NYC 2023
Slide 2
Slide 2 text
@mipsytipsy
engineer/cofounder/CTO
https://charity.wtf
real observability for complex systems
new!
Slide 3
Slide 3 text
My ❤ belongs to operations engineering…
Everything interesting happens in prod
The cost of writing software can be
rounded down to 0, compared with the
cost of maintaining and operating it.
Slide 4
Slide 4 text
“Fuck you”
“DevOps is Dead”
Stop trying to sell me shit
with your shitty clickbait
Slide 5
Slide 5 text
Software doesn’t die.*
• COBOL
• Java
• Javascript
• MySQL
• Postgres
• LISP
• emacs
• SQL
• FreeBSD
• Linux
• IPv4
• TCP/IP
• png
• gcc
• gdb
• elisp
• X11
• /proc
• grep
• sed/awk
• O’Reilly books
• bash
• nginx
• haproxy
* a list of things that are not dead, all of which are older than devops
Slide 6
Slide 6 text
Warning:
You might hate this talk. It’s all about
definitions and what terms mean. That’s
ok!! I’m not offended if you leave :)
Slide 7
Slide 7 text
“DevOps is dead”
is just a stupid thing to say…
clickbait marketing🤮
But there is a kernel of truth there
DevOps is not eternal.
It will be superseded.
Slide 8
Slide 8 text
Operating that software is eternal.
Developing software is eternal.
but “DevOps”?
What happens when there are no
more “dev” teams and “ops teams”?
🤔
🤔
Slide 9
Slide 9 text
The long arc of software careers
1990
Write code and
run what you write
1995
Devs write code,
Ops runs code.
Friction ensues.
2007
DevOps emerges;
devs + ops
Empathy, #hugops blah blah
2023
Write code and
run what you write
Slide 10
Slide 10 text
1. Every engineer writes code.
2. Every engineer runs the
code that they write, and
operates it in production.
These days:
Slide 11
Slide 11 text
Systems are becoming
rapidly more complex.
They can only really be operated
by the people who write them.
And you can’t do a good job of writing them
unless you are regularly exposed to the
feedback loops of operating them.
Slide 12
Slide 12 text
Operational expertise is more critical than ever,
but the landscape is shifting for ops roles.
Two big trends are converging:
everybody writes code,
runs the code they write
hosted infra and tools,
we all move up the stack
Slide 13
Slide 13 text
We are decoupling “infrastructure”
from “software operations”
Platform engineering has emerged
from this realignment.
• Companies are shutting down their ops teams and
outsourcing infrastructure to PaaS/IaaS/etc.
• We now rely on a complex web of other higher-level
providers, services and tools via APIs and SDKs.
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
No.
You have a platform engineering
org, which encompasses your
infrastructure needs
Infrastructure(n): the code you have to run,
in order to run the code you want to run.
Slide 16
Slide 16 text
Infrastructure(n): the code you have to run,
in order to run the code you want to run.
Infrastructure is a cost center.
It may be a competitive differentiator,
but it is still a cost center.
which means you want as little as possible.
Slide 17
Slide 17 text
⛔ Infrastructure Org
✅ Platform Org
• SRE
• Deep subsystem teams
• “Pure” platform teams
• Security
• Release engineering
• Developer tools
• Front-end developer experience
Slide 18
Slide 18 text
One of the things platform
teams are best at:
Running Less Software.
Slide 19
Slide 19 text
which builds infra composes
architecture as a product.
Within your platform organization,
you may have a platform team
Slide 20
Slide 20 text
No content
Slide 21
Slide 21 text
How to tell if your “platform team” is
really a platform team or not:
Is the team responsible for SLOs, service
uptime, and a reliable customer experience?
✅ platform team
NO
⛔ platform team
YES
Slide 22
Slide 22 text
Platform teams are responsible
for developer productivity.
Product engineering teams
and SREs are responsible for
customer experience.
Slide 23
Slide 23 text
If your platform team spends a lot of time
writing software, something is wrong.
Slide 24
Slide 24 text
Your platform team
*should* spend time on:
• Doing discovery
• Building champions
• Baking in feedback cycles
• Working with product managers
• Working with design (!)
• Figuring out the golden path
• Practicing change management
• Building a roadmap
• Talking with focus groups
• Building internal APIs
Slide 25
Slide 25 text
Cost is an essential part of architecture.
Build vs Buy is not the only time
we need to think about this!!
Slide 26
Slide 26 text
“If you build it, they will come”??
No, they fucking won’t.
Make sure you are building a platform
that people actually want and need!
Slide 27
Slide 27 text
“Vendor engineering” is a large
share of any platform team’s remit
Cost is an essential part of
architecture.
Platform teams are
super high leverage.
Slide 28
Slide 28 text
If you’re an infra/devops/ops engineer, and you
haven’t learned to work on product: Learn.
Once you dig your way out of
firefighting, product is what comes next.
Slide 29
Slide 29 text
The hardest part of software is operating it.
Always has been. Always will be.
Slide 30
Slide 30 text
In conclusion,
computers are
terrible
Everything dies
Have fun!