In this presentation, I'm addressing all the organizational issues related to devops teams and the rise of platform engineering. The good, the bad, and the pitfalls of how to organize your team (effort, skills, and gtd).

1. Tales of the mythical
Cloud-Native Platform
(How Kubernetes won’t fix your broken organization and
what you can do about it)

2. About Me
Jacopo Nardiello (@jnardiello)
Founder & CEO SIGHUP
CNCF Ambassador
Engineer
Dad of 2 kiddos
Up until 2014 - Software Engineer
2014 - Shifted to DevOps
started working on this thing called Docker and all the mess to run it in
prod
2015 - Pushing Kubernetes to prod
I need to run stuff in prod, deep into orchestrators war, Kubernetes
had a clear vision and solid core community I got very involved with. I
was onto something

3. About SIGHUP
2018 - Unleash Kubernetes Fury, The truly free Kubernetes Distro
~tens of clusters in Prod. As we focus on running and maintaining upstream Kubernetes
infrastructures, we develop a common set of modules to provision standard clusters. This
is where we realise that, we have developed a Kubernetes Distro. Kubernetes Fury
Distribution gets CNCF Certified.
2020 - Kubernetes Fury becomes an Ecosystem as we onboard more organisations
Fury powers ~Hundreds of prod clusters, from startups to enterprises.
We announce more OSS projects: Permission Manager, Gatekeeper Policy Manager,
OPA-Notary connector, Certified Container Images, Kage.
Check them out!
https://kubernetesfury.com
https://github.com/sighupio
@sighup_

4. The goal for this talk
This is not a talk about containers
Too often we simply focus on:
- What tech stack to adopt
- The latest cool technology
- What product to buy on the market
These things are NOT very important!

5. The goal for this talk
- The “Why”
- What are the key aspects and challenges to focus on (both
technological and organizational)

6. Cloud Native - Why
Ogni azienda oggi e’ una
software company.
DevOps come uno
standard de-facto
(we made it!!)
Aumentare quindi sviluppo e velocity di
rilascio di nuovi prodotti.
Capacità di sviluppare e far evolvere il
software verso nuovi prodotti. Il business
guida, IT deve seguire.
Evitare incident ed aumentare l’efficienza e
affidabilità operative.
Implementare o migliorare governance
aziendale e security.

7. Organisations:
The good and the bad

8. Commonly known orgs
The traditional
model
DevOps’ed
vs.

9. The traditional model - The good and the bad
The traditional
model
Bashed for the last 20 years (for a reason 😬).
- Everything is manual
- Hardly anything is reproducible nor
automated
- Everything is a ticket
- No swe culture
- Company velocity: 💩
This is what the average advocate (myself
5y-ago included) would tell your management to
justify change (and 💰). And that’s ok, because
they wouldn’t be wrong, BUT…

10. The traditional model - The good and the bad
The traditional
model BUT
The missing point: these people are hell of professionals.
- Super in-depth knowledge, super low-level
- They know how to run systems in prod
- They are the good kind of silos**
** Next talk idea: how to get banned from all future conferences worldwide with one simple sentence

11. The DevOps’ed model - The good and the bad
The DevOps’ed
model
The good
- High degree of automation
- High short-term velocity &
time-to-value
- Strong ownership on running systems
“You build it, you run it” - this is the system
pushed by cloud vendors (for a reason 💰),
hardly anyone has the maturity to talk about the
disadvantages of this model.

12. The DevOps’ed model - The good and the bad
The DevOps’ed
model
The bad
- Fine for small orgs, quickly turns into a
nightmare for large organizations.
- The Horde 🧌 effect:
- High fragmentation
- Extremely inefficient devs
time-allocation
- Developers Burnout as complexity of
tools grows
- Lower TCO but higher short-term costs

13. The real holy grail of infra automation:
Platform engineering

14. Towards platform engineering
The Platform
Engineering model

15. Towards platform engineering (IDP) - A Target Org
- Internal Dev Platform Team
(IDP)
Will integrate low level components, third
party software and will write abstractions
and components with software.
IDP to enable self-serve of infrastructure
from DevOps & Application teams,
abstracting away the vertical complexity.
- DevOps
Consume and integrate platform
abstractions with application software, still
in charge of delivering to prod.
- SRE
Observability, SLO & defcon
management.

17. The role of Kubernetes towards platform engineering
Kubernetes as the holy grail of organisational and technological transformation.

18. The role of Kubernetes towards platform engineering
Kubernetes as the holy grail of organisational and technological transformation.
Introduced a powerful low level abstraction layer that is consumable via a
coherent API.
COMPLEX
(The kind of low level complexity you don’t
want to throw on developers)

19. Is K8s the holy grail of transformation?
�� �� ��
- Not just containers
- IDP should provide documentation
and abstractions to enable app
teams to consume infra
dependencies for their specific
needs.
- An IDP is NOT a general purpose
all-you-can-eat product you can buy
on the market.
An IDP is much more than just
Kubernetes.

20. The only key aspect: Golden Paths
To enhance velocity and time-to-value, focus on
the Golden Paths, technology (k8s included) is
just a building block (and not a solution by itself)

21. To wrap it up
- You must invest in building up the seniority in your team to
identify and automate:
- Your golden paths (what matters to you)
- Your existing layered technological complexity (this is where the
challenge is)
- Self-serve of infrastructural layers (way beyond containers)
- The adoption of Cloud Native technologies, is just a (small) part
of the overall story.
We had all the necessary technology to implement all these aspects before
Kubernetes - so, it’s not about the technology.

22. Thank you
Come and talk to me in the exposition area
@jnardiello