Notas sobre la ArqConf 2015

Este es mi re­sumen so­bre la Ar­q­Conf 2015, la con­fer­en­cia so­bre ar­qui­tec­tura de ­soft­ware que tu­vo lu­gar en la UCA el 30 de Abril de 2015. La idea es sin­te­ti­zar las prin­ci­pales ideas que me llevé y re­saltar lo más im­por­tante.

Se pre­sen­tan a con­tin­uación un lis­ta­do de las ideas prin­ci­pales por char­la con un breve lis­ta­do de lo que más desta­co por ca­da un­o. Nótese que la lista no es de ningu­na man­era ex­haus­ti­va, y ca­da sec­ción es en re­al­i­dad un breve pár­rafo ilus­tra­tivo a mo­do de re­sumen muy a al­to niv­el.

Ca­da sec­ción ll­e­va un tí­tu­lo alu­si­vo al tema de la pre­sentación, un breve re­sumen y una lista con los prin­ci­pales pun­tos que desta­co.

Orden en una arquitectura y la agilidad como atributo de calidad

Se basó en la ex­pe­ri­en­cia de un ar­qui­tec­to lid­eran­do un equipo de ar­qui­tec­tura para un de­safi­ante proyec­to. El dis­er­tante ex­plicó los prob­le­mas a re­solver, y el mar­co tec­nológi­co en el que se de­sar­rol­ló la solu­ción, y có­mo con un­a ar­qui­tec­tura el­e­gante y sim­ple con rel­a­ti­va­mente pocos com­po­nentes se puede ll­e­var a cabo una im­ple­mentación de gran porte que de so­porte a 150.000 transac­ciones ­con­cur­rentes.

  • El fac­­tor clave del éx­i­­to de una ar­qui­tec­­tu­ra es la co­­mu­ni­­cación.

  • La ag­il­i­­dad de un equipo co­­mo atrib­u­­to de cal­i­­dad. Es in­­tere­san­te, porque cuan­­do un­o pi­en­sa en atrib­u­­tos de cal­i­­dad se le ocur­ren cosas co­­mo se­guri­­dad, man­teni­­bil­i­­dad, us­a­bil­i­­dad, es­­­cal­a­­bil­i­­dad, etc. pero no el he­­cho de ser ágil. Sin em­bar­­go es en ­­gen­er­al de­seable que el equipo sea ágil y se pue­­da adap­­tar fá­­cil­­mente a los cam­bios, y en ese ca­­so ¿Por qué no agre­­gar­­lo co­­mo un atrib­u­­to de cal­i­­dad?

  • La flex­i­­bil­i­­dad del equipo, tam­bién co­­mo atrib­u­­to de cal­i­­dad. Anál­o­­go al an­te­ri­or, pero con un de­­talle: si es un atrib­u­­to de cal­i­­dad, tiene que ser med­i­ble. Lo in­­tere­san­te no es só­­lo la orig­i­­nal­i­­dad de este tipo de atrib­u­­tos de cal­i­­dad “no tradi­­cionales”, si­no tam­bién en co­­mo con­sid­er­ar­­los den­tro de los es­­ce­­nar­ios de cal­i­­dad.

  • Los re­­quer­im­ien­­tos deben pri­orizarse en el mar­­co glob­al de la or­­ga­ni­zación.

Arquitectura y Big Data Analytics.

