Microservizi e procedure memorizzate

Le procedure memorizzate sono considerate cattive pratiche in un'architettura a microservizi?

Ecco i miei pensieri:

• la maggior parte dei libri sui microservizi raccomanda un database per microservizio. Le procedure memorizzate in genere funzionano su un database monolitico.

• ancora una volta la maggior parte dei libri di architettura di microservizi afferma che dovrebbero essere autonomi e liberamente accoppiati. Usando le procedure memorizzate scritte, diciamo specificamente in Oracle, accoppia strettamente il microservizio a quella tecnologia.

• la maggior parte dei libri di architettura di microservizi (che ho letto) raccomandano che i microservizi siano orientati al business (progettati utilizzando il design guidato dal dominio (DDD)). Spostando la logica di business in stored procedure nel database non è più così.

Qualche idea su questo?

Non c'è nulla che proibisca o discuti esplicitamente contro l'uso di stored procedure con microservizi.

Dichiarazione di non responsabilità: non mi piacciono le stored procedure dal punto di vista dello sviluppatore, ma ciò non è in alcun modo correlato ai microservizi.

Le procedure memorizzate in genere funzionano su un database monolite.

Penso che stai cedendo a un errore logico.

Oggi le procedure memorizzate sono in declino. La maggior parte delle procedure memorizzate ancora in uso proviene da una base di codice precedente mantenuta in circolazione. All'epoca, i database monolitici erano anche molto più diffusi rispetto a quando i microservizi sono diventati popolari.

Procs memorizzati e database monolitici si trovano entrambi in vecchie basi di codice, motivo per cui li vedi insieme più spesso. Ma questo non è un collegamento causale. Non usi proc memorizzati perché hai un database monolitico. Non hai un database monolitico perché usi processi memorizzati.

la maggior parte dei libri sui microservizi raccomanda un database per microservizio.

Non vi è alcun motivo tecnico per cui questi database più piccoli non possano avere stored procedure.

Come ho già detto, non mi piacciono i proc memorizzati. Li trovo ingombranti e resistenti alla manutenzione futura. Penso che la diffusione degli sprocs su molti piccoli database aggravi ulteriormente i problemi che già non mi piacciono. Ma ciò non significa che non possa essere fatto.

ancora una volta la maggior parte dei libri di architettura di microservizi afferma che dovrebbero essere autonomi e liberamente accoppiati. Utilizzando le procedure memorizzate scritte in modo specifico in Oracle, si accoppia strettamente il microservizio a quella tecnologia.

D'altra parte, lo stesso argomento può essere fatto per qualsiasi ORM utilizzato dal microservizio. Non tutti gli ORM supporteranno neanche tutti i database. L'accoppiamento (in particolare la sua tenuta) è un concetto relativo. È una questione di essere il più rilassato possibile.

Gli sprocs soffrono di accoppiamento stretto in generale indipendentemente dai microservizi. Vorrei sconsigliare gli sprocs in generale, ma non in particolare perché stai usando microservizi. È lo stesso argomento di prima: non credo che gli sprocs siano la strada da percorrere (in generale), ma potrebbe essere solo il mio pregiudizio e non è correlato ai microservizi.

la maggior parte dei libri msa (che ho letto) raccomandano che i microservizi siano orientati al business (progettati usando ddd). Spostando la logica di business in stored procedure nel database non è più così.

Questa è sempre stata la mia lamentela principale su sprocs: logica di business nel database. Anche quando non è l'intenzione, tende in qualche modo a finire sempre così.

Ma ancora una volta, questa lamentela esiste indipendentemente dal fatto che tu usi o meno i microservizi. L'unica ragione per cui sembra un problema più grande è perché i microservizi ti spingono a modernizzare l'intera architettura e gli sprocs non sono più così favoriti nelle architetture moderne.

Per scrivere software è necessario unire strettamente una tecnologia.

Per lo meno all'ambiente di runtime fornito dal linguaggio di programmazione sviluppato all'interno.

Più in generale, tuttavia, scoprirai che il tuo micro-servizio è strettamente associato a diverse tecnologie:

• Network Service Framework per fornire implementazioni di protocollo HTTP / SSL / SOAP di alto livello
• Repository / ORM / DAO Framework per fornire persistenza.
• Framework di manipolazione dei dati per fornire strumenti per lavorare con i dati.
• Process / Threading / OS Framework per fornire accesso a risorse del sistema operativo come multi-tasking, file system, memoria, calcolo GPU, schede di espansione, ecc ...

