DevOps e' solo il termine piu' fallito della storia dell' IT

[teflon]

@amigaunicorn questa mi interessa, continuo sentire a parlare di devops come se fosse la panacea per tutti i mali...

[amigaunicorn]

@teflon

finche' non gli dici che , 24/7, hanno dieci minuti per la prima analisi di un ticket PRIO 1, e un'ora per risolverlo.

E allora scoprono che non capiscono operations, e a loro va bene devops, ma "dal lato dev".

[teflon]

@amigaunicorn said in DevOps e' solo il termine piu' fallito della storia dell' IT:

@teflon

finche' non gli dici che , 24/7, hanno dieci minuti per la prima analisi di un ticket PRIO 1, e un'ora per risolverlo.

E allora scoprono che non capiscono operations, e a loro va bene devops, ma "dal lato dev".

credo di iniziare a capire cosa intendi...

[teflon]

mi mancava il concetto di "operations". Sono andato a "studiare" con chat-gpt

Aspect	Traditional IT Operations	DevOps
Focus	Stability, reliability, uptime	Speed, automation, collaboration
Responsibility	Managing infrastructure, support, monitoring	Bridging development and operations for faster, reliable delivery
Team Structure	Separate Ops and Dev teams (siloed)	Cross-functional teams (Dev + Ops + QA)
Workflow	Manual deployments, slower change cycles	Automated CI/CD pipelines, rapid iteration
Culture	Reactive (responding to issues)	Proactive (preventing issues, continuous improvement)

wow, sembra che sto coso supporti alla grande il markdown...

[teflon]

in questo video ho sentito parlare per la prima volta del trunk based development e ho iniziato a nutrire qualche perplessita'....

https://youtu.be/zjPyqhAuo_w?si=MezqQNonfZWJCthu

[absc]

@teflon

DevOps: tagliamo costi, facciamo fare il lavoro di operations ai programmatori (che non lo sanno fare).

Trunk-based development: Buzzword yadda yadda. Quello che qualsiasi progetto open source negli ultimi 50 anni fa.

Il linux kernel? FreeBSD? OpenBSD? NetBSD? GNU?

Tutto quello e' trunk-based, ma sai com'e': in informatica non ci sono mai abbastanza buzzword.

BTW: si, il forum supporta Markdown alla grande.

[teflon]

@absc

si, quello che mi ha dato da pensare del video e' il trunk-based development applicato al ci/cd, nel senso che dopo il push del master quello va in produzione...

per fortuna quando facevo software quello veniva ancora distribuito via cd per le installazioni sui cnc e non messo su dei server

@absc said in DevOps e' solo il termine piu' fallito della storia dell' IT:

in informatica non ci sono mai abbastanza buzzword.

mado' se e' vero

[absc]

@teflon

E chissà perché, lo fanno solo quei posti dove non viene creato nulla di importante.

[Gabriel]

Io l'ho sempre visto come un tentativo di risparmiare sull'ops fatto da chi non ha idea di cosa vuol dire fare ops...

[sbz]

@teflon said in DevOps e' solo il termine piu' fallito della storia dell' IT:

Cross-functional teams

Allora, sta cosa che DevOps e' cross-functional l'ho vista solo sulla carta. Nella grande maggioranza delle applicazioni che ho visto (grande confirmation bias, lo so) e' sempre lo stesso 'buttare il codice oltre la rete' (come diceva @amigaunicorn).

A mia esperienza, forzare sviluppatori ad avere oncall per escalation oncall con 30 minuti di ready time risolve il problema - o quanto meno li rende improvvisamente interessati a scrivere roba che funziona.

[philotette]

Nella mia esperienza è cross-functional team nel senso che in ogni team ci sono N sviluppatori con bravura media 50 (di cui 45 in sviluppo) e UN DevOps bravo 150 (di cui 40 in sviluppo). Tale cristo è quello che mette su il codice, ferma qualche merdata prima che vada su, e quelle che non ferma le vede per primo e capisce quale sviluppatore cazziare. E ovviamente fa parte pure del team di devops, anch'esso con gente di diversa bravura.

Ho l'idea insomma che si è passati dall'avere team di sviluppo con un senior o chi per lui molto sveglio, che si assicura che il codice prodotto sia davvero buono e che rispetti tutti i crismi (documentazione, artefatti) per essere utile a ops, e un team di ops con l'equivalente altrettanto sveglio che si assicura che il codice vada e rimanga su.
A team di sviluppo e di ops con gente moderatamente brava, e una sorta di supervisione ops->dev implicita.

[teflon]

whoa! Per chat-gpt sembra che tunk-based dev + ci/cd piaccia praticamente a tutti al di sotto di centrale nucleare, aerospaziale, automotive ...

se e' davvero cosi' sto scoprendo un mondo ...

