Como se ha repetido una y otra vez, la mejor forma de encontrar la solución a un problema es enfocarse e invertir la mayor parte del tiempo en el problema mismo y no en la solución. El mundo de TI no es algo diferente y comúnmente ocurre que tendemos a perdernos el bosque mirando el árbol.
La razón de este fenómeno es la complejidad inherente en cada rama de TI, por lo cual es necesario hacer un alto en el camino para identificar quien es nuestro cliente y sus necesidades reales. Probablemente al realizar este ejercicio encontremos alternativas que a simple vista no se percibirían.
Tratar de adecuar una solución en particular a cada problema puede que no sea la mejor idea, tal y como lo menciona el RFC 1925 https://tools.ietf.org/html/rfc1925 “Con suficiente empuje, los cerdos vuelan muy bien. Sin embargo, esto no es necesariamente una buena idea. Es difícil estar seguro de dónde van a aterrizar, y podría ser peligroso sentarse debajo de ellos cuando vuelan por encima”.
Si extrapolamos lo anterior al mundo de los centros de datos podemos encontrar quienes son los clientes directos y los clientes indirectos. Es claro que los clientes directos del centro de datos son las aplicaciones y sus desarrolladores, lo que hace necesario que entendamos claramente su comportamiento y necesidades con el fin de poder entregar el mayor valor.
Existen múltiples tecnologías, metodologías, arquitecturas y paradigmas que se han usado a través del tiempo para construir aplicaciones, de ahí las diferentes terminologías usadas para referirse a la arquitectura de estas. Teniendo en cuenta que el cliente directo de las aplicaciones es el negocio, realizar cambios arquitectónicos, metodológicos o tecnológicos sobre las mismas se convierte en una tarea lejos de ser trivial, razón por la cual en el mundo empresarial siempre encontramos un sin número de aplicaciones de diferente tipo que hacen necesario que entendamos su comportamiento para ofrecer el mejor valor desde la perspectiva de la infraestructura y el centro de datos. Si evaluamos los cambios en el tiempo en relación con el desarrollo de aplicaciones, encontramos múltiples términos que resultan familiares, entre ellos:
- Cliente servidor
- Monolitos
- Multicapa
- Arquitecturas orientadas a servicios (SOA)
- Servicios Web (Web Services)
- Microservicios
- Arquitecturas limpias (Clean architecture)
- Arquitecturas de capa de cebolla (Onion architecture)
Y en cuanto a marcos de referencia metodológico encontramos algunas como las siguientes:
- Agile
- Scrum
- Kanban
- Lean
- Waterfall
Lo que demuestra el dinamismo y la búsqueda continua de crear software de forma más ágil para beneficio del negocio. Sin embargo, las aplicaciones corren sobre infraestructura de TI propia o de un tercero, como es el caso de las nubes públicas. De cualquier forma, se necesita que la gestión de la infraestructura como un todo (servidores, almacenamiento, redes, seguridad) se realice a la velocidad necesaria para evitar el desperdicio de tiempo de los grupos de desarrollo de software, razón por la cual empiezan a aparecer metodologías como DevOps.
DevOps como sabemos, es una filosofía que procura unificar desarrollo con operaciones (gestión de infraestructura de TI), en lo que respecta a la cultura, sistemas, prácticas y herramientas, y así de forma acelerada y más frecuente, alcanzar mejoramiento continuo y entrega de valor a los clientes.
Si usamos métodos tradicionales para gestionar la infraestructura terminamos con múltiples elementos independientes, incluso cuando está claro que cada uno está controlado por alguna forma de software. Realmente lo que se busca es construir un sistema que involucre todas las partes individuales, para poder cumplir con la filosofía de DevOps.
Normalmente un problema computacional se simplifica ocultando los detalles y complejidades a los subsistemas, permitiendo la separación de responsabilidades, facilitando la inter-operatividad y la independencia de componentes. La implementación particular resulta en la adición de una capa de abstracción. En la imagen anterior se ven los elementos como silos, y a continuación se verá el resultado de la adición.
El resultado que se obtiene es el consumo de la infraestructura desde un único punto de acceso, ocultando las complejidades de cada tecnología independiente para el beneficio del cliente directo (en este caso las aplicaciones). Un modelo como este trae beneficios adicionales, entre ellos la posibilidad de tratar la infraestructura de forma programática (Infraestructura como código), básicamente replicar los beneficios que se tienen cuando se crea software, entre ellos versionamiento de los cambios de configuración, DRY (El concepto de no repetir lo que ya existe), disminuir errores por configuración manual, automatización de pruebas, entre otros.
En resumen, el software se está comiendo al mundo (Como lo dice Marc Andreessen) y el centro de datos no es la excepción.
Autor:
Waldir Montoya
Senior Solution Engineer, VMware
[email protected]
Colombia, Bogota