E questo è fare un micro-servizio a ossa nude.

Procedura di archiviazione

Una procedura memorizzata è semplicemente un'altra tecnologia che è possibile scegliere di utilizzare o meno. Magicamente non rende il tuo codice monolitico o micro.

Quello che è però è:

• Un'altra tecnologia. Ogni tecnologia presente nell'applicazione riduce la probabilità che un determinato programmatore possa leggere, comprendere e fare sagge scelte di progettazione per quel mix tecnologico.
• Un linguaggio che utilizza un diverso paradigma di programmazione. È fin troppo facile per i non esperti provare a forzare la propria prospettiva imperativa, funzionale, OO, ecc ... su di essa, che spesso porta a risultati tutt'altro che stellari.
• Un'API. Che deve essere mantenuto come qualsiasi altra classe nella base di codice. Significa anche che il database fornisce un'interfaccia non generica. Ciò rende più difficile sia la sostituzione del motore di database stesso, sia l'applicazione trasparente di comportamenti generici come la memorizzazione nella cache.
• Un manufatto. Che deve essere aggiornato, testato e distribuito. Questo può essere fatto, ma i database sono artefatti viventi che richiedono un approccio diverso. Di solito non puoi semplicemente eliminare l'originale e sostituirlo. Spesso è necessaria un'attenta orchestrazione delle modifiche nel tempo per migrare il sistema allo stato desiderato.

Ognuno di questi è un costo reale. In alcuni casi il costo è giustificabile, in altri no.

Pagheresti quasi la stessa serie di costi ospitando un motore di scripting. L'unica riduzione è che potresti scegliere lo stesso paradigma di programmazione della lingua host.

Logica di business

Spostare le regole di business nel database è una cattiva pratica. Solo non a causa di stored procedure.

È una cattiva pratica, perché il database e la logica aziendale operano su diversi livelli di taglio.

• Un database in applicazioni mature può essere utilizzato da decenni. Generalmente questi sistemi avranno il motore periodicamente aggiornato, ma il database stesso è stato migrato. Non è stato ucciso e ricostruito dall'inizio. Non vi è alcun motivo per cui un micro servizio non possa essere altrettanto longevo.

• Contrasti decenni con quanto velocemente cambiano le regole aziendali. Nella mia esperienza, una vecchia regola aziendale ha forse alcuni anni, la maggior parte tuttavia cambia rapidamente e non si può mai dire quale cambierà dopo. Un nuovo requisito da parte di un regolatore, un vecchio prodotto in fase di disattivazione, modifiche alla lettera intestata, modifiche al numero di dipendenti che riferiscono a un capo, ecc., Ecc., Ecc.

Se la logica aziendale è distribuita tra i livelli di cesoiatura, in particolare in un livello più lento e di maggiore durata, genererà resistenza ai cambiamenti. Ciò non è necessariamente una cattiva cosa. Dopotutto, l'unico database che non ha alcuna logica aziendale è un triplo archivio.

Il semplice atto di specificare uno schema di tabella sta spostando la logica di business nel database.

Architettura

Stai contendendo di utilizzare lo strumento appropriato per il problema appropriato, senza aver bisogno di troppi strumenti, né di renderlo troppo difficile da risolvere, al fine di creare e mantenere una soluzione.

Questo non è facile

Ma pensiamo all'impensabile, come manterresti la logica di business distribuita in più lingue?

• Un catalogo ... in modo che ogni implementazione delle regole di business possa essere tracciata e gestita.
• Test ... che potrebbero essere utilizzati per ogni regola aziendale indipendentemente da dove e come è stata implementata.
• Un'implementazione di riferimento ... in modo che quando si trovano discrepanze, esiste una fonte di verità (o almeno una fonte di dibattito).

Ma anche questo ha un costo.

• È meglio consentire alle regole aziendali di avere molte implementazioni? Ciascuno può trarre vantaggio dalle capacità di squadra e dalle disposizioni quadro, ma necessitano di controlli di qualità rigorosi per scongiurare molti piccoli capricci?
• O è meglio avere un'unica fonte di verità, scritta in una sola lingua? Probabilmente più economico da implementare, ma anche una singola fonte di errore, esso stesso un componente monolitico che resiste al cambiamento di fronte a piattaforme, framework o strumenti ancora da inventare?

