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.

Cloud o “cuidado con La Nube, que puede ser de tormenta”.

Uno de los temas tecnológicos “de moda“ estos últimos años es la de “Computación en la nube”  o de forma abreviada Cloud o la Nube. El problema es que con ese término se referencia en muchas ocasiones  conceptos distintos o erróneos, se mezclan aspectos técnicos con otros operativos/económicos y además se atribuye propiedades casi mágicas que van a arreglar todos los problemas tecnológicos de una entidad. Este artículo reflexiona, como es habitual de forma crítica, sobre los diferentes conceptos y hasta qué punto pueden ser una solución o un problema adicional.

Sistema VirtualBox en Windows7 ejecutando dos máquinas virtuales: Linux Mint17 y Ubuntu14.04 Gnome3. Waspteo [CC0]

 

Conceptos

 

Para empezar ¿qué quiere decir Computación en la nube?
Básicamente se trata de disponer de “servicios informáticos” (ordenadores, bases de datos, aplicaciones,..) gestionados por una empresa. Es decir, en lugar de comprar un ordenador (o un programa) me conecto a un sistema remoto que una empresa me ofrece pagando por horas, meses, uso, etc.
Pero, ¿Eso no es lo que se hacía ya hace años, antes incluso de la Burbuja de las .COM, cuando contrataba un hosting o Alojamiento Web para publicar mis páginas o mi base de datos de productos y servicios?
Si, realmente sería lo mismo (o una variante), así que lo primero que habría que aclarar es que no se acaba de descubrir ni es algo “revolucionario”, lleva utilizándose más de 20 años. E incluso si se retrocede a los albores de la informática, el alquiler de tiempo de grandes ordenadores (Mainframe) se practicaba hace ya 50 años.
No obstante el modelo se ha formalizado y ampliado, tanto tecnológicamente como comercialmente, y además la mejora de las comunicaciones y la extensión del uso de los móviles lo ha reforzado.

Suele distinguirse varios “modelos” de servicio:

• Iaas (Infrastructure as a Service) lo que de forma muy simplificada puede traducirse como que contratamos “hardware” es decir un “ordenador”, un “disco”, “servicios de red”, etc. Es decir se dispone de “ordenadores virtuales” que configuramos según nuestras necesidades y dentro de los cuales podemos instalar los sistemas operativos que deseemos (y que debemos tener licenciados si lo requieren) y adicionalmente los programas elegidos. Esta es una posibilidad que desde hace unos 12 años ha estado disponible para instalar en ordenadores físicos en las instalaciones de cualquier empresa, utilizando programas como Virtual Box o VMWare pero que ahora se ha generalizado, permitiendo el disponer de ordenadores “remotos”.

• PaaS (Platform as a Service) que de forma simplificada puede traducirse como que se contrata un “ordenador con software instalado” (sistema operativo, entorno Java, php, python, servidor web, base de datos, etc.). Este modelo se asimilaría al tradicional de hosting.

• SaaS (Software as a Service) En ese modelo lo que se contrata es el uso de un software (por ejemplo: un programa de contabilidad, gestión de ventas, gestión de Centros de llamadas-Call Centre, etc...). En lugar de adquirir un software, instalarlo y gestionarlo, se contrata el uso de uno, pagando por usuarios, períodos de tiempo, etc. Y una empresa gestiona todo el sistema, dando de alta usuarios, realizando copias de seguridad, gestionando licencias, almacenamiento, etc. De forma transparente totalmente para los usuarios, que simplemente utilizan un servicio sin todas las complejidades que implica por detrás.

Además de estos tipos de servicio (cuyas fronteras no siempre son claras), hay otras criterios importantes, como pueden ser la división entre Nube Pública (Es decir servicios expuestos “a todo el mundo”, de los cuales contratamos una parte), Nube Privada (Una nube “particular” para una entidad, lo que podría asimilarse a “no alquilo un apartamento = ‘Nube Pública’ sino todo un edificio, incluyendo mi propia recepción-control de entrada”) y Nube Híbrida (Combinando elementos de Nube Pública y Nube Privada o elementos de infraestructura propia).

Sam Johnston [CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)]

Hay un elemento importante a tener en cuenta que es ¿qué tipo de “máquina virtual” utilizo?
En estos últimos años se ha extendido un modelo de virtualización muy novedoso, la tecnología de contenedores , dentro de los cuales destaca Docker.
De forma simplificada, se trata de manejar contenedores, o “mini ordenadores” (estamos hablando en ocasiones de menos de 500M, es decir menos memoria que cualquier teléfono actual) con un “mini sistema operativo” (que suele ser el núcleo de Linux) y con una forma de trabajo en la que, en lugar de instalar el programa, se copia simplemente la máquina virtual con todo ya instalado. Si hace falta más potencia, se hacen dos copias de la máquina, etc. Como en los casos anteriores, puede utilizarse Docker sin acudir a la Nube, es decir podría utilizarse imágenes Docker dentro de nuestros propios sistemas.

