Notas sobre la ArqConf 2015

Es­te es mi re­su­men so­bre la Ar­q­Conf 2015, la con­fe­ren­cia so­bre ar­qui­tec­tu­ra de ­so­ftwa­re que tu­vo lu­gar en la UCA el 30 de Abril de 2015. La idea es sin­te­ti­za­r ­las prin­ci­pa­les ideas que me lle­vé y re­sal­tar lo más im­por­tan­te.

Se pre­sen­tan a con­ti­nua­ción un lis­ta­do de las ideas prin­ci­pa­les por char­la con un ­bre­ve lis­ta­do de lo que más des­ta­co por ca­da uno. Nó­te­se que la lis­ta no es de ­nin­gu­na ma­ne­ra exhaus­ti­va, y ca­da sec­ción es en rea­li­dad un bre­ve pá­rra­fo ilus­tra­ti­vo­ a mo­do de re­su­men muy a al­to ni­ve­l.

Ca­da sec­ción lle­va un tí­tu­lo alu­si­vo al te­ma de la pre­sen­ta­ció­n, un bre­ve re­su­men y una lis­ta con los prin­ci­pa­les pun­tos que des­ta­co.

Orden en una arquitectura y la agilidad como atributo de calidad

Se ba­só en la ex­pe­rien­cia de un ar­qui­tec­to li­de­ran­do un equi­po de ar­qui­tec­tu­ra pa­ra un de­sa­fian­te pro­yec­to. El di­ser­tan­te ex­pli­có los pro­ble­mas a re­sol­ve­r, y el mar­co tec­no­ló­gi­co en el que se de­sa­rro­lló la so­lu­ció­n, y có­mo con una ar­qui­tec­tu­ra ele­gan­te y sim­ple con re­la­ti­va­men­te po­cos com­po­nen­tes se pue­de lle­va­r a ca­bo una im­ple­men­ta­ción de gran por­te que de so­por­te a 150.000 tran­sac­cio­nes ­con­cu­rren­tes.

  • El fac­tor cla­ve del éxi­to de una ar­qui­tec­tu­ra es la co­mu­ni­ca­ció­n.
  • La agi­li­dad de un equi­po co­mo atri­bu­to de ca­li­da­d. Es in­te­re­san­te, por­que cuan­do uno­ ­pien­sa en atri­bu­tos de ca­li­dad se le ocu­rren co­sas co­mo se­gu­ri­dad, man­te­ni­bi­li­dad, usa­bi­li­dad, es­ca­la­bi­li­dad, etc. pe­ro no el he­cho de ser ági­l. Sin em­bar­go es en ­ge­ne­ral de­sea­ble que el equi­po sea ágil y se pue­da adap­tar fá­cil­men­te a los cam­bio­s, y en ese ca­so ¿Por qué no agre­gar­lo co­mo un atri­bu­to de ca­li­da­d?
  • La fle­xi­bi­li­dad del equi­po, tam­bién co­mo atri­bu­to de ca­li­da­d. Aná­lo­go al an­te­rio­r, ­pe­ro con un de­ta­lle: si es un atri­bu­to de ca­li­da­d, tie­ne que ser me­di­ble. Lo in­te­re­san­te no es só­lo la ori­gi­na­li­dad de es­te ti­po de atri­bu­tos de ca­li­dad “no tra­di­cio­na­le­s”, ­sino tam­bién en co­mo con­si­de­rar­los den­tro de los es­ce­na­rios de ca­li­dad.
  • Los re­que­ri­mien­tos de­ben prio­ri­zar­se en el mar­co glo­bal de la or­ga­ni­za­ció­n.

Arquitectura y Big Data Analytics.

