El aumento de la capacidad de procesamiento y el desarrollo de tecnologías de virtualización en la plataforma x86, por un lado, y la expansión de la externalización de TI, por otro, han llevado al concepto de utility computing (TI como un servicio público). ¿Por qué no pagar por TI de la misma manera que pagamos por agua o electricidad: exactamente lo que se necesita y solo cuando se necesita?
En este momento surgió el concepto de computación en la nube: el consumo de servicios de TI desde la "nube", es decir, desde un conjunto externo de recursos, sin preocuparse de cómo y de dónde provienen esos recursos. Al igual que no nos preocupamos por la infraestructura de las estaciones de bombeo del suministro de agua. En este momento también se había desarrollado el otro aspecto del concepto, es decir, la noción de servicios de TI y cómo gestionarlos dentro del marco de ITIL / ITSM.
Se han desarrollado una serie de definiciones sobre nubes (computación en la nube), pero no se deben considerar como la verdad última; son solo una forma de formalizar las formas de proporcionar utility computing.
- "La computación en la nube es una tecnología de procesamiento distribuido de datos, donde los recursos y la potencia informática se proporcionan al usuario como un servicio de Internet" Wikipedia
- "La computación en la nube es un modelo que proporciona acceso de red conveniente a un conjunto compartido de recursos computacionales configurables (como redes, servidores, sistemas de almacenamiento de datos, aplicaciones y servicios) a demanda, que se pueden aprovisionar y poner a disposición rápidamente con un esfuerzo mínimo de gestión o intervención por parte del proveedor de servicios" NIST
- "La computación en la nube es un paradigma que proporciona acceso de red a un conjunto escalable y flexible de recursos físicos o virtuales distribuidos, que se ofrecen en modo de autoservicio y gestionados a demanda" ISO/IEC 17788:2014. Tecnología de la información — Computación en la nube — Resumen y vocabulario.
Según NIST, existen tres tipos principales de nubes:
- IaaS – Infrastructure as a Service — Infraestructura como servicio
- PaaS – Platform as a Service — Plataforma como servicio
- SaaS — Software as a Service — Software como servicio
Para una comprensión simplificada de la diferencia, consideremos el modelo Pizza-as-a-Service:
NIST define las siguientes características necesarias de un servicio de TI que permite considerarlo como nube.
- Acceso a la red universal (broad network access) – el servicio debe tener una interfaz de red universal que permita la conexión y uso del servicio prácticamente por cualquiera con requisitos mínimos. Por ejemplo, para utilizar la red eléctrica de 220V, basta con conectarse a cualquier enchufe con un conector universal estándar (enchufe), que no cambia independientemente de si se trata de una tetera, una aspiradora o un portátil.
- Medición del servicio (measured service) – una característica clave del servicio en la nube es la medibilidad del servicio. Volviendo a la analogía con la electricidad: pagarás exactamente por lo que consumas con una granularidad mínima, incluso hasta el costo de hervir agua una vez, si durante todo el mes solo estuviste en casa una vez y tomaste una taza de té.
- Autoconfiguración de servicios bajo demanda (on demand self service) – el proveedor de la nube ofrece al cliente la posibilidad de configurar el servicio razonablemente, sin necesidad de interactuar con el personal del proveedor. Para hervir agua, no es necesario contactar previamente a la compañía eléctrica y avisarles para obtener permiso. Desde el momento en que la casa está conectada (se ha firmado un contrato), todos los consumidores pueden gestionar la potencia provista de manera independiente.
- Elasticidad rápida (rapid elasticity) – el proveedor de la nube ofrece recursos con la posibilidad de aumentar/disminuir la potencia de manera instantánea (dentro de ciertos límites razonables). Tan pronto como se enciende la tetera, el proveedor entrega inmediatamente 3 kW de potencia a la red, y tan pronto como se apaga, reduce la entrega a cero.
- Agrupación de recursos en un pool (resource pooling) – los mecanismos internos del proveedor de servicios permiten combinar capacidades generadoras individuales en un grupo (pool) de recursos, proporcionando posteriormente esos recursos como un servicio a diversos consumidores. Incluyendo la tetera, a nosotros nos preocupa muy poco de qué planta eléctrica proviene la potencia. Y todos los demás consumidores utilizan esta potencia junto a nosotros.
Es importante entender que las características del cloud descritas anteriormente no son arbitrarias, sino que son una conclusión lógica de la concepción de la computación utility. Y un servicio público debe poseer estas características en el marco de esta concepción. Al no cumplir con alguna de estas características, el servicio no se vuelve peor ni se convierte en 'tóxico', simplemente deja de ser un servicio en la nube. Entonces, ¿quién dijo que todos los servicios deben serlo?
¿Por qué lo menciono por separado? En los últimos 10 años desde que apareció la definición de NIST, ha habido muchos debates sobre lo que realmente significa 'nube' de acuerdo a esa definición. En los Estados Unidos, todavía a veces se utiliza en el ámbito judicial la expresión 'cumple con la letra de la ley, pero no con su espíritu' — y en el caso de la computación en la nube, lo fundamental es precisamente el espíritu, los recursos en alquiler con solo un par de clics.
Es importante destacar que las 5 características mencionadas anteriormente son aplicables a la nube pública, pero al pasar a una nube privada, la mayoría de ellas se vuelven opcionales.
- Acceso de red universal (broad network access) – en el marco de una nube privada, la organización tiene control total tanto sobre las capacidades generadoras como sobre los clientes usuarios. Por lo tanto, esta característica se puede considerar cumplida automáticamente.
- Medición del servicio (measured service) – esta es una característica clave de la concepción de la computación utility, donde se paga por el consumo real. Pero, ¿cómo pagará la organización a sí misma? En este caso, se realiza una división entre la generación y el consumo dentro de la empresa, donde las TI se convierten en proveedor y las divisiones de negocio en consumidores de servicios. La liquidación mutua ocurre entre divisiones. Pueden existir dos modos de operación: chargeback (con liquidaciones reales y movimiento de fondos) y showback (como un informe del consumo de recursos en rublo, pero sin movimiento de finanzas).
- Configuración automática de servicios bajo demanda (on demand self service) – dentro de la organización puede haber un servicio de TI general, y en este caso, la característica pierde sentido. Sin embargo, cuando hay especialistas de TI o administradores de aplicaciones en las divisiones de negocio, es necesario organizar un portal de autoservicio. La conclusión es que esta característica es opcional y depende de la estructura del negocio.
- La elasticidad rápida pierde sentido dentro de la organización debido a la rigidez del conjunto de equipos para una nube privada. Puede aplicarse de manera limitada en el contexto de los saldos internos. Conclusión: no es aplicable para la nube privada.
- La agrupación de recursos se ha vuelto prácticamente universal, ya que casi no existen organizaciones que no utilicen la virtualización de servidores. Por lo tanto, se puede considerar que esta característica se lleva a cabo automáticamente.
Pregunta: ¿Qué es realmente esa nube privada? ¿Qué necesita comprar e implementar una empresa para construirla?
Respuesta: una nube privada es una transición hacia un nuevo modelo administrativo de interacción entre TI y el negocio, que consiste en un 80% en medidas administrativas y solo un 20% en tecnologías.
El pago solo por los recursos consumidos y un ingreso fácil, sin la necesidad de invertir cientos de millones en gastos de capital, han determinado un nuevo paisaje tecnológico y la aparición de empresas multimillonarias. Por ejemplo, los gigantes modernos Dropbox e Instagram comenzaron como startups en AWS sin ninguna infraestructura propia.
Es importante resaltar que las herramientas de gestión de servicios en la nube se están volviendo significativamente más indirectas, y una de las principales responsabilidades del director de TI pasa a ser la selección de proveedores y el control de calidad. Examinemos la problemática de estas dos nuevas responsabilidades.
Apareciendo como una alternativa a la clásica infraestructura pesada con centros de datos y hardware propio, las nubes parecen engañosamente ligeras. Es fácil entrar en la nube, pero la cuestión de salir suele quedar sin resolver. Al igual que en cualquier otra industria, los proveedores de la nube buscan proteger su negocio y complicar la competencia. El único momento competitivo serio surge solo en la elección inicial del proveedor de servicios en la nube, y luego el proveedor hará todo lo posible para evitar que el cliente se marche. De hecho, no todos los esfuerzos se centrarán en la calidad de los servicios o su variedad. Primero y ante todo, se trata de ofrecer servicios únicos y utilizar software del sistema poco convencional que dificulta la migración a otro proveedor. Por lo tanto, al elegir un proveedor de servicios, es necesario al mismo tiempo formular un plan de transición de este proveedor (en esencia, un plan de recuperación ante desastres – DRP) y pensar en la arquitectura de almacenamiento de datos y copias de seguridad.
El segundo aspecto importante de las nuevas responsabilidades del director de TI es el control de la calidad de los servicios del proveedor. Casi todos los proveedores de la nube cumplen con el SLA según sus propias métricas internas, lo que puede tener una relación muy indirecta con los procesos comerciales del cliente. Por lo tanto, implementar un sistema propio de monitoreo y control se convierte en uno de los proyectos clave al trasladar sistemas de TI significativos al proveedor de la nube. Continuando con el tema del SLA, es necesario subrayar que la gran mayoría de los proveedores de la nube limitan su responsabilidad por el incumplimiento del SLA al pago mensual o a una parte del mismo. Por ejemplo, AWS y Azure, al superar el umbral de disponibilidad del 95% (36 horas al mes), ofrecen un 100% de descuento en la suscripción, mientras que Yandex.Cloud ofrece un 30%.
Y, por supuesto, no debemos olvidar que las nubes no solo existen en la forma de gigantes como Amazon y colosos como Yandex. También hay nubes más pequeñas, del tamaño de un gato o incluso de un ratón. Como muestra el ejemplo de CloudMouse, a veces una nube simplemente se apaga. No recibirás ninguna compensación, ni descuento; no recibirás nada, excepto una pérdida total de datos.
Debido a los problemas mencionados anteriormente con la implementación de sistemas informáticos de alta criticidad empresarial en infraestructuras en la nube, en los últimos años hemos observado el fenómeno de la "repatriación de la nube".
Para 2020, la computación en la nube había alcanzado el pico de expectativas infladas y el concepto se encontraba en camino al valle de la desilusión (según el ciclo de hype de Gartner). Según investigaciones y hasta el 80% de los clientes empresariales están devolviendo y planean devolver cargas de trabajo de la nube a sus propios centros de datos por razones:
- Aumentar la disponibilidad / rendimiento;
- Reducir costos;
- Para cumplir con los requisitos de seguridad de la información.
¿Qué hacer y cómo es que todo "realmente" funciona?
No hay dudas de que la nube ha llegado para quedarse. Y con cada año su papel crecerá. Sin embargo, no vivimos en un futuro lejano, sino en 2020, en una situación bastante definida. ¿Qué hacer con la nube si no eres una startup, sino un cliente corporativo clásico?
- Las nubes son, ante todo, un lugar para servicios con cargas de trabajo impredecibles o con una fuerte estacionalidad.
- En la mayoría de los casos, los servicios con cargas de trabajo predecibles y estables son más económicos de mantener en su propio centro de datos.
- Es necesario comenzar a trabajar con la nube a través de entornos de prueba y servicios de baja prioridad.
- La consideración de la ubicación de los sistemas de información en la nube comienza con el desarrollo de una metodología para salir de la nube hacia otra nube (o de regreso a su propio centro de datos).
- La colocación de un sistema de información en la nube comienza con el desarrollo de un esquema de respaldo a una infraestructura controlada por usted.
Fuente: habr.com