Prefarrò la mia risposta dicendo che gestisco effettivamente un paio di microservizi che utilizzano procedure memorizzate. Inoltre ho scritto molte procedure memorizzate in vari punti della mia carriera e sono decisamente d'accordo sul fatto che le cose possano andare molto, molto male se usate in modo errato.

Quindi la risposta breve è, no, le procedure memorizzate non sono intrinsecamente cattive in un'architettura a microservizi. Ma devi capire:

1. Stai aggiungendo ostacoli alla sostituzione dei motori di archiviazione. Se alcune caratteristiche operative o prestazionali o limitazioni delle funzionalità richiedono di cambiare i motori di archiviazione, il costo sarà maggiore perché dovrai scrivere e testare molto nuovo codice. L'esecuzione di più di un motore di archiviazione (durante una fase di migrazione o per isolare le attività in base alle esigenze di prestazione) può comportare problemi di coerenza a meno che non si utilizzi il commit in due fasi (2PC), che presenta problemi di prestazioni.
2. Hai un'altra API da mantenere, il che significa che le tue dipendenze possono rompersi. L'aggiunta, la rimozione o la modifica dei tipi di parametri nelle procedure può interrompere il codice esistente. La stessa cosa accade con le tabelle e le query, ma i tuoi strumenti potrebbero essere meno utili per rintracciare dove le cose potrebbero andare storte. I problemi con le procedure memorizzate si trovano in genere in fase di esecuzione, molto tardi nel processo di sviluppo / distribuzione.
3. Le autorizzazioni per il database sono diventate più complicate. Una procedura viene eseguita come utente registrato o come qualche altro ruolo? Devi pensarci e gestirlo (si spera in modo automatizzato.)
4. Devi essere in grado di migrare verso nuove versioni in modo sicuro. Spesso una procedura deve essere abbandonata e ricreata. Ancora una volta, le autorizzazioni potrebbero causare alcuni problemi.
5. Il rollback di una migrazione non riuscita può comportare uno sforzo maggiore. Quando l'ambiente di produzione è separato dagli sviluppatori, le cose diventano ancora più difficili.

Questi sono alcuni usi delle stored procedure che ritengo spesso utili:

1. Applicazione della cronologia delle modifiche (registri di controllo). I trigger sono comunemente utilizzati per questo scopo e i trigger sono stored procedure. In alcuni database è anche possibile impedire inserimenti e aggiornamenti interamente per il ruolo dell'applicazione: i client eseguono procedure eseguite come ruoli diversi con autorizzazioni appropriate e che applicano tutti i comportamenti necessari.
2. Estensione dei vincoli di controllo. Questo potrebbe portarti nel territorio della logica aziendale, ma ci sono casi in cui gli strumenti di vincolo integrati di un database potrebbero non essere sufficienti per ciò di cui hai bisogno. Spesso il modo migliore per esprimere i controlli è con il codice imperativo e si rischia di inserire dati errati se si dipende dall'applicazione per farlo per te.
3. Incapsulamento di query complesse quando una vista è inappropriata o troppo complicata. Ho visto alcuni casi in cui una vista corretta richiede alcuni SQL estremamente complessi che possono essere espressi in modo molto più comprensibile in una procedura memorizzata. Questo è probabilmente raro, ma si verifica.

In generale, ti suggerisco di provare prima le viste e di ricorrere alle procedure solo quando necessario. Le viste ben progettate possono effettivamente funzionare come API, astraggendo i dettagli di come vengono interrogate le tabelle sottostanti. Aumentare l'API (viste) con le stored procedure ha senso in alcune circostanze. È anche possibile emettere JSON direttamente da una query SQL, ignorando l'intero disordine di mappatura dei dati dai risultati della query al modello di dati dell'applicazione. Se questa è una buona idea è qualcosa che devi determinare in base alle tue esigenze.

Dal momento che dovresti già gestire le risorse del tuo database (schema, autorizzazioni, ecc.) Tramite alcuni strumenti automatici, no, le procedure memorizzate non sono intrinsecamente dannose per i microservizi.

Le procedure memorizzate sono dettagli di implementazione. Le funzioni del database, lambdas o uno script shell archiviato da qualche parte nel file system sono tutti dettagli di implementazione e irrilevanti per l'architettura.

la maggior parte dei libri sui microservizi raccomanda un database per microservizio.

Ok, quindi possiamo codificare le procedure memorizzate in questi database.

ancora una volta la maggior parte dei libri di architettura di microservizi afferma che dovrebbero essere autonomi e liberamente accoppiati

