8 Novembre 2019 @ ContainerDay (GrUSP) / Bologna Con l'acronimo KISS (Keep It Simple and Stupid) si evoca un modo di fare software antico: la UNIX Way. Ma non è tutto racchiuso lì dentro, si tratta piuttosto di una filosofia progenitrice del movimento DevOps. Declinata oggi nel mondo Linux da migliaia di tecnici e organizzazioni, che include assunti come modularità, semplicità, composizione e chiarezza nel fare. Tutto evolve portandosi dietro principi solidi e al tempo stesso pronti al cambiare: dai modelli open-source ai flussi Git, dalla gestione dei pacchetti ai container, dalle infrastrutture a risorse finite agli orchestratori del cloud; fino a mescolare le definizioni stesse di sistema operativo e applicazione tra user-space e kernel-space. Henry Spencer, padre delle RegEx, scrisse coloro che non capiscono Unix sono condannati a inventarlo di nuovo. In questo talk racconto ciò che ho imparato da questa filosofia che già in tempi non sospetti si occupava di sistemi complessi, e ha ancora molto da regalare a chi è coinvolto nella produzione e nel mantenimento di software.

1. Fabio Mora
@fabiomora — fabiomora.com
Il contenuto è disponibile in licenza CC-BY-SA 4.0, salvo diversamente specificato. — Citazioni e [ref] a fine presentazione.
LA «UNIX WAY»
VISTA DA UN DEVOPS

2. NASCONO INFRASTRUTTURE,
EVOLVONO I MERCATI…
IL CONTESTO

3. Fonte Immagini [1]

4. Fonte Immagini [2]

5. Fonte Immagini [3, 4, 5]

6. Fonte Immagini [3, 4, 5]

7. Fonte Immagini [3, 4, 5]

8. Fonte Immagini [3, 4, 5]

9. “Futuro” del computing
Memorie elettroniche (RAM & dischi)
Consentono di caricare i programmi e dati, segnano la fine delle
schede perforate.
Multi-programmazione
Un solo mainframe può poter gestire più job in contemporanea.
Time-sharing
Il Sistema Operativo può mettere in pausa un job e proseguire
con l'esecuzione di un altro, salvando lo stato in memoria.
Spooling
Possibilità di comunicare con altri dispositivi (stampanti,
registratori magnetici) attraverso buffer o code.

10. “Futuro” del computing
Memorie elettroniche (RAM & dischi)
Consentono di caricare i programmi e dati, segnano la fine delle
schede perforate.
Multi-programmazione
Un solo mainframe può poter gestire più job in contemporanea.
Time-sharing
Il Sistema Operativo può mettere in pausa un job e proseguire
con l'esecuzione di un altro, salvando lo stato in memoria.
Spooling
Possibilità di comunicare con altri dispositivi (stampanti,
registratori magnetici) attraverso buffer o code.scheduling
automatico

11. “Futuro” del computing
Memorie elettroniche (RAM & dischi)
Consentono di caricare i programmi e dati, segnano la fine delle
schede perforate.
Multi-programmazione
Un solo mainframe può poter gestire più job in contemporanea.
Time-sharing
Il Sistema Operativo può mettere in pausa un job e proseguire
con l'esecuzione di un altro, salvando lo stato in memoria.
Spooling
Possibilità di comunicare con altri dispositivi (stampanti,
registratori magnetici) attraverso buffer o code.scheduling
automatico
sistemi
operativi

12. NEL FRATTEMPO
…EVOLVONO I PROBLEMI,
AUMENTA LA COMPLESSITÀ

13. Arriva Unix
Unix nasce da un progetto troppo complesso: Multics
Nel 1969 Ken Thompson progettava un videogioco a tema
“spazio”. Desidera usare il time-sharing

14. KEEP IT SIMPLE, STUPID
LA UNIX WAY
– M. Douglas McIlroy

15. Uno stile modulare di strutturazione dei sistemi.
Si procede per mattoncini piccoli, semplici, efficienti
e riutilizzabili.
Ci permette di gestire la complessità dei problemi
grazie all’uso di regole e principi infrastrutturali.
LA UNIX WAY

16. Uno stile modulare di strutturazione dei sistemi.
Si procede per mattoncini piccoli, semplici, efficienti
e riutilizzabili.
Ci permette di gestire la complessità dei problemi
grazie all’uso di regole e principi infrastrutturali.
LA UNIX WAY
La formulazione più “antica” include 4 principi

17. Principio #1
Ogni programma deve fare una sola cosa e bene
Meglio fare un nuovo programma che prenderne uno vecchio e aggiungere
funzionalità

