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 fa­c­­tor cla­­ve del éxi­­to de una ar­­qui­­te­c­­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, po­r­­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­­ba­r­­go es en ­­ge­­ne­­ral de­­sea­­ble que el equi­­po sea ágil y se pue­­da ada­p­­tar fá­­ci­l­­men­­te a los ca­m­­bio­­s, y en ese ca­­so ¿Por qué no agre­­ga­r­­lo co­­­mo un atri­­bu­­to de ca­­li­­da­­d?

  • La fle­­xi­­bi­­li­­dad del equi­­po, ta­m­­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 ta­m­­bién en co­­­mo co­n­­si­­de­­ra­r­­los den­­tro de los es­­ce­­na­­rios de ca­­li­­dad.

  • Los re­­que­­ri­­mien­­tos de­­ben prio­­­ri­­za­r­­se en el ma­r­­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­s­a­­mien­­to de in­­fo­r­­ma­­ción en co­­­las de men­s­a­­jes no tra­­di­­cio­­­na­­le­s (­­con es­­ta­­do pe­r­­sis­­ten­­te). Es un eje­m­­plo de una te­c­­no­­­lo­­­gía que tu­­vo un ca­­so de éxi­­to rea­­l en pro­­­ye­c­­tos de Big Da­­ta.

  • Sie­m­­pre gua­r­­dar la fuen­­te de da­­to­­s: lla­­ma­­da “la fuen­­te de la ve­r­­da­­d” (the sou­r­­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 eje­m­­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­­fo­r­­ma­­ción de fo­r­­ma ide­m­­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 eje­m­­plo eje­­cu­­tan­­do un SQL que su­­me uno en al­­gu­­na co­­­lu­m­­na), si­m­­ple­­men­­te se agre­­gue una nue­­va en­­tra­­da y lue­­go el re­­su­l­­ta­­do se ca­l­­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­­ve­r­­si­­ble de in­­fo­r­­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.

  • Si­m­­pli­­fi­­car las va­­ria­­bles te­c­­no­­­ló­­­gi­­ca­s. En lu­­gar de te­­ner un ex­­ten­­so re­­pe­r­­to­­­rio te­c­­no­­­ló­­­gi­­co co­­n ­­mu­­chas te­c­­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 ­­te­c­­no­­­lo­­­gía­s, y, aun­­que es­­tas no se ada­p­­ten pe­r­­fe­c­­ta­­men­­te a ca­­da pro­­­ble­­ma en pa­r­­ti­­cu­­la­­r, aún así hay que pri­­vi­­le­­giar el pra­g­­ma­­tis­­mo, ha­­cien­­do los ajus­­tes ne­­ce­s­a­­rio­­s.

  • Te­­ner un es­­que­­ma de da­­tos (da­­ta sche­­ma) pa­­ra po­­­der in­­te­­grar la in­­fo­r­­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­­te­c­­tu­­ras de mi­­cro se­r­­vi­­cios pe­r­­mi­­ten ob­­te­­ner la mis­­ma fun­­cio­­­na­­li­­da­­d, pe­­ro de fo­r­­ma ­­dis­­tri­­bui­­da, en contra­­po­­­si­­ción a lo que se­­ría una ar­­qui­­te­c­­tu­­ra mo­­­no­­­lí­­ti­­ca.

  • Es­­to pe­r­­mi­­te es­­ca­­lar de fo­r­­ma más fle­­xi­­ble, por eje­m­­plo se pue­­den ad­­mi­­nis­­trar los su­b­­sis­­te­­ma­s ­­de fo­r­­ma in­­de­­pen­­dien­­te, asi­g­­nan­­do los re­­cu­r­­sos o man­­te­­nien­­do más co­m­­po­­­nen­­tes pe­­ro más si­m­­ple­s.

  • Es­­ta se­­pa­­ra­­ción ta­m­­bién pue­­de re­­fle­­ja­r­­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 co­n­­ve­r­sar la ar­­qui­­te­c­­tu­­ra en fun­­ción de los re­­que­­ri­­mien­­tos con el PM, si­n ­­ne­­ce­s­a­­ria­­men­­te en­­trar en mu­­chos de­­ta­­lles té­c­­ni­­co­­s, co­n­­cen­­trán­­do­­­se en la fun­­cio­­­na­­li­­dad y ­­co­m­­po­r­­ta­­mien­­to es­­pe­­ra­­do.

  • És­­ta co­n­­ve­r­s­ación so­­­bre la ar­­qui­­te­c­­tu­­ra de­­be ser con­s­­tan­­te a lo la­r­­go de to­­­do el ci­­clo de de­s­a­­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 co­n­­ce­p­­tual es fun­­da­­men­­ta­­l: Las so­­­lu­­cio­­­nes de­­ben pro­­­po­r­­cio­­­na­r­­se de fo­r­­ma uni­­fo­r­­me, a­­pli­­can­­do sen­­dos es­­ti­­los y te­c­­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­­­ye­c­­tos se usan mu­­chas te­c­­no­­­lo­­­gías di­­fe­­ren­­tes, el re­­su­l­­ta­­do es una ar­­qui­­te­c­­tu­­ra ­­gi­­gan­­te y muy di­­fí­­cil de man­­te­­ne­­r.

  • Ca­­da co­m­­po­­­nen­­te té­c­­ni­­co in­­terno del equi­­po de in­­ge­­nie­­ría no es el pri­n­­ci­­pal ob­­je­­ti­­vo de la or­­ga­­ni­­za­­ció­­n, ­­si no que es­­tán pa­­ra res­­po­n­­der a és­­to­­s.

  • Ado­p­­tar nue­­vas te­c­­no­­­lo­­­gías so­­­lo por que pre­sen­­ta al­­gu­­nas ven­­ta­­jas pa­r­­cia­­les no sie­m­­pre es una bue­­­na idea a la­r­­go­­ ­­pla­­zo. Sue­­le su­­ce­­der que a la­r­­go pla­­zo te­r­­mi­­na te­­nien­­do co­n­se­­cuen­­cias pe­r­­ju­­di­­cia­­les pa­­ra el pro­­­ye­c­­to.

  • Los sis­­te­­mas de­­ben di­se­­ña­r­­se y con­s­­trui­r­­se pa­­ra du­­rar va­­rios años (~10), y es­­to im­­pli­­ca que la­s ­­te­c­­no­­­lo­­­gías de con­s­­tru­c­­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 tie­m­­po que du­­re el sis­­te­­ma pro­­­du­c­­ti­­vo. No se­­ría ­­de­­sea­­ble te­­ner que man­­te­­ner o ha­­ce­r­­se ca­r­­go de te­c­­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 ve­r­­da­­des re­­ve­­la­­das). Es­­to si­g­­ni­­fi­­ca que cuan­­do­­ a­l­­go se de­­no­­­mi­­na co­­­mo bue­­­na prá­c­­ti­­ca hay que plan­­tea­r­­se si rea­l­­men­­te es así, y aun­­que lo fue­­ra, si esas ven­­ta­­jas que trae apli­­can al pro­­­ye­c­­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­s­a­­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­­­ye­c­­tos apli­­can­­do “pa­­tro­­­nes de di­se­­ño” (o de ar­­qui­­te­c­­tu­­ra) o “bue­­­nas prá­c­­ti­­cas ági­­le­s”, etc. si­n ­­pen­sar rea­l­­men­­te có­­­mo apli­­can al pro­­­ye­c­­to (a­l­­go pue­­de ha­­ber da­­do re­­su­l­­ta­­dos ex­­ce­­len­­tes en otro pro­­­ye­c­­to­­, en otra em­­pre­s­a, en otro país, pe­­ro el ar­­qui­­te­c­­to de­­be co­n­­si­­de­­rar si esas va­­ria­­bles rea­l­­men­­te coi­n­­ci­­den o ­­son re­­le­­van­­tes al co­n­­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.