Microservizi e tempo di produzione [chiuso]

Now, let say a company implemented microservices and each team is responsible for it's own microservice.

Questo è un errore. Una società può implementare molti servizi da diversi team, ma è un unico team di produzione che sarà responsabile di mantenerlo in esecuzione. Ciò significa che i team di sviluppo dovranno fornire una quantità sufficiente di documentazione e / o strumenti per garantire che possano svolgere il proprio lavoro. Che non è molto diverso da qualsiasi altra architettura.

On other hand, you can't centralize Ops with microservices, because each microservice may have different technological stack, different way of troubleshooting and monitoring

Certo, ma ancora una volta - questo significa solo che la documentazione per mantenerla in esecuzione deve essere più completa che se il team di sviluppo avesse prodotto un sistema standard utilizzando strumenti esistenti (come una piattaforma di "base" sarebbe già stata compresa e quindi non necessaria ri-documentazione).

La maggior parte delle aziende si svilupperà comunque su un'architettura standard, se sei un negozio .NET il team che rilascia un servizio Ruby on Rails non sarà apprezzato (se è autorizzato a consegnare una cosa del genere in primo luogo).

l'altro aspetto della manutenzione è che un'impresa avrà anche requisiti di monitoraggio standard. Quindi un team di produzione dirà che si aspettano di vedere i registri in un determinato formato, con segnalazioni di errori in un determinato modello, ecc. Anche se questo non aiuta i servizi di terzi acquistati, riduce in modo significativo i costi di manutenzione.

In breve, un microservizio non è una carta bianca per un team di sviluppo per buttare via gli standard esistenti e fare tutto ciò che sentono questa settimana. I requisiti per il funzionamento del servizio all'interno dell'ambiente esistente saranno comunque specificati nella richiesta originale.

I microservizi sono molto più semplici delle loro controparti più pesanti come JSF, ROR, MVC, CORBA o un numero qualsiasi di altri acronimi tecnologici aziendali. Più semplice significa più facile da mantenere e continuare a funzionare. Anche Node.JS e NoSQL fanno parte di questa tendenza verso architetture più semplici e disaccoppiate.

Tuttavia, la manutenzione non è l'unica considerazione al momento di decidere se utilizzare o meno i microservizi. Come hai giustamente sottolineato, i microservizi aggiungono complessità di loro spontanea volontà:

Lamaggiorpartedelleaziendenonhabisognodimicroservizi. Martin Fowler dice :

Don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.

La vera sfida è l'integrazione di componenti eterogenei in un sistema coerente, ma questo è sempre stato il caso, e questo problema può essere semplificato avendo tutti i microservizi conformi a un'architettura REST e la semplicità generale dei componenti che i microservizi incoraggiano .

I micro-servizi e le SoA in generale sono interessanti, ma si basano su un'infrastruttura completa e resiliente.

Se non hai abbastanza failover che hai ancora bisogno di ingegneri per uscire alle 3 del mattino quando qualcosa si rompe probabilmente hai più lavoro da fare in questa zona!

A mio parere, non è il 'server X che ha fatto crashare l'emergenza!' che devi preoccuparti di questa architettura, in quanto può essere gestita con failover e ridondanza tradizionali.

Sono i messaggi persi e l'orchestrazione rotta tra i microservizi, che è il vero dolore in più rispetto a una configurazione tradizionale. "Lo 0,3% dei clienti non riceve l'ordine quando gli orologi vanno avanti!" o 'i prodotti che iniziano con Z non stanno avendo la modifica del prezzo di vendita applicata!' wtfs è il tuo nuovo incubo