Che termine usate per descrivere questa situazione? 🤔

[Matteo Mortari]

Ciao a tutti,
vi scrivo come individual contributor perché davvero vorrei un parere di questa community.

Sto cercando la parola che viene più usata per descrivere quel che succede/deve-accadere/inizia dopo che un servizio deployato nel cloud va giù...
Se usate Kubernetes o simili, siete più soliti dire: adesso devo iniziare a "debuggare" per capire cosa è successo, devo fare "troubleshooting" sul cluster, devo fare la "root cause analysis", ...?

Potete rispondermi direttamente qui; o per chi preferisce "allargare" questa conversazione sui socials:
https://www.linkedin.com/feed/update/urn:li:activity:7057754663697149953
https://www.youtube.com/post/UgkxuWxAgOf9q41BzKqvjiPAbKDG6K5OIXK6
https://twitter.com/tari_manga/status/1651989526946906113

Grazie anticipatamente, ormai sono troppo curioso in merito e spero di trovare ottimi spunti dai vostri riscontri; in ogni caso grazie anticipatamente! 🙏
Ciao,
MM

--

Matteo Mortari

youtube.com/@MatteoMortari

linkedin.com/in/matteomortari

[Raf]

Ciao, non sono ammesse altre varianti sul tema tipo "devo capire che azz è successo?" :D 

Scherzi a parte, a me viene più spontaneo utilizzare il termine troubleshooting per cercare di capire cosa sia successo e come risolvere.

Il termine debuggare lo associo di più alla ricerca di errori all'interno di un programma che non funziona, mentre il termine root cause analysis lo utilizziamo in genere quando si verifica qualche "disastro", magari scatenato da più concause, con impatti in qualche modo significativi sull'operatività tali da giustificare di riportarli nel registro degli incidenti, con relativa analisi di cosa è successo e identificazioni delle azioni correttive da mettere in atto per evitare che si ripeta.

JM2c

Raf

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/CAHOoiErRMC%3D-oNH3Wrf3S_DPK%2B%3D%2Bdo7vojtmzJtvPN%2B-6mSxWg%40mail.gmail.com.

[Simone Bordet]

Ciao,

On Wed, May 3, 2023 at 9:05 PM Matteo Mortari <matteo....@gmail.com> wrote:
>

> Ciao a tutti,
> vi scrivo come individual contributor perché davvero vorrei un parere di questa community.
>
> Sto cercando la parola che viene più usata per descrivere quel che succede/deve-accadere/inizia dopo che un servizio deployato nel cloud va giù...

> Se usate Kubernetes o simili, siete più soliti dire: adesso devo iniziare a...

Buttare via Kubernetes.

:D

--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

[Roberto Franchini]

On Wed, 3 May 2023, 21:05 Matteo Mortari, <matteo....@gmail.com> wrote:

Ciao a tutti,
vi scrivo come individual contributor perché davvero vorrei un parere di questa community.

Sto cercando la parola che viene più usata per descrivere quel che succede/deve-accadere/inizia dopo che un servizio deployato nel cloud va giù...
Se usate Kubernetes o simili, siete più soliti dire: adesso devo iniziare a

Invocare le tue divinità preferite nel modo che ti è più consono: la preghiera e la blasfemia sono entrambe valide.

Ricorda che puoi attingere a svariati pantheon. 

[Gian Carlo Pace]

From: jugt...@googlegroups.com <jugt...@googlegroups.com> on behalf of Simone Bordet <simone...@gmail.com>

> Buttare via Kubernetes.
>
> :D

Ho letto un articolo di DHH a tal proposito che, come al solito, la tocca piano dicendo:

 

“In many ways, microservices is a zombie architecture. Another strain of an intellectual contagion that just refuses to die. It's been eating brains since the dark days of J2EE (remote server beans, anyone??) through the WS-Deathstar nonsense, and now in the form of microservices and serverless.”

 

E cita anche Kelsey Hightower che dice:

 

"We’re gonna break [the monolith] up and somehow find the engineering discipline we never had in the first place... Now you went from writing bad code to building bad infrastructure. 

 

Because it drives a lot of new spend, it drives a lot of new hiring… So a lot of people get addicted to all the flourishment of money, and marketing, and it’s just a lot of buzz that people are attaching their assignment to, when honestly it’s not gonna necessarily solve their problem."

 

Se foste interessati all’articolo lo trovate qui: https://world.hey.com/dhh/even-amazon-can-t-make-sense-of-serverless-or-microservices-59625580

 

Ciao!

--

Gk

 

 

[Marco Bartolini]

Buttare via Kubernetes sottoscrivo!

sull'articolo di DHH, direi che il punto chiave di lettura e' nella frase:

But, as with many good ideas, this pattern turned toxic as soon as it was adopted outside its original context, and wrecked havoc once it got pushed into the internals of single-application architectures.

 tutte le soluzioni hanno pro e contro

https://www.youtube.com/watch?v=GBTdnfD6s5Q&t=230s

questa e' una bella chiacchierata sull'argomento tra Martin Fowler e Sam Newman, registrata tempo fa, sono meno sensazionalistici come modello d'informazione, ma piu' obiettivi secondo me :)

ps

Buttare via K8s!

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/GV1P193MB221317EFFA162822E5C775D6AC6D9%40GV1P193MB2213.EURP193.PROD.OUTLOOK.COM.

[Massimo Ugues]

Mi spiace andare OT ma le considerazioni uscite dal thread originale sono interessanti: quando parlate di buttare via k8s intendente l’utilizzo diretto o tutte le infrastrutture create sopra? (e.g. OpenShift).

E nel qual caso vi posso chiedere le principali motivazioni ed alternative?

Max

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/CAMYu_7PuAmHwKNqNgHwy4YJ6HxkwW4jAm70ra1bQ1KG4KvXUWA%40mail.gmail.com.

--

Massimo Ugues

[steferk]

Rincaro pesantemente l'OT. (Mi dispiace per OP, ma non mi dispiace abbastanza da non farlo '-__- )

Mi incuriosisce il passaggio da Kubernetes a microservizi...

Cioè io (da ignorante, mai approfondito, magari sbaglio...) metto Kubernetes in una scatola "modalità di deploy".

I microservizi li intendevo come, ecco come scatola sarebbe "organizzazione struttura + architettura software". 

Cioè se sviluppo un microservizio io mi immagino che se ho un vecchio PC libero che regge il carico mi copio il microservizio nella cartella di tomcat e sempre microservizio è.... o lo metto su una VM (non docker) e il servizio/coso lo devo scrivere (quasi) uguale...

D'altro canto ho visto dei monoliti che presi e deployati su Kubernetes diventavano "microservizi".

E anche qui si passa da microservizi a Kubernetes e viceversa... che sembrano la stessa cosa. Anche a me era sfuggito il salto le prime due volte che ho letto.

Mi ha colpito la discrepanza leggendo l'articolo citato da Gian Carlo.

Qualcuno magari mi sa puntare al perché microservizio = Kubernetes? o__o'

--

[Andrea Del Bene]

Grazie per la segnalazione. Parole da incorniciare:

"Bingo. Replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in almost all cases. "

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/CAMYu_7PuAmHwKNqNgHwy4YJ6HxkwW4jAm70ra1bQ1KG4KvXUWA%40mail.gmail.com.

[Raf]

On Thu, May 4, 2023 at 3:47 PM Andrea Del Bene <andrea....@host.it> wrote:

Grazie per la segnalazione. Parole da incorniciare:
"Bingo. Replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in almost all cases. "

Vero, ma ci sono dei vincoli in questa frase: "within a single, coherent team and application".

Se vi capitasse di dover analizzare dei (milioni di) documenti con:

* un analizzatore morfologico implementato in C 

* una serie di componenti a regole implementati in Java / Drools / Lucene

* algoritmi di M/L implementati in Python / Tensorflow 

* algoritmi di clustering realizzati in R

ognuno con il suo carico di lavoro (non tutti i documenti passano dappertutto) e tempi di risposta anche molto differenti, davvero buttereste via K8s? 🤔

Il fatto che, probabilmente in molti casi, sia utilizzato a sproposito non lo rende necessariamente uno strumento "sbagliato".

Quindi, anche se in controtendenza rispetto al resto del thread, non butterò K8s... almeno per il momento 😀

JM2c,

Raf

<CUT>

[Alessandro Bx]

K8s dove lavoro è anche anche Infrastructure as code e la possibilità di utilizzare java 17 , penso che non lo butterò via nemmeno io.

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/CAGNBUw2F0mYB-pvBQdNUnpqG6xh%2Bj1U-9TKa9xAevmGVtsQcXA%40mail.gmail.com.

[Gian Carlo Pace]

Nel mondo IT le parole giuste sono sempre trade-off e it depends 😊

 

Ci sono molti casi in cui architetture a microservizi hanno valore di business anche se probabilmente sono molti meno di quelli in cui vengono utilizzati.

 

Giusto per fornire altri punti di vista, in questo tweet ci sono considerazioni interessanti rispetto a serverless e microservices: https://twitter.com/theburningmonk/status/1654115131209424899?s=12&t=FeXzMEHHzV0T_1YdXtijXA

 

Ciao!

--

Gk

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/CA%2B5tP6qDFJF1YEAWLDWjkcsCm4W8Ez0_ytyyoqjdEbZ0eg0ung%40mail.gmail.com.

[Danilo Ventura]

A volte comincia lo "scarica barile" 😀 

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "JUG Torino - JVM User Group Torino" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a jugtorino+...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/jugtorino/CAHOoiErRMC%3D-oNH3Wrf3S_DPK%2B%3D%2Bdo7vojtmzJtvPN%2B-6mSxWg%40mail.gmail.com.

[Roberto Cappa]

Ho visto usare Kubernetes per tirare su DUE (presunti) microservizi: il front-end e il back-end. Alla domanda "ma perchè???" mi è stato risposto: "alla fine oggi tutti usano Kubernetes, è uno standard di mercato". A posto.