CIO
Cuando realiza un vuelo en un avión sucede algo extraordinario. La mayoría de las veces la aeronave es conducida por un piloto automático y el de carne y hueso es en realidad una especie de “meta piloto”, un guardián que mira para estar seguro de que su colega automatizado no haga algo estúpido.
Cada año millones de personas confían sus vidas a este sistema, no tienen ningún problema con él, de hecho, se impresionan que un piloto automático pueda hacer esas cosas de manera eficaz. En ese contexto, considere ahora lo extraño que es no disponer de un software que pueda “pilotar” un centro de datos. No apueste a que permanecerá de esa manera. Eso está cambiando, lo que va a tener grandes consecuencias.
Detrás de la nube: administración y gestión
La importancia de la automatización de los centros de datos en la nube se debe a que no son entornos estáticos pre provisionados para ejecutar un conjunto finito y conocido de cargas de trabajo, con una demanda previsible; sino todo lo contrario. Son marcos altamente dinámicos en los que todo cambia todo el tiempo.
Lea después: 3 pasos para obtener el data center de primer mundo
¿Cómo gestionar decenas o cientos de miles de servidores con redes asociadas, sistemas de almacenamiento, una amplia gama de software y los sistemas administrativos? ¿Cómo conseguir que esos componentes entreguen sus servicios con un clic a los impacientes y exigentes usuarios de la nube? La respuesta es la automatización, o al menos lo será cuando se haya descubierto cómo hacerla.
Gestión de servicios para el centro de datos
Las principales empresas de tecnología trabajan en esto desde hace muchos años. Un buen ejemplo es Microsoft y su sistema Autopilot. En palabras de Microsoft, “Autopilot es responsable de automatizar el aprovisionamiento y despliegue del software; monitorear el sistema y llevar a cabo acciones de reparación para manejar el software y el hardware defectuosos. Una supuesta clave subyacente al piloto automático es que los servicios construidos en él deben ser diseñados para ser manejables“.
Servicios manejables, ese es el requisito. El piloto automático de un avión pierde su sentido si no puede ajustar las superficies de control (alerones, aletas, timones). Una pregunta interesante es acerca de dónde las empresas están en ese viaje en términos del centro de datos, en otras palabras, qué tan cerca están de tener al piloto automático del centro de datos conectado a sus “superficies de control”.
Los principales temas de esta “gestión de servicios” son desacoplamiento y control basados en software. En términos generales, es necesario definir los servicios importantes con varios niveles de granularidad, aislarlos unos de otros y darles control y APIs de monitoreo. En algunas áreas de los centros de datos hay una gran sofisticación al respecto.
La virtualización de los servidores ha desacoplado las aplicaciones de los servidores físicos y hay sistemas de gestión de VM capaces de gestionar los ciclos de vida y la salud de las máquinas virtuales. Los contenedores llevan esto considerablemente más lejos, pues incluyen elementos de gran alcance alrededor del empaquetado y de la independencia de la localización.
En cuanto a la conexión a las redes, el progreso de las virtuales ha sido rápido. La concepción centrada en la aplicación de la red es análoga a la centrada en la aplicación de la máquina en la que se está ejecutando pero, en ambos casos, la concepción es errada (en el mejor sentido de la palabra), pues pretende ser un hardware real, pero en realidad desacopla la aplicación del mismo.
En ambos casos tiene el control basado en API y sistemas de nivel superior que interactúan con ellas. Lo mismo ocurre con la virtualización del almacenamiento y el almacenamiento definido por software.
El aumento de los sistemas híper-convergentes a nivel de servidor sigue un patrón similar: desacoplar los servicios y proporcionar mecanismos para el control basados en el software. Existe una buena “manejabilidad del servicio” y está progresando muy rápidamente. ¿Qué falta?
Más allá de la virtualización: desacoplamiento en la capa de la base de datos
-Hoy en día se puede tener una API que permita agregar o quitar una VM a su aplicación para soportar un aumento o caída de usuarios simultáneos e incluso permitir que una herramienta de orquestación, como Kubernetes, agregue o elimine la VM automáticamente cuando sea necesario. ¿Puede hacer esto con el sistema de su base de datos?
-Hoy en día se puede tener una API que permita proveer y configurar una red privada de una manera totalmente automatizada. ¿Puede proporcionar y configurar una base de datos de esa manera?
-Hoy en día se puede tener una API que permita mover un conjunto de micro servicios en ejecución a una máquina física diferente, para permitir el mantenimiento de la actual. ¿Su base de datos tiene ese tipo de API?
-Hoy en día se puede tener una API que reconfigure su sistema de almacenamiento mientras está dando servicio a otras aplicaciones. ¿Su sistema de base de datos es compatible con eso?
No olvide ver: Así serán los Data Center del futuro
El diseño histórico del RDBMS es tan fundamentalmente antitético a la infraestructura elástica que, no importa lo inteligente que sea el piloto automático del centro de datos, no tiene acceso a las “superficies de control” útiles.
Eso se debe a que los sistemas de base de datos tradicionales no pueden realizar las acciones que se esperarían de un centro de datos elástico. No puede llamar a una API para indicarle a Oracle o SQL Server que agregue 10 nodos más a una base de datos en ejecución.
Introducción a la base de datos definida por el software
El reto de proporcionar grandes APIs de automatización para las bases de datos está relacionado con el desacoplamiento. El diseño principal de los principales sistemas de bases de datos nació con el System-R de IBM a mediados de los años setenta, cuyo patrón dominante es el acoplamiento estrecho, especialmente entre la memoria y el almacenaje. Un diseño modular ligeramente acoplado sería mejor para la automatización, pero el RDBMS tradicional es monolítico.
La próxima generación de sistemas de bases de datos, los llamados sistemas Elastic SQL deberían ser diseñados para ser modulares, ligeramente acoplados, componibles y programables por software. Tal vez deberíamos referirnos a las bases de datos Elastic SQL como bases de datos definidas por software, porque desde una perspectiva de automatización es el requisito central.
Comments