Una pre­sen­ta­ción ex­ce­len­te, con mu­cho de­ta­lle y ri­que­za téc­ni­ca, nom­bran­do tec­no­lo­gía­s, ­me­to­do­lo­gía­s, téc­ni­ca­s, y es­ti­los de ar­qui­tec­tu­ra orien­ta­dos a Big Da­ta.

  • Ka­fka co­mo he­rra­mien­ta pa­ra pro­ce­sa­mien­to de in­for­ma­ción en co­las de men­sa­jes no tra­di­cio­na­le­s (­con es­ta­do per­sis­ten­te). Es un ejem­plo de una tec­no­lo­gía que tu­vo un ca­so de éxi­to rea­l en pro­yec­tos de Big Da­ta.
  • Siem­pre guar­dar la fuen­te de da­to­s: lla­ma­da “la fuen­te de la ver­da­d” (the sour­ce of tru­th), es una bue­na prác­ti­ca, ya que tie­ne va­rias ven­ta­ja­s, co­mo por ejem­plo:
    • Pe­r­­mi­­te co­­­rre­­gir erro­­­res en ca­­so de fa­­lla (a pa­r­­tir de los da­­to­­s, se pue­­de vo­l­­ver a pro­­­ce­sar y no hay una pé­r­­di­­da irre­­cu­­pe­­ra­­ble de in­­fo­r­­ma­­ció­­n).
    • Pre­­se­r­­van­­do los da­­tos ori­­gi­­na­­les (raw da­­ta), es po­­­si­­ble en un fu­­tu­­ro ela­­bo­­­rar o ca­l­­cu­­lar nue­­va­s ­­mé­­tri­­cas si se re­­quie­­ren, co­­­sa que si por el co­n­­tra­­rio só­­­lo se gua­r­­da­­ran los da­­tos pro­­­ce­s­a­­do­­s, se­­ría i­m­­po­­­si­­ble.
    • El co­s­­to ex­­tra por el al­­ma­­ce­­na­­mien­­to no de­­be­­­ría ser un pro­­­ble­­ma, co­n­­si­­de­­ran­­do los be­­­ne­­fi­­cio­­s.
  • Pro­ce­sar la in­for­ma­ción de for­ma idem­po­ten­te: es­ta qui­zá sea la idea que me­jor re­fle­ja una ­bue­na prác­ti­ca ge­ne­ra­l, no so­lo apli­ca­ble a Big Da­ta. En lu­gar de pro­ce­sar mo­di­fi­can­do re­gis­tro­s (­por ejem­plo eje­cu­tan­do un SQL que su­me uno en al­gu­na co­lum­na), sim­ple­men­te se agre­gue una nue­va en­tra­da y lue­go el re­sul­ta­do se cal­cu­le so­bre el to­ta­l. De es­ta ma­ne­ra no se mo­di­fi­can los da­to­s, y ­de nue­vo, un po­ten­cial error es re­pa­ra­ble, no hay pér­di­da irre­ver­si­ble de in­for­ma­ció­n, etc. És­ta en ­rea­li­dad es una idea que ya exis­tía en sis­te­mas de BI, pe­ro es in­te­re­san­te no­ta­r ­que re­gis­trar los he­chos se pue­de usar pa­ra mu­chos más ca­so­s.
  • Sim­pli­fi­car las va­ria­bles tec­no­ló­gi­ca­s. En lu­gar de te­ner un ex­ten­so re­per­to­rio tec­no­ló­gi­co co­n ­mu­chas tec­no­lo­gías de pro­pó­si­to es­pe­cí­fi­co, es me­jor y más fá­cil de man­te­ner un en­torno con me­no­s ­tec­no­lo­gía­s, y, aun­que es­tas no se adap­ten per­fec­ta­men­te a ca­da pro­ble­ma en par­ti­cu­la­r, aún así hay que pri­vi­le­giar el prag­ma­tis­mo, ha­cien­do los ajus­tes ne­ce­sa­rio­s.
  • Te­ner un es­que­ma de da­tos (da­ta sche­ma) pa­ra po­der in­te­grar la in­for­ma­ción que se pro­ce­sa des­de ­di­fe­ren­tes fuen­tes.

