Muchos en los negocios, y la mayoría en la industria de la tecnología en particular, dirían «sí» con confianza. La palabra es preeminente y, de todas las conferencias, libros y referencias en línea, hay descripciones disponibles. Parece que cualquier negocio serio debería estar relacionado de alguna manera con la nube. El problema es que primero necesitamos comprender qué es realmente, sus capacidades y cómo podemos trabajar con él. Este artículo intentará discutir este problema y se basa en dos premisas simples: la nube es más que una simple infraestructura virtual bajo demanda y presenta algunos desafíos para los arquitectos de software e infraestructura. Veamos.

¿Sabes qué es la nube y cómo usarla?

Podemos empezar buscando una definición de Nube. Básicamente es “el uso de recursos informáticos (hardware y software) que se entregan como un servicio a través de una red (normalmente Internet)”. Esa definición es de alguna manera precisa, pero la haremos un poco más abstracta al decir que la nube es un conjunto de recursos a los que se puede acceder y utilizar de forma remota. Esos recursos no están restringidos al hardware y software, ya que pueden ser servicios o datos / información (que requieren software y hardware, por supuesto). La pequeña diferencia es la abstracción real de los recursos que viven o residen en la nube. Es decir, la nube es el lugar «ahí fuera» que es un conjunto de recursos a los que podemos acceder.

Ahora, hay muchas formas en que se puede acceder a esos recursos en la nube, pero el estándar casi de facto es usar la metáfora del servicio. La nube es entonces ese pool de recursos que nos ofrece un conjunto de servicios (funcionalidad empresarial) a través de un canal de comunicación especial que podemos consumir a través de la red. Esta abstracción trajo una plétora de recursos servidos mediante servicios, como Infraestructura como servicio (IaaS), Plataforma como servicio (PaaS) e incluso Datos como servicio (DaaS).

Criterios que impactán al diseño de una insfraestructura en la nube

Estos recursos son los mismos que utilizan los sistemas «locales» habituales. La diferencia es que están en la nube, en el grupo, a los que se accede mediante la metáfora del servicio. Esto viene con algunas restricciones importantes sobre lo que el sistema puede y no puede hacer, y también afecta la forma en que el sistema está diseñado per-se. Repasemos esas cinco consideraciones o criterios.

  1. Los criterios de abstracción
  2. Los criterios de comunicación
  3. Los criterios de gobernanza
  4. Los criterios de seguridad
  5. Los criterios de tamaño

Los criterios de abstracción

Los recursos en la nube pueden no ser lo que parecen. Mediante la virtualización y otras técnicas, la nube puede ofrecer diferentes tipos de recursos que pueden no ser reales. A nivel de infraestructura, la nube puede ofrecer computadoras con algo de memoria y potencia de procesador, pero no necesariamente una máquina física existente. La abstracción de los recursos es una parte muy importante de la oferta de la nube que tiene muchos beneficios y algunas restricciones.

La abstracción proporcionará a los equipos de TI y de desarrollo de software la importante «facilidad de uso». La configuración e implementación de una máquina, por ejemplo, es tan fácil como agregarla a una cuenta y luego grabar un sistema preconfigurado en ella. Crear una nueva base de datos o instalar un nuevo servicio es tan fácil como hacer un par de clics. Esto se debe a que todo el trabajo pesado se realiza en la implementación de la nube, no en nuestro sistema real. Solo consumimos el servicio de agregar una nueva base de datos. Cómo se hace eso está oculto.
Lo que perdemos entonces es un poco de control. Para ofrecer esa facilidad de uso, se debe implementar la simplicidad, y eso significa reducir la granularidad de la configuración. No hay espacio para ajustar o manejar directamente los parámetros de configuración con el fin de ajustar la solución a nuestras necesidades. Si lo hace, puede evitar el uso de recursos en la nube para algunas aplicaciones que tienen requisitos especiales distintos de las configuraciones estándar o más comunes.

Los criterios de comunicación

Una característica importante del acceso a los recursos en la nube es la necesidad de tecnología de comunicación. La comunicación significa información (control, estado y negocio) que fluye del sistema local a la nube y viceversa. Eso viene con un interesante conjunto de consideraciones a tener en cuenta:

  • API externa. Para acceder a los recursos debemos seguir la especificación de la API que nos brinda el proveedor de la nube. Esa API está fuera de nuestro control y puede proporcionar capacidades fantásticas o limitar nuestra propia funcionalidad. Esa API debe evaluarse para determinar si se ajusta a nuestras necesidades.
  • Velocidad. Toda comunicación afecta la velocidad de procesamiento. En el contexto de la nube eso es claro cuando incluimos seguridad (costo de cifrado), validación de datos, latencia de la red, etc. Los requisitos que son sensibles a los tiempos de respuesta deben validarse antes de usar la nube con ellos.
  • Riesgo de datos / control. Como se mencionó anteriormente, podemos perder el control. Un proveedor externo es el que administra nuestros recursos y datos. Cualquier problema o excepción será manejado por el proveedor.
  • El estado en línea. Por supuesto, la comunicación significa que debemos estar conectados, en línea. Este estado en línea, cuando la nube es externa, requiere una conexión continua a Internet. Una falla en la línea dejará el sistema inoperativo, un riesgo que debe evaluarse y mitigarse.