Tra le capacità aziendali, i cicli di vita dello sviluppo, la gestione, le implementazioni, le posizioni dei team, ecc. Niente a che vedere con i dettagli dell'implementazione. I microservizi non risolvono un problema tecnico (esattamente il contrario). Vengono per risolvere i problemi con la gestione e il time-to-market. È una strategia, non una tattica. Un modo per fallire velocemente con il minor costo possibile. Se una determinata capacità aziendale si rivela inutile, la lasciamo cadere senza incasinare altre capacità, implementazioni, gestione dei progetti, rilasci ...

Si noti che la "divisione" si comporta già come un agente di disaccoppiamento. Supponiamo che abbiamo due servizi, A è supportato da Oracle e B da MongoDB. Se non infrangiamo la regola d'oro del disaccoppiamento, dovrebbe essere possibile far cadere A + Oracle con effetti collaterali trascurabili su B.

Utilizzando le procedure memorizzate scritte in modo specifico in Oracle, si accoppia strettamente il microservizio a quella tecnologia.

Potrebbe causare il blocco del fornitore. Molte volte, il venditore è imposto dall'azienda per motivi storici o contrattuali ¹ . È importante sapere come non bloccare il nostro codice al fornitore. Ad esempio, alcuni ORM e framework implementano un nuovo linguaggio di query che nasconde le funzioni e le funzionalità integrate nel database.

Tuttavia, se i nostri servizi sono sufficientemente micro, il blocco dei fornitori non è più un problema poiché influisce su una piccola parte del tutto. Una piccola parte che dovrebbe essere possibile essere sostituita (o isolata) rapidamente.

la maggior parte dei libri di MSA (che ho letto) raccomandano che i microservizi siano orientati al business (progettati usando DDD).

Dovrebbe essere guidato dal mondo degli affari e qui la cosa. Non tutte le aziende traggono vantaggio da DDD. DDD e microservizi si sovrappongono in molti punti, ma non sono causa-effetto. Potremmo finire con un ecosistema di microservizi composto da servizi anemici. O composto da un mix di entrambi: servizi che implementano un dominio complesso e stupidi servizi anemici che forniscono POJO direttamente dal DB. Non c'è niente di sbagliato in questo.

Per quanto riguarda i libri, si concentrano solo sull'esecuzione della strategia. Le tattiche - come trarre vantaggio dal calcolo distribuito - come farlo funzionare per il successo, ma sono (di solito) agnostici rispetto alla strategia. Le strategie variano da un'azienda all'altra e raramente dipendono dagli sviluppatori. Quindi, dobbiamo ancora estrapolare e adattare ciò che i libri dicono ai nostri bisogni, requisiti e vincoli specifici. L'obiettivo è rendere la strategia aziendale redditizia e sostenibile.

Tieni sempre presente che qualsiasi architettura è un mezzo per raggiungere un fine. Le regole commerciali. Non costruiamo ecosistemi di microservizi per la moda o per l'amore per l'arte.

Non ha davvero nulla a che fare con i microservizi.

Le procedure memorizzate possono avere senso se il servizio ha un'architettura a strati "vecchio stile" in cui il DB è la base del servizio, con accesso ai dati e livelli di logica aziendale in cima. L'interfaccia tra il servizio e il database in tale architettura è molto specifica per i dettagli più interni del servizio. In genere ci saranno adattatori specifici del servizio per ogni tipo di database supportato e la specificità dell'API esposta dall'adattatore consente di utilizzare le procedure memorizzate nei livelli sottostanti.

Ci sono molti problemi con architetture del genere. Ancora più importante, rende la maggior parte della logica molto difficile da testare. Queste architetture non sono più a favore.

Se si utilizza una "architettura pulita" di nuova generazione, "architettura cipolla" o simile, il database sarà una dipendenza iniettata , specificata ai livelli esterni. Poiché è definito nei livelli esterni, l'interfaccia fornita per il database deve essere generica . Non può riflettere i dettagli più interni del servizio, poiché tali dettagli devono essere nascosti dagli strati più esterni dell'architettura. La definizione di un'interfaccia di procedura memorizzata generica che può funzionare con qualsiasi database o unità di test unità è incredibilmente difficile e non realmente necessaria, quindi le procedure memorizzate non sono spesso pratiche in questo tipo di architetture.

La relazione con i microservizi è solo che i microservizi sono nuovi e in ascesa - non facciamo più monoliti - e che anche questi nuovi stili architettonici sono in crescita - non facciamo più strati piatti.