Dove e come gira il tuo runtime dichiarativo.

Un progetto Pwas tipico è composto da pochi componenti containerizzati: il backend interpretato, il client che genera le interfacce, l'orchestratore quando servono le automazioni, uno o più microservizi quando servono elaborazioni dedicate, e una base dati relazionale standard.

Non c'è un cluster di prodotti da installare né un ecosistema di dipendenze proprietarie. Il requisito minimo è un ambiente in grado di eseguire container: una macchina virtuale con Docker è sufficiente per partire, un orchestratore di container è la scelta naturale quando servono alta disponibilità e scalabilità orizzontale.

Questo è anche il motivo per cui l'installazione nella vostra sala server non è una versione ridotta del prodotto: è esattamente lo stesso software, eseguito altrove.

Dove decidete voi, e la decisione è una configurazione di distribuzione invece che una scelta di prodotto. Le tre modalità che coprono quasi tutti i casi sono: cloud europeo gestito da noi o da voi, on-premise nella vostra infrastruttura, e ibrido — tipicamente con la parte rivolta all'esterno su cloud e il cuore applicativo in sede.

La scelta resta reversibile: poiché il progetto è containerizzato e la base dati è relazionale standard, spostarlo significa spostare container e dati, non riprogettare l'applicazione. È un punto che conviene verificare esplicitamente in fase di valutazione, perché è una differenza reale rispetto a piattaforme il cui funzionamento dipende da servizi gestiti di uno specifico fornitore.

Quando il progetto prevede l'uso di modelli linguistici, la collocazione del modello è una decisione separata e va presa esplicitamente, comprese le opzioni che mantengono l'elaborazione entro un perimetro che controllate.

Dipende da come volete impostarlo, e tutte e tre le configurazioni sono praticabili.

• Gestito da noi, su cloud europeo: ce ne occupiamo noi, con i livelli di servizio concordati. È la scelta di chi non ha o non vuole impegnare un presidio sistemistico.
• Gestito da voi, con il nostro supporto: il vostro team opera l'infrastruttura, noi interveniamo sull'applicazione. Frequente nelle organizzazioni che hanno già un presidio e vincoli sul perimetro.
• Gestito da un partner: il vostro fornitore di infrastruttura abituale opera lo stack. Poiché non ci sono tecnologie esotiche, un buon presidio sistemistico lavora con ciò che già conosce.

In tutti e tre i casi, il monitoraggio applicativo, la raccolta dei log e i backup si integrano con gli strumenti che già usate invece di richiedere una console dedicata.