Arquitecturas de Micro servicios.

Es muy in­te­re­san­te es­cu­char so­bre los mi­cro ser­vi­cio­s, y có­mo es­te ti­po de ar­qui­tec­tu­ras per­mi­ten una es­ca­la­bi­li­dad más fle­xi­ble.

  • Las ar­qui­tec­tu­ras de mi­cro ser­vi­cios per­mi­ten ob­te­ner la mis­ma fun­cio­na­li­da­d, pe­ro de for­ma ­dis­tri­bui­da, en contra­po­si­ción a lo que se­ría una ar­qui­tec­tu­ra mo­no­lí­ti­ca.
  • Es­to per­mi­te es­ca­lar de for­ma más fle­xi­ble, por ejem­plo se pue­den ad­mi­nis­trar los sub­sis­te­ma­s ­de for­ma in­de­pen­dien­te, asig­nan­do los re­cur­sos o man­te­nien­do más com­po­nen­tes pe­ro más sim­ple­s.
  • Es­ta se­pa­ra­ción tam­bién pue­de re­fle­jar­se en equi­pos de tra­ba­jo, áreas o pro­ce­so­s.

Arquitectura y métodos ágiles

En es­ta oca­sió­n, se ha­bló de la ar­qui­tec­tu­ra de so­ftwa­re des­de el pun­to de vis­ta de las me­to­do­lo­gía­s á­gi­les y los pro­ce­sos de de­sa­rro­llo ali­nea­dos a los re­que­ri­mien­tos fun­cio­na­les del ne­go­cio.

  • El equi­po pue­de con­ver­sar la ar­qui­tec­tu­ra en fun­ción de los re­que­ri­mien­tos con el PM, si­n ­ne­ce­sa­ria­men­te en­trar en mu­chos de­ta­lles téc­ni­co­s, con­cen­trán­do­se en la fun­cio­na­li­dad y ­com­por­ta­mien­to es­pe­ra­do.
  • És­ta con­ver­sación so­bre la ar­qui­tec­tu­ra de­be ser cons­tan­te a lo lar­go de to­do el ci­clo de de­sa­rro­llo.

Arquitectura aplicada la producción

Ex­ce­len­te cie­rre de la con­fe­ren­cia. Hi­zo mu­cho hin­ca­pié en có­mo se ve a la ar­qui­tec­tu­ra y el ro­l ­del ar­qui­tec­to o el equi­po de ar­qui­tec­tu­ra des­de el pun­to de vis­ta del CIO. És­to di­lu­ci­dó bas­tan­te ­so­bre lo que se es­pe­ra del equi­po de ar­qui­tec­tu­ra pa­ra que la or­ga­ni­za­ción fun­cio­ne.

Lo más des­ta­ca­do fue ver qué es lo que se es­pe­ra y lo que NO se es­pe­ra del ar­qui­tec­to, y có­mo­ ­lo más im­por­tan­te es po­der brin­dar una so­lu­ción co­mo in­ge­nie­ro­s, que res­pon­da a las ne­ce­si­da­des ­del ne­go­cio. La prin­ci­pal ri­que­za es­tu­vo en que las ideas fue­ron ilus­tra­das con ex­pe­rien­cias rea­le­s en Da­ta Cen­ters rea­le­s.

