Posizione dei componenti della soluzione: centralizzazione rispetto a più istanze rispetto alle librerie

4

Al momento siamo nelle prime fasi di costruzione di un sistema sostanziale, con l'obiettivo di fare gran parte di ciò che fanno molti sistemi esistenti, in un modo flessibile, estensibile e gestibile. Supporterà più istanze complete per diversi clienti. Una delle cose che continua a emergere nell'intero sistema è la seguente: dove dovrebbe [componente x] sedersi?

Potremmo:

  • (A) centralizza completamente in un singolo servizio web separato, condiviso da tutte le istanze; la configurazione sarebbe mantenuta centralmente in modo che potesse dare ad ogni istanza quello di cui aveva bisogno, e potrebbe includere plugin specifici dell'istanza
  • (B) lo hanno come servizio separato, ma installarlo più volte, configurato individualmente per ogni istanza principale della soluzione; il servizio potrebbe essere utilizzato da più componenti cooperanti all'interno di un'istanza
  • (C) crea la funzionalità come libreria e incorporala direttamente negli altri componenti

Per ognuno ci sono alcuni pro e contro:

A è efficiente in termini di risorse e consente facilmente ad es. monitoraggio dell'attività su tutta la soluzione. La creazione di un singolo servizio sufficientemente configurabile / flessibile creerà ulteriori sfide di sviluppo. Gli aggiornamenti del codice potrebbero avere un impatto sull'intera soluzione sia in termini di tempi di inattività che di pianificazione di test / implementazione, indipendentemente dal fatto che la modifica del codice sia destinata a migliorare ogni istanza.

B utilizza più risorse, ma localizza la configurazione, che può essere meno complessa. Le modifiche al codice possono essere implementate in un modo più gestibile, ma sarà necessario uno sforzo maggiore per eseguire il roll-out in più di un luogo.

C elimina la necessità di un servizio separato e offre il potenziale per la massima flessibilità se il codice di chiamata non deve essere limitato all'esecuzione di tutte le funzioni tramite l'API del servizio web; gli aggiornamenti al codice richiederebbero la ridistribuzione delle DLL ovunque fossero utilizzati, il che potrebbe essere in ogni componente di un'istanza anziché solo una volta per istanza come in B.

In particolare, ci sto pensando da una funzionalità PoV, preoccupandomi ad es. dove i dati sono effettivamente memorizzati. Ho ignorato l'opzione D, "copia e incolla il codice ovunque, o reimplemento willy nilly".

Mi chiedo come si applica a un'intera gamma di componenti, da specifiche funzioni aziendali, a cose più ampie come la registrazione, la gestione degli errori, l'accesso ai dati, ecc. Mi rendo conto che la risposta finale dipenderà sempre molto ogni esempio, ma ci sono considerazioni che non ho menzionato che potrebbero avere un grande impatto? Ci sono esempi in cui è un assoluto senza cervello? C'è qualche modo sistematico per aiutare a prendere questa decisione? Ho perso completamente un'intera opzione?

