En les primeres etapes d'una plataforma de dades, l'objectiu sol ser pragmàtic: connectar una font, portar les seves dades al magatzem i començar a modelar-les. Cada enginyer de dades se centra en resoldre la seva pròpia integració i construeix el procés al voltant de la necessitat específica que té al davant.

Aquesta manera de treballar permet un progrés ràpid. Tanmateix, a mesura que creix el nombre de fonts i diverses persones es desenvolupen a la mateixa plataforma, les decisions preses individualment comencen a afectar el sistema en conjunt.

Cada procés d'ingestió pot acabar utilitzant la seva pròpia estructura, polítiques de reintent, enfocament de gestió d'errors i mecanismes de supervisió. Els processos funcionen i les dades arriben a la seva destinació, però la plataforma no té una base comuna.

Tot i que el nombre de pipelines continua sent petit, aquestes diferències poden ser manejables. El problema sorgeix a mesura que la plataforma creix: la incorporació d'una nova font ja no consisteix únicament a desenvolupar la seva extracció. També requereix decidir de nou com iniciar el procés, com coordinar les seves fases, quina informació registrar i què hauria de passar quan alguna cosa falla.

En aquest punt, l'autonomia individual pot començar a convertir-se en complexitat operativa.

‍

El problema: créixer sense una base comuna

‍

Aquesta situació va sorgir en un projecte zenital basat en una plataforma de dades d'AWS.

En aquest entorn, Amazon EventBridge programava les execucions, AWS Step Functions coordinava els diferents processos i AWS Glue executava la lògica d'extracció i processament. Posteriorment, dbt transformava les dades i Power BI les utilitzava per actualitzar i distribuir la informació. Amazon CloudWatch centralitzava els registres i habilitava la supervisió de l'execució.

A mesura que incorporàvem noves fonts, cada procés d'ingestió s'havia construït segons els seus propis criteris. Tots els processos complien el seu propòsit, però podien utilitzar estructures diferents, aplicar les seves pròpies polítiques de reintent o gestionar els errors de manera diferent.

La manca d'una base comuna no només va afectar el temps de desenvolupament. També va dificultar la comprensió del que s'estava executant en un moment donat i va augmentar la dependència del coneixement de les persones que havien creat cada procés.

Quan es produïa un incident, primer calia entendre com s'havia construït aquest procés d'ingestió específic: quina entrada rebia, quines tasques executava, com propagava els errors i quins processos en depenien. Dues fallades similars podien requerir investigacions diferents perquè les canonades no necessàriament seguien el mateix patró.

Aquesta variabilitat també va dificultar els canvis transversals. Potser caldria implementar una millora en la gestió d'errors, la supervisió o l'execució de treballs per separat en diversos processos.

Com a resultat, part de l'esforç de l'equip es va dedicar a reconstruir mecanismes d'orquestració que ja s'havien resolt anteriorment, en lloc de centrar-se en la lògica específica de la font o desenvolupar models que aportessin valor empresarial.

Per tant, la necessitat no era crear una nova màquina d'estats. Era establir una manera compartida de dissenyar i operar els processos d'ingestió.

‍

La solució: estandarditzar sense construir un monòlit

‍

Per resoldre el problema, vam avaluar diferents alternatives.

El primer era mantenir una màquina d'estats independent per a cada procés d'ingestió. Aquest enfocament proporcionava autonomia i permetia que cada flux s'adaptés completament a les característiques del seu origen. Tanmateix, també preservava la duplicació i permetia que continuessin sorgint diferents enfocaments.

A l'extrem oposat, podríem construir un únic flux de treball completament genèric. Totes les fonts passarien pel mateix orquestrador i compartirien una única implementació. Això proporcionaria uniformitat, però també podria crear un component monolític ple de condicions i excepcions.

Si cada nou requisit s'hagués d'incorporar al flux central, finalment caldria conèixer els detalls de totes les fonts. La centralització reduiria algunes inconsistències, però a costa d'un major acoblament, un major impacte del canvi i una dependència d'un sol component.

Vam triar un punt intermedi: combinar un orquestrador general amb mòduls especialitzats.

L'objectiu no era que tots els processos d'ingestió fossin idèntics, sinó que compartissin aquelles decisions operatives que no tenien sentit redefinir en cada pipeline.

El principi de disseny es pot resumir de la següent manera:

Centralitzar els contractes, la gestió d'errors i l'observabilitat, mantenint alhora separada la lògica específica de la font.

Com funciona l'arquitectura

‍

El primer pas va ser identificar les capacitats que s'utilitzaven repetidament a la plataforma. A partir d'aquestes, es van crear processos reutilitzables per a la ingestió des de bases de dades, API i fitxers, així com per executar treballs dbt, actualitzar Power BI i distribuir informes actualitzats.

Cada mòdul resol una responsabilitat específica i es pot reutilitzar en diferents processos. Un nou procés d'ingestió no necessita implementar tota la cadena; simplement combina les capacitats que requereix.

El flux global es pot representar de la següent manera:

Amazon EventBridge actua com a punt d'entrada i planificació. A més d'activar l'execució, envia un contracte comú que conté el context necessari per identificar quin procés s'està llançant, quines fonts s'han d'executar i quines fases pertanyen al flux.