Una pre­sentación ex­ce­len­te, con mu­cho de­talle y riqueza téc­ni­ca, nom­bran­do tec­nologías, metodologías, téc­ni­cas, y es­ti­los de ar­qui­tec­tura ori­en­ta­dos a Big Da­ta.

  • Kaf­­ka co­­mo her­ramien­­ta para pro­ce­samien­­to de in­­­for­­ma­­ción en co­las de men­sajes no tradi­­cionales (­­con es­­­ta­­do per­­sis­ten­te). Es un ejem­p­­lo de una tec­nología que tu­­vo un ca­­so de éx­i­­to re­al en proyec­­tos de Big Da­­ta.

  • Siem­pre guardar la fuente de datos: lla­­ma­­da “la fuente de la ver­­dad” (the source of truth), es una bue­­na prác­ti­­ca, ya que tiene varias ven­­ta­­jas, co­­mo por ejem­­plo:

    • Per­mite cor­re­­­gir er­rores en ca­­­so de fal­la (a par­tir de los datos, se puede volver a pro­ce­sar y no hay una pér­di­­­da ir­re­cu­per­a­ble de in­­­­­for­­­ma­­­ción).

    • Pre­ser­­­van­­­do los datos orig­i­­­nales (raw da­­­ta), es posi­ble en un fu­­­turo elab­o­rar o cal­cu­lar nuevas métri­c­as si se re­quieren, cosa que si por el con­­­trario só­­­lo se guardaran los datos pro­ce­sa­­­dos, sería im­­­posi­ble.

    • El cos­­­to ex­­­tra por el al­­­ma­ce­­­namien­­­to no de­bería ser un prob­le­­­ma, con­sider­an­­­do los ben­e­­fi­­­cios.

  • Pro­ce­sar la in­­­for­­ma­­ción de for­­ma idem­po­­tente: es­­­ta quizá sea la idea que mejor re­fle­­ja un­a bue­­na prác­ti­­ca gen­er­al, no so­­lo apli­­ca­ble a Big Da­­ta. En lu­­gar de pro­ce­sar mod­­i­f­i­­can­­do reg­istros (­­por ejem­p­­lo eje­cu­­tan­­do un SQL que sume uno en al­gu­­na colum­­na), sim­­ple­­mente se agregue una nue­­va en­­tra­­da y luego el re­­sul­­ta­­do se cal­cule so­bre el to­­tal. De es­­­ta man­era no se mod­­i­f­i­­can los datos, y de nuevo, un po­ten­­cial er­ror es repara­ble, no hay pér­di­­da ir­re­versible de in­­­for­­ma­­ción, etc. És­­ta en re­al­i­­dad es una idea que ya ex­istía en sis­temas de BI, pero es in­­tere­sante no­­tar que reg­is­­trar los he­­chos se puede us­ar para mu­­chos más ca­­sos.

  • Sim­­pli­­ficar las var­i­ables tec­nológ­i­­cas. En lu­­gar de ten­er un ex­ten­­so reper­­to­rio tec­nológi­­co con ­­muchas tec­nologías de propósi­­to es­­pecí­­fi­­co, es mejor y más fá­­cil de man­ten­er un en­­torno con menos tec­nologías, y, aunque es­­­tas no se adapten per­fec­­ta­­mente a ca­­da prob­le­­ma en par­tic­u­lar, aún así hay que priv­i­le­­giar el prag­­ma­tismo, ha­­cien­­do los ajustes nece­sar­ios.

  • Ten­er un es­­que­­ma de datos (da­­ta schema) para poder in­­te­­grar la in­­­for­­ma­­ción que se pro­ce­sa des­de d­ifer­­entes fuentes.

Arquitecturas de Micro servicios.

Es muy in­tere­sante es­cuchar so­bre los mi­cro ser­vi­cios, y có­mo este tipo de ar­qui­tec­turas per­miten una es­cal­a­bil­i­dad más flex­i­ble.

  • Las ar­qui­tec­­turas de mi­cro ser­vi­­cios per­miten obten­er la mis­­­ma fun­­cional­i­­dad, pero de for­­ma dis­­tribuida, en con­­tra­­posi­­ción a lo que sería una ar­qui­tec­­tu­ra monolíti­­ca.

  • Es­­­to per­mite es­­­calar de for­­ma más flex­i­ble, por ejem­p­­lo se pueden ad­min­is­­trar los sub­­­sis­temas de for­­ma in­­de­pen­di­en­te, asig­­nan­­do los re­cur­­sos o man­te­nien­­do más com­po­­nentes pero más sim­­ples.

  • Es­­­ta sep­a­ración tam­bién puede re­fle­­jarse en equipos de tra­ba­jo, áreas o pro­ce­­sos.

Arquitectura y métodos ágiles

En es­ta ocasión, se habló de la ar­qui­tec­tura de soft­ware des­de el pun­to de vista de las metodologías ágiles y los pro­ce­sos de de­sar­rol­lo alin­ea­d­os a los re­quer­im­ien­tos fun­cionales del ne­go­cio.

  • El equipo puede con­ver­sar la ar­qui­tec­­tu­ra en fun­­ción de los re­­quer­im­ien­­tos con el PM, sin nece­sar­i­a­­mente en­­trar en mu­­chos de­­talles téc­ni­­cos, con­­cen­trán­­dose en la fun­­cional­i­­dad y ­­com­­por­­tamien­­to es­­per­a­­do.

  • És­­ta con­ver­sación so­bre la ar­qui­tec­­tu­ra debe ser con­s­tante a lo largo de to­­do el ci­­clo de de­sar­rol­­lo.

Arquitectura aplicada la producción

Ex­ce­lente cierre de la con­fer­en­ci­a. Hi­zo mu­cho hin­capié en có­mo se ve a la ar­qui­tec­tura y el rol del ar­qui­tec­to o el equipo de ar­qui­tec­tura des­de el pun­to de vista del CIO. És­to dilu­cidó bas­tan­te ­so­bre lo que se es­pera del equipo de ar­qui­tec­tura para que la or­ga­ni­zación fun­cione.

