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­tura es la co­mu­ni­cación.
  • La ag­ili­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­abil­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 proce­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.
  • Proce­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 proce­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 vari­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 proce­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­tura 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­tura en fun­ción de los re­quer­im­ien­tos con el PM, sin nece­sari­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­tura debe ser con­stante 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áloga­mente, si ­para difer­entes proyec­tos se us­an muchas tec­nologías difer­entes, el re­sul­ta­do es una ar­qui­tec­tura 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­tando 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 real­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­tura) o “bue­nas prác­ti­cas ágiles”, etc. sin pen­sar real­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 vari­ables real­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.