Al­go lla­ma­ti­vo es que mu­chas ideas men­cio­na­das son en rea­li­dad cues­tio­nes que se asu­men en un pro­yec­to­ ­de so­ftwa­re, pe­ro co­mo sa­be­mos en la prác­ti­ca no siem­pre su­ce­de, y es­to de­ri­va en ma­los re­sul­ta­do­s.

  • La in­te­gri­dad con­cep­tual es fun­da­men­ta­l: Las so­lu­cio­nes de­ben pro­por­cio­nar­se de for­ma uni­for­me, a­pli­can­do sen­dos es­ti­los y tec­no­lo­gías pa­ra los mis­mos ti­pos de pro­ble­ma­s. Aná­lo­ga­men­te, si ­pa­ra di­fe­ren­tes pro­yec­tos se usan mu­chas tec­no­lo­gías di­fe­ren­tes, el re­sul­ta­do es una ar­qui­tec­tu­ra ­gi­gan­te y muy di­fí­cil de man­te­ne­r.
  • Ca­da com­po­nen­te téc­ni­co in­terno del equi­po de in­ge­nie­ría no es el prin­ci­pal ob­je­ti­vo de la or­ga­ni­za­ció­n, ­si no que es­tán pa­ra res­pon­der a és­to­s.
  • Adop­tar nue­vas tec­no­lo­gías so­lo por que pre­sen­ta al­gu­nas ven­ta­jas par­cia­les no siem­pre es una bue­na idea a lar­go­ ­pla­zo. Sue­le su­ce­der que a lar­go pla­zo ter­mi­na te­nien­do con­se­cuen­cias per­ju­di­cia­les pa­ra el pro­yec­to.
  • Los sis­te­mas de­ben di­se­ñar­se y cons­truir­se pa­ra du­rar va­rios años (~10), y es­to im­pli­ca que la­s ­tec­no­lo­gías de cons­truc­ción tie­nen que te­ner va­rios años de exis­ti­r, de ma­ne­ra que sea ­ra­zo­na­ble ase­ve­rar que se­gui­rán es­tan­do dis­po­ni­bles el tiem­po que du­re el sis­te­ma pro­duc­ti­vo. No se­ría ­de­sea­ble te­ner que man­te­ner o ha­cer­se car­go de tec­no­lo­gías (fra­mewo­rks, toolki­ts, etc.) ob­so­le­ta­s.
  • Cri­ti­car las lla­ma­das “bue­nas prác­ti­ca­s” (o ver­da­des re­ve­la­das). Es­to sig­ni­fi­ca que cuan­do­ al­go se de­no­mi­na co­mo bue­na prác­ti­ca hay que plan­tear­se si real­men­te es así, y aun­que lo fue­ra, si esas ven­ta­jas que trae apli­can al pro­yec­to en cues­tió­n. És­ta es otra idea más ge­ne­ra­l, se tra­ta en ­de­fi­ni­ti­va de te­ner pen­sa­mien­to crí­ti­co, pe­ro es al­go que en mu­chos ca­sos no su­ce­de, y ve­mos en ge­ne­ra­l ­va­rios pro­yec­tos apli­can­do “pa­tro­nes de di­se­ño” (o de ar­qui­tec­tu­ra) o “bue­nas prác­ti­cas ági­le­s”, etc. si­n ­pen­sar real­men­te có­mo apli­can al pro­yec­to (al­go pue­de ha­ber da­do re­sul­ta­dos ex­ce­len­tes en otro pro­yec­to­, en otra em­pre­sa, en otro país, pe­ro el ar­qui­tec­to de­be con­si­de­rar si esas va­ria­bles real­men­te coin­ci­den o ­son re­le­van­tes al con­tex­to­).

>>> Conclusiones

Con­si­de­ro que la con­fe­ren­cia fue muy bue­na, te­nien­do en cuen­ta la ca­li­dad de las pre­sen­ta­cio­nes, la ex­pe­rien­cia de los di­ser­tan­tes y que to­do es­ta­ba alie­na­do con­cep­tual­men­te, lo cua­l hi­zo que la tran­si­ción en­tre te­mas tu­vie­ra una con­ti­nui­dad no­ta­ble.

Es ade­más im­por­tan­te des­ta­car que es­te ti­po de con­fe­ren­cia­s, ade­más de ser en­ri­que­cer la ex­pe­rien­cia ­pro­fe­sio­nal de to­dos (di­ser­tan­tes, or­ga­ni­za­do­res y con­cu­rren­tes), be­ne­fi­cian a la co­mu­ni­dad de ar­qui­tec­to­s.