Lo más desta­ca­do fue ver qué es lo que se es­pera y lo que NO se es­pera del ar­qui­tec­to, y có­mo ­lo más im­por­tante es poder brindar una solu­ción co­mo in­ge­nieros, que re­spon­da a las necesi­dades del ne­go­cio. La prin­ci­pal riqueza es­tu­vo en que las ideas fueron ilustradas con ex­pe­ri­en­cias reales en Da­ta Cen­ters reales.

Al­go lla­ma­ti­vo es que muchas ideas men­cionadas son en re­al­i­dad cues­tiones que se asumen en un proyec­to de soft­ware, pero co­mo sabe­mos en la prác­ti­ca no siem­pre sucede, y es­to deri­va en ma­l­os re­sul­ta­dos.

  • La in­­te­­gri­­dad con­­cep­­tu­al es fun­­da­­men­­tal: Las solu­­ciones deben pro­­por­­cionarse de for­­ma uni­­forme, apli­­can­­do sendos es­­ti­­los y tec­nologías para los mis­­­mos tipos de prob­le­­mas. Análo­ga­­mente, si ­­para difer­­entes proyec­­tos se us­an muchas tec­nologías difer­­en­tes, el re­­sul­­ta­­do es una ar­qui­tec­­tu­ra gi­­gante y muy difí­­cil de man­ten­er.

  • Ca­­da com­po­­nente téc­ni­­co in­­ter­no del equipo de in­­ge­niería no es el prin­­ci­­pal ob­­je­ti­­vo de la or­­ga­ni­zación, si no que es­­tán para re­spon­der a és­­tos.

  • Adop­­tar nuevas tec­nologías so­­lo por que pre­sen­­ta al­gu­­nas ven­­ta­­jas par­­ciales no siem­pre es una bue­­na idea a largo ­­pla­­zo. Suele suced­er que a largo pla­­zo ter­mi­­na te­nien­­do con­se­cuen­­cias per­ju­di­­ciales para el proyec­­to.

  • Los sis­temas deben dis­­eñarse y con­stru­irse para du­rar var­ios años (~10), y es­­­to im­­pli­­ca que las tec­nologías de con­struc­­ción tienen que ten­er var­ios años de ex­i­s­tir, de man­era que sea ra­­zon­able asev­er­ar que seguirán es­­­tan­do disponibles el tiem­po que dure el sis­tema pro­­duc­ti­­vo. No sería de­seable ten­er que man­ten­er o hac­erse car­­go de tec­nologías (frame­­work­s, toolk­it­s, etc.) ob­­so­le­­tas.

  • Criticar las lla­­madas “bue­­nas prác­ti­­cas” (o ver­­dades rev­e­ladas). Es­­­to sig­nifi­­ca que cuan­­do al­­go se de­nom­i­­na co­­mo bue­­na prác­ti­­ca hay que plantearse si re­al­­mente es así, y aunque lo fuer­a, si e­sas ven­­ta­­jas que trae apli­­can al proyec­­to en cuestión. És­­ta es otra idea más gen­er­al, se tra­­ta en defini­ti­­va de ten­er pen­samien­­to críti­­co, pero es al­­go que en mu­­chos ca­­sos no sucede, y ve­­mos en gen­er­al ­­var­ios proyec­­tos apli­­can­­do “pa­trones de dis­­eño” (o de ar­qui­tec­­tu­ra) o “bue­­nas prác­ti­­cas ágiles”, etc. sin pen­sar re­al­­mente có­­mo apli­­can al proyec­­to (al­­go puede haber da­­do re­­sul­­ta­­dos ex­ce­­lentes en otro proyec­­to, en otra em­pre­sa, en otro país, pero el ar­qui­tec­­to debe con­sid­er­ar si esas var­i­ables re­al­­mente co­in­­ci­­den o ­­son rel­e­­vantes al con­­tex­­to).

>>> Conclusiones

Con­sidero que la con­fer­en­cia fue muy bue­na, te­nien­do en cuen­ta la cal­i­dad de las pre­senta­ciones, la ­ex­pe­ri­en­cia de los dis­er­tantes y que to­do es­ta­ba alien­ado con­cep­tual­mente, lo cual hi­zo que la tran­si­ción en­tre temas tu­viera una con­tinuidad no­table.

Es además im­por­tante destacar que este tipo de con­fer­en­ci­as, además de ser en­rique­cer la ex­pe­ri­en­ci­a pro­fe­sion­al de to­dos (dis­er­tan­tes, or­ga­ni­zadores y con­cur­rentes), ben­e­fi­cian a la co­mu­nidad de ar­qui­tec­tos.