Category	Application Example	Uses Trunk-Based + CI/CD?	Reason
Social Media	Instagram, Twitter, TikTok	Yes	Fast iteration, A/B testing, rapid feature rollout
eCommerce	Amazon, Shopify	Yes	Frequent updates, promotions, scalable architecture
Streaming	Netflix, Spotify, YouTube	Yes	Personalized content, high deployment frequency
SaaS Platforms	GitHub, Slack, Notion	Yes	Continuous delivery of features and improvements
Mobile Banking Apps	Revolut, Monzo	Yes (with strict controls)	Uses trunk-based, but gated CI/CD with approvals and audits
Machine Learning Platforms	Google AI, DataRobot	Yes	Automated training, testing, and deployment of models
Gaming Platforms	Riot Games, Steam backend	Yes	Requires fast patching and live updates
Search Engines	Google Search	Yes	Frequent deployments with strong guardrails and experimentation
Category	Application Example	Uses Trunk-Based + CI/CD?	Reason
------------------------------------	--------------------------------	-----------------------------	----------------------------------------------------------------
Aerospace Systems	SpaceX flight control software	Rarely	Mission-critical, safety risks, strict testing cycles
Medical Devices	Pacemaker firmware, MRI software	No	Regulated (FDA, ISO), requires extensive manual QA and approvals
Nuclear Power Systems	Reactor control software	No	Safety-critical, long QA and verification cycles
Automotive Safety Systems	Airbag software, ABS control	No	Functional safety (ISO 26262), formal verification needed
Industrial Control Systems	SCADA in power grids	Rarely	High risk of downtime, often manually tested and staged
Defense Systems	Missile guidance software	No	National security and safety requirements, formal certification
Traditional Banking Core Systems	COBOL-based mainframes	Rarely	Legacy tech, batch processing, risk-averse culture

[teflon]

@absc said in DevOps e' solo il termine piu' fallito della storia dell' IT:

@teflon

E chissà perché, lo fanno solo quei posti dove non viene creato nulla di importante.

This gives me back hope...

[teflon]

@sbz said in DevOps e' solo il termine piu' fallito della storia dell' IT:

@teflon said in DevOps e' solo il termine piu' fallito della storia dell' IT:

Cross-functional teams

Allora, sta cosa che DevOps e' cross-functional l'ho vista solo sulla carta. Nella grande maggioranza delle applicazioni che ho visto (grande confirmation bias, lo so) e' sempre lo stesso 'buttare il codice oltre la rete' (come diceva @amigaunicorn).

A mia esperienza, forzare sviluppatori ad avere oncall per escalation oncall con 30 minuti di ready time risolve il problema - o quanto meno li rende improvvisamente interessati a scrivere roba che funziona.

mi sono fatto l'idea che il devops sia gestito da dev che fanno dev e dev che si sono studiati devops che fanno le pipleline e qiundi facciano la parte ops

[teflon]

@philotette said in DevOps e' solo il termine piu' fallito della storia dell' IT:

Nella mia esperienza è cross-functional team nel senso che in ogni team ci sono N sviluppatori con bravura media 50 (di cui 45 in sviluppo) e UN DevOps bravo 150 (di cui 40 in sviluppo). Tale cristo è quello che mette su il codice, ferma qualche merdata prima che vada su, e quelle che non ferma le vede per primo e capisce quale sviluppatore cazziare. E ovviamente fa parte pure del team di devops, anch'esso con gente di diversa bravura.

Ho l'idea insomma che si è passati dall'avere team di sviluppo con un senior o chi per lui molto sveglio, che si assicura che il codice prodotto sia davvero buono e che rispetti tutti i crismi (documentazione, artefatti) per essere utile a ops, e un team di ops con l'equivalente altrettanto sveglio che si assicura che il codice vada e rimanga su.
A team di sviluppo e di ops con gente moderatamente brava, e una sorta di supervisione ops->dev implicita.

questo lo trovo molto interessante. Io sono nel mondo della consulenza e ho visto agli inizi degli anni 2000 cambiare le richieste da persone valide che costavano il giusto a piu' persone, non importa se scarse, ma che l'importante era che costassero meno A PERSONA.

[amigaunicorn]

@teflon said in DevOps e' solo il termine piu' fallito della storia dell' IT:

A mia esperienza, forzare sviluppatori ad avere oncall per escalation oncall con 30 minuti di ready time risolve il problema - o quanto meno li rende improvvisamente interessati a scrivere roba che funziona.

scordatelo. Il team di devops parte sempre, diciamo, con 10 dev e 10 sistemisti, ognuno che pretende di saper fare il lavoro dell'altro, se non altro almeno nella questione di creare ambienti di test e CI/CD, anche se la CD nessuno sano di mente la utilizza e si fanno ancora i golive schedulati.

E quindi abbiamo il glorioso team di DevOps, che contiene tutti gli skill che la skill matrix richiede.

Poi arriva il cliente. E dice: firmami lo SLA. I prio 1 , anche di notte, hanno dieci minuti per la prima risposta e preanalisi, e un'ora per la soluzione. Altrimenti scalano.

In quel momento, non e' che i dev si sforzeranno di scrivere codice che funziona. Semplicemente, i dev diranno che non fanno callout notturno, perche' poi l'indomani sono stanchi e non sviluppano bene. E quindi saranno esentati dal fare callout notturno. Da quel momento, solo quelli con gli skill di sysadmin saranno papabili, e diventeranno il team di callout. E quindi avrai due team separati, con orari di lavoro separati e procedure diverse:

• un team agile/scrum per i dev, che lavorano dalle 8 alle 17
• un team di sistemisti, che oltre alle CRQ per andare in produzione, si pippano l 24/7 e la reperibilita'.

e DevOps rimane sulla carta.

scene gia' viste ovunque.