Al debat tecnològic actual, la repatriació de càrregues de treball des del núvol públic torna a enfrontar dos bàndols: els que creuen que tot ha d'anar al núvol i els que, després d'una factura inesperada o una caiguda del proveïdor, exigeixen el retorn immediat a servidors propis. Ambdues posicions pateixen el mateix error: comencen per la plataforma en lloc de per la càrrega de treball. El veritable artefacte de decisió no és la màquina virtual ni el clúster de Kubernetes, sinó el perímetre complet del servei de negoci: aplicacions, dades, identitats, xarxes, serveis gestionats, còpies de seguretat, observabilitat, pipelines de desplegament i l'equip humà que ho opera. Aquest article proposa un motor de col·locació de càrregues (workload placement engine) que substitueix la ideologia per evidència mesurable, i que integra capacitats de cloud AWS/Azure, intel·ligència artificial, ciberseguretat i automatització empresarial en un marc reutilitzable.
El concepte de repatriació no s'ha de tractar com una religió. Una empresa pot obtenir estalvis significatius movent una càrrega estable des d'un model de consum car a una infraestructura eficient, però també pot perdre capacitats d'elasticitat si la demanda és variable. El motor de col·locació ha d'aplicar restriccions dures abans de puntuar: una restricció jurisdiccional, de latència màxima o de connectivitat pot eliminar un candidat per molt bo que sigui el seu promig. Només després de passar aquests filtres s'entra a l'etapa de comparació econòmica i d'ajust ponderat.
La primera correcció conceptual és separar el lloc on s'executa la infraestructura (venue) de l'entorn d'execució (runtime). Kubernetes pot córrer al núvol, núvol privat, edge o bare metal, però no elimina la gravetat de les dades ni les dependències d'identitat o de serveis gestionats. El motor ha d'avaluar per separat el venue, el runtime, el model operatiu i el perímetre de dades. Per exemple, moure un contenidor d'AKS a un clúster a VMware Cloud Foundation pot preservar l'objecte de desplegament, però canvia l'emmagatzematge, el balancejador, el proveïdor d'identitat, la xarxa, el backup i el suport. La portabilitat del contenidor no és portabilitat del servei.
Les empreses es veuen obligades a reavaluar la col·locació quan canvien els fets: creixement de costos, rendiment insuficient, canvis regulatoris, renovacions de llicències o renovació de maquinari. En tots aquests casos, l'error comú és comparar una factura de núvol amb el preu de compra d'un servidor, ignorant personal, instal·lacions, energia, backup, llicències i riscos. El motor de col·locació exigeix un model econòmic complet a cinc anys que inclogui infraestructura, programari de plataforma, emmagatzematge, xarxa, instal·lacions, seguretat, observabilitat, backup, mà d'obra operativa, migració i riscos de capacitat ociosa. I s'ha d'expressar en cost unitari: cost per transacció completada, per client actiu, per sol·licitud d'API que compleix l'objectiu de latència.
Un dels aspectes més infravalorats és la gravetat de les dades. No n'hi ha prou amb saber la mida de la base de dades; cal conèixer la taxa de canvi diària, el nombre de còpies, les finestres de transferència, els consumidors d'aquestes dades i la intensitat de lectura/escriptura. Un conjunt de 20 TB amb baixa taxa de canvi pot ser més fàcil de moure que un de 2 TB que canvia contínuament i alimenta desenes de serveis. Per això el còmput s'ha d'acostar a les dades més difícils de moure, però no necessàriament tots els components de presentació o control els han d'acompanyar.
En aquest context, Q2BSTUDIO aporta una perspectiva pràctica. Com a empresa de desenvolupament de programari i tecnologia, ajuda els seus clients a dissenyar motors de col·locació basats en evidència, integrant serveis de IA, ciberseguretat, Business Intelligence amb Power BI i automatització de processos. L'experiència demostra que no existeix una plataforma universalment superior; el que existeix és una decisió informada que pesa rendiment, sobirania, elasticitat, cost total i capacitat de reversió. Per exemple, una càrrega estacional de comerç electrònic amb pics set vegades superiors a la mitjana es beneficia de l'elasticitat d'Azure, mentre que un sistema de processament regional de reclamacions amb 45 TB de dades i dependència de llicències Microsoft pot encaixar millor a Azure Local o Nutanix. El motor de col·locació revela aquestes diferències sense prejudicis.
La sobirania i la jurisdicció no són sinònims. La residència de dades indica on s'emmagatzemen físicament; la sobirania determina qui controla la infraestructura i les claus; la jurisdicció es refereix a quines lleis apliquen. Un operador públic pot oferir una regió en un país, però els administradors del proveïdor poden estar subjectes a una altra legislació. El motor ha de traduir els requisits legals en restriccions dures verificables. De la mateixa manera, la resiliència no es demostra amb un SLA del proveïdor, sinó amb proves de restauració, commutació per error i anàlisi de dependències compartides. L'incident de Google Cloud el juny de 2025 va mostrar com un canvi global en polítiques d'API management pot afectar serveis monitoritzats i la mateixa infraestructura d'estat. La lliçó no és que el núvol públic sigui insegur, sinó que el nombre de regions no protegeix d'una dependència correlacionada en el pla de control.
Les llicències constitueixen un altre factor que pot invertir el guanyador aparent. Azure Hybrid Benefit pot canviar dràsticament l'economia d'Azure Local per a llicències Microsoft qualificades, però no aplica a tots els nivells. VMware Cloud Foundation 9.1 té comportaments diferents en mode connectat i desconnectat. Nutanix utilitza mètriques diferents segons producte, edició i model de desplegament. El motor ha de modelar aquestes variables amb la intervenció del responsable de llicències i no basar-se en la memòria de l'equip d'arquitectura.
La mà d'obra operativa no desapareix al núvol. El núvol elimina el muntatge de servidors, però no l'enginyeria de capacitat, la gestió d'identitats, el disseny de xarxa, el backup, la seguretat ni la resposta a incidents. Al núvol privat, l'automatització i la maduresa del cicle de vida determinen l'economia unitària. Mesurar el treball per hores dedicades a aprovisionament, pedaços, rotació de certificats i recuperació és més fiable que comptar caps en un organigrama. El motor ha d'incloure l'esforç operatiu com un cost directe.
La migració i la sortida tenen costos que sovint s'amaguen. La repatriació no acaba quan la màquina virtual arrenca al destí; cal validar el rendiment, la seguretat, el backup, l'acceptació de l'usuari i la desactivació de l'entorn anterior. El motor ha de calcular el temps d'equilibri (breakeven) i comparar-lo amb la vida útil esperada de la càrrega. Si una aplicació es retirarà en dos anys, una migració costosa pot no tenir sentit encara que la plataforma de destí sigui més barata a llarg termini.
Finalment, tota decisió de col·locació ha de tenir data de caducitat. El motor ha de registrar un temps objectiu de sortida, una ruta d'exportació de dades provada, una data de revisió i els esdeveniments que forcen una reavaluació (canvi de llicència, creixement de dades fora del previst, nova versió de plataforma, etc.). D'aquesta manera, l'empresa gaudeix dels beneficis del compromís amb una plataforma sense convertir-lo en un bloqueig permanent.
En resum, la repatriació al núvol no és una estratègia en si mateixa, com tampoc ho és l'adopció del núvol públic. Ambdues són accions de col·locació que poden ser encertades o errònies segons la càrrega de treball, l'objectiu de negoci, el model operatiu i l'evidència disponible. El motor de col·locació basat en restriccions, puntuació ponderada i confiança de l'evidència permet a les organitzacions col·locar cada servei de negoci on pugui lliurar el millor equilibri de rendiment, resiliència, control, velocitat, cost i reversibilitat. I en aquest procés, comptar amb un soci tecnològic com Q2BSTUDIO, que entén tant el desenvolupament d'aplicacions a mida com la integració de núvol, IA, ciberseguretat i BI, marca la diferència entre una decisió dogmàtica i una decisió intel·ligent.