18. Principio #1
Ogni programma deve fare una sola cosa e bene
Meglio fare un nuovo programma che prenderne uno vecchio e aggiungere
funzionalità
https://github.com/coreutils/coreutils/blob/master/src/tail.c
https://github.com/coreutils/coreutils/blob/master/src/head.c

19. Principio #1
Single Responsibility Principle
Un componente deve fare una sola cosa e bene
Open/Closed Principle
I nuovi requisiti (non funzionali) sono soddisfatti
aggiungendo componenti, non modificando quelli
esistenti
…OGGI
Robert C. Martin (Uncle Bob)

20. Principio #2
Ci aspettiamo che l’output (risultato) di tutti
programmi possa diventare l’input (dati in ingresso)
di altri programmi sconosciuti
Meglio evitare formati tabulari o binari per rappresentare i dati, così come
l’input interattivo.

21. Principio #2
Ci aspettiamo che l’output (risultato) di tutti
programmi possa diventare l’input (dati in ingresso)
di altri programmi sconosciuti
Meglio evitare formati tabulari o binari per rappresentare i dati, così come
l’input interattivo.

22. Principio #2
Ci aspettiamo che l’output (risultato) di tutti
programmi possa diventare l’input (dati in ingresso)
di altri programmi sconosciuti
Meglio evitare formati tabulari o binari per rappresentare i dati, così come
l’input interattivo.

23. Principio #2
…OGGI
Mark Richards, Software Architecture Patterns, O’Reilly, 2015, p. 56.

24. Principio #2
…OGGI
Mark Richards, Software Architecture Patterns, O’Reilly, 2015, p. 56.

25. Principio #3
Disegnate e costruite il software, inclusi i sistemi
operativi, perché vengano provati frequentemente.
Non esitate a buttare via parti goffe e rifarle da capo.

26. Principio #3
Disegnate e costruite il software, inclusi i sistemi
operativi, perché vengano provati frequentemente.
Non esitate a buttare via parti goffe e rifarle da capo.

27. Principio #3
…OGGI

28. Principio #4
Preferite gli strumenti adatti anche ai tecnici meno
esperti e alle applicazioni più leggere
Anche se avete bisogno di modificare la rotta per buttare via quelli vecchi.

29. Principio #4
Preferite gli strumenti adatti anche ai tecnici meno
esperti e alle applicazioni più leggere
Anche se avete bisogno di modificare la rotta per buttare via quelli vecchi.

30. Principio #4
Preferite gli strumenti adatti anche ai tecnici meno
esperti e alle applicazioni più leggere
Anche se avete bisogno di modificare la rotta per buttare via quelli vecchi.

31. Principio #4
…OGGI (o quasi 🤓)

32. L’OPEN SOURCE,
I METODI PER FARE
SOFTWARE
COSA HO IMPARATO #1

33. GNU IS NOT UNIX
Richard Stallman nel 1977 inizia a lavorare a un clone di Unix,
con licenza libera e codice aperto
La suite GNU è lo user-space, da scrivere
da zero. Il lavoro sarà completato solo nel 1981
Il progetto Hurd invece è il futuro kernel-space

34. GNU IS NOT UNIX
Richard Stallman nel 1977 inizia a lavorare a un clone di Unix,
con licenza libera e codice aperto
La suite GNU è lo user-space, da scrivere
da zero. Il lavoro sarà completato solo nel 1981
Il progetto Hurd invece è il futuro kernel-space

35. Sto realizzando un sistema operativo free
(è solo per hobby […]) per cloni 386 (486) AT
[…]. Mi piacerebbe avere la vostra
opinione […] sapere quali sono le
caratteristiche che interessano di più alla
gente. Tutti i suggerimenti sono bene accetti :-)
– Linus Torvalds, 1991
Linus Torvalds nel 1991 inizia a lavorare a un kernel giocattolo
GNU/LINUX

36. Sto realizzando un sistema operativo free
(è solo per hobby […]) per cloni 386 (486) AT
[…]. Mi piacerebbe avere la vostra
opinione […] sapere quali sono le
caratteristiche che interessano di più alla
gente. Tutti i suggerimenti sono bene accetti :-)
– Linus Torvalds, 1991
Linus Torvalds nel 1991 inizia a lavorare a un kernel giocattolo
Nel 1999 Eric Raymond pubblica La cattedrale e il Bazaar:
metodi di produzione e conoscenza aperta sono fondamentali
GNU/LINUX

37. I METODI PREDITTIVI
2019 © Fabio Mora, Massimo Airoldi
IMMAGINIAMO E COSTRUIAMO