Los criterios de gobernanza.

Puede que sea necesario ampliar la gobernanza. Las políticas y normas pueden cambiar debido a las capacidades recientemente adquiridas en infraestructura y software cuando se trabaja con la nube. Revisemos:

  • Aprovisionamiento dinámico. La nube ofrece la capacidad de creación dinámica de recursos. Eso permite un aprovisionamiento a pedido y la creación de recursos sobre la marcha en función de las necesidades reales. Eso debería ser automático. Por supuesto, esto requiere la recopilación de datos para la toma de decisiones, pero también minimiza los cambios caóticos en la infraestructura y el tamaño del servicio. Se debe tener especial cuidado ya que agregar más recursos puede afectar componentes sensibles (imagine una sobrecarga de consultas de base de datos o la saturación de la red).
  • Fail Over / Recuperación. Más recursos significan más posibilidades de fallas en los componentes. Por otro lado, los problemas con los recursos inflados o abandonados se pueden resolver con la creación cuidadosa de más recursos para reemplazar los que están dañados. Se necesitan políticas que regulen esto.
  • Equipo de operaciones afectado. Manejar un conjunto estático de servidores es un trabajo duro. Ahora, manejar grandes conjuntos de servidores dinámicos que se crean y eliminan dinámicamente puede resultar engorroso. Es posible que las operaciones deban cambiar de rumbo hacia la manipulación de recursos y el uso de plantillas.
  • Desarrollo basado en la nube. Los equipos de desarrollo deben estar preparados para el aprovisionamiento dinámico. Es decir, el software debe conocer la nube y, al tener acceso a la API de la nube, puede autoaprovisionar los recursos necesarios. Ahora, también debe proporcionar servicios para verificaciones de cordura, monitoreo y control externo, de modo que un componente de administración central pueda detectar problemas y aislarlos. Eso puede ser fácil con un par de recursos, pero una masa dinámica requerirá herramientas adicionales.

Los criterios de seguridad.

En seguridad tenemos preocupaciones y limitaciones. Las dos preocupaciones principales son:

  1. Datos C.I.A. Una de las principales preocupaciones en materia de seguridad es garantizar la confidencialidad, integridad y disponibilidad de los datos. La CIA de datos es un conjunto de propiedades que deben aplicarse según los datos y el proceso que requieren los datos. Esas propiedades también se ven afectadas por «dónde» se encuentran los datos. Los datos en la nube pública dependen en gran medida de la implementación de la nube. El proveedor de la nube puede ver los datos; los problemas con los proveedores pueden alterar los datos o, lo que es peor, dejar los datos inalcanzables. Los datos están en otro lugar y no están totalmente bajo nuestro control. Por lo tanto, se debe implementar una aplicación adicional, como el cifrado en el origen (para que los datos se cifren en las instalaciones), la validación de datos y las copias de seguridad de datos en vivo (como en los planes de continuidad del negocio, consulte el siguiente punto).
  2. Fallo masivo. Sí, ha sucedido. El proveedor de la nube puede tener un apagón grave y todos nuestros servicios en la nube son inalcanzables. Dependiendo de cuán críticos sean esos servicios, debemos tener en cuenta esta preocupación en nuestro plan de continuidad comercial.

Por supuesto, existen algunas limitaciones legales que también debemos tener en cuenta. Por ejemplo, datos que no deben salir del país o que no se pueden «exportar» a algunas ubicaciones.

Los criterios de tamaño

Sí, la nube ofrece un escalado inmediato de nuestra infraestructura o servicios. De repente, podemos escalar de uno a miles de servidores. Controlar una gran cantidad de recursos es una tarea compleja. Veamos qué debemos tener en cuenta:

  • Creación y Control. Cómo, cuándo y cuánto crear. Esto debe estar impulsado por políticas, monitoreo regular y análisis cuidadoso del impacto al agregar recursos. La otra parte del trabajo es cómo controlar esa masa de recursos. Desde estrategias de cuadrícula hasta expansión viral y control de recursos (donde cada recurso puede crear y controlar adicionalmente un pequeño conjunto de recursos), cada uno de ellos requerirá un componente de control. Un control centralizado no es una buena idea, ya que es posible que no pueda controlar esa masa sin ayuda.
  • Salud del Recurso. El autoconocimiento es imprescindible. Un control de salud automático que permite que los componentes del sistema nos notifiquen de manera oportuna e informativa cuando algo anda mal.
  • Integración de múltiples proveedores. Por supuesto, hay casos en los que se necesitan varios proveedores para cumplir con los requisitos del sistema. La administración de grandes conjuntos de recursos que se pueden ubicar en diferentes nubes requiere un poco de abstracción. Se debe realizar una planificación e integración cuidadosas con el plan de continuidad del negocio.

Resumiendo.

La nube es una excelente forma nueva de proporcionar recursos utilizando la metáfora del servicio, que ofrece capacidades interesantes para sistemas dinámicos y en crecimiento. Pero, al mismo tiempo, plantea algunas limitaciones y preocupaciones relacionadas que los arquitectos de software e infraestructura deben comprender y resolver al crear las arquitecturas de software e infraestructura.