EDIT (un po 'più in dettaglio nel caso in cui faccia la differenza): Storicamente, a causa di una mancanza di accortezza, abbiamo adattato le esigenze di diversi clienti simili ma anche sostanzialmente diversi, basandoci fondamentalmente sull'intera base di codice, a parte una manciata di librerie banali. Siamo decisamente impegnati in un qualche tipo di approccio SOA con la riscrittura, e certamente in un numero di codice notevolmente più condiviso, ma potrebbero ancora esserci dei benefici o requisiti per mantenere una certa separazione per ogni "istanza", con cui intendo un'intera raccolta di servizi fornire tutto il necessario per un cliente: il cliente può richiedere la propria installazione logicamente o fisicamente o addirittura geograficamente separata; l'istanza di un cliente può consistere di moduli A e B, un altro B e C e D ed E. Sento istintivamente che ci sono due modi per essere "SOA" qui: uno per avere letteralmente uno di tutto, e lasciarli funzionare tutti insieme in modi diversi per i diversi clienti, o in alternativa per avere uno dei moduli necessari all'interno di un cliente, ma la natura liberamente accoppiata dei servizi consentirebbe comunque di aggiungere facilmente un altro modulo a un cliente esistente o spostare una risorsa -intensivo modulo per il proprio hardware per un solo cliente.

Non fraintendermi, apprezzo tutti i punti, ma penso di non essere in un posto mentale dove semplicemente il fatto di fare qualcosa in un certo modo, che potrebbe sicuramente offrire qualche beneficio in alcune situazioni, potrebbe portare anche a problemi se gestiti male, è del tutto inaccettabile. Quindi è meglio non lasciare che esista la possibilità anche se ciò porta a una maggiore complessità / impegno / ecc. Un po 'come non permettere alcol in casa, perché sai che se è lì puoi bere tutto da solo e correre in strada con le mutande, anche se un drink tranquillo per rilassarsi dopo il lavoro potrebbe essere bello. Probabilmente dovrei smettere di chiacchierare ora ...

    
posta frumious 22.07.2011 - 12:48
fonte

3 risposte

4

Il mio consiglio è di "mantenere l'IT semplice (KISS)". Detto questo, penso che i vantaggi del servizio centralizzato superino di gran lunga i costi. Si afferma che la configurazione potrebbe diventare più complessa. Dubito che sia più complesso del radunare più istanze con utenti e configurazioni separati. Perché non un singolo servizio consuma più configurazioni? È più facile da implementare e mantenere a mio modesto parere, ma poi di nuovo non conosco i dettagli tecnici. Vai per l'opzione A .

link

È ampiamente utilizzato e molto popolare per numerose ragioni.

B) sarà inevitabile causare mal di testa per il tuo dipartimento di supporto. Più istanze, più processi, ciascuno con un processo client corrispondente. Come lo risolverai? È più complicato identificare il processo colpevole e difficile durante l'implementazione e l'installazione. Ma queste cose dovrebbero essere semplici, il più semplice possibile! Scrivi:

Code changes can be rolled out in a more manageable way

E ho letto: Version Chaos!

C) sembra una buona opzione, ma generalmente non è utilizzabile. Dovresti modularizzare e creare le librerie in primo luogo. Non è necessario aggiornare tutte le applicazioni quando cambiano le librerie. In realtà, questo sarebbe abbastanza pericoloso. Basta congelarli regolarmente e quando si aggiorna l'applicazione, spedirla nel suo complesso con tutte le librerie, dopo i test di integrazione per l'applicazione specifica sono stati passati . Tuttavia, questo approccio può causare anche un caos della versione.

Concludendo, vorrei dire che una sfida fondamentale per mantenere il controllo sul proprio ambiente è congelare specifiche e versioni regolarmente e quindi abilitare la retrocompatibilità.

    
risposta data 22.07.2011 - 13:06
fonte
0

I second Falcon con l'opzione A, ma con questo avvertimento:

Dovresti gestire complessità e difficoltà spostandoli nel luogo in cui hai gli strumenti per affrontarlo.

Se i tuoi amministratori di sistema sono dei maestri dei nagi e dei tuoi programmatori che miagolano i neofiti, allora è probabilmente una buona idea cercare soluzioni che semplificano l'attività di programmazione a scapito del sovraccarico di amministrazione dei sistemi aggiuntivi. Se il contrario è vero, ovviamente, ciò ti porta in una diversa direzione di progettazione.

    
risposta data 12.12.2013 - 17:32
fonte
0

C) Funzionerà solo se i servizi implementano una sorta di logica o calcolo e non si basano su alcuni database o altri dati persistenti. Anche se il servizio sta implementando un calcolo, si verificherà un problema quando è necessaria una modifica.

Ad esempio, se il tuo servizio esegue alcuni calcoli dei prezzi, allora avrai un problema quando la formula di calcolo del prezzo deve essere cambiata (a causa di un cambiamento nel business) perché non sarai in grado di aggiornare tutte le applicazioni che usano quella libreria tutti allo stesso tempo.

    
risposta data 12.12.2013 - 20:38
fonte

Leggi altre domande sui tag