3.2 El nomadismo desorienta

Un nómada es el que va de un lugar a otro y no se establece en ningún sitio de forma permanente. Podríamos definir un nómada digital como aquel que prueba muchas tecnologías, pero no se centra en ninguna. Esto está muy bien porque te da una visión muy amplia y además obtienes experiencia en diferentes ámbitos y con muchas herramientas distintas. No obstante, hay que tener presente lo que dice el viejo refrán: aprendiz de mucho, maestro de nada.

Gente que siempre quiere estar a la última

Actualmente es imposible ser un experto en todas las tecnologías que hay en el mercado, básicamente porque aparecen nuevas cada día. Hay gente a la que le gusta estar a la última y cuando se enteran de que han sacado algo nuevo quieren ser de los primeros en probarlo (early adopters). Estos son los que están en la cresta de la ola, probando las herramientas antes de que sean populares, estables y ampliamente reconocidas (mainstream).

Trabajar con herramientas muy nuevas en producción no suele ser una buena idea, ya que la tecnología estará verde. Cuando una tecnología está verde significa que aún no hay una gran comunidad detrás (no ha habido tiempo suficiente para que se popularice), está en fase de cambios constantes, probablemente le faltarán funcionalidades y no será estable o, lo que es lo mismo, habrá bugs.

Evidentemente, no queremos usar herramientas que no sean estables en producción. Pero esto tampoco significa que tengamos que descartar todas las herramientas nuevas que aparezcan. Sí las podemos tener en nuestro radar y ver cuál es su evolución para estar preparados cuando sean consideradas estables (maduras) y sea seguro usarlas en sistemas reales y no de prueba.

Todo el mundo quiere ser guay e ir con la gorra al revés

La vida en general funciona por tendencias o modas, un ejemplo clarísimo es la ropa. Si un año están de moda las camisas de rayas, al año siguiente serás un pringado si las llevas porque entonces estarán de moda las de cuadros. Algo similar ocurre con la tecnología.

Cuando una tecnología en concreto se pone de moda, entonces pareces el tonto de la clase si no la sabes usar y, si no la conoces, mejor ni hablamos… Hay que tener criterio propio y sentido común porque elegir una tecnología que pasará a formar parte del sistema informático de una empresa no es lo mismo que elegir una camisa, es más, puede suponer un gran trade-off. Una mala decisión en un momento dado se puede pagar muy cara en el futuro.

Lo que a uno le funciona puede que a otro no. Siempre hay que tener en cuenta los recursos de los que se dispone, el contexto y la finalidad. Si a una persona le sienta bien una camisa azul, no tiene por qué sentarte bien a ti o al revés. Lo que para uno es barato, para otro puede resultarle caro. No hay dos personas iguales, pero tampoco hay dos empresas iguales. Por lo tanto, no hay que hacer lo que hacen los demás solo porque ellos lo tienen y tú no, antes hay que ver si tú lo necesitas realmente y te va a aportar algún valor o solo gastos inútiles. Dicho de forma más técnica, hay que ver cuál será el retorno de la inversión.

Sé de casos en los que ha habido empresas que han decidido volver a implementar proyectos que tenían hechos con unas tecnologías, por otras, debido a los altos costes de operación y mantenimiento. Imagínatelo por un momento, estás manteniendo varios proyectos de diferentes clientes, todos hechos con la misma tecnología, pero los costes asociados son tan elevados que has tenido algunos miembros de tu equipo haciendo pruebas con tecnologías alternativas. Con los resultados obtenidos, se ha decidido que es mejor invertir en volver a escribir los proyectos usando las nuevas tecnologías que siguiendo con las actuales. Parece increíble, ¿verdad? Pues es cierto. Por lo tanto, mucho cuidado.

No te ahogues con los contenedores

Hoy en día, muchos hablan de herramientas como Docker, Docker Compose, Docker Swarm, Kubernetes, OpenShift, Rancher, etc., pero solo unos pocos saben realmente qué son, para qué sirven, cuándo son realmente útiles y cómo funcionan. Hay gente que se piensa que los contenedores son máquinas virtuales y acaba creando un único contenedor gigante con todos los servicios dentro. Esto es potencialmente tan doloroso como pegarse un tiro en un pie, así que, por favor, no lo hagas.