Por último, hay que destacar que las principales empresas que ofrecen servicios en la Nube incluyen además servicios propietarios que solo ellos tienen (servicios de almacenamiento avanzado, de base de datos, de inteligencia artificial, etc.)

 

Coste

¿Cómo se cobra? Es muy variable y MUY complejo, y depende de cada proveedor. La idea general es de “pago por uso”, es decir contratamos una suscripción (bolsa económica) y podemos crear nuestra infraestructura de acuerdo a ese importe (por ejemplo la suscripción puede permitir crear dos máquinas “pequeñas” o una “grande”).
Sin embargo no es tan sencillo, porque también se puede contabilizar factores como:
    •  el tiempo que esas máquinas están funcionando
    •  la cantidad de bytes cargados o descargados
    • los bytes almacenados
    • el ancho de banda disponible para acceder o descargar
    • el número de operaciones de almacenamiento
    • El tipo/velocidad de respuesta del disco (HDD o SDD)
    • ….
Ciertos proveedores limitan alguno de esos factores, de forma que, por ejemplo, la máquina de tipo A está limitada a X capacidad simultánea u ofrecen paquetes cerrados (Ej: máquina con 4 CPU, 8G RAM y 50G de disco)
Como ejemplo, en estas direcciones pueden estudiarse las complejas tarifas de dos de los principales proveedores: Amazon  y Azure
En principio parece que por “economía de escala”, un proveedor de Nube podría ofrecer el servicio por un coste menor que el tenerlo en nuestras instalaciones, pero no hay que olvidar que estamos “alquilando” y, dependiendo de las necesidades y uso, el alquiler puede salir más rentable o menos (si no fuera así, ninguna empresa compraría camiones o furgonetas y las alquilarían siempre).

 

Ventajas

 

Como hemos visto, “casi todo” lo que puede hacerse en la Nube, puede hacerse en nuestras propias instalaciones, de forma que las principales ventajas serían:

1. Flexibilidad: En una o dos horas puede activarse una nueva máquina, no hay que comprar hardware. Incluso aunque se disponga de un sistema interno de virtualización, normalmente estarán optimizados los recursos y no habrá mucha capacidad sobrante para crear una máquina virtual. Esto puede ser especialmente útil para realizar pruebas o cálculos puntuales, creando un gran número de máquinas para un uso puntual, que luego se liberan. Tambien puede utlizarse para una nueva empresa que no quiere invertir demasiado, o para tareas que re realizan períodicamente (procesos semanales o mensuales intensivos que requieren ordenadores que no se utilizan salvo en esos momentos).
2. No requerir ciertos perfiles profesionales: La administración y gestión de disponibilidad de las máquinas está delegada a otra empresa, de forma que no es necesario contratar por ejemplo un profesional que no tendría trabajo todo el tiempo. No obstante esta función, en cuanto la empresa tenga cierto volumen, justifica la contratación de una persona, y en cualquier caso, siempre podría contratarse esos servicios a otra empresa para realizarlos de forma remota con los ordenadores locales sin estar en la Nube.
3. Disponer de servicios específicos que se ofrecen únicamente en La Nube: Algunos proveedores ofrecen productos/servicios (de almacenamiento, base de datos, análisis, estadísticas, Inteligencia Artificial,..) que solo ofrecen ellos. En ese caso, más que La Nube, se trata de utilizar un servicio que no está disponible en otro ámbito.
4. Acceso mundial: No es necesario crear una estructura de servidores y una DMZ en nuestras instalaciones para publicar ciertos servicios y servidores (por ejemplo para colaboradores, otras empresa, etc.). No obstante no hay que olvidar que esa información que se publique en La Nube, deberá sincronizarse con los servidores internos (salvo que sea información aislada y todo el trabajo y proceso se haga en esos servidores). Adicionalmente, puede obtenerse resultados similares para colaborar con empleados y otras entidades usando una VPN.
5. Coste: En principio puede resultar rentable pagar por uso, y por ejemplo apagar ciertos servidores durante noches o fines de semana. Es un modelo de "alquiler" frente a "compra". Además, una empresa que preste este servicio tiene miles de servidores y aprovecha el tiempo en que un usuario apaga para ejecutar tareas de otro, frente a un modelo habitual en que solo presta servicio 8h o 12h.

 

Inconvenientes

 

