DevOps e' solo il termine piu' fallito della storia dell' IT
-
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.
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
-
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
E chissà perché, lo fanno solo quei posti dove non viene creato nulla di importante.
Un'ascia e' per sempre
-
Io l'ho sempre visto come un tentativo di risparmiare sull'ops fatto da chi non ha idea di cosa vuol dire fare ops...
-
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 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.
-
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. -
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 
YesFast iteration, A/B testing, rapid feature rollout eCommerce Amazon, Shopify YesFrequent updates, promotions, scalable architecture Streaming Netflix, Spotify, YouTube YesPersonalized content, high deployment frequency SaaS Platforms GitHub, Slack, Notion YesContinuous 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 YesAutomated training, testing, and deployment of models Gaming Platforms Riot Games, Steam backend YesRequires fast patching and live updates Search Engines Google Search YesFrequent deployments with strong guardrails and experimentation Category Application Example Uses Trunk-Based + CI/CD? Reason ------------------------------------ -------------------------------- ----------------------------- ---------------------------------------------------------------- Aerospace Systems SpaceX flight control software 
RarelyMission-critical, safety risks, strict testing cycles Medical Devices Pacemaker firmware, MRI software NoRegulated (FDA, ISO), requires extensive manual QA and approvals Nuclear Power Systems Reactor control software NoSafety-critical, long QA and verification cycles Automotive Safety Systems Airbag software, ABS control NoFunctional safety (ISO 26262), formal verification needed Industrial Control Systems SCADA in power grids RarelyHigh risk of downtime, often manually tested and staged Defense Systems Missile guidance software NoNational security and safety requirements, formal certification Traditional Banking Core Systems COBOL-based mainframes RarelyLegacy tech, batch processing, risk-averse culture -
E chissà perché, lo fanno solo quei posti dove non viene creato nulla di importante.
@absc said in DevOps e' solo il termine piu' fallito della storia dell' IT:
E chissà perché, lo fanno solo quei posti dove non viene creato nulla di importante.
This gives me back hope...
-
@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.
@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
-
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.@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.
-
@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 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.
“Il deuterio è come il Grana Padano”. (J.R.Oppenheimer)
-
@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.
@amigaunicorn said in DevOps e' solo il termine piu' fallito della storia dell' IT:
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
Per fortuna nel mio settore queste richieste non capitano, ma il concetto e' molto chiaro.
Quindi gli ops, nelle realta fuori italia, ricevono una bella indennita per la reperibilita' e guadagnano piu' dei dev ? -
@amigaunicorn said in DevOps e' solo il termine piu' fallito della storia dell' IT:
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
Per fortuna nel mio settore queste richieste non capitano, ma il concetto e' molto chiaro.
Quindi gli ops, nelle realta fuori italia, ricevono una bella indennita per la reperibilita' e guadagnano piu' dei dev ?@teflon questo dipende dall'azienda, ma il punto e' che quando ci sono veri SLA, i team di devops si spezzano in due.