Aquesta entrada arriba a una funció Step general, que interpreta l'execució sol·licitada. L'enginyer defineix quins mòduls s'han d'activar i en quines fonts han d'operar. L'orquestrador llavors compon el flux utilitzant els processos disponibles.

Una execució, per exemple, podria estar limitada a la ingestió d'un fitxer. Una altra podria combinar una ingestió relacional, l'execució d'una tasca dbt i l'actualització posterior d'un informe. L'estructura general continua sent la mateixa, però la composició canvia segons el requisit.

La lògica d'extracció es manté a AWS Glue. Step Functions coordina les fases i controla l'estat d'execució, mentre que cada tasca de Glue gestiona les especificitats del seu origen.

Aquesta separació evita que l'orquestrador hagi de saber com s'autentica una API, com es processa un fitxer o quina consulta utilitza una extracció relacional. La seva responsabilitat és coordinar els components, no absorbir la seva lògica interna.

‍

Millors pràctiques aplicades

‍

La documentació oficial d'AWS Step Functions recomana dividir els processos complexos en components modulars i reutilitzables amb responsabilitats clares. Hem aplicat aquest principi al nostre context mitjançant quatre decisions:

• Responsabilitats diferenciades. Cada mòdul representa una capacitat recognoscible, com ara la ingestió relacional, la ingestió d'API o l'execució de treballs de dbt.
• Interfícies comunes. Els mòduls reben una estructura d'entrada coherent i preserven el context necessari per identificar l'execució.
• Gestió d'errors consistent. La plataforma utilitza un patró comú per detectar, propagar i exposar errors, tot i que cada categoria d'error pot requerir una resposta diferent.
• Observabilitat transversal. CloudWatch centralitza els registres, les mètriques, la durada de l'execució i l'estat de l'execució.

Cada mòdul ha de tenir una responsabilitat clara i una interfície comprensible. En cas contrari, la fragmentació simplement traslladaria la complexitat d'un gran flux de treball a molts fluxos de treball que són difícils de relacionar entre si.

‍

Beneficis: per a l'equip i per al client

Per a l'equip

Abans del redisseny, afegir una font requeria desenvolupar tant la seva lògica específica com gran part del seu comportament operatiu. L'enginyer havia de decidir com iniciar el procés, com estructurar el flux, com executar les tasques i com supervisar el resultat.

Amb la nova arquitectura, una part important d'aquestes decisions ja s'ha resolt.

L'enginyer pot seleccionar el mòdul adequat per al tipus de font, configurar-ne els paràmetres i implementar la lògica específica de l'extracció. Quan el procés requereix executar models dbt o actualitzar un informe de Power BI, aquests mòduls es poden incorporar sense haver de tornar a desenvolupar les seves integracions.

Això no vol dir que totes les fonts siguin trivials. Una API pot requerir un mecanisme d'autenticació particular, una base de dades pot requerir una estratègia incremental específica i un fitxer pot presentar un format complex.

Aquestes diferències encara existeixen, però ja no requereixen redissenyar tota l'arquitectura d'execució.

Per a l'equip, aquesta base comuna ofereix diversos avantatges:

• Redueix el treball tècnic repetitiu.
• Simplifica la investigació d'incidents.
• Permet aplicar millores als components compartits.
• Redueix la dependència de la persona que va construir originalment cada procés.
• Manté l'autonomia per desenvolupar la lògica específica de la font.

L'autonomia no desapareix. Es centra en les decisions on realment aporta valor.

‍

Per al client

L'impacte d'aquesta arquitectura no es limita a l'equip tècnic.

Afegir una nova font requereix menys treball d'orquestració, cosa que permet dedicar recursos més aviat a comprendre les dades, desenvolupar transformacions i abordar les necessitats empresarials.

Una estructura comuna també millora la traçabilitat i facilita la investigació d'incidents. La plataforma conserva el context necessari per saber quin procés es va iniciar, quins components es van executar i en quina fase es va produir un error.

Per al client, això es tradueix en una plataforma més ben preparada per créixer. Els nous requisits no requereixen construir una arquitectura des de zero, sinó ampliar una base que ja conté les capacitats operatives habituals.

‍

Conclusió: Governar sense eliminar excepcions

‍

Aquest enfocament també introdueix un compromís. Compartir contractes i processos millora la coherència i la traçabilitat, però crea un cert grau d'acoblament al voltant de components comuns.

És per això que l'abast de l'orquestrador general ha de romandre limitat. Si s'hagués de modificar cada vegada que aparegués un cas especial, es convertiria en el coll d'ampolla que intentàvem evitar.

La governança no consisteix a forçar que tots els processos siguin idèntics. Es tracta de definir una manera recomanada de treballar i garantir que les excepcions siguin conscients, visibles i justificades.

En aquest context, governar els processos d'ingestió significa convertir els criteris de l'equip en comportaments comuns de la plataforma: com s'inicia una execució, com s'identifica, com es controla i com s'observa.

El canvi més important no va ser crear una nova funció Step, sinó evitar que cada nova font hagués de resoldre els mateixos problemes operatius de nou.

Una plataforma de dades s'escala quan ja no obliga a tots els enginyers a prendre les mateixes decisions operatives una vegada i una altra.

‍