1. Coste: (SI, no está repetido por error, La Nube puede resultar MUY cara) En este punto ya depende mucho de los costes y economía de escala que tenga cada empresa/institución. Depende mucho de cada caso, uso y precios. Una empresa pequeña puede no requerir alguno de los servicios (soporte 24 horas, Alta disponibilidad, escalado automáticos,..) que se incluyen “automáticamente”, y puede resultarle caro. Una grande, a partir de un volumen, lo resuelve internamente con sus equipos y profesionales y puede resultarle más barato que en La Nube, por lo que tampoco le representa una ventaja. La única forma es analizar en cada escenario el coste completo (teniendo en cuenta todos los factores por supuesto)..
2. Seguridad: Por supuesto que cualquier sistema puede ser potencialmente atacado y accedido. Pero si está públicamente disponible en Internet (y por tanto solo protegido por una clave) siempre será más inseguro que un sistema interno al que no puede accederse públicamente desde Internet.
3. Legislación: La legislación de muchos países (incluida la Comunidad Europea) limita el manejo de datos personales, que no pueden almacenarse en cualquier lugar. Incluso en algunos países de Sudamérica, los datos y documentos no pueden salir del país. Teniendo en cuenta que para los datos almacenados en la Nube no está especificada su ubicación (o en algunos casos se especifica pero eligiendo una central “de zona” que abarca muchos países), hay muchos casos en que no es legal el uso para manejar datos personales.
4. Integración: Salvo que tengamos TODOS los servidores en La Nube, esos servidores en La Nube deberán conectarse con nuestros servidores internos (para actualizar datos de clientes, servicios, documentación, pedidos, expedientes,…). Esa integración puede ser compleja e insegura, ya que publicamos una “puerta de entrada” al corazón de nuestros servidores.
5. Disponer de servicios específicos que se ofrecen únicamente en La Nube: Algunos proveedores ofrecen productos/servicios (de almacenamiento, base de datos, análisis, estadísticas, Inteligencia Artificial,..) que solo ofrecen ellos.  Si, tampoco está repetido por error. Depender de un fabricante y usar un servicio que solo ofrece el significa una dependencia muy fuerte. Si el producto no va bien y se retira, o si el precio sube desorbitadamente, no hay alternativa (y si la hay implicará un desarrollo o modificaciones de los proyectos importantes, ya que son productos propietarios cuya forma de integración/invocación no suele ser estándar)

 

Y ¿entonces?...

 

Como en cualquier otra decisión, no hay respuestas absolutas, aunque sí hay algunas consideraciones a tener en cuenta antes de decidir y sobre todo delimitar el alcance de la decisión y el sentido de la decisión, para poder evaluarla correctamente.

El decidir “nuestra estrategia es el uso de La Nube” NO es una decisión tecnológica sino principalmente económica, al igual que lo sería decidir que otra empresa gestione nuestros equipos.

Si por Nube se entiende manejar máquinas virtuales ( que hace años que puede hacerse, lo raro empieza a ser no tenerlas), la decisión tecnológica sería “nuestra estrategia es virtualizar todos los ordenadores” (lo cual puede hacerse en nuestras instalaciones o en un proveedor de Nube, y la decisión será económica). En cualquier caso, serían dos decisiones:
    1- Analizar las ventajas e inconvenientes de Virtualizar (principalmente tecnológica)
    2- Analizar DONDE se hace, en nuestras instalaciones o en La Nube (principalmente económica)

Si por Nube se entiende utilizar Docker, esta SI es una decisión tecnológica muy importante, ya que la forma de desarrollar, administrar y monitorizar es muy diferente al uso de máquinas “normales” (virtualizadas o no), pero que puede llevarse a cabo igualmente “dentro” o “fuera”. Pero en ese caso la decisión es “nuestra estrategia es usar Docker para todos los proyectos”. En cualquier caso, serían dos decisiones:
    1- Analizar las ventajas e inconvenientes de usar Docker (principalmente tecnológica)
    2- Analizar DONDE se hace, en nuestras instalaciones o en La Nube (principalmente económica)

Si por Nube se entiende utilizar unos servicios concretos de un proveedor concreto, la decisión SÍ es tecnológica, pero no debe expresarse como “nuestra estrategia es el uso de La Nube” sino “nuestra estrategia es el uso de los servicios A y B del proveedor X” (habitualmente sin otras alternativas).

Una vez delimitado el sentido y alcance de la decisión, entonces realmente podremos analizar sobre los factores importantes (económicos, tecnológicos, seguridad, dependencia, nivel  de servicio, etc.) y tomar la decisión adecuada.

Por mucho que se ponga de moda, como cualquier otra tecnología, el uso de La Nube NO es la panacea, en unos casos puede ser muy útil y en otros casos un problema (y caro). Si nos acercamos corriendo a La Nube si analizarlo previamente, podemos encontrarnos con que es una Nube de tormenta...