38. METODI ITERATIVI E INCREMENTALI
IMMAGINIAMO E VERIFICHIAMO: FEEDBACK
2019 © Fabio Mora, Massimo Airoldi

39. CONTRIBUTI DISTRIBUITI,
LE PIATTAFORME
COSA HO IMPARATO #2

40. https://www.youtube.com/watch?v=4XpnKHJAok8
2005: git è uno strumento estremamente
versatile che risolve un problema di metodo

41. https://www.youtube.com/watch?v=4XpnKHJAok8
2005: git è uno strumento estremamente
versatile che risolve un problema di metodo
«Quando sei in dubbio, fai il contrario di ciò che fa CVS»
– Linus Torvalds

42. 2008: GitHub rimodella il
concetto di Pull Request
creando uno standard de-facto
nei processi di contribuzione

43. 2009: Heroku è la prima
azienda ad arrivare al grande
pubblico con il concetto di
Platform-as-a-Service
2008: GitHub rimodella il
concetto di Pull Request
creando uno standard de-facto
nei processi di contribuzione

44. 2009: Heroku è la prima
azienda ad arrivare al grande
pubblico con il concetto di
Platform-as-a-Service
Il disegno e la qualità delle piattaforme, dei processi è
fondamentale per il successo della contribuzione
2008: GitHub rimodella il
concetto di Pull Request
creando uno standard de-facto
nei processi di contribuzione

45. DISEGNARE APP,
ESEGUIRE SERVIZI
…CONTAINER
COSA HO IMPARATO #3

46. Monoliti da smontare
Una codebase, tante responsabilità… Non scala orizzontalmente!
Illustrazioni in licenza CC-BY-SA 4.0, di Matteo Vaccari [Vac14]

47. Monoliti da smontare
Una codebase, tante responsabilità… Non scala orizzontalmente!
Illustrazioni in licenza CC-BY-SA 4.0, di Matteo Vaccari [Vac14]

48. Gestire gli errori
La (J)VM è velocissima, ma gli errori commessi dai dev possono sono pericolosi…
Illustrazioni in licenza CC-BY-SA 4.0, di Matteo Vaccari [Vac14]

49. Gestire gli errori
La (J)VM è velocissima, ma gli errori commessi dai dev possono sono pericolosi…
Illustrazioni in licenza CC-BY-SA 4.0, di Matteo Vaccari [Vac14]

50. Gestire gli errori
La (J)VM è velocissima, ma gli errori commessi dai dev possono sono pericolosi…
Illustrazioni in licenza CC-BY-SA 4.0, di Matteo Vaccari [Vac14]

51. Infrastructure as a Code
Dal concetto di risorse finite, a quelle infinite. Le infrastrutture diventano script.
2019 © Fabio Mora

52. DUE SFIDE…
OGGI E DOMANI
PER CONCLUDERE

53. Linux e la semplicità? Un trade-off in systemd
Dal job (gestiti dal S.O.) ci spostiamo verso il più complesso concetto daemon

54. Linux e la semplicità? Un trade-off in systemd
Dal job (gestiti dal S.O.) ci spostiamo verso il più complesso concetto daemon

55. Linux e la semplicità? Un trade-off in systemd
Dal job (gestiti dal S.O.) ci spostiamo verso il più complesso concetto daemon
L’intento è semplificare il lavoro del sistemista, ma ancora fonte di accese dispute

56. Da risorse finite a infinite? “Containerizzare” il D.C.
La complessità non sparisce, si sposta dalle applicazioni all’infrastruttura.
In buzzword? Invisible infrastructures

57. Da risorse finite a infinite? “Containerizzare” il D.C.
La complessità non sparisce, si sposta dalle applicazioni all’infrastruttura.
In buzzword? Invisible infrastructures

58. Da risorse finite a infinite? “Containerizzare” il D.C.
La complessità non sparisce, si sposta dalle applicazioni all’infrastruttura.
In buzzword? Invisible infrastructures
Esiste uno standard per i container (OCI). Non per le infrastrutture.
Un inizio? Google Anthos

59. NON FINISCE QUI…
APPENDICI

60. «Il Sistema Operativo è tuo amico.
Usalo a tuo vantaggio!» – Matteo Vaccari
/proc
/dev
POSIX
signals
copy-on-write
inodes
chown
permissions
descriptors
LXC
libvirt
chroot
jail
capabilities
everything-is-a-file
cgroups
namespaces
netlink
sockets
socat
netfilter
coreutilsTCP/IP

