Migrar al núvol: què decidir abans de moure el primer servidor

Una migració al núvol s'encareix quan es planteja com un trasllat de servidors. Les decisions que fixen la factura i el risc es prenen abans de moure res: quines càrregues existeixen, quina convé refer, quina n'hi ha prou amb apagar. Aquest és l'ordre que seguim amb empreses mitjanes que surten d'un centre de dades propi o d'un proveïdor d'allotjament.

L'inventari decideix més que el proveïdor

No es pot migrar el que no es coneix. El primer lliurable de qualsevol migració és una llista de càrregues de treball amb cinc dades per a cadascuna: què fa i qui la fa servir, de què depèn (bases de dades, fitxers compartits, integracions amb l'ERP), quina disponibilitat necessita, quina sensibilitat tenen les seves dades i quant costa avui entre maquinari, llicències i hores de manteniment.

Amb aquesta llista, cada càrrega rep una de sis decisions.

A la pràctica, l'exercici sol descobrir càrregues que ningú no fa servir des de fa mesos i que s'apaguen abans de començar. És l'estalvi més barat de tota la migració.

La factura puja quan es copien els servidors tal com estan

Copiar cada màquina virtual del centre de dades a una màquina virtual al núvol és el camí més ràpid i el més car al cap de sis mesos. Les màquines arriben amb la mida que tenien, dimensionades per a un pic que passa dues vegades l'any. Al núvol, aquesta mida es paga per hora.

El que canvia la factura és aprofitar el que ja ve gestionat. Una base de dades a Azure SQL o Amazon RDS elimina el servidor que calia actualitzar i del qual calia fer còpies a mà. Un procés nocturn arrenca en una funció d'Azure Functions o AWS Lambda, executa el seu script en Python i s'atura, sense cap màquina engegada la resta del dia. I una aplicació empaquetada en Docker es desplega igual en un servidor petit que en un servei de contenidors, sense dependre de com estigui configurada la màquina.

El procés de càrrega del magatzem de dades de Grupo Pomona Iberia té aquesta forma: un ETL en Python que s'executa cada matinada, llegeix Excel, carpetes de SharePoint i els ERPs de quatre empreses, i deixa les dades a punt a Power BI abans que arribi la direcció. Aquesta feina dura minuts al dia. És el tipus de càrrega que convé executar com a tasca programada i no com a servidor permanent.

Els fonaments van abans que la primera càrrega

Abans de migrar res cal muntar la xarxa, la identitat i les còpies. Sembla burocràcia i és el que evita que el primer trasllat acabi en incident.

Xarxa: una xarxa virtual amb subxarxes separades per al que s'exposa a internet i el que no, i una VPN entre el núvol i les oficines per a tot el que continua en local. A Pomona, la connexió permanent amb els ERPs es va resoldre amb una VPN i accés directe per SQL, i aquest és el mateix tipus d'enllaç que una migració necessita per moure dades sense tallar el servei.

Identitat i accessos: qui pot crear recursos i qui pot veure dades, amb autenticació en dos passos i permisos per grup en lloc de per persona. Xifratge en repòs i en trànsit activat per defecte. Còpies de seguretat automàtiques, amb una restauració de prova feta abans de migrar la primera base de dades.

Cost: etiquetes a cada recurs (projecte, entorn, responsable) i alertes de pressupost des del primer dia. Sense etiquetes, la factura del núvol és un únic número que ningú no pot explicar a final de mes.

Un pilot de baix risc ensenya més que el pla

La primera càrrega que es mou hauria de ser visible i poc crítica: una eina interna, la web corporativa, un entorn de proves. Si alguna cosa falla, ningú no deixa de facturar. Si surt bé, l'equip ha après el procediment amb una càrrega que perdona errors.

A partir del pilot, la resta es mou per onades ordenades per risc. Per a cada càrrega el guió és el mateix: preparar l'entorn, migrar les dades (gairebé sempre la part lenta), desplegar, provar, redirigir el trànsit, vigilar una o dues setmanes i apagar l'entorn antic. Convé pressupostar que durant aquest període es paguen els dos entorns alhora. És el cost de migrar sense talls.

Apagar l'antic és el pas que més s'endarrereix. Mentre el servidor vell continuï engegat per si de cas, la migració no ha acabat i es paga el doble.

Azure o AWS: la resposta és en el que l'empresa ja fa servir

Per a una empresa que treballa amb Microsoft 365, Business Central i Power BI, Azure és l'opció natural. La identitat ja és a Entra ID, i els serveis de dades i d'IA s'integren amb el que l'equip ja coneix. Per a una empresa el producte de la qual és programari propi, amb contenidors i serveis exposats a clients, AWS és una base igual de sòlida i en la qual també construïm.

El que convé evitar és repartir càrregues entre dos proveïdors sense una raó concreta. Cada núvol exigeix la seva pròpia xarxa, la seva identitat i la seva monitorització, i mantenir-ne dos duplica la feina d'operació. El multinúvol té sentit per exigència normativa o per un servei concret que només existeix en un d'ells. En la resta de casos és complexitat sense retorn.

Per on començar aquesta setmana

• Llistar les deu càrregues de treball més importants amb dependències, sensibilitat de dades i cost mensual actual.
• Marcar les que ningú no fa servir i apagar-les abans de contractar res.
• Triar un pilot visible i poc crític, i fixar amb què se'n mesurarà l'èxit.
• Activar etiquetes de cost i alertes de pressupost al compte de núvol des del primer recurs.
• Fer una restauració de prova de les còpies actuals; si falla en local, fallarà al núvol.

Si el cas encaixa, a LakeTab el revisem en una primera trucada de 60 minuts.