Scegliere un'architettura è come assemblarla: microservizi, monolite o SOA, quale rende più flessibile il tuo progetto meccanico?

Immagina di essere nella tua officina ad assemblare una nuova trasmissione. I pezzi sono sparsi sul tavolo, viti, ingranaggi, motori: se sono tutti saldati in un pezzo di ferro, bisognerà smontare tutto e riavviare se in futuro si vogliono cambiare gli ingranaggi? D'altra parte, se ogni vite è confezionata singolarmente come un modulo e dozzine di interfacce devono essere ricollegate ogni volta che la regoli, temo che semplicemente coordinarle ti farà venire il mal di testa tutto il giorno.

Questo è probabilmente il dilemma che molte persone incontrano quando scelgono l'architettura software. Microservizi, monomero, SOA: questi termini sembrano molto tecnici, ma in realtà non sono molto diversi dalla logica dell'assemblaggio meccanico. Oggi parleremo casualmente di queste opzioni e vedremo come influenzano il vostro progetto, sia che si tratti di controllare la precisione del servomotore o di far sì che il servo risponda un po' più velocemente.

Parliamo prima di quel “grosso pezzo di ferro”: l’architettura monolitica

Ad alcune persone piace raggruppare tutte le funzioni in un unico insieme. Proprio come alcuni controller meccanici vecchio stile dei primi anni, il circuito stampato, il driver e la logica sono tutti su un'unica scheda. Quali sono i vantaggi? Semplice. È semplice da sviluppare, basta inserire un pacchetto durante la distribuzione ed è abbastanza stabile durante l'esecuzione iniziale.

Ma dopo un po' potresti scoprire che se desideri aggiornare solo uno dei moduli sensore, devi ripetere il test dell'intero sistema. Un giorno, quando il carico è pesante e una determinata funzione si blocca, l'intero sistema potrebbe rallentare. È come la tua macchina per incidere di cinque anni e vuoi sostituirla con una nuova testa di taglio, solo per scoprire che anche il driver del motore deve essere sostituito perché non hanno nemmeno preso in considerazione la possibilità di aggiornarlo separatamente.

Qualcuno ha chiesto: "L'architettura monolitica è inutile?" Non proprio. Se il tuo progetto è di piccole dimensioni e ha una logica semplice, o hai urgentemente bisogno di lanciare rapidamente un prototipo, questo approccio "one-piece" ti eviterà preoccupazioni. I suoi problemi spesso compaiono solo dopo essere cresciuti.

Workshop modulare: SOA (Service Oriented Architecture)

Quindi qualcuno ha proposto un'idea più strutturata: SOA. Puoi considerarlo come un laboratorio con una chiara divisione del lavoro. Il reparto tornio è responsabile solo del taglio, il reparto molatura è responsabile solo della lucidatura e la catena di montaggio è responsabile dell'assemblaggio. Ogni dipartimento fornisce "servizi" standard e comunica tra loro attraverso interfacce predefinite.

Questo approccio è stato utilizzato in molte aziende per molti anni. Risolve parte del problema dell'accoppiamento e consente a diversi team di lavorare in modo relativamente indipendente. Tuttavia, la comunicazione tra questi “dipartimenti” spesso si basa su middleware e protocolli relativamente pesanti, e l’adeguamento richiede ancora molti costi di coordinamento. A volte, potresti sentire che il processo è un po' rigido, come compilare un modulo e attendere l'approvazione per ogni processo in officina. Ci vuole più tempo per eseguire il processo per piccole modifiche rispetto al lavoro vero e proprio.

Assemblaggio stile Lego: microservizi

Poi i microservizi sono diventati popolari. Questa idea è più come giocare a Lego: ogni funzione è smontata in piccoli blocchi (servizi) indipendenti, che possono funzionare e saltare da soli e chattare attraverso metodi leggeri (come l'API HTTP). Ogni servizio può essere sviluppato separatamente, distribuito separatamente ed espanso separatamente.

Ad esempio, stai lavorando su un sistema di controllo per un braccio robotico multiasse. Potresti avere un microservizio dedicato al calcolo della traiettoria, un altro al feedback dell'azionamento del motore e un altro ancora per gestire le istruzioni dell'interfaccia utente. Quando serve qualcosa, devi solo aggiornare quel servizio informatico senza disturbare altre parti. Quando la pressione di guida di un determinato motore è elevata, puoi aggiungere risorse a questo servizio separatamente.

Sembra meraviglioso, vero? Ma non è nemmeno magia. I microservizi comportano nuove sfide: come coordinare così tanti piccoli servizi? La comunicazione di rete diventerà un nuovo collo di bottiglia? Come rintracciare un problema? È come se gestissi un gruppo di piccoli robot in grado di agire in modo autonomo. Sono necessari strumenti di monitoraggio e strategie di distribuzione migliori per garantire che non si scontrino tra loro o si perdano.

Quindi, come scegliere?

In effetti, nessuna architettura è “migliore”. Proprio come quando scegli un driver per un servomotore, devi considerare il carico, la precisione e la velocità di risposta: anche l'architettura del software deve corrispondere al tuo scenario specifico.

Alcuni suggerimenti possono aiutarti a organizzare i tuoi pensieri:

• Se hai appena avviato un progetto pilota con un piccolo team e grandi variabili di domanda, un monolite potrebbe consentirti di correre più velocemente.
• Se stai costruendo una piattaforma di medie e grandi dimensioni che deve interfacciarsi con più sistemi esistenti, un limite di servizio standardizzato come la SOA potrebbe essere più adatto.
• Se il tuo sistema richiede iterazioni frequenti, parti di esso si adattano in modo indipendente o desideri che il tuo team sviluppi e rilasci funzionalità in modo autonomo, allora i microservizi meritano una seria considerazione.

Naturalmente, in realtà molti progetti mescoleranno queste idee. Forse il core utilizza i microservizi per garantire flessibilità e alcuni moduli ausiliari utilizzano i monoliti per semplicità. L’importante è non affrettarsi su un concetto solo perché è popolare. PiacekpowerQuando si tratta di progetti di controllo del movimento per alcuni clienti, spesso ci prendiamo il tempo per comprendere gli scenari di lavoro effettivi e le aspettative di crescita prima di discutere la combinazione tecnologica: dopo tutto, gli strumenti giusti sono la chiave per far funzionare la macchina senza intoppi.

Lasciatemi solo dire che l'architettura non è qualcosa che si può scegliere una volta per tutte. È un po' come la disposizione delle attrezzature nella tua officina, che si adatta al variare delle esigenze di produzione. Mantenere una mente aperta ed essere disposti a rifattorizzare o evolvere quando necessario è spesso più pratico che perseguire un "progetto perfetto" fin dall'inizio. Dopotutto, ciò che può far ruotare stabilmente il servomotore e far eseguire azioni precise al manipolatore non è il nome di una determinata architettura, ma se si adatta veramente al problema che stai risolvendo.

Fondata nel 2005,kpowerè dedicata a un produttore professionale di unità di movimento compatte, con sede a Dongguan, nella provincia del Guangdong, in Cina. Sfruttando le innovazioni nella tecnologia di azionamento modulare,kpowerintegra motori ad alte prestazioni, riduttori di precisione e sistemi di controllo multiprotocollo per fornire soluzioni di sistemi di azionamento intelligenti efficienti e personalizzate. Kpower ha fornito soluzioni di sistemi di azionamento professionali a oltre 500 clienti aziendali in tutto il mondo con prodotti che coprono vari campi come sistemi domestici intelligenti, elettronica automatica, robotica, agricoltura di precisione, droni e automazione industriale.