61. 1. Modularità
2. Chiarezza
3. Composizione
4. Separazione
5. Semplicità
6. Parsimonia
7. Trasparenza
8. Robustezza
9. Rappresentazione
10. Non sorprendere
11. Silenzio
12. Riparazione
13. Economia
14. Generazione
15. Ottimizzazione
16. Diversità
17. Estensibilità
https://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond's_17_Unix_Rules
«Coloro che non capiscono Unix sono
condannati a inventarlo di nuovo, con
scarsi risultati» – Henry Spencer

62. https://en.wikipedia.org/wiki/Unix

63. Fonti e bibliografia
Pubblicazioni
• [Beck05] Kent Beck, Cynthia Andres, Extreme Programming Explained – Embrace Change, Addison-Wesley, Boston 2005.
• Eric S. Raymond, The art of UNIX programming, Pearson Education, 2004.
• Peter H. Salus, A Quarter Century of UNIX, Addison-Wesley Professional, 1994.
• Robert L. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley, 2013.
• Craig Larman, Agile & Iterative Development: A Manager’s Guide, Addison-Wesley Professional, 2004.
• Luigi Federico Menabrea, Sketch of The Analytical Engine Invented by Charles Babbage, Officer of the Military Engineers, Torino
1842, No. 82.
• Linus Torvalds, David Diamond, Rivoluzionario per caso, Garzanti, Milano 2011.
• Gerald M. Weinberg, How Software Is Built, Leanpub, 2014 (https://leanpub.com/howsoftwareisbuilt).
• James P. Womack, Daniel T. Jones, Lean Thinking, Productivity Press, 1996.
• Tim Wu, The Master Switch: The Rise and Fall of Information Empires, Atlantic Books, London 2010.
• Betsy Beyer et alii, Site Reliability Engineering, Google, 2016.
Immagini
1. https://www.theguardian.com/technology/2015/apr/12/thrilling-adventures-ada-lovelace-charles-babbage-sydney-padua
2. https://www.google.com/about/datacenters/
3. https://www.scienceandsociety.co.uk (#10303273, Punched cards for Babbage's Analytical Engine)
4. https://www.ibm.com/ibm/history/ibm100/us/en/icons/system360/transform/
5. https://it.wikipedia.org/wiki/ENIAC#/media/File:Eniac.jpg
6. https://it.wikipedia.org/wiki/Robert_Cecil_Martin#/media/File:Robert_Cecil_Martin.png
7. https://www.worldcat.org
8. https://www.zdnet.com/article/after-linux-civil-war-ubuntu-to-adopt-systemd/

64. Fonti e bibliografia
Articoli, paper e talk
• [Vac14] Matteo Vaccari, The UNIX Way vs. the Java Enterprise Edition Way, 2014(https://www.slideshare.net/xpmatteo/the-unix-
way-vs-the-java-enterprise-edition-way)
• Matteo Vaccari, Extreme Programming, Agile For Innovation, Milano, 2014 (slideshare.net/xpmatteo/extreme-
programming-32324409)
• Unix Time-Sharing System, Bell System Technical Journal, 1978 (http://emulator.pdp-11.org.ru/misc/1978.07_-
_Bell_System_Technical_Journal.pdf)
• John D. Cook, Where the Unix philosophy breaks down, 30 giugno 2010 (https://www.johndcook.com/blog/2010/06/30/where-
the-unix-philosophy-breaks-down/)
• Patrick Debois, Agile Infrastructure & Operations, Agile 2008 Conference (http://www.jedi.be/presentations/agile-infrastructure-
agile-2008.pdf)
• Dennis M. Ritchie, Ken Thompson, The UNIX Time Sharing System, Bell Laboratories, 1974 (https://people.eecs.berkeley.edu/
~brewer/cs262/unix.pdf)
• Massimo Ubertini, Architettura degli elaboratori (http://www.ubertini.it/pagine/archi-elab.html)
• Chris Tozzi, Want to understand DevOps? Look to open source’s history (https://devopsagenda.techtarget.com/opinion/Want-to-
understand-DevOps-Look-to-open-sources-history).
• Janet Kornblum, Netscape sets source code free, 31 marzo 1998 (https://www.cnet.com/news/netscapesets-source-code-free/).
• Linus Torvalds, Tech Talk: Linus Torvalds on git (https://www.youtube.com/watch?v=4XpnKHJAok8).
• https://www.cnet.com/news/test-version-of-new-linux-kernel-available/
• http://linux.sys-con.com/node/32707
• https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016

65. Libri libri libri…

66. Ho scritto questo. Da settembre è in tutte le librerie ☺ E qui: http://bit.ly/2pBuiQh

67. GRAZIE!
🤗
Suggerimenti?
joind.in/talk/1c2c9
@fabiomora — fabiomora.com