Quan desenvolupem una aplicació web no tenim per què encarregar-nos de tots els components necessaris perquè funcione. Podem desenvolupar i administrar nosaltres mateixos el servidor, el sistema operatiu, l’entorn d’execució, la base de dades i l’aplicació, o podem delegar part d’estes tasques en proveïdors cloud.
Des del punt de vista d’un programador, la principal diferència entre els diferents models de servicis cloud és quina part de la infraestructura i del programari gestionem nosaltres i quina part proporciona el proveïdor. En esta unitat estudiarem les principals opcions i conceptes necessaris per a comprendre l’ecosistema actual de desplegament en el núvol, i practicarem amb un exemple en alguna d’elles.
Els servicis cloud poden classificar-se atés el nivell de responsabilitat que assumix el proveïdor enfront del desenvolupador. La classificació tradicional distingix tres models principals:
Estos models representen diferents nivells d’abstracció i de responsabilitat entre el proveïdor i el desenvolupador. A continuació expliquem les característiques principals de cada un.
IaaS o Infraestructura com a Servici consistix a contractar recursos informàtics com a màquines virtuals, emmagatzematge, xarxes o capacitat de processament. El proveïdor s’encarrega de la infraestructura física, però nosaltres continuem havent d’administrar gran part de l’entorn en el qual s’executarà la nostra aplicació.
Per exemple, podem contractar una màquina virtual i instal·lar en ella Linux, Node.js, Express i la nostra aplicació. També haurem d’encarregar-nos de tasques com les actualitzacions, la configuració de la xarxa, la seguretat i el manteniment del sistema. Proporciona, per tant, molt de control, però també molta responsabilitat. Alguns exemples són Amazon EC2, Azure Virtual Machines o Google Compute Engine.
PaaS o Plataforma com a Servici proporciona un entorn preparat per a executar les nostres aplicacions. El proveïdor s’encarrega de gran part de la infraestructura i nosaltres ens centrem principalment a desenrotllar, configurar i desplegar el nostre programari. Alguns exemples són Render, Railway, Google App Engine o Azure App Service.
Podem connectar un repositori de GitHub amb una plataforma com Render i configurar els comandos necessaris per a construir i executar el nostre backend Node.js + Express. La plataforma s’ocupa de gran part de les tasques relacionades amb el servidor i nosaltres ens centrem en la nostra aplicació. PaaS oferix, per tant, menys control que IaaS, però simplifica considerablement el desplegament i el manteniment.
SaaS o Programari com a Servici és el nivell més alt d’abstracció en el núvol. Consistix a utilitzar una aplicació completament desenrotllada, allotjada i mantinguda per un tercer, a la qual solem accedir a través d’un navegador web o mitjançant una API.
En este model, el proveïdor s’encarrega de totes les capes: infraestructura física, sistema operatiu, base de dades, codi de l’aplicació i escalabilitat. Nosaltres únicament consumim el servici i gestionem el nostre propi compte o dades.
Tradicionalment està orientat a usuaris finals (com Google Workspace, Jira o GitHub) però, des de la perspectiva d’un desenvolupador, este concepte s’estén a la integració de servicis especialitzats via API o SDK. En lloc de construir subsistemes complexos des de zero, consumim solucions ja operatives per a:
El principal avantatge és que podem incorporar funcionalitats ràpidament sense haver de desenrotllar i mantindre tota la infraestructura necessària. A canvi, la nostra aplicació passa a dependre del proveïdor, dels seus preus, límits, disponibilitat i API.
Amb l’evolució de la computació en el núvol han aparegut altres models que descriuen formes específiques de consumir servicis cloud, com:
Estos conceptes no han d’entendre’s necessàriament com a categories independents al mateix nivell que IaaS, PaaS i SaaS, sinó com a formes especialitzades d’oferir o consumir determinats servicis cloud.
També cal esmentar que estos models no són necessàriament excloents. Una aplicació web moderna pot combinar diferents servicis cloud. Per exemple, podem desenvolupar un frontend Angular i un backend Node.js + Express, i desplegar-los en una plataforma com Render, i utilitzar MongoDB Atlas com a servici de base de dades. D’esta manera, podem construir una aplicació combinant programari desenvolupat per nosaltres amb infraestructura i servicis proporcionats per tercers.
Per a mostrar un exemple de tot això emprarem Render. En els següents apartats provarem de desplegar una API REST amb Express i Mongoose, allotjant la base de dades en MongoDB Atlas.
Com hem comentat anteriorment, Render entra dins de la categoria de PaaS (Platform as a Service), i ens proporciona un entorn completament configurat per a executar les nostres aplicacions web. És especialment interessant per al nostre cas perquè permet desplegar actualment servicis web Node.js/Express directament des d’un repositori GitHub o similar, i disposa d’una modalitat gratuïta per a experimentar (web oficial)
En Render podem desplegar tant servidors backend persistents (desenrotllats en Node.js, Python, Go o qualsevol tecnologia empaquetada amb Docker), com a llocs web frontend en HTML/CSS/JS servits de manera ràpida i gratuïta a través d’una xarxa CDN. A més, permet allotjar i gestionar bases de dades PostgreSQL i Redis, i també connectar amb altres bases de dades remotes.
Com a punt fort, permet mantindre processos en execució contínua (com a servidors Express o WebSockets) i oferix xarxes privades per a connectar de manera segura el nostre backend amb la base de dades sense exposar-la a Internet. En la seua modalitat gratuïta, els servicis web se suspenen després d’uns 15 minuts sense trànsit, per la qual cosa la primera petició després de la inactivitat pot tardar uns segons a respondre (arrancada en fred).
Si ho comparem amb un VPS (Servidor Privat Virtual), Render oferix una sèrie d’avantatges:
En canvi, en un VPS tenim un control total del sistema i l’entorn, però hem d’encarregar-nos d’instal·lar i administrar tot: sistema operatiu, servidors, connexions remotes, etc.
A més, una de les característiques més potents de les plataformes PaaS modernes és la seua integració directa amb repositoris de GitHub o GitLab. Això ens permet implementar un flux de treball automatitzat i continu:
git push a la branca principal (main), el PaaS detecta automàticament la nova versió.npm install) i prepara els arxius per a producció.npm run start o node server.js).Prendrem com a base el projecte ContactesREST_v2 que es va desenrotllar en este document. En ell vam construir una API REST per a gestionar un model senzill de contactes.
Ací pots descarregar el codi del projecte que usarem, des d’un repositori GitHub. Si li dones una ullada, hi ha alguns xicotets canvis sobre l’original d’aquell document:
.env.example amb dades de prova. Hauràs de copiar-ho a un altre anomenat .env i canviar en ell les dades pels de la teua pròpia connexió. Per a gestionar les variables d’entorn instal·lem la llibreria dotenv des de package.json, juntament amb express i mongoose.PORT=3000
MONGODB_URI=mongodb+srv://usuari:password@url_cluster/nomBD?parametres
node_modules com el fitxer .env, que pot tindre dades sensibles per a proves en local (només es puja .env.example, amb dades de prova inofensives).node_modules/
.env
També trobaràs un fitxer db_seed.js en l’arrel del projecte, que conté codi per a inserir en la base de dades una sèrie de contactes, restaurants i mascotes de prova, perquè no estiga buida. Este fitxer l’executarem després per a poblar la base de dades a l’inici.
Addicionalment, s’han afegit uns scripts en la secció scripts de package.json per a llançar l’aplicació amb el comando npm (encara que també es pot llançar amb node index.js). Des de Render es podrà triar el comando a executar per a posar-la en marxa.
"scripts": {
"start": "node index.js",
"dev": "node --watch index.js",
"seed": "node db_seed.js"
},
Com a segon pas important haurem de tindre un compte creat en MongoDB Atlas, i haver creat un clúster seguint els passos indicats en este document.
En el fitxer .env del nostre projecte hem de tindre emmagatzemada la URL de connexió a la base de dades, amb el format ja conegut de mongodb+srv://usuari:password@url_cluster/nomBD?parametres. Dins dels paràmetres, poden vindre bé un parell d’ells:
mongodb+srv://usuari:password@url_cluster/nomBD?retryWrites=true&w=majority
retryWrites=true permet que, si una operació d’escriptura (insert, update, delete) falla per un error temporal de xarxa o una reorganització del clúster (per exemple, un canvi de node principal), el driver de Node.js la reintente automàticament una vegada abans de llançar un error a la teua aplicació. Evita que l’API falle davant talls momentanis de connexió.w=majority establix el nivell de confirmació d’escriptura. En MongoDB Atlas les dades es repliquen en diversos servidors (un conjunt de rèpliques, usualment 3 nodes). Amb este paràmetre indiquem a MongoDB que no retorne la confirmació d’èxit a l’API fins que la dada haja sigut escrit físicament en la majoria dels nodes del clúster (almenys 2 dels 3). Garantix que les dades no es perden si un dels servidors patix una caiguda just després de rebre la petició.Ara que ja tenim configurat el projecte Node de manera adequada, i el nostre clúster en MongoDB Atlas, configurarem un repositori GitHub on allotjarem el nostre projecte, i el sincronitzarem amb Render perquè desplegue l’aplicació.
Crearem el nostre repositori públic en GitHub on emmagatzemar este projecte. Suposarem, per a este pas, que tens compte creat en GitHub i que has instal·lat la ferramenta Git en el teu sistema. Si no és així, completa estos dos passos abans de continuar.
El primer que farem serà inicialitzar un repositori local en la nostra carpeta de projecte Node. Podem fer-ho des del terminal integrat en VS Code, dins del projecte, escrivint estos comandos:
# Inicialitzem repositori
git init
# Afegim tot el contingut inicialment (el fitxer .gitignore exclou el que corresponga)
git add .
git commit -m "Commit inicial: projecte Express i Mongoose configurat"
# Canviem de nom la branca principal a "main" (opcional, encara que recomanable)
git branch -M main
Ara hem d’accedir a GitHub, crear un nou repositori buit (podem anomenar-ho com vulguem. Per exemple, ContactesREST) i quedar-nos amb la seua adreça (per exemple, https://github.com/el-teu-usuari/contactesrest.git). Ara connectarem el nostre repositori local amb eixe repositori GitHub:
git remote add origin https://github.com/el-teu-usuari/el-teu-repositori.git
git push -o origin main
Com a últim pas, crearem un nou projecte en el nostre compte de Render (si no tens compte, crea un). Des del nostre panell (Dashboard) triem crear un nou Web Service.
Després connectem amb el repositori en qüestió
El següent pas és configurar el servici. En el formulari ens demanen que posem un nom, el llenguatge o framework de desenvolupament (Node), la branca principal del repositori, la regió on desplegar-lo…
També indiquem el comando per a construir el projecte (en el nostre cas, npm install) i per a posar-lo en marxa (podem triar node index.js o bé npm run start dels nostres scripts). Finalment, podem especificar la tarifa (gratuïta en el nostre cas) i les variables d’entorn que s’utilitzaran. Podem afegir-les a mà o bé copiar-les/pegar-les del nostre fitxer .env (recorda que este fitxer NO es puja a GitHub).
En la secció d’opcions avançades podem especificar algun detall més. Per exemple (per a opcions de pagament) podem indicar un pre-deploy Command, que vindria bé per a executar npm run seed i poblar la base de dades a l’inici. Com està deshabilitat per a l’opció gratuïta, haurem d’executar este comando des del nostre ordinador local per a emplenar la base de dades de MongoDB Atlas.
Una vegada emplenades les opcions de configuració, podem desplegar el servici i, si tot és correcte, després d’uns segons per a fer el build i instal·lar les llibreries necessàries, el tindrem disponible en una direcció per defecte dins del domini xxxxx.onrender.com, on xxxxx serà el nom que li hàgem donat al projecte en Render.
Actualment existixen moltes plataformes PaaS i, encara que totes ens permeten connectar un repositori de GitHub per a automatitzar el desplegament, cada una està pensada per a resoldre necessitats distintes, des de frontends estàtics optimitzats en CDN fins a backends persistents i bases de dades gestionades. A continuació nomenem algunes amb les seues particulars característiques.
Ací veiem una anàlisi comparativa de les plataformes comentades: