Injustificada Prepotencia

 

Tradicionalmente, ha existido cierta competencia o “pique” entre distintos profesionales de las tecnologías de la información de acuerdo al tipo de productos y tecnologías escogidas (Linux vs Windows vs Mac, Java vs .Net, Programación Orientada a Objetos vs “Programación Estructurada”, Pascal vs Cobol, Aplicaciones Web vs Clientes “pesados”, CVS vs SVN, ...).

Esta competencia ha sido generalmente “amistosa”, “la sangre nunca ha llegado al rio” y ha oscilado entre debates intelectuales intensos, con exposición de argumentos y análisis interesantes a formas amistosas de provocar o hacer bromas a un compañero.

Generalmente se ha respetado a la otra parte que utilizaba otra tecnología y como mucho se ha interiorizado al respecto reflexiones como: ”Si utiliza ese lenguaje posiblemente su código tendrá más errores”, “Creo que esa plataforma/lenguaje no tiene futuro”, “Pienso que no conseguirá buen rendimiento si utiliza ese sistema/lenguaje”,…, considerando poco adecuadas o menos eficientes las tecnologías de la otra parte pero manteniendo siempre una consideración profesional al que utilizaba esas tecnologías (como siempre con excepciones, que de todo hay).

Sin embargo, en estos últimos años creo percibir (y evidentemente no tengo datos estadísticamente significativos, y menos en algo tan subjetivo como lo que estoy comentando) una injustificada prepotencia en bastantes profesionales que utilizan tecnologías o paradigmas de “moda”, respecto a aquellos que no las utilizan o ¡incluso se atreven a criticarlas!. Entre las que situaría como “tecnologías/paradigmas de moda” podría situarse elementos como las bases de datos NoSQL, los Arquitectura de Microservicios, DevOps, desarrollo Agile, Cloud,…

La diferencia respecto a la situación anterior no es que se piense que la opción propia es mejor y que el otro profesional está eligiendo una opción errónea, es que parece que se considera a quien no utiliza esta tecnología como un “espécimen” a un nivel “evolutivo” cercano al australopiteco (tecnológicamente hablando, eso sí).

No se plantea un debate “de igual a igual”, sino una mirada de “conmiseración”, donde se opta por no entrar en debates y se llegan a oir frases como :“Pobre, no entiende cómo se hacen ahora las cosas”, “Se ha quedado anticuado”, “Usa los sistemas de antes”, "ahora las cosas ya no se hacen así",…  

Esta ridícula y totalmente injustificada prepotencia, no debida unicamente a los profesionales sino también a las empresas que presionan para que se utilice “el último grito“ en tecnologías y metodologías, a quien más perjudica finalmente es a las empresas, que acaban desplegando un producto que en ocasiones carece de la calidad adecuada y cuyo coste es mayor de lo que deberían, debido al uso de metodologías/tecnologías inadecuadas.

No está de más recordar el gráfico "clásico" de implantación de tecnologías, para ayudar a pensar con ponderación sobre los riesgos de "las modas".

 

IOTpreneur, CC BY-SA 4.0, via Wikimedia Commons

Los profesionales también acaban sufriendo horas adicionales de trabajo y sobrecarga y en muchas ocasiones mala imagen ya que la solución finalmente implantada “no funciona” o tiene un rendimiento lamentable, además de los retrasos sufridos. En cualquier caso, el profesional que elige o recomienda la tecnología es el primer responsable del posible fracaso. Y si recibe presiones de la empresa, debe al menos analizar esa nueva tecnología y, si no es realmente válida, transmitir ese riesgo a quien corresponde. Si aun así los responsables del proyecto insisten y luego hay problemas, no podrán decir que desconocían los incumplimiento de plazos, riesgos o costes potenciales.

Como he analizado anteriormente en artículos sobre diversos aspectos, como Cloud (http://pensamientocriticoti.blogspot.com/2019/10/cloud-o-cuidado-con-la-nube-que-puede.html), Framework (http://pensamientocriticoti.blogspot.com/2019/03/los-framework-de-desarrollo-un-regalo.html), Metodología Agile (http://pensamientocriticoti.blogspot.com/2017/12/reflexiones-sobre-las-metodologias.html) o Microservicios (http://pensamientocriticoti.blogspot.com/2017/10/los-microservicios-no-son-la-solucion.html), no no hay solución “mágica” y no siempre un paradigma o tecnología “de moda” es mejor o más adecuado.

Contra esta especie de adanismo, que piensa que “el mundo acaba de empezar y antes no existía nada comparable”, creo que es conveniente recordar datos como los siguientes:

• Antes de la “moda” de los servicios REST existió hace más de 20 años la “moda” los WebServices con toda su parafernalia de productos y conceptos como “diccionarios de servicios “(diccionarios de API,), “desacople de aplicaciones”, “el final de las aplicaciones monolíticas,”.. ¿suena familiar?.

• Antes de se difundiera la virtualización, IBM ya disponia en 1972 de sistemas de virtualización con su tecnología VM  en sistemas tan “obsoletos” como el mainframe, trabajando con lenguajes “anticuados” como COBOL.

• El concepto de nube (Cloud), como lugar donde albergar nuestros servidores y bases de datos, es básicamente lo mismo que se ofrecía en los 90 como “hosting”.

• Antes del manifiesto y la metodología Agile ha habido muchos sistemas y metodologías iterativas y con implicación/revisión con el usuario/propietario del software, como puede ser la programación extrema XP ( ¿suena familiar ese proceso iterativo con intervención del cliente de la XP? ), remontándonos incluso a los años 60s.

• Los famosos desarrollos serverless, es decir no tener un servidor levantado todo el tiempo sino arrancar un proceso para atender una petición (personalmente me parece un derroche y poco eficiente, pero el análisis sería objeto de otro artículo, y como siempre, puede tener ventajas en algún caso) es básicamente el mismo concepto de desarrollo de aplicaciones web por medio de CGI definido a principio de los años 90s

Por supuesto he hecho una simplificación y hay diferencias, pero las ideas y conceptos básicos de todas esas tecnologías y paradigmas que he comparado son realmente las mismas.

La conclusión de ese repaso sería que “casi no hay nada nuevo bajo el sol”, o al menos que las “nuevos” paradigmas y tecnologías de desarrollo no son tan “nuevos” como pensamos en ocasiones, salvo algunas excepciones, que por supuesto las hay. En general, es un proceso más evolutivo y gradual de lo que aparenta, con muy pocos saltos “gigantes”.

 

Charles Darwin [See page for author, CC BY 4.0 , via Wikimedia Commons]

Acudiendo a Darwin, mal interpretado en muchas ocasiones, no es “La supervivencia del más FUERTE”, es “la supervivencia del mas APTO”(https://es.wikipedia.org/wiki/Supervivencia_del_m%C3%A1s_apto) para un medio y entorno concreto (por eso, una característica que facilita la supervivencia en un desierto puede dificultarla en una jungla).

En nuestro caso la tecnología o profesional más adecuado para un proyecto, no existe “MEJOR” (más fuerte) tecnología para todos los proyectos, ni ninguna tecnología o metodología es mejor siempre y por tanto, no debe aplicarse siempre ni automáticamente.

Todo ello creo que debe hacernos reflexionar, ser más abiertos y tomar más en consideración tanto a cualquier tecnología como a cualquier profesional para evaluar y diseñar soluciones.

No más "liderazgo", por favor.

Es muy habitual leer periódicamente artículos en distintos ámbitos, incluyendo foros profesionales como LinkedIn, acerca de las características de un “buen lider” o del “liderazgo”. Ya entrado el S.XXI, ¿No es esto muy “medieval”? ¿No suena a los consejos para ser “buen rey”? o más aún ¿No suena a recomendaciones para ser “macho alfa”?. 

 

Las sociedades más avanzadas y prósperas se caracterizan principalmente por tener una buena organización y legislación (social, laboral, educativa, sanitaria, etc.), no buenos reyes (o presidentes). ¿No debería ser igual el modelo para las empresas? ¿No debe basarse en la normativa (legislación) interna? ¿No debe “gobernar” un buen gestor por medio de la creación de normas y organización del trabajo y no tomando decisiones puntuales? ¿Quién conoce a los líderes de países situados en los primeros puestos mundiales en cuanto educación, calidad de vida o servicios sociales? (como suele asociarse tradicionalmente a los países nórdicos)

Sin entrar a valorar estas características defendidas asociadas a los "líderes", que en muchos casos son interesantes y ayudan al desempeño y funcionamiento de la empresa, quería reflexionar sobre el retraso y la falta de eficiencia que ese modelo arrastra.

¿Admitiríamos que el Ministro de Hacienda personalmente decidiera para cada contribuyente en concreto qué porcentaje de ingresos debe paga en concepto de impuestos?

No, evidentemente se exige una ley que especifique ese porcentaje en función de los ingresos, así como una serie de desgravaciones y consideraciones igualmente fijadas, para que no pueda definirse discrecionalmente.

Similarmente, ¿Podría funcionar un país en que no estuviera reglado, por ejemplo, la relación entre ayuntamientos y estado o qué nivel del estado (Central, autonómico, municipal) es responsable de la Sanidad?

Sin embargo, el funcionamiento de muchas empresas, especialmente en el área de servicios, y más aún en las de TI, sigue un modelo muy “medieval” donde la discrecionalidad es muy alta en todos los aspectos y los diversos niveles. No me refiero a los aspectos laborales que están reglamentados por leyes o convenios generales (aunque hay elementos como las horas extras o la flexibilidad horaria que cuyo respeto es muy discutible), sino a las funciones y organización interna.

Rsc src / CC BY-SA (https://creativecommons.org/licenses/by-sa/3.0)

 

Creo que son escasísimas las empresas en que cada persona/categoría tiene por escrito cuales son funciones o cada departamento sus funciones y la relación con otros departamentos.

Por supuesto se puede alegar que cuando se contrata a una persona, se le contrata para un puesto. Sin embargo, eso significa muy poco por varios motivos:

1. En muchos casos la empresa tiene unas pocas categorías dentro de las cuales caben muchísimas personas. Ser contratado como “Consultor Senior” o “Analista” no explicita claramente las funciones.

2. En muchas ocasiones, se asigna a las personas en una categoría por su sueldo y no por sus funciones.

3. El significado de cada categoría o puesto varía mucho entre empresas (e incluso entre departamentos).

4. Además de las promociones, puede haber movilidad interna y asignación a otros puestos.

Así, podemos ser “Administradores de Sistemas” pero eso no indica si debo instalar TODOS los sistemas o por ejemplo solo Linux, o, siendo “Administrador de Bases de Datos” no implica si además debe instalarse y configurarse el sistema operativo sobre el que se instalará la base de datos o eso lo hará un “Administrador de Sistemas”.

Con los departamentos y áreas ocurre lo mismo. Por supuesto cuando hay reorganizaciones suele publicarse un organigrama (aunque conozco muchos casos en que brillan por su ausencia y como mucho hay una lista de directores), donde aparece, por ejemplo “Área de Ventas”, “Área de Consultoría” o “Área de Sistemas” con sus responsables correspondientes. Sin embargo, al margen de unas descripciones breves de las funciones (que básicamente explican lo que se deduce del nombre) no suele detallarse realmente las funciones ni las relaciones.

Así, por ejemplo, si el Área de Ventas necesita acudir con un técnico del Área de Consultoría para una labor de preventa para un posible cliente ¿Debe solicitarlo al área de consultoría? ¿Se le cobrará internamente? ¿Qué ocurre si hay colisiones entre las dos áreas?

Toda esta indefinición provoca, por una parte, mucha ineficiencia y falta de productividad, ya que en cada caso hay que analizar qué hacer, o no se hace ya que se espera que otra persona/equipo lo haga o en el peor de los casos se hace mal y hay que repetirlo.

Además, obliga a mucha microgestión, es decir a que cada responsable tenga que estar dirigiendo continuamente al nivel inferior, o peor aún, a varios niveles por debajo, ante la falta de reglas claras que permitan tomar decisiones sin consultar o pedir permiso. Este problema, además de en las escuelas de negocio, se ha comentado bastante en el ámbito de los juegos de estrategia en ordenador, donde se ha evolucionado desde los juegos más primitivos, que obligaban a tener que indicar continuamente a cada pieza del juego qué hacer (moverse de un punto a otro, realizar una actividad concreta, ...), hasta poder dar criterios generales (“busca recursos”, “vigilar toda esta zona”,..).

 

Four Blair Services Pvt. Ltd. / CC BY-SA (https://creativecommons.org/licenses/by-sa/4.0)

Por otra parte, esa falta de definición provoca desafección y “quema” a los profesionales. Al igual que se crea descontento ciudadano si las leyes no están claras y alguien puede ser penalizado sin que exista un motivo claro, los empleados tratados como “súbditos”, que no conocen las normas y las “leyes” a seguir y dependen de la discrecionalidad y buen (o mal) hacer de su responsable, en lugar de ser autosuficientes y tener MUY claro su trabajo, lo más probable es que acaben “emigrando”.

Además esta discrecionalidad en cuanto a tareas asignadas, funciones, etc. acaba provocando mal ambiente y sensación de “enchufe” o “persecución” al no estar claramente definido el marco de juego. Incluso aunque el responsable se comporte de forma justa y sistemática, se acaban provocando problemas y sospechas de subjetividad, difíciles de romper ya que no hay “reglas del juego” claras.

Al igual que todas las jerarquías del estado (desde un primer ministro a un alcalde) gobiernan promulgando leyes y disposiciones de diverso rango, ¿no deberían los distintos responsables “gobernar” por medio de normas, es decir definiendo los procedimientos y responsabilidades de cada área y de cada grupo profesional (grupo no desde un punto de vista laboral o de cobro de nóminas sino de funciones reales)?

Dr ian mitchell / CC0

 

No estoy planteando un modelo autogestionario o plano, que por otra parte, hasta cierto punto es básico de las metodologías agiles, el modelo más moderno y en boga de desarrollo de aplicaciones, así que tampoco es una opción a desdeñar, sino simplemente resalto la importancia de definir una organización clara y documentada (tal como hacía hincapié en un artículo anterior).

Esto es, por otra parte, el corazón de todos los sistemas de calidad (como dice la definición tradicional de calidad: “Haz todo lo que escribes y escribe todo lo que hagas”) y evita depender de la mayor o menor habilidad de todos los intervinientes (incluidos todos los escalones jerárquicos de la empresa). Si todo el mundo trabaja tal como indican los procedimientos, hay menos incertidumbre, mayor calidad y mayor rendimiento ( o competitividad, es decir producto o servicio producido por coste, independientemente de que hablemos de una empresa privada o de una institución pública).

Sin quitar importancia al valor que aporta cada persona, y a las características que un buen gestor puede aportar a cualquier equipo (no todo puede estar reglamentado, las relaciones humanas son importantes, un mal ambiente puede hundir a cualquier grupo de trabajo, etc,) pensemos en que cualquier empresa es una estructura muy compleja y la única forma de que funcione eficientemente es una buena y clara organización, conocida por todos los empleados y departamentos y documentada.

Durante esta pandemia, en que un porcentaje importante de la población, de distintos sectores y categorías profesionales, ha estado teletrabajando, y por tanto sin sus responsables respectivos "encima", hay estudios que han detectado mejoras de productividad. Al no estar en contacto continuo, probablemente ha sido necesario dar "criterios generales" para que los empleados realicen su trabajo. Esto parece confirmar que no se trata de "liderazgo" sino de organización.

En el siglo XXI lo importante no son los reyes sino los estados.....

CPDs "tuneados"

En los últimos años se está produciendo de forma exagerada lo que podríamos llamar “CPD tuneados”. Y utilizo esa expresión por comparación con esos coches que podemos encontrar por la calle, con alerones y extensiones de diverso tipo, luces por debajo y pintados con unos diseños de gusto discutible, y que sin embargo en ocasiones tienen un motor y unos amortiguadores “manifiestamente mejorables”.

"DSC01000" by carc772 is licensed under CC BY-NC-SA 2.0

De forma equivalente, nos encontramos con empresas que carecen de herramientas de gestión documental (https://pensamientocriticoti.blogspot.com/2018/02/la-maldicion-de-la-gestion-documental.html), con procesos sin automatizar con herramientas de  BPM o de Gestión de Expedientes, servidores y sistemas de bases de datos obsoletos y en general, sin los sistemas ESTRUCTURALES adecuados, pero que sin embargo están analizando cómo utilizar Blockchain,  Bigdata o Machine Learning  a pesar de que probablemente no podrán aplicarlo o no les será de utilidad ( https://pensamientocriticoti.blogspot.com/2018/03/por-que-bigdata-no-es-para-todo-el-mundo.html ) o cómo desplegar en la Nube (Cloud) aunque en ocasiones puede resultarles más costoso o incluso ilegal de acuerdo a la normativa del país.

Hace tiempo, herramientas y tecnologías aplicables a mejorar y automatizar los procesos de una empresa, y por tanto a ser más competitivos, eran objeto de análisis y selección exclusivamente del departamento de tecnología/informática/TI y el resto de los departamentos simplemente solicitaban que se mejorara o informatizara procesos o área concretas, “como fuese”, ya fuera adquiriendo equipos, desarrollando programas o comprando productos. Es decir, los usuarios indicaban qué funcionalidad querían y los técnicos buscaban cómo ofrecerla de la mejor manera posible.

Sin embargo, últimamente diversos términos y tecnologías “se han puesto de moda”, son “cool” y desde multinacionales hasta pymes solicitan a los departamentos de TI “que instalen Bigdata”, que “apliquen Machine Learning” o que se implante cualquier otra tecnología en boga.

Por supuesto, muchas de esas tecnologías pueden ser muy interesantes y reportar beneficios pero el problema es la falta de un análisis racional antes de emprender su uso. Volviendo al ejemplo de los coches ¿Tiene sentido añadir unos alerones nuevos cuando el motor no funciona bien y los amortiguadores no prestan la amortiguación adecuada? ¿No es más racional, y aportan mayor rendimiento, el mejorar y poner a punto los elementos básicos del coche en lugar de añadir anexos que aportan poco (o incluso no aportan nada)?

 Cuando la racionalidad y el rendimiento prima, por supuesto que es así; en Fórmula 1 nadie “toca un tornillo” sin exhaustivos estudios, ya que se trata de optimizar todo (consumo, resistencia, respuesta, etc.) pero esto no tiene por qué aplicar a una persona joven orgullosa de su coche, que puede desear lucirlo ante sus amistades, ya que el beneficio puede ser de imagen, no económico.

Public Domain

Sin embargo en una empresa la productividad y el rendimiento mandan, o eso debería ser. Pero el comportamiento de muchas empresas se parece más al de la persona joven que quiere lucir el coche que al del equipo de Fórmula 1 que quiere mejorar el rendimiento de un coche. Y para ello, como “queda bien”, se emprenden proyectos costosos y en muchos casos inútiles, para implantar tecnologías innecesarias o no aplicables.

Por supuesto que puede considerarse  una inversión como mejora de imagen, ya que se ofrece una visión de empresa moderna, pero en cualquier caso analizando el coste/beneficio, lo que no suele ser el caso.

A esta “orgía tecnológica” innecesaria contribuyen muchas empresas que ofrecen un futuro maravilloso y consiguen vender proyectos costosos, y en muchas ocasiones inútiles o con pocos beneficios, en base a unas expectativas irreales o excesivas (Algunos ejemplos de que "no es oro todo lo que reluce": https://medium.com/@kaistinchcombe/decentralized-and-trustless-crypto-paradise-is-actually-a-medieval-hellhole-c1ca122efdec , https://hackernoon.com/ten-years-in-nobody-has-come-up-with-a-use-case-for-blockchain-ee98c180100 , https://www.bloomberg.com/news/features/2018-03-09/bitcoin-is-ridiculous-blockchain-is-dangerous-paul-ford ).

Pero el análisis de la eficacia o no de muchas tecnologías no es el objetivo de este texto, sino la desigualdad de medios empleados en mejorar o informatizar procesos y funciones críticas de la empresa frente a los esfuerzos invertidos en elementos “decorativos”.

En ese sentido, la participación e iniciativa de los usuarios y departamentos fuera del de TI, que es muy deseable y necesario por supuesto, no debería ser “Quiero un proyecto para implantar Bigdata/Blockchain/….” Sino “Este proceso/aplicación no es muy eficiente, convendría mejorarlo o implementarlo de nuevo” O “¿Qué sistemas podemos mejorar para que el proceso, coste o interacción con los usuarios/clientes mejore?”.

Si la respuesta a eso, tras un estudio, resulta ser que conviene implementar Blockchain/BigData/…., perfecto, bienvenido sea, pero el invertir tiempo y dinero en una tecnología por ser "moderna" nos lleva a un CPD tan “tuneado” e ineficiente como algunos de esos coches que podemos encontrar.

Los Framework de desarrollo, un "regalo envenenado"

Voy a expresar algo que, aunque a muchos desarrolladores “horrorizará”, estoy seguro de que muchos otros comparten: Los Framework  (marcos de desarrollo) son un “regalo envenenado”.

Aunque su uso está muy extendido y existen muchos Frameworks, generalmente suelo evitar su uso para los proyectos en que participo y creo que en muchos casos, a pesar de sus aparentes ventajas, son contraproducentes.

Por supuesto esto no es una norma absoluta, y hay casos en que sí me parece apropiado, ya sea por normalizar desarrollos o porque el proyecto lo requiera.
El problema es que muchos Arquitectos y Desarrolladores dan por supuesto que “deben utilizarse”, que "es la mejor opción" y “te miran como un marciano” si, por ejemplo, argumentas que prefieres no usar Hibernate.

Sin embargo, tal como predica el pensamiento crítico, no debemos asumir nada sin reflexionar. Argumento a continuación por qué no es tan evidente la ventaja.

 

Framework vs bibliotecas.

El primer punto a aclarar es la denominación de Framework de desarrollo y su diferencia con las bibliotecas de desarrollo, librerías o APIs de productos o servicios.

En cualquier lenguaje de programación, cuando hablamos de bibliotecas, nos referimos a un conjunto de funciones , métodos y clases que nos permiten realizar diversas operaciones (ordenar listas de valores, reproducir archivos de audio o video, generar gráficos, acceder a servicios o a bases de datos,  etc.). Por tanto cuando desarrollamos un programa y utilizamos bibliotecas, debemos construir y elaborar la lógica del programa, y cuando necesitamos utilizar unos servicios “especializados”, en lugar de programarlos desde cero, se acude a esas bibliotecas que alguien ha construido previamente (y que se habrán publicado como software libre o  como producto privativo, con sus correspondientes licencias). Es decir en este escenario, la lógica y el marco de trabajo lo impone el proyecto, que solo acude a las bibliotecas para algunas funciones.

En cambio, cuando desarrollamos utilizando algún framework (como AngularJS, Struts,  SpringBoot  o Ruby on Rails ) el marco o modelo de trabajo lo fija el Framework, que impone una estructura, una lógica y una forma de trabajo, dentro de la cual la tarea de desarrollo del proyecto es “rellenar los huecos” (lo que no implica que sea poco trabajo, pueden ser "huecos" enormes de miles de horas de desarrollo por supuesto).

Modelo MVC usado en Frameworks como Struts (by Wooptoo [Public domain])

Comparando con un modelo más cercano a todos, si estuviéramos construyendo una estantería para nuestra casa, el modelo de desarrollo basado en librerías equivaldría a cortar las maderas a medida y, para las piezas complicadas, como cajones o elementos abatibles, comprar esas piezas ya hechas.

En cambio el equivalente a utilizar un Framework sería comprar unas estanterías con unas dimensiones fijas, y rellenar los huecos con baldas para adaptarse a nuestras necesidades.

Por supuesto el modelo no es totalmente exacto y además en ocasiones la frontera es difusa, ya que los Framework tiene bibliotecas de funciones adicionales/complementarias y las bibliotecas en ocasiones imponen una forma de trabajo. Pero como aproximación creo que es válida.

Con una biblioteca, el desarrollador “manda”, dirige el flujo y lógica e invoca las funciones deseadas cuando se necesitan-

Con un Framework, el desarrollador se “adapta” al Framework, se ajusta a esa lógica y “contrato" y es “invocado” dentro de ese modelo.

 

Ventajas de los Framework.

Por supuesto, los Framework tienen muchas ventajas:

• Conforman un esqueleto bien estructurado, con lo que no hay que pensar en muchos aspectos (gestión de errores, verificación datos, etc.), pues ya están previstos.
• Cuando hay un equipo grande, o varios equipos en una empresa, asegura que todos los proyectos se desarrollen igual.
• Las personas que se incorporen a la empresa, al ser un Framework estándar, es posible que conozcan ese Framework, y pueden ser productivos antes.

Telco [Public domain]

En muchas ocasiones, y como se da por supuesto que “los Framework son muy útiles y aumentan la productividad”, solo se recuerda las ventajas, o incluso no se analiza, simplemente se utilizan porque “ahora se programa así”.
Sin embargo, “no es oro todo lo que reluce”.

 

Inconvenientes de los Framework.

Entre los principales inconvenientes, puede citarse:

• El “sobrepeso”: Muchos Framework son “monstruosos”, e introducen una sobrecarga muy importante, lo que implica mucho más hardware para poder prestar los mismos servicios. El ahorro en tiempo de desarrollo puede no compensar el coste en infraestructura adicional.
• La compatibilidad: En ocasiones, los Framework cambian la forma de trabajo y te obligan a cambiar gran parte del código y/o de la lógica de un proyecto. Quizá un ejemplo “sangrante” es el cambio en alguna versión de AngularJS, que lo convertía en totalmente incompatible con la versión anterior. En cambio, si una biblioteca cambia ciertos métodos o clases, es posible realizar cambios en la llamada a esos métodos, o incluso crear un recubrimiento con el “contrato” anterior, que convierta internamente las llamadas al nuevo estilo, sin afectar demasiado al grueso del programa.
• El exceso de dependencias: Es habitual que muchos Framework arrastren muchas herramientas y bibliotecas. ¿Qué ocurre si además del Framework queremos usar otras bibliotecas, como es habitual? Esas bibliotecas, que en ocasiones requieren bibliotecas adicionales complicando aún más el escenario, pueden colisionar con las del propio Framework. El resultado es que no puedes utilizar la biblioteca que deseas y hay que buscar otras. Hay otro efecto peor, que es que la incompatibilidad surja a posteriori, es decir cuando se actualiza la versión del Framework y descubres que colisiona con alguno de los elementos que ya utilizas, lo que obliga a hacer (bastantes) cambios. Por supuesto, pueden surgir colisiones entre bibliotecas aunque no se utilice Framework, pero las probabilidades son menores y, además, siempre pueden cambiarse por otras con menos impacto que el rehacer toda la lógica.
• La continuidad en el tiempo: Si una biblioteca desaparece, se cambia por otra con relativo esfuerzo. Si un Framework desaparece, hay que “rehacer” el proyecto.
• El aprendizaje: Los Framework suelen ser grandes y complejos, lleva tiempo aprenderlos y entender la lógica y empezar a desarrollar bajo ellos.
• La evolución: Al ser muy grandes, la evolución puede ser lenta y no estar disponibles para, por ejemplo, la última versión de Java, base de datos, navegador o sistema operativo.

 

¿Hay alternativas?

Si se desea acelerar el desarrollo, aumentar la calidad (evitando errores) y seguir una estructura común (para facilitar la movilidad entre equipos). ¿No hay más remedio que utilizar Framework?

No necesariamente, hay diversos recursos:

• Crear un mini-Framework propio, creando una estructura de clases que gestionen el esqueleto, incluyendo todos los controles de errores y escenarios necesarios, y dejando que los proyectos creen subclases y sobrecarguen los elementos necesarios. No serán tan sofisticados como un framework, pero a cambio:
• Estarán más adaptados a nuestros desarrollos y negocio
• Serán mucho más ligeros
• No se depende de terceros y por tanto pueden evolucionarse como nuestros desarrollos requieran.
• Crear patrones internos, de forma que los desarrollos tengan un modelo o proyecto tipo, que se copie y cambie.
• Definir normativas y recomendaciones internas.
•  . . . .

 

Conclusiones

Creo que si se desea un nuevo proyecto (o reorganizar un equipo de desarrollo), antes de asumir que se utilizará el Framework XYZ (o al contrario, asumir que NO se utilizará NINGÚN Framework) es imprescindible plantearse preguntas como:

¿Cuánto ahorro en tiempo de desarrollo frente a cuánto tardo en aprenderlo?
¿Aprovecho el 100% del Framework o solo un pequeño porcentaje?
¿Es más eficaz utilizar uno o construir uno mismo un pequeño framework o librerías?
¿Es estable o puede cambiar?
¿Qué sobrecarga introduce en términos de recursos de máquina requeridos?
¿Es válido para muchos proyecto o solo este?
¿Arrastrar muchas librerías? ¿Cuales?
¿Qué limitaciones de ejecución y plataforma me impone?
. . .

Una vez sopesadas todas las opciones, con una visión crítica podremos elegir la más adecuada que en ocasiones podrá ser la que inicialmente esperábamos como “normal” y en otros casos no, pero en cualquier caso habrá sido una decisión sopesada y SIN ASUMIR nada.

La "barrera del sonido"

Recuerdo haber oído esta expresión a dos empleados de recursos humanos tomando un café, hace muchos años en una consultora en que trabajaba. Se referían a un candidato que había “traspasado la barrera del sonido”, es decir, había superado cierta edad (desconozco si podían ser 40 o 50 años), lo que prácticamente lo descalificaba para el puesto.

Aunque el tema de la edad laboral se ha tratado en numerosas ocasiones por especialistas, y aunque parece ridículo tener que argumentar sobre algo tan evidente, especialmente en el ámbito de las Tecnologías de la Información que es el que mejor conozco, creo que no está de más volver a reflexionar sobre el alto coste económico que tiene para una empresa de Tecnologías de  la INFORMACIÓN el “tirar a la basura” toda esa INFORMACIÓN y experiencia que albergan empleados a los que se prejubila o que tienen esos candidatos a los que no se contrata.

Quizá lo primero a destacar que es creo que este modelo es principalmente aplicable a España. Los datos de que dispongo, tanto obtenidos desde Internet como directamente de otros profesionales (compañeros o proveedores) que trabajan en otros países, muestran que no ocurre, o no con tanta frecuencia, en otros países.

By Internet Archive Book Images, via Wikimedia Commons

Escenarios de “derroche”

Creo que en las empresas de TI hay tres formas en que se desperdicia el capital humano por la edad:

• Estructura de la carrera profesional
• Prejubilaciones y despidos
• No contratación por edad

 

Estructura de la carrera profesional

En la mayoría de las empresas de TI no existe REALMENTE una carrera profesional PROLONGADA que permita a un buen técnico seguir evolucionando en su carrera aumentando el RECONOCIMIENTO profesional y el SUELDO.
En gran parte de las empresas de tecnología la evolución implicar dejar de ser técnico y convertirse en gestor (si se desea que el sueldo y el reconocimiento aumenten). Esto provoca que, en ocasiones, la empresa pierda un buen técnico y adquiera un mal gestor (según el clásico Principio de Incompetencia de Peter ).
Por supuesto no quiere decir que todos los jefes de proyecto deban proceder carreras de gestión (es habitual ver resultados desastrosos cuando alguien que no conoce las singularidades y características del desarrollo de software intenta gestionar o dirigir el trabajo, por lo que es recomendable que la gestión la realicen personas con experiencia en tecnología), sino que la evolución debe ser por convencimiento e interés y no de forma “forzada” para no quedarse estancado.
El resultado es que esa experiencia y conocimientos se pierden y la empresa, que posiblemente ha sustituido en  su “pool” de técnicos un perfil “caro” por uno “barato”, en lugar de aumentar su beneficio, pierde en eficiencia (produce más barato pero probablemente  más lento y con peor calidad) y posiblemente pueda tener más errores o retrasos, con los costes asociados.

Esto desde luego no ocurre, o no de forma tan acusada, en otros países (basta comparar las bandas salariales o las ofertas de empleo habituales en España y otros países). Esto se evitaría si, como ocurre en otros países, puedes encontrar un programador con 60 años al que todo el mundo consulta y respeta  al que se encarga los proyectos difíciles y pide asesoramiento.

Prejubilaciones y despidos

A lo anterior hay que sumar los despidos o prejubilaciones a partir de una edad. El argumento, que en algunos casos puntuales es cierto, de dificultad o incapacidad para reciclarse, en la mayoría de los casos no tiene ningún soporte objetivo.
El mundo de las TI ha cambiado radicalmente cada pocos años y la mayoría de los profesionales han tenido que aprender nuevas herramientas y sobre todo nuevos paradigmas y tecnologías.

El despido de esos profesionales que conocen los proyectos y herramientas de la empresa, dado que muchas veces la documentación es incompleta, o incluso no existe, hace que se pierda mucho valor y mucha productividad.

En el mejor de los casos, se perderán varios meses hasta que una nueva persona, sin experiencia, aprenda todos los detalles, por lo que el ahorro en salarios debe minorarse restando todos esos meses improductivos.

En el peor, no habrá nadie capaz de asumir la tarea, o quien la asuma lo hará con errores que tiene un coste.
Y ese coste puede ser muy grande (indemnizaciones a clientes, perdida de muchas horas de trabajo de empleados,..).
Lamentablemente no se suele imputar esos errores o pérdidas al departamento que “ha ahorrado” sino que en ocasiones parece atribuirse a “una conjunción de astros” o a “lo complicada que es la informática” por lo que no hay forma de comparar el impacto real de esos “ahorros”.
Una imputación real de lo que cuesta esos “ahorros” sustituyendo a profesionales avezados por becarios posiblemente mostrara cifras mucho peores y probablemente costes mayores.

Nadie responsable plantea usar tornillos de mala calidad para utilizarlos en piezas estructurales y sin embargo sí se considera “normal” prejubilar a profesionales “de calidad” y sustituirlos por profesionales sin experiencia. La diferencia es que cuando un tornillo se rompe y la empresa tiene que pagar indemnizaciones, las responsabilidades y la causa suele ser más clara, mientras que si un desarrollo falla y la empresa tiene que asumir indemnizaciones, la causa no siempre se plantea de forma tan clara.

Por último, como ejemplo claro del absurdo a que se llega, conozco al menos dos casos de empresas que prejubilaron a técnicos (con su indemnización correspondiente) y tras descubrir que nadie conocía cómo hacer su trabajo, tuvieron que contratarles de nuevo como consultores externos (con sus costes extras).

No contratación por edad

Los casos anteriores se producen con empleados dentro de la empresa, pero un porcentaje importante de los casos se produce por la no contratación de profesionales que han superado cierta edad.
Desde luego en este caso no aplica la obsolescencia de conocimientos o imposibilidad de reciclar, ya que si no conocen la tecnología o disciplina para la que se les requiere, no hay por qué contratarles, independientemente de su edad.

Por tanto el único motivo puede ser la edad, y en ocasiones, su banda salarial, que puede ser más alta que la de un recién licenciado. Como en el caso anterior, parece claro que la productividad y calidad compensan (en gran parte de los casos) el coste sobre un recién licenciado.

Lamentablemente, parece que estas “manías” (no he encontrado en mi vida nadie que sea capaz de dar una argumentación coherente a este tema, por lo que solo puede tacharse de “moda” o “manía”)  se extienden a algunas empresas que mantenían un criterio coherente: https://www.elconfidencial.com/alma-corazon-vida/2018-05-04/empresas-trabajar-discriminacion-edad_1558692/

0 A.D. game Wildfire games (CC)

Es curioso, que ahora que está tan de moda la gamificación, y que además hace tiempo que se considera que los juegos permiten aprender técnicas y estrategias luego aplicables a la vida empresarial, no se recuerda algo que cualquier jugador de juegos de estrategia conoce:

En la mayoría de juegos de estrategia, la táctica ganadora pasa siempre por tener pocos soldados muy bien equipados y con mucha experiencia  (“caros”) y no en tener muchos  “baratos”. 

Y eso se lleva aplicando desde hace siglos al juego de estrategia por antonomasia, el ajedrez. Ningún jugador cambiaría una reina por dos o tres peones.

By User:Mutante [CC], from Wikimedia Commons

Como en otros casos, esperemos que una revisión crítica de los costes e impacto real de los “ahorros” en personal, al igual que he comentado respecto al material de trabajo  reconduzca la situación.

Reflexiones sobre las Metodologías Agiles

En estos últimos años, se ha ido extendiendo el modelo de desarrollo software llamado Metodología Agile o desarrollo ágil de software, en sus distintas variantes y enfoques: Kanban , Scrum o XP entre otros. Aunque muchos principios son antiguos, y algunos como la Programación Extrema (XP) se pusieron de moda hace años, ha sido últimamente cuando se ha desatado el “furor” por este modo de trabajo.

En el Manifiesto por el Desarrollo Ágil se resaltaron una serie de criterios y ponderaciones

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan

Que se plasman en 12 principios:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

By Dr ian mitchell (Own work) [CC BY-SA 3.0]

De forma muy simplificada, ¿qué se pretende conseguir?

Pues que en lugar de acordar con un cliente (interno o externo) un proyecto totalmente cerrado, que el cliente no ve hasta que han pasado muchos meses, descubriendo (con horror en algunos casos) en el momento de la entrega que no tiene nada que ver con lo que pensaba, se utiliza una aproximación gradual que el cliente/usuario puede ir siguiendo y orientando.

En lugar de un modelo jerárquico donde un jefe de proyecto o un analista transmite unas decisiones (que en algunos casos pueden ser erróneas), se utiliza un modelo cooperativo de trabajo en equipo, donde todo el mundo (incluido el usuario) aporta y se siente integrado, consiguiendo más calidad y productividad.

Y en lugar de perder demasiado tiempo documentando y actualizando documentación en algunos casos innecesaria, debe emplearse en hacer un código fuente claro y autodocumentado.

Personalmente pienso que el trabajo en equipo y la implicación de todos integrantes de un proyecto es un principio indiscutible, se use la metodología que se use. El tener en cuenta las opiniones de profesionales con distintos enfoques (programador, arquitecto, experto en base de datos, administrador,..) enriquece y permite detectar problemas y orientar mejor el proyecto, teniendo en cuenta la experiencia de cada perfil.

Igualmente la participación del cliente/usuario, evita un efecto “teléfono estropeado” donde el usuario cuenta lo que quiere a un técnico, que lo traduce para otro que lo transmite a otro, hasta que al final el programador implementa algo totalmente distinto.

También parece indiscutible, se use la metodología que se use, la efectividad de revisar el trabajo y el modo de desarrollo, buscando y aplicando mejoras al mismo (tanto a las soluciones como al modo de trabajo), lo que lleva años aplicándose en cadenas de montaje industriales de Japón con el nombre de Kaizen.

Sin embargo hay otros principios que aunque inicialmente parecen muy razonables, sin embargo pueden provocar problemas. Como en cualquier herramienta, disciplina o metodología, los problemas provienen de dos fuentes: mal uso de la metodología y problemas intrínsecos a la metodología, que en algunos casos se entremezclan.

Algunos problemas potenciales

Quizá el primero que surge es el de coste y plazos. Antes de empezar un proyecto debe conocerse su viabilidad y fechas de disponibilidad. Si el alcance (requisitos) y la solución no están muy cerrados no es posible conocer si el proyecto es viable ni si podrá entrar en producción en plazos. Por tanto, o se conocen (casi) todos los requisitos inicialmente (lo que choca con la “alegría” en “recibir requisitos en épocas tardías”), o son requisitos menores o se corre el riesgo de irse en plazos y costes tanto o más que en desarrollo “tradicional”.

Hay otro riesgo relacionado con el suministro gradual de requisitos. Como se citaba en el párrafo anterior, hay requisitos que pueden implicar más trabajo, pero hay requisitos que pueden implicar cambios sustanciales en la solución o herramientas usadas. Hace años las aplicaciones se desarrollaban en un lenguaje de programación u otro, almacenaban los datos en una base de datos y el grueso del trabajo era “programación” sin más. Pero los proyectos son cada vez más complejos, se exigen más funcionalidades, y los volúmenes son mayores. Esto ha provocado que raramente se desarrolle absolutamente todo desde cero. Lo habitual es que se utilicen framework de desarrollo, que se utilicen muchas librerías o bibliotecas  y que se integre múltiples productos y servidores en un solo proyecto. Los requisitos de “última hora” pueden provocar que se descubra que alguno de los lenguajes/productos/librerías/tecnologías elegidos no sirven porque no cubren esa función o no ofrecen el rendimiento esperado, lo que puede provocar:

• el rehacer gran parte del desarrollo para integrar otro producto/librería,
• el tener que comprar licencias de otro producto,
• el requerir infraestructura y servidores que no estaban previstos,

Todo ello con los costes económicos y de plazos asociados.

Otro punto potencialmente peligroso es el de las “entregas periódicas”. Un proyecto medianamente complejo requiere normalmente la construcción (o selección) de marcos de trabajo, librerías, clases, etc. comunes a todo el proyecto y que luego facilitan el desarrollo y su calidad. Pero esos elementos iniciales en la mayoría de los casos son componentes muy “técnicos”, no son entregas “funcionales” por lo que puede ocurrir que los Sprint iniciales, o bien se hacen mucho más largos que el resto o bien la “revisión del proyecto” puede ser ver un fichero jar de java, que “no muestra nada” inteligible.

Quiero con ello resaltar la importancia de estas primeras fases en que se pone los cimientos y estructura del proyecto, y durante los cuales no hay nada que mostrar a un usuario no técnico. El forzar un desarrollo que muestre periódicamente “algo funcionando” puede llevar a desarrollos mal estructurados y mal enfocados, provocando el clásico desarrollo “espagueti” de Visual Basic que aunque muestra rápidamente pantallas, se hace imposible de mantener y propenso a errores al tener “todo conectado con todo”.

Finalmente, respecto la documentación, hay dos elementos “peligrosos”:

• se debe dar prioridad a “software funcionando frente a documentación”.
• “El método más eficiente y efectivo de comunicar información es la conversación…”,

Respecto al primero, si la documentación se toma como un “trámite” que se encarga al “becario”, el proyecto está condenado al fracaso a largo plazo (con cualquier metodología) ya que la documentación debe reflejar una visión clara y de alto nivel del proyecto de forma que en un futuro se entienda cómo funciona todo el sistema, qué se integra con qué, y porque se han tomado ciertas decisiones y no otras.

Desde luego documentar lo que un método o función hacen, puede documentarse en el Javadoc del mismo, no tiene sentido elaborar una documentación redundante y con riesgo de incoherencias o desactualización.

Pero muchas veces la documentación más importante NO está en el código fuente (entre otras cosas porque puede afectar a varios fuentes, a la forma de instalar un producto o de usar una librería o a otros elementos que no son el código fuente en sí). La documentación debe hacer referencia a la arquitectura general, la forma recomendada de uso, documentar porqué se optó por un producto o implementación. Sin esa información documentada adecuadamente, una segunda fase del proyecto (o la corrección de errores), que además podría incorporar un equipo nuevo, puede tomar decisiones incorrectas.

Respecto a la transmisión de información oral, evidentemente ayuda a explicar algunos aspectos y a debatir propuestas en modo “tormenta de ideas”, pero el escribirlas ayuda a formalizar y sistematizar las ideas y propuestas y formaliza el análisis y debate de los puntos, generando reuniones más eficaces. “Las palabras se las lleva el viendo”, y adicionalmente el texto escrito y formal permite evitar interpretaciones diferentes por distintos integrantes de un equipo.

En función de las reflexiones anteriores, podría deducirse que para proyectos donde el grueso está decidido (o incluso implementado) y queda pendiente el interfaz de usuario, o se trabaja sobre una nueva iteración, parece especialmente adecuado, mientras que para proyectos totalmente nuevos, con mucha indefinición funcional y tecnológica, el riesgo con una metodología ágil es mayor, especialmente si no se utiliza adecuadamente.

Como en cualquier herramienta (física o intelectual) debe utilizarse con criterio y analizando en cada caso los riesgos y necesidades. Al final, entre el blanco y el negro hay toda una gama de grises, y se debe elegir cual es el “color” adecuado, aplicando la metodología y los criterios de la forma adecuada y sin “fundamentalismos”.

No Brain | by Pierre-Olivier

Como indicaba un letrero sobre una maquinaria pesada “CAUTION: This machine has no brain, use your own” (“Precaución: esta máquina no tiene cerebro, use el suyo propio”)

Los Microservicios NO son LA SOLUCIÓN

 

No, los Microservicios NO son "LA SOLUCIÓN" ni "valen para todo".

Estos dos últimos años se ha desatado una “locura” en torno a la Arquitectura de Microservicios, que ha “revolucionado” el modo de desarrollar y aparenta ser el “Bálsamo de Fierabrás” que “cura todas las dolencias”. Cualquier proyecto que no utilice Microservicios se considera automáticamente una “antigualla” y totalmente obsoleto  y erróneo. Me temo que debo disentir.

Como cualquier solución tecnológica, tiene sus ventajas e inconvenientes y sus ámbitos de aplicación.  Hay muchos escenarios para los que es una solución válida, pero no es aplicable automáticamente a todos los proyectos, ni siquiera a la mayoría, y además creo que el “entusiasmo” está haciendo no se evalúe adecuadamente sus desventajas, solo las ventajas. Para cualquier proyecto y escenario debe evaluarse con la mente abierta diversas soluciones, ponderar y medir ventajas e inconvenientes y sólo entonces elegir la mejor opción.

Creo que algunos sentimos una sensación de “Déjà vu” que hace recordar en cierto modo el entusiasmo en su momento con los Servicios Web, ahora rechazados frente al nuevo “juguete”. Ambos coinciden en ser una Arquitectura Orientada a Servicios, que prometía desacoplar los elementos de las aplicaciones, desarrollar aplicaciones más ligeras sin repetir código, desarrollar en distintos lenguajes y tecnologías y ofrecer un abanico servicios que por medio de una especie de diccionario/directorio, permitiría a las aplicaciones dinámicamente localizar el servicio web adecuado e invocarlo. ¿Suena conocido?

Antes de reflexionar sobre la Arquitectura de Microservicios, hay que destacar que su aparición ha coincidido con dos tecnologías/paradigmas muy importantes y útiles, un incremento de las posibilidades y oferta de virtualización (por medio de servicios como Amazon o Azure o por medio de “micro-máquinas virtuales” como Docker) y los modelos de integración continua y DevOps. Hay que tener en cuenta, que puede usarse microservicios sin esos elementos y que puede hacerse desarrollo “monolítico” con ellos, por tanto hay que centrarse exclusivamente en las características de los microservicios en sí mismos.

Otro punto previo a considerar es la simplificación planteada de “aplicación monolítica” frente a “aplicación basada en microservicios”. Creo que hace muchos años que no veo una aplicación totalmente monolítica y aislada. La mayor parte de las aplicaciones están distribuidas en varios servidores, invocan Servicios Web, leen de colas de mensajería, se integran con herramientas EAI, intercambian archivos con otros servidores del mismo proceso, etc. En cuanto a los microservicios, a pesar de su nombre no son exactamente “micro”. Según recomiendan los expertos, deben tener cierta coherencia funcional, por lo que no se trata simplemente de, por ejemplo, un servicio de “alta de un elemento”, ni siquiera de un servicio de mantenimiento (alta, baja y modificación) de elementos. Cada “servicio” puede consistir en varios métodos/funciones de diversa complejidad. Por tanto no se trata de comparar opción “monolítica - gigante” frente a opción “totalmente distribuida - micro” sino opción “poco distribuida con grandes bloques” frente a opción “muy distribuida con bloques pequeños”.

Para poder comparar ventajas e inconvenientes voy a plantear un proyecto hipotético a desarrollar en Java para desplegar en un servidor de aplicaciones, comparando las dos alternativas de arquitectura (monolítica vs microservicios) y revisando hasta qué punto son reales las “ventajas” de los MicroServicios. Supongamos un proyecto que consta de 4 bloques funcionales (susceptibles de convertirse cada uno en un micro servicio) con interrelaciones entre ellos. Para este escenario, se comparan las dos soluciones en tres aspectos principales:

1. Diseño - Desarrollo,
2. Despliegue - Infraestructura
3. Explotación - Monitorización.

 

1- Diseño - Desarrollo.

 1-A) “Los microservicios permiten a trabajar a varios grupos de forma independientemente”.
Por supuesto, al igual que los paquetes, espacios de nombres, librerías o diversas técnicas existentes en la mayoría de los lenguajes ”serios”.
Dado que los métodos y parámetros entre bloques/servicios deben estar definidos en fases iniciales (en otro caso no podemos saber a qué se invoca ni con qué parámetros ya sea por medio de microservicios o métodos de clases) los 4 bloques funcionales podrían dividirse en 4 proyectos/paquetes/jar y trabajar en paralelo cuatro equipos, exactamente igual que 4 equipos podrían trabajar en los 4 microservicios. La diferencia principal sería que unos invocarían a otros llamando a métodos y clases y otros invocando microservicios remotos.

1-B) “Los microservicios permiten a trabajar en diversos lenguajes y tecnologías”.
Eso es cierto, aunque relativamente. Si necesitas invocar a otras tecnologías (ejemplo desde Java a servicios .Net) siempre puede utilizarse invocaciones REST, servicios Web o incluso JNI (https://es.wikipedia.org/wiki/Java_Native_Interface), aunque desde luego no siempre están disponibles todos los productos en esa forma. Además, para los principales lenguajes hay miles de librerías y APIs de productos.
Por último, el tener un equipo especializado en diversas tecnologías/lenguajes implica que si hay que mover técnicos de un servicio/bloque a otro puede no ser posible. Un equipo uniforme es más elástico.

1-C) “Los microservicios permiten tener BB.DD independientes para cada microservicio”.
Tradicionalmente las BB.DD. han incluido dos características vitales: La transaccionalidad (que nos permite realizar una serie de operaciones y, si todo es correcto, confirmarlas de forma que se haga todo o nada) y la integridad relacional (que asegura que no pueda referenciarse valores o códigos que no existen). Cuando se utiliza una BB.DD. con un modelo “completo”, la transaccionalidad e integridad está asegurada.
Si cada conjunto de tablas está separado y las operaciones se realizan invocando servicios, deberá gestionarse manualmente escenarios como que tras invocar una actualización o inserción de varias tablas, cuando uno de los servicios notifique que no se ha podido realizar la operación, deba deshacerse la operación. Para ello deberá implementarse en cada servicio una serie de métodos para deshacer cada una de las posibles operaciones del servicio (es decir, grosso modo se multiplica los métodos/servicios expuestos por 2).
Similarmente, debe gestionarse la integridad, es decir asegurar que cuando se inserta un registro, los valores referenciados (códigos de país, producto, cliente,…) existen o que antes de borrar se compruebe que nadie lo referencia. Esto no es trivial ya que, en situaciones de mucha concurrencia, entre la comprobación de existencia y la inserción, otra tarea puede borrar el registro referenciado, generando inconsistencias.

Veamos ahora los inconvenientes durante el desarrollo que en ocasiones se olvidan de los microservicios:

1-D) Control de tipos de parámetros: Cuando la comunicación entre bloques se hace utilizando un lenguaje (Java en este ejemplo), los cambios o control de tipo de dato (cadena, fecha, entero, etc.) se detectan en tiempo de compilación y son explícitos en la propia definición de los método y clases publicados. En los microservicios el intercambio de datos se hace en modo texto, por lo que debe convertirse todos los parámetros a texto y volverse a convertir al tipo físico al recibirlos. Esto no solo implica una sobrecarga de desarrollo sino un riesgo de errores, al poder depender de elementos locales a cada servidor como código de páginas (UTF-Windows 1252), formatos de fechas (dd/mm/aaaa, mm-dd-aaaa,…), decimales (123,4 – 123.4), etc.

1-E) Encapsulación: Cuando la comunicación entre bloques se hace utilizando un lenguaje (Java en este ejemplo), podemos recibir un objeto de un bloque/método, y pasarlo a otro sin necesidad de conocer la estructura, ya que la orientación a objetos nos asegura la encapsulación. Por ejemplo el bloque funcional de Contratación puede devolver en un método un objeto de clase Pedido y ese objeto pedido se transmite completo al bloque Almacen: Almacen.ActualizaInventario(Pedido1). Si se cambia la estructura (y el modelo de datos) de la clase Pedido, solo debe modificarse los componentes realmente afectados, no los intermedios. Con un modelo de MicroServicios, muchos elementos intermedios tendrían que modificarse para transmitir o leer todos los elementos de un Pedido. Esta encapsulación también afecta a otros aspectos de implementación y rendimiento. Por ejemplo, una invocación a un método Pedido.getItems() que devuelva la lista de elementos, puede implementarse para que devuelva a lista desde memoria (si estaban cargados previamente) o busque en la BB.DD. si no lo estaban). Con microservicios sería necesaria la invocación explícita al otro microservicio.

1-F) Sobrecarga de comunicaciones: La invocación a una clase o método dentro de un lenguaje es trivial. La invocación a otro microservicio, implica un código adicional (ya sea implementado directamente o utilizando un framework) que debe gestionar la conversión y emparejamiento de parámetros, la gestión de comunicaciones y timeout, reintentos, resolución de urls, etc.

1-G) Control de parámetros: Cuando la comunicación entre bloques se hace utilizando un lenguaje, si un método de un bloque funcional que admitía 2 parámetros se modifica para utilizar 3, esos cambios se detectan y saltan en tiempo de compilación. En el caso de los microservicios, hasta que no se invoque no se detecta el error.

2- Despliegue e infraestructura.

2-A) “Los microservicios son más ligeros”
Si repasamos las necesidades (obviando la alta disponibilidad, que implica duplicar todo en cualquiera de las dos arquitecturas), vemos que la aplicación monolítica requiere 1 sistema operativo + 1 máquina Java + servidor de aplicaciones + librerías comunes y de utilidad (driver jdbc, log4j, manejo XML, etc.) + cuatro módulos, lo que puede representarse como:

Bloque/Servicio A

Bloque/Servicio B

Bloque/Servicio C

Bloque/Servicio D

Librerías comunes

Servidor Aplicaciones

JVM

Sistema Operativo

La versión basada en microservicios requerirá 4 * [ 1 sistema operativo + 1 máquina Java + servidor de aplicaciones + librerías comunes y de utilidad (driver jdbc, log4j, manejo XML, etc.)+ 1 módulo + elementos adicionales comentados (comunicaciones, formateo y comprobación datos entrada/salida, cancelación transacciones)  ], por lo que podría representarse:

Bloque/Servicio A		Bloque/Servicio B		Bloque/Servicio C		Bloque/Servicio D
Librerías comunes		Librerías comunes		Librerías comunes		Librerías comunes
Servidor Aplicaciones		Servidor Aplicaciones		Servidor Aplicaciones		Servidor Aplicaciones
JVM		JVM		JVM		JVM
Sistema Operativo		Sistema Operativo		Sistema Operativo		Sistema Operativo

Es decir, en el caso muy simplificado de que todos los bloques fueran iguales (caso no real, ya que el S.O., JVM y servidor de aplicaciones son mucho más grandes que los bloques funcionales) se trata de 8 bloques/unidades de memoria (y puede equipararse a consumo de CPU para procesar y manejar esa información), frente a 24 bloques, es decir 3 veces más de infraestructura necesaria (en memoria y CPU).
Si estuviéramos hablando de, por ejemplo 10 microservicios/bloques funcionales, la comparación sería de 14 frente a 60 “unidades”.

Y si consideramos tamaños diferentes de cada bloque y un poco más reales de sistema operativo (incluso en sistemas Docker), tamaños de JVM y servidor de aplicaciones (servidores de aplicaciones miniatura como Jetty) frente a tamaño de microservicios, incluso en el caso de 4 bloques, la comparación es de:

Bloque/Servicio A	20M
Bloque/Servicio B	20M
Bloque/Servicio C	20M
Bloque/Servicio D	20M
Librerías comunes	50M
Servidor Aplicaciones	100M
JVM	100M
Sistema Operativo	500M

830M frente a 3160M o en el caso de 10 microservicios, 950M frente a 7.900M es decir un coste en infraestructura entre 4 y 8 veces mayor (y con otros tamaños de S.O y servidor de aplicaciones, incluso 10 o 15 veces mayor).

2-B) “Los microservicios son más fácilmente escalables”
Suele argumentarse que en el caso de los microservicios el escalado es más fácil, ya que puede desplegarse más instancias del servicio más usado. Es decir si el bloque A es invocado más veces que el resto, podría desplegarse dos instancias/instalaciones del microservicio A y una para cada una del resto, es decir algo como:

Bloque/Servicio A

Bloque/Servicio A

Bloque/Servicio B

Bloque/Servicio C

Bloque/Servicio D

Sin entrar en los costes, ya revisados, hay algo sorprendente en la afirmación. Si se despliega un servicio/bloque en un servidor, ese servidor únicamente puede ejecutar esa tarea. Es decir una instalación dimensionada para atender 4 peticiones simultáneas de servicios A, solo podrá atender esas 4 peticiones:

A	A		B	B		C	C		D	D
A	A		B						D	D

Si se recibe 6 peticiones de tipo A o 5 de tipo D, no podrán atenderse

Un servidor donde se haya desplegado todos los paquetes, dimensionado para atender 16 peticiones, atenderá cualquier petición de cualquier tipo (A, B, C o D) hasta su máximo de recursos

A	A	A	B
A	A	A	B
B	C	C	D
D	D	D	D

O lo que de forma doméstica puede expresarse como “en un cajón grande tienes más flexibilidad que en 4 cajones pequeños”. Por supuesto que pueden desplegarse más instancias para atender al servicio A, pero en la opción monolítica no sería necesario, al margen de los costes de infraestructura antes citados.

2-C) “En caso de caída de un microservicio, el resto puede seguir funcionando”
Me sorprende que tras años de existencia de sistemas de tolerancia a fallos, granjas de servidores, tecnologías cluster, alta disponibilidad Activo/Activo y Activo/pasivo, y disponibilidades predicadas del 99, 99% del tiempo, se plantee que se puede “no disponer” de una aplicación. Pero incluso si fuera el caso, plantear que “si se cae un microservicio el resto siguen funcionando” es algo bastante discutible. Si se trata, por ejemplo, de una contratación y no se puede acceder al servicio de “clientes”, o al servicio de “almacén”, o la “pasarela de pago”, no podrá realizarse esa contratación. La aplicación tiene generalmente una coherencia y unos servicios interconectados. Si uno de ellos se cae, probablemente no pueda realizarse la mayor parte de las operaciones, y en muchos casos, ninguna.

2-D) “Puede desplegarse nuevas versiones de los microservicios de forma independiente”
Habría que distinguir lo primero a que llamamos “nuevas versiones”.  Si se trata de desplegar una corrección de un error o una optimización, por supuesto puede hacerse de forma independiente, al igual que puede hacerse también en una aplicación monolítica sustituyendo el fichero java jar correspondiente. Si se trata de una NUEVA versión, que expone un “contrato” nuevo (con diferentes parámetros, un comportamiento distinto, métodos adicionales,..) desde luego deberá desplegarse y probarse de forma conjunta. En otro caso, se está invocando a operaciones cuyo comportamiento es distinto (aunque no lo sea el “contrato” expuesto). El concepto de “pruebas de integración” existe hace mucho años, tanto en aplicaciones monolíticas como en las que no lo son, debido a que en cuanto hay que integrar varios sistemas, existen riesgos y comportamiento no perfectamente documentados (autenticación entre sistemas, códigos de página, tamaños de bloque, límites en cuanto a número de parámetros. Comportamiento ante excepciones, timeout, etc.)

2-E) Comunicaciones: Por último, hay algo que parece olvidarse, la comunicación entre servidores y microservicios tiene un coste de infraestructura, no es gratis. Y si se trata de un entorno en nube, podemos incluso consultar los precios de transferencias internas y externas (https://aws.amazon.com/es/ec2/pricing/on-demand/). Por tanto el uso de microservicios tiene además ese sobrecoste por el hecho de estar intercambiando información entre servidores que no se produce en la opción monolítica.

 

 3- Administración Monitorización

Respecto a este punto, podría revisarse 3 aspectos:

A) Instalación y actualización (de Sistema Operativo, servidor de aplicaciones, utilidades y por supuesto aplicación).
B) Monitorización (debe controlarse el estado de memoria, CPU y disco de los servidores, así como el estado del servidor de aplicaciones y de la aplicación en sí).
C) Depuración y monitorización del proceso/BAM (es decir tanto depurar y analizar problemas de la aplicación como analizar en tiempo real el estado de un proceso de negocio.

3-A) En el primer caso, parece evidente que, de instalar y configurar un servidor (virtual o no) y una aplicación, hemos multiplicado el trabajo por el número de microservicios del proyecto (por supuesto la alta disponibilidad multiplica en ambos casos por dos). Lo mismo aplica para las actualizaciones y parches de seguridad o fixpack de microservicios, librerías o S.O. Desde luego, con plataformas como Docker esto se simplifica, y el número de tareas manuales se reduce, pero esto también aplica a la opción monolítica. El hecho es que sean muchas o pocas las tareas y pruebas de regresión, hay que multiplicarlas por el número de microservicios.

3-B) La monitorización de los servidores y la infraestructura (que siempre es necesaria para controlar problemas de lentitud, memoria o disco) se multiplica igualmente por el número de microservicios desplegados. No me refiero solo a caídas del sistema (que es casi lo más automatizable) sino verificar que los tiempos de respuesta son adecuados, que el nivel de uso de la CPU no sea del 99% o que la memoria libre de RAM o la de almacenamiento estén por encima de unos valores.

3-C) En cuanto a la depuración, desde luego el analizar un problema recurriendo a 4 (o N) ficheros de traza “paralelos” es mucho más complicado que disponer de un solo fichero donde se vea la secuencia y la lógica de las distintas operaciones. En cuanto a la monitorización de procesos, a nivel funcional y de cuadro de mando, también se complica más al contar con 4 (o N) elementos separados.

 

Conclusión.

La conclusión no es que los microservicios no sean una solución válida, la conclusión es que no son LA SOLUCIÓN a aplicar automáticamente en todos los casos ni son siempre la mejor opción.

Son una opción más a aplicar cuando las características del proyecto sean las adecuadas, a comparar en pie de igualdad con muchas otras, incluyendo, por supuesto, un desarrollo “monolítico”.