Vermutech #51
Aquesta setmana he tingut un petit xoc amb coses que pensava que ja havien quedat enrere… com imprimir papers i signar-los a mà. La frase va ser: “ui, és que aquí al banc… això de la signatura digital no ho fem servir” 🤦🏻♂️. En sèrio? A més, jo no tinc impressora i tampoc en tenim a les oficines. Hauríem de poder viure sense haver d’imprimir tantes coses.
Sense sortir del sector (banca), t’adones de com és de valuós trobar la persona adequada, aquella que et busca solucions i no la que diu “ui, això no és possible” o “no, això no es pot pas fer”, el típic computer says no. Per tant, mai siguis d’aquesta gent i intenta ajudar en la mesura que puguis 🤝🏻.
D’altra banda, aquesta setmana hem acabat un sistema nou de Feature Flags, que permetrà activar i desactivar funcionalitats experimentals del nostre sistema. Això ens permetrà desplegar novetats “en prova”, inactives per defecte, però que qualsevol podrà activar i fer-nos arribar feedback. Un pas més per iterar més ràpid sense trencar res.
Començo amb algunes recomanacions,
💾 Programari
Restish: Una eina de terminal per fer crides a APIs REST. Sí,
curlho fa tot, però amb tants de flags, a vegades fer una cosa tan senzilla es complica 😁. Amb restish és realment més còmode i llegible.
🤔 Curiositats
Internet Roadtrip: Neal.fun ja és un clàssic en aquesta secció, i aquest cop ha creat un “joc” col·laboratiu: a través de Google Street View, la gent vota per on ha de continuar un cotxe. En el moment d’escriure això el viatge porta 5.292 km recorreguts!
📦 Recursos
WITH Clauses de Postgres: Sóc molt fan de PostgreSQL, i aquesta funcionalitat és una d’aquelles que no valores fins que no n’entens la potència. Aquest article ho explica molt bé amb exemples clars. Si fas consultes complexes, t'interessa.
🌟 El concepte
Aquesta setmana vull parlar d’un concepte bàsic però fonamental quan pensem en el creixement d’un sistema: l’escalabilitat, i concretament, la diferència entre escalar de forma vertical o de forma horitzontal.
Quan una aplicació comença a créixer —més usuaris, més dades, més trànsit— cal decidir com fer que aguanti el volum sense col·lapsar. I aquí apareixen dues estratègies clàssiques:
Escalabilitat vertical vol dir fer més gran el servidor que ja tens: més CPU, més RAM, més disc. És l’equivalent a millorar el motor d’un cotxe perquè vagi més ràpid. És simple, directe i moltes vegades suficient... fins que deixes de poder posar “més motor” perquè has arribat al límit físic o econòmic.
Escalabilitat horitzontal, en canvi, consisteix a afegir més màquines que treballin en paral·lel. És com passar de tenir un camió molt gran a tenir tota una flota de furgonetes que reparteixen feina. Això implica més complexitat (coordinar, repartir càrrega, garantir la consistència), però té l’avantatge que pots continuar afegint nodes pràcticament sense límit.
A GISCE-TI, el nostre ERP fa servir un sistema de cues i workers per gestionar moltes operacions de forma paral·lela. Això ens permet escalar horitzontalment: podem afegir més workers si hi ha més càrrega i mantenir un temps de resposta estable. Cada worker s’encarrega d’un conjunt de tasques i, com que funcionen de forma independent, es poden repartir en diferents màquines.
Aquest enfocament ens dona flexibilitat per créixer i adaptar-nos a moments de més càrrega, com pot ser el tancament mensual de facturació o processos massius de validació.
En resum: escalar verticalment és més fàcil però amb límits. Escalar horitzontalment és més flexible però també més complex. Saber quan i com aplicar cada estratègia és clau per fer créixer qualsevol sistema de forma saludable.
💖 Feedback
Si t’ha agradat i em vols ajudar, fes arribar aquest contingut a qui creguis que li pot interessar, i entra al canal de Telegram per comentar la publicació.