Quando il tuo progetto è bloccato nel dibattito su "microservizi o monolite"

Immagina: la riunione del team è entrata nella terza ora, la lavagna è piena di scatole e frecce, il caffè è stato bevuto, ma il dibattito sull'architettura non si è fermato: "I microservizi sono più flessibili!" "Ma la distribuzione monolitica è più semplice!" In questo momento, vuoi solo qualcosa che possa realmente muoversi, invece di restare nei dibattiti teorici?

Spesso pensiamo che la selezione della tecnologia sia una questione puramente software, ma quando inizi effettivamente a costruire prodotti, scoprirai che gli attuatori nel mondo fisico, come servo precisi e servomotori affidabili, sono spesso le mani che realizzano le idee. Indipendentemente dall'architettura utilizzata nel backend, ciò che l'utente finale ritiene è se la parte meccanica è fluida e se la risposta è tempestiva.

Perché le prestazioni dell'hardware dovrebbero influenzare le decisioni sul software?

Qualcuno mi ha chiesto: "Utilizziamo microservizi nel backend. Anche la parte di controllo motore dovrebbe essere suddivisa in moduli indipendenti?" In effetti, non è necessario copiarlo meccanicamente. L'architettura software risolve i problemi di scalabilità e manutenibilità, mentre la selezione dell'hardware si concentra su precisione, coppia e velocità di risposta. Ad esempio, se si progetta un dispositivo di visualizzazione automatizzato, il software può essere aggiornato frequentemente in modo iterativo, ma lo sterzo interno è accurato la prima volta: non ha alcuna possibilità di "aggiornamento a caldo".

kpowerQuando si affronta questo tipo di progetti è stato scoperto un fenomeno interessante: molti team passano molto tempo a discutere sull'architettura software, ma per impostazione predefinita "ci sarà sempre un modo" nella parte hardware. Il risultato è spesso un sistema dal design accattivante, ma l'esperienza complessiva è compromessa a causa della mancanza di precisione degli attuatori meccanici.

Allora come uscire da questo ciclo?

Pensa prima chiaramente a quali azioni desideri, quindi guarda indietro a quale struttura è necessaria.

Ad esempio, se crei un dispositivo di visualizzazione interattivo:

• Hai bisogno di una rapida regolazione dell'angolo? Quindi la velocità di reazione è la chiave
• Hai bisogno di sollevare una certa quantità di peso senza problemi? Quella coppia e stabilità sono più importanti
• Hai bisogno di funzionare continuamente per molto tempo? La durabilità e la dissipazione del calore dovrebbero essere prioritarie

Questi determinano quale motore scegliere e influenzano indirettamente anche la progettazione del software della parte di controllo. Un motore che richiede un elevato controllo in tempo reale può essere più adatto per un accoppiamento stretto con il controller; for scenarios that require high accuracy but not extreme real-time requirements, a microservice approach through API calls may be neater.

Risposte alle domande più frequenti

"Abbiamo un budget limitato. Dovremmo accontentarci prima di motori economici e poi aggiornarli?" È un po' come costruire un edificio alto con impalcature fragili: la sostituzione successiva spesso significa riprogettare la struttura.kpoweruna volta gli ingegneri aiutarono un team a pianificare: inizialmente prevedevano di utilizzare motori a basso costo per verificare prima l'idea, ma il test ha rilevato che l'errore di precisione impediva la calibrazione dell'intero sistema di feedback. Successivamente, il modello è stato riselezionato, il che ha aumentato il costo iniziale del 15%, ma ha consentito di risparmiare almeno due mesi di tempo nella rimessa a punto del sistema.

"Nell'architettura dei microservizi, come dovrebbe essere progettata la parte di controllo hardware?" Non è necessario disporre di microservizi per il bene di "microservizi". Tratta la parte che interagisce direttamente con l'hardware come un limite di servizio indipendente e definisci l'interfaccia in base alle caratteristiche di risposta dell'hardware. Se un motore richiede una risposta in millisecondi, non lasciarlo passare attraverso troppi livelli di servizio. L’architettura serve degli obiettivi, non il contrario.

Dettagli invisibili, risultati visibili

L'anno scorso, un team ha creato un sistema dimostrativo di stoccaggio intelligente. L'architettura del software era elegante e bella. Tuttavia, durante la dimostrazione sul posto, il servo di manovra ha sempre vibrato leggermente nelle posizioni chiave. Il problema non è la logica del software, ma la mancanza di stabilità del motore alle basse velocità. Successivamente sono passati a un modello più adatto a scenari a bassa velocità e il problema è scomparso.

Questo genere di cose non è raro. Si dedica molto tempo alla progettazione di suddivisioni di servizi, database e definizioni di interfaccia perfette, ma la sensazione più intuitiva per gli utenti è spesso se il braccio robotico è fluido, se la piattaforma rotante è silenziosa e se il posizionamento è accurato.

Quindi, la prossima volta che hai una riunione...

Quando la discussione rientra nel ciclo di "quale architettura è migliore", prova a cambiare la domanda: "Quale movimento fisico vogliamo ottenere? Quanto deve essere veloce, preciso e potente questo movimento?"

La risposta è spesso molto più chiara. L'architettura software può essere continuamente modificata e ricostruita, ma una volta integrato l'hardware, il costo di sostituzione è molto più elevato. Ancorare prima gli indicatori principali dell'hardware e poi lasciare che sia l'architettura software a corrispondervi, e non viceversa.

Le buone decisioni tecniche non riguardano la scelta della risposta “giusta”, ma il lasciare che ciascuna parte faccia ciò che sa fare meglio. Il motore è responsabile dell'esecuzione precisa, il software è responsabile della pianificazione flessibile e il tuo team è responsabile della creazione di valore: in questo modo, indipendentemente dal fatto che il backend sia un microservizio o un monolite, il front-end offre agli utenti un'esperienza fluida e affidabile.

In definitiva, agli utenti non interessa quanto sia dettagliato il tuo servizio, a loro interessa solo che il prodotto funzioni come previsto. Il passo che fa sì che le aspettative diventino realtà inizia spesso da un motore adatto.

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, Kpower integra 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.