luca
Ci sono sostanzialmente due modi di costruire il sistema che ci serve e che ho provato a descrivere nell' altro topic.
Il primo è costrure un sistema ad hoc, integrato e autoconsistente in cui tutte le parti sono progettate insieme per interagire in modo efficace; per motivi di praticità è possibile spezzarlo in più componenti (distribuirlo cioè su vari server distinti che lavorino in sinergia) tuttavia il funzionamento complessivo è legato al funzionamento di ciascuna componente e se uno fa cilecca o è incompatibile con gli altri, l' intero sistema non funziona e tutto si inceppa.
Possiamo perfino dislocare le varie componenti in ambienti diversi e questo è sicuramnente utile per la manutenzione, ma la loro interdipendenza non cambia, è come distinguere in una macchina scocca, carrozzeria, motore e interni, tutti devono adattarsi uno all' altro e possono certamente essere riparati, ma non sostituiti con altri diversi di un altro costruttore o più moderni.
Lo schema sotto è solo un esempio in cui ho immaginato di usare 6 server 3 posti nel datacenter del DIT e 3 nel cloud privato sempre del DIT.
Un sistema simile va acceso e spento tutto insieme e consuma le stesse risorse sia che vada a pieno regime sia che invece aspetti di essere interrogato e usato. Ed è necessario dargli sempre tutte le energie per funzionare a pieno regime perchè non è scalabile cioè non può essere potenziato o depotenziato.
Il secondo modo mi piace di più, forse perchè da bambino passavo ore con il lego.
Si può costrure un sistema modulare in cui ogni pezzo sia indipendente dall' altro e quindi possono essere progettati e costruiti separatamente senza troppi vincoli: sostituiti, ammodernati e aggiustati senza che questo cambi il funzionamento generale e soprattutto, risiedendo tutti come containers nello stesso server possono ricevere risorse a seconda del loro uso e quindi senza sprechi.
Lo schema sotto è un esempio di questa architettura che è tenuta insieme da un pezzo fondamentale chiamato orchestratore che indirizza le risorse al componente che ne fa richiesta e si incarica della interazione tra i componenti.
La scelta di come costruire il nostro robot influenza certamente anche la scelta del costruttore a cui affidare il lavoro.
Con il primo schema abbiamo solo 2 possibilità:
Rivolgerci ad una azienda capace di progettarlo e realizzarlo per intero, come un vestito su misura, e certamente ce ne sono di molto capaci sul mercato, oppure cercare una azienda che abbia già realizzato un sistema simile e che abbia bisogno solo di qualche ritocco per soddisfare le nostre necessità e anche in questo caso ci sono molte aziende di ottimo livello se ci muoviamo nel campo dei Big DATA dell' intelligenza Artificiale e della Business intelligence.
Il secondo schema oltre alle due modalità precedenti ce ne consente altre due.
La prima è utilizzare componenti base già collaudate e far costruire da qualcuno quelle più specializzate su nostro progetto.
La seconda è acquistare separatamente tutte le varie componenti e poi rivolgerci a qualcuno perchè le assembli secondo le nostre esigenze (esistono già nel campo dell' open source tutte le componenti necessarie).
Considerate anche che una delle componenti fondamentali cioè i servizi cartografici l' abbiamo già in casa con la NIC e quindi non dobbiamo fare altro che farla lavorare insieme con le altre con grande risparmio.
Spero che queste riflessioni siano utili al RUP a cui spetta la decisione ma anche a tutti i membri del gruppo di lavoro e alla mediageo che dovranno contribuire a indirizzare le scelte.