Headless is more (parte 3/4)
Dopo aver analizzato l’architettura a microservizi ed aver visto che anche uno dei software monolitici più diffusi può essere snellito e separato dalla parte di interfaccia, in questa terza parte andremo a vedere in che tipo di ambienti di hosting può essere installato un CMS.
5 tipologie di hosting
Un aspetto cruciale di un CMS è l’ambiente che ospiterà le funzionalità e i dati che questo software dovrà gestire. Andiamo a vedere le tipologie più moderne e utilizzate.
Infrastructure as a Service (IaaS)
Il provider fornisce un hardware virtualizzato (infrastruttura) su un cloud in cui vengono installati il sistema operativo, il database, i vari servizi ed il CMS. Il provider garantisce la disponibilità delle risorse e la connessione ad Internet.
Quindi resta a carico del cliente:
1. Installare e configurare il sistema operativo ed i servizi necessari.
2. Installare e configurare il CMS.
3. Mantenere in sicurezza il sistema operativo ed i servizi installati (backup, aggiornamenti, monitoraggio, …).
4. Mantenere in sicurezza il CMS (backup, aggiornamenti, monitoraggio, …).
5. Monitorare le performance dell’infrastruttura.
Con questa soluzione il cliente è praticamente responsabile di tutto quello che avviene all’interno dell’infrastruttura.
Esempi: DigitalOcean, Linode, Rackspace
Platform as a Service (PaaS)
Il provider offre una piattaforma virtualizzata con sistema operativo e servizi già presenti e mantenuti all’interno della quale viene installato il CMS.
Quindi resta a carico del cliente:
1. Installare e configurare il CMS.
2. Mantenere in sicurezza il CMS (aggiornamenti, monitoraggio, …).
3. Risolvere eventuali problemi di performance dovuti all’applicativo.
Questa soluzione comporta molte meno responsabilità rispetto alla precedente lasciando però a carico del cliente tutti gli oneri legati all’applicativo CMS.
Esempi: Heroku, Windows Azure, Force.com
Managed cloud hosting
In questo caso il provider fornisce un ambiente con CMS ed è solitamente già pre-installato in un IaaS e garantisce la disponibilità dell’intera infrastruttura comprensiva dell’applicativo CMS.
In questo modo la responsabilità del cliente è solo relativa alle funzionalità custom erogate dall’applicativo.
Questa soluzione presenta però un limite: le eventuali problematiche di sicurezza, performance o altro dovranno essere gestite dal fornitore, senza che il cliente abbia quindi il controllo sulle tempistiche. Inoltre vengono spesso posti dal provider alcuni vincoli sulle possibilità di personalizzazione del CMS.
Esempi: WP Engine, Acquia, Pagely, Pantheon
Software as a Service (SaaS)
Qui il provider eroga Il CMS come un servizio puro e ne garantisce ogni aspetto, dalla sicurezza alle performance.
Non ci sono responsabilità da parte del cliente se non la corretta configurazione del servizio.
Il grande limite di questa soluzione è l’assenza di possibilità di personalizzazione, se non previste dalla piattaforma stessa.
Es. Wordpress.com, Squarespace, Shopify
Function as a Service (FaaS / Serverless)
Il provider propone un ambiente in grado di eseguire funzioni custom utilizzando diversi linguaggi di programmazione, tra questi il più diffuso è Javascript (Node), senza doversi dotare di nessun tipo di infrastruttura per l’hosting. Questa tipologia di servizio non permette l’installazione di un CMS ma è estremamente utile per aggiungere nuove funzionalità a CMS esistenti o a siti completamente statici che quindi non potrebbero eseguire nessun tipo di funzione.
Il cliente, in questo caso, non deve preoccuparsi di alcun aspetto se non il corretto funzionamento delle procedure implementate.
Esempi: AWS Lambda, Azure Functions, Google Cloud Functions
Esistono alcuni possibili scenari per sviluppo di un Headless CMS…..che verranno svelati nel prossimo articolo.
Se ti sei perso le prime due pubblicazioni
Headless is more (parte 1) — Differenza tra Monolite e Headless technology
Headless is more (parte 2) — CMS Headless e 3 vantaggi chiave
Headless is more (parte 3) — 5 Hosting per sviluppare la Headless technology
Headless is more (parte 4) — 3 scenari di sviluppo