Hay que tener presente que un contenedor no es una máquina virtual, en todo caso, podríamos equipararlo a una «micro máquina virtual». Aun así, insisto en que son conceptos distintos, ya que los contenedores, a diferencia de las máquinas virtuales, sirven para aislar aplicaciones en vez de sistemas operativos completos y, por lo tanto, son mucho más ligeros. Un contenedor no está pensado para ejecutar múltiples procesos en segundo plano, sino para ejecutar uno y en primer plano. Existen imágenes de Docker que pesan unos pocos MB y no incluyen ni editor de textos, con lo cual, crear un contenedor monstruoso es una muy mala idea porque después va a ser realmente difícil de mantener.

El hecho de trabajar con contenedores implica un cambio de paradigma, tanto a nivel de desarrollo como de DevOps y de sistemas, con lo cual, antes de introducir una tecnología «porque sí», hay que documentarse para ver qué curva de aprendizaje supone y qué impacto real tendrá sobre el equipo y la organización en general. Te recomiendo que le eches un vistazo a «The Twelve-Factor App», se trata de una metodología para construir aplicaciones SaaS y los contenedores son un gran aliado para conseguirlo.

Con todo esto no digo que Docker (u otras alternativas) sean malos, ni mucho menos. De hecho, lo he usado en muchas ocasiones y me ha sido muy útil porque, si se emplea adecuadamente, los proyectos quedan totalmente encapsulados, con sus correspondientes dependencias con las versiones fijadas. Además, su uso es de gran utilidad a la hora de trabajar con arquitecturas basadas en microservicios. No obstante, también es cierto que otras veces me ha complicado bastante la vida. Con lo cual, referente a esta tecnología «trending», para mí es especialmente útil cuando:

• Hay que desplegar un mismo proyecto en repetidas ocasiones.
• Hay mucho tráfico o picos de tráfico y se tiene que poder escalar horizontalmente.
• Se trata de un proyecto complejo con multitud de servicios que interactúan entre ellos. De esta forma, nos ahorramos tener que instalarlos y configurarlos uno a uno.
• Se requieren versiones incompatibles con nuestro sistema porque son más nuevas o más antiguas de las que permite.
• Se necesitan versiones diferentes de paquetes que ya tenemos instalados en nuestro sistema.
• Se administran muchas aplicaciones, ya que a nivel de sistemas puede simplificar la gestión debido a que supone una gran abstracción. No hará falta conocer los entresijos de los proyectos, sino gestionar los contenedores (inmutables) donde se ejecuten.

Por supuesto, todos estos beneficios no son gratis y pueden añadir una complejidad extra a nivel de desarrollo e incluso a la hora de hacer los despliegues. En consecuencia, si vas a hacer un proyecto relativamente sencillo que vas a desplegar en un único servidor y en caso de necesidad puedes escalar verticalmente añadiendo más recursos a la máquina, entonces no tienes por qué dockerizarlo y puedes seguir optando por una instalación «de toda la vida».

JavaScript fatigue

Como no podía ser de otra forma, en un capítulo dedicado al nomadismo no podía pasar por alto el mundo de JavaScript. Dicen que, si das una patada a una piedra, debajo pueden aparecer una o dos librerías o frameworks de JS nuevos. Y si la das muy fuerte, puede que hasta más, pero no mejores.

Sí, amigo mío, JavaScript está de moda y su ecosistema está más vivo que nunca, de hecho, aparecen herramientas nuevas cada día. Al final, en vez de simplificarnos la vida nos acaban agobiando porque no sabemos cuáles elegir. Además, las versiones cambian cada dos por tres y en algunos de estos cambios no guardan compatibilidad con las anteriores.

Si eres de los que les gusta estar aprendiendo nuevas tecnologías constantemente, entonces aquí estarás en tu salsa, de lo contrario es probable que lo acabes dejando, asqueado y harto de aprender constantemente nuevos frameworks. Al final, muchos de ellos hacen lo mismo, pero cambiando nombres, complicándote la vida en mayor o menor grado y poca cosa más.

Por ejemplo, a día de hoy, tres de los grandes frameworks de JavaScript (entre muchos otros) son: Angular, React y Vue.js, lo cual no significa que dentro de cuatro días aparezcan otros tropecientos más que hagan lo mismo o algo muy parecido.