Conceptos de computación en la nube

La computación en la nube da acceso a recursos informáticos a través de una red cuando se necesitan. Esos recursos incluyen potencia de procesamiento, almacenamiento, bases de datos, redes y aplicaciones completas. Proceden de un conjunto compartido y pueden prepararse y devolverse rápidamente, con poca interacción con el personal del proveedor.

De comprar equipos a solicitar capacidad

Un proveedor de servicios en la nube suministra servicios; un cliente o consumidor los usa. AWS, Microsoft Azure y Google Cloud son grandes proveedores de nube pública. Aprovisionar un recurso significa dejarlo listo para usar. Desaprovisionarlo significa liberarlo. Una carga de trabajo es la aplicación o el proceso, sus datos y los recursos necesarios para ejecutarlo.

En la nube pública, el proveedor es dueño de los equipos físicos y los mantiene. Los clientes obtienen los servicios que necesitan y pagan según el modelo de precios del servicio. Una organización también puede operar su propia nube privada. Sus departamentos siguen tomando recursos de un conjunto compartido y el sistema mide su uso, aunque ningún proveedor externo envíe una factura.

Compara las formas de operar una tienda web

Con infraestructura informática local, una empresa compra un servidor para su propio edificio. El personal elige el hardware, espera la entrega, instala un sistema operativo, conecta la red y después instala la tienda. La empresa también se encarga de la electricidad, la refrigeración, las reparaciones y la sustitución final. Debe planificar la capacidad antes de que las ventas revelen cuánta necesita.

Con una VM en la nube, un empleado selecciona un tamaño y una ubicación en una consola web. El servidor puede estar listo en minutos. Si el experimento termina después de un mes, el empleado elimina la VM. Sus cargos de cómputo terminan, pero el almacenamiento conservado por separado u otros recursos pueden seguir generando costos.

El alojamiento en instalaciones compartidas cambia la ubicación de los servidores propios; por sí mismo no cambia cómo se aprovisionan. Del mismo modo, un servidor alquilado al que se accede por internet puede ser alojamiento tradicional. El acceso por red por sí solo es solo una parte del modelo de nube.

Tres preguntas distintas

La definición del NIST separa las características esenciales, los modelos de servicio y los modelos de implementación. Las características preguntan: «¿Funciona como una nube?». El modelo de servicio pregunta: «¿Qué capas administra el proveedor?». El modelo de implementación pregunta: «¿Para quién es la infraestructura?». Una nube privada puede proporcionar IaaS y una nube pública puede proporcionar SaaS.

Los datos en la nube tienen un lugar físico en equipos de almacenamiento de centros de datos. Los clientes suelen elegir una región, aunque normalmente no seleccionan un disco o host concreto. «En la nube» describe el modelo de prestación, no datos sin ubicación.

NIST SP 800-145 describe cinco características esenciales de la computación en la nube. Cada una responde a una pregunta práctica distinta sobre la obtención y el uso de recursos. Un servicio necesita la combinación completa; un gran conjunto de servidores o una página de pedidos en línea por sí solos no son suficientes.

Las cinco características

1. Autoservicio bajo demanda: los clientes crean recursos por sí mismos cuando los necesitan. Un desarrollador puede aprovisionar un volumen de 100 GB a las 2 de la madrugada mediante una consola o API sin esperar a un empleado del proveedor. Una API es una interfaz que permite a un programa solicitar acciones a otro sistema.
2. Acceso amplio a la red: los mecanismos de red estándar ponen los servicios a disposición de distintos dispositivos. El personal podría usar el mismo servicio mediante el navegador de un portátil, una aplicación de teléfono o software que llama a una API mediante HTTPS. El acceso puede seguir requiriendo autenticación y una conexión de red privada.
3. Agrupación de recursos: el proveedor asigna y reasigna capacidad de procesamiento, memoria, almacenamiento y red entre los clientes. Cada cliente es un inquilino. La separación lógica protege a los inquilinos mientras se comparten los recursos físicos. Los clientes suelen poder elegir una región sin conocer el servidor concreto que interviene.
4. Elasticidad rápida: la capacidad puede ampliarse y reducirse rápidamente con la demanda. Una plataforma de video podría usar 4 servidores normalmente, 40 para una final en directo y 4 después. La automatización suele realizar estos cambios, pero la definición también permite cambios rápidos iniciados por una persona.
5. Servicio medido: el sistema registra el uso en unidades adecuadas, como segundos de cómputo, GB de almacenamiento o cuentas activas. El proveedor y el cliente pueden supervisar, controlar y elaborar informes sobre el consumo.

Aplica las pruebas a dos servicios

Una empresa alquila un servidor dedicado tras rellenar un formulario de ventas. La entrega tarda tres días y una ampliación necesita un nuevo contrato. Paga 200 u.m. al mes. La espera descarta el autoservicio bajo demanda y el proceso de ampliación carece de elasticidad rápida. El equipo dedicado no procede de un conjunto compartido. Estas observaciones identifican el servicio como alojamiento tradicional.

La tarifa mensual fija no resuelve la cuestión de la medición. El proveedor de alojamiento podría seguir registrando el tiempo de CPU o el uso de la red. La medición y la facturación son distintas: un medidor registra el consumo; una regla de precios convierte alguna medida en un cargo.

Considera ahora un servicio de correo electrónico. Un administrador puede añadir o eliminar buzones de inmediato, los usuarios se conectan desde distintos dispositivos, la infraestructura agrupada sirve a muchas organizaciones, la capacidad cambia con la demanda de cuentas y el servicio informa de los usuarios activos. Esta combinación cumple las cinco características, aunque su factura sea una suscripción mensual.

Reconoce una coincidencia parcial

Un departamento de informática puede ejecutar muchas VM mientras los empleados esperan días a que cada solicitud se apruebe y se cree manualmente. La virtualización ayuda a agrupar recursos, pero este proceso carece de autoservicio. Añadir un portal solo es útil si la automatización, el aprovisionamiento rápido y la medición del uso lo respaldan.

Una nube privada puede usar su medidor para informes departamentales o cargos internos. Por tanto, el servicio medido se aplica incluso sin una factura externa. La elasticidad también requiere devolver capacidad: mantener permanentemente la capacidad máxima deja recursos inactivos cuando baja la demanda.

La virtualización crea versiones mediante software de recursos informáticos físicos. Permite que un servidor físico sirva de soporte a varias computadoras independientes creadas por software. Los operadores de nube combinan esto con automatización, autoservicio y medición del uso para poner capacidad a disposición rápidamente.

Hosts, invitados e hipervisores

Una máquina virtual (VM) tiene procesadores virtuales, memoria, discos e interfaces de red. Ejecuta su propio sistema operativo invitado y sus aplicaciones. La computadora física que la sustenta es el host. Un hipervisor crea las VM, asigna capacidad física y mantiene la memoria y el almacenamiento de cada VM separados lógicamente.

Una imagen de VM es un punto de partida almacenado para una máquina virtual. El software puede crear una VM a partir de esa imagen sin pedir un nuevo servidor físico. Iniciar, cambiar el tamaño y eliminar VM facilita el aprovisionamiento rápido y la elasticidad. El sistema de virtualización puede registrar el uso de recursos, lo que facilita la medición. Algunas plataformas también admiten la migración en vivo, que traslada una VM en ejecución entre hosts para que el mantenimiento del hardware cause poca o ninguna interrupción.

Analiza la consolidación

Supongamos que 12 servidores físicos de igual potencia tienen cada uno un uso promedio de CPU del 10 %. Su carga promedio combinada es:

Eso equivale a la capacidad de procesamiento de 1,2 servidores. Trasladar las cargas de trabajo a VM en dos hosts de igual potencia da un promedio por host de:

Se pueden retirar diez máquinas físicas, lo que reduce el consumo de electricidad, la refrigeración y el mantenimiento. Antes de hacerlo, el equipo también debe comprobar la demanda máxima de CPU y las necesidades de memoria, discos y red. El cálculo del promedio por sí solo no permite determinar si dos hosts soportarán todos los períodos de mucha actividad o el fallo de un host.

Compartir sin compartir datos

La tenencia múltiple significa que varios clientes usan infraestructura compartida. El aislamiento impide que un inquilino acceda a la memoria o los discos de la VM de otro. Los límites físicos compartidos aún pueden afectar al rendimiento: un inquilino con una actividad inusualmente intensa puede competir por la capacidad, lo que se conoce como el efecto del vecino ruidoso. Los controles de recursos limitan ese efecto. Los hosts dedicados proporcionan un servidor físico completo a los clientes cuyos requisitos lo exigen.

La virtualización del almacenamiento presenta discos agrupados como volúmenes virtuales. La virtualización de redes proporciona redes separadas definidas por software sobre conexiones físicas compartidas.

Los contenedores empaquetan aplicaciones, bibliotecas y configuraciones mientras comparten el núcleo de un sistema operativo. Una VM tiene un sistema operativo invitado completo; un contenedor no. Los contenedores suelen arrancar más rápido y usar menos recursos, mientras que las VM proporcionan una separación más sólida entre sistemas operativos y pueden ejecutar distintos sistemas invitados. Los contenedores suelen ejecutarse dentro de VM.

Una nube también puede ofrecer servidores físicos mediante autoservicio. La virtualización es una base fundamental, mientras que las cinco características del servicio determinan si la oferta en su conjunto es computación en la nube.

Un modelo de servicio describe qué proporciona el proveedor y qué administra el cliente. Imagina la tecnología como capas: edificios y equipos físicos, virtualización, sistema operativo, software intermedio y entorno de ejecución, aplicación y datos. Un entorno de ejecución es el entorno de software que ejecuta el código de una aplicación, como Python o Java.

Compara los tres modelos estándar

Con infraestructura informática local, la organización administra toda la pila. De IaaS a PaaS y a SaaS, el proveedor asume más trabajo. El cliente gana comodidad y renuncia a parte de la libertad para cambiar el sistema subyacente.

Un blog, tres formas de operarlo

Un cliente de IaaS inicia una VM de Linux, instala el servidor web, la base de datos y el software del blog, y mantiene esas capas. El proveedor sigue reparando el host físico y manteniendo el hipervisor. Aplicar parches al sistema operativo invitado corresponde al cliente.

Un cliente de PaaS implementa una aplicación de blog en una plataforma compatible. El proveedor proporciona actualizaciones del sistema operativo y del entorno de ejecución. El cliente mantiene la aplicación y debe seguir el proceso de actualización de la plataforma. En AWS Elastic Beanstalk se pueden activar los parches y las actualizaciones menores administrados; los clientes mantienen los entornos en versiones compatibles y resuelven las actualizaciones fallidas. Si desactivan las actualizaciones administradas, son responsables de aplicarlas.

Un cliente de SaaS se suscribe a una aplicación de blog ya preparada y empieza a escribir. El proveedor opera la aplicación, pero el cliente sigue controlando quién puede publicar y qué contenido se comparte.

Reconoce ejemplos habituales

Las bases de datos administradas, como Amazon RDS, Azure SQL Database y Google Cloud SQL, suelen considerarse PaaS: el cliente usa una base de datos sin mantener la plataforma de servidores subyacente.

Clasifica el servicio, no la empresa que lo vende. Un proveedor puede ofrecer los tres modelos, y algunos productos distribuyen las responsabilidades de formas que quedan entre las categorías clásicas. Consulta las responsabilidades de la oferta concreta cuando el nombre por sí solo no sea claro.

Las denominaciones más específicas siguen la misma idea. DBaaS significa base de datos como servicio; FaaS significa función como servicio; XaaS es una denominación amplia para «cualquier cosa como servicio». Sea cual sea el nombre, alguien debe seguir siendo responsable de los datos del cliente y de las decisiones de acceso.

La computación sin servidor significa que el cliente usa código o un servicio sin elegir, dimensionar ni mantener sus servidores. Los servidores siguen realizando el trabajo. El proveedor administra la infraestructura y el escalado, y los cargos se basan en medidas de uso específicas de cada servicio.

Sigue un evento a través de una función

Con la función como servicio (FaaS), el cliente carga una pequeña unidad de código. Un evento desencadena una ejecución: una solicitud web, un archivo cargado, un mensaje en una cola o una programación. Para un servicio de fotos, la secuencia es:

1. Un cliente carga una fotografía en el almacenamiento.
2. El evento de carga inicia una función.
3. La función crea y almacena una miniatura.
4. La ejecución termina.

AWS Lambda, Azure Functions y Google Cloud Run functions son ejemplos. Las funciones suelen escalar a cero cuando están inactivas y cobrar por solicitudes y tiempo de ejecución. La computación sin servidor también incluye servicios como Amazon S3, Amazon DynamoDB y Google BigQuery. Los datos almacenados pueden seguir generando cargos mientras no se ejecuta código. Los planes de funciones con capacidad siempre lista también pueden cobrar durante los períodos de poca actividad.

Calcula la factura de una función

Considera tarifas ilustrativas de 0,20 u.m. por millón de solicitudes y 0,000017 u.m. por GB·s. Cada una de 3 millones de solicitudes usa 0,5 GB de memoria durante 200 milisegundos, o 0,2 segundos.

Primero calcula el tiempo total de ejecución y después el uso de memoria por tiempo:

El cómputo cuesta 5,10 u.m. y las solicitudes cuestan 0,60 u.m., lo que suma 5,70 u.m. En este ejemplo de precios no hay cargo mínimo ni cargo de cómputo por inactividad. Una VM a 0,05 u.m. por hora durante 730 horas cuesta 36,50 u.m.

Cada solicitud cuesta 0,0000019 u.m. en el ejemplo. Dividir 36,50 u.m. entre esa cantidad da unos 19,2 millones de solicitudes. Por encima de ese volumen, la VM tiene un precio de cómputo de lista menor, siempre que pueda soportar el trabajo. El almacenamiento, el uso de la red y la administración también importan en una comparación completa.

Comprende los límites de operación

Un arranque en frío es el retraso mientras el servicio prepara un entorno de ejecución. Una función debe ser sin estado: las ejecuciones posteriores no deben depender de la memoria ni de los archivos locales de ejecuciones anteriores. Guarda los datos duraderos en una base de datos o servicio de almacenamiento.

Cada oferta tiene límites de ejecución. Las invocaciones estándar de AWS Lambda tienen un máximo de 15 minutos. Algunos modos de invocación de Lambda Managed Instances permiten ejecuciones más largas; el modo de servicio aplicable determina el límite. Los trabajos de larga duración deben ajustarse a las reglas del servicio elegido.

La computación sin servidor suele ser adecuada para tráfico irregular, procesamiento de eventos, trabajos programados breves y automatización. Un uso intenso y constante puede favorecer otras opciones de cómputo. La necesidad de configuraciones personalizadas del sistema operativo también puede descartar una plataforma de funciones. Los desencadenantes y las API específicos del proveedor pueden dificultar una migración futura.

La computación sin servidor suele agruparse con PaaS. Su infraestructura administrada reduce el trabajo con servidores, mientras que el cliente sigue protegiendo el código, los permisos, la configuración y los datos.

Empieza la elección de un modelo de servicio por los requisitos de la carga de trabajo. Una tecnología conocida puede ser una mala elección si genera un mantenimiento que el equipo no puede asumir. Un producto altamente administrado también puede ser una mala elección si elimina el control que necesita la aplicación.

Pregunta qué hay que controlar

Usa estas preguntas en orden:

1. ¿Una aplicación ya preparada satisface la necesidad del negocio? Considera SaaS.
2. ¿El equipo implementa su propia aplicación en un lenguaje compatible sin necesitar control del sistema operativo? Considera PaaS.
3. ¿El trabajo es breve, se desencadena por eventos y tiene un volumen irregular? Considera las funciones sin servidor.
4. ¿El equipo debe controlar el sistema operativo invitado, instalar software especial o trasladar un servidor sin cambios? Considera IaaS.

PaaS y la computación sin servidor se solapan. La elección útil es el servicio concreto cuyo modelo de ejecución, límites y herramientas compatibles se ajustan a la aplicación.

Relaciona requisitos y modelos

Para la aplicación antigua, IaaS proporciona control de una VM, no control sin restricciones del hardware físico del proveedor. Aún hay que comprobar la compatibilidad y el soporte. En SaaS, confirma que las funciones y opciones de configuración disponibles cumplen los requisitos antes de aceptar la comodidad que ofrece.

Incluye el esfuerzo operativo en el costo

Supongamos que una VM cuesta 40 u.m. al mes y necesita cuatro horas de administración a 50 u.m. por hora. La administración cuesta 200 u.m., por lo que el total es de 240 u.m. En este ejemplo, un plan PaaS adecuado cuesta 90 u.m. y casi no requiere administración. Su tarifa de servicio más alta viene acompañada de un costo total menor.

La comparación del trabajo incluye la aplicación de parches, la supervisión, las copias de seguridad, las actualizaciones de la aplicación y las habilidades necesarias para responder cuando algo falla. Trasladar más capas al proveedor reduce algunas de estas tareas, pero no elimina la gestión de la aplicación ni del acceso.

Combina modelos cuando el trabajo sea distinto

Una empresa puede usar SaaS para la gestión de relaciones con clientes, PaaS para su sitio web, funciones para procesar nuevos pedidos y una VM para un componente antiguo. Cada servicio tiene su propio límite de gestión.

La portabilidad también forma parte de la decisión. Las VM y los contenedores pueden ser relativamente fáciles de trasladar cuando sus dependencias son portables. Las plataformas administradas y los desencadenantes de funciones pueden vincular el código a un proveedor. La dependencia del proveedor es el esfuerzo y el costo adicionales que crea esa dependencia.

Una decisión puede cambiar con el tiempo. Realojar una aplicación en una VM puede ser un primer paso útil, seguido más adelante por una migración de plataforma. El motivo para elegir IaaS debe ser un requisito actual, como el control del sistema operativo, y no solo la familiaridad.

Un modelo de implementación describe los usuarios para quienes se proporciona la infraestructura de nube. Un modelo de servicio describe las capas suministradas. Son elecciones distintas: una organización puede obtener máquinas virtuales mediante IaaS tanto en una nube pública como en una privada.

Nube pública

La infraestructura de nube pública está disponible para el uso del público general. Un proveedor es su dueño y la opera en sus centros de datos. AWS, Microsoft Azure y Google Cloud son ejemplos; otros proveedores son Oracle Cloud, IBM Cloud y Alibaba Cloud.

Los clientes comparten la infraestructura y suelen acceder a los servicios por internet, aunque también es posible el acceso mediante una red privada. Evitan comprar equipos físicos, pueden obtener grandes cantidades de capacidad rápidamente y elegir entre ubicaciones de todo el mundo. También dependen de las decisiones del proveedor sobre sus servicios y de la conectividad de red, y tienen menos control del hardware físico.

«Pública» describe quién puede convertirse en cliente. No significa que todo el mundo pueda ver los datos de todos los clientes. El aislamiento y los controles de acceso separan los recursos. Permitir la lectura pública de un contenedor de almacenamiento es una opción de configuración, no una característica inevitable de la nube pública.

Nube privada

Una nube privada está reservada para una organización, que puede tener muchos departamentos. La organización, un tercero o ambos pueden operarla. Puede estar en el edificio de la organización o alojada en otro lugar.

La nube privada proporciona un control más directo de los equipos, la ubicación y la configuración de seguridad. Ese control puede ayudar con determinados requisitos contractuales o normativos. El operador debe financiar la capacidad y emplear a las personas que la operan. La ampliación está limitada por el hardware disponible, por lo que tiene menos economías de escala que un gran proveedor público.

Una sala de servidores local solo cuenta como nube privada cuando proporciona características de nube, incluidos el autoservicio, la agrupación, la elasticidad rápida y el uso medido. Instalar VM por sí solo deja sin cubrir partes importantes de ese modelo de servicio. OpenStack es un ejemplo de software usado para construir nubes privadas.

Nube comunitaria

Una nube comunitaria sirve a un grupo concreto de organizaciones con intereses compartidos. Pueden compartir una misión, una política de seguridad o requisitos de cumplimiento normativo. Las organizaciones miembros, un tercero o una combinación de ambos pueden operarla en instalaciones propias o externas. Varios hospitales podrían compartir una infraestructura diseñada en torno a sus requisitos comunes sobre datos de salud.

Una oferta exclusiva para el gobierno puede servir a una comunidad, pero las condiciones reales de acceso y la forma de operación determinan su clasificación. La ubicación por sí sola no permite identificar un modelo de implementación. Una nube privada alojada externamente sigue siendo privada aunque esté en el edificio de un proveedor.

Las organizaciones suelen mantener algunas cargas de trabajo en instalaciones locales y ejecutar otras en nubes públicas. Los nombres nube híbrida y multinube describen características distintas de esa disposición. Una empresa puede tener ambas a la vez.

Conecta entornos en un modelo híbrido

El NIST define la nube híbrida como infraestructuras de nube distintas conectadas mediante tecnología que permite trasladar datos o aplicaciones entre ellas. Los componentes permanecen separados. En las conversaciones cotidianas sobre la nube, incluidos los exámenes básicos de los proveedores, la nube híbrida suele significar una nube pública conectada a una nube privada o a sistemas locales.

Un enlace seguro puede ser una VPN cifrada por internet o una conexión privada dedicada. Las herramientas compartidas de identidad y gestión pueden ayudar al personal a operar los entornos conjuntamente. Azure Arc, AWS Outposts y Google Distributed Cloud admiten distintas formas de operar entre ubicaciones; son ejemplos, no productos intercambiables.

Un modelo híbrido puede mantener registros sensibles, software antiguo o sistemas de control de equipos en las instalaciones locales mientras la nube pública aloja un sitio web o atiende la demanda adicional. También facilita la migración por etapas y las soluciones remotas de copia de seguridad o recuperación. Estas ventajas conllevan trabajo adicional de red, seguridad y gestión.

Analiza el desbordamiento a la nube pública

La nube privada de un comercio minorista gestiona 2000 pedidos por minuto. Durante una venta, la demanda sube a 5000. La nube pública gestiona el exceso:

Su parte del trabajo máximo es:

Esto es desbordamiento a la nube pública: se usa capacidad adicional durante los picos y se libera después. La aplicación y las conexiones de datos deben permitir repartir ese trabajo. Suscribirse simplemente a un segundo servicio no hace que se produzca el desbordamiento.

Usa varios proveedores públicos

Multinube significa usar servicios de dos o más proveedores de nube pública. Una empresa podría elegir los servicios de análisis de datos de un proveedor y el alojamiento web de otro. Los servicios pueden usarse por separado; la multinube no exige trasladar la misma carga de trabajo entre ellos.

Entre los posibles motivos están elegir la mejor opción para cada tarea, cumplir requisitos de ubicación, reducir la dependencia de un proveedor o combinar sistemas tras una fusión. Los costos incluyen distintos conjuntos de habilidades, herramientas de seguridad y facturas de transferencia de datos.

Para una empresa emergente sin centro de datos, la nube pública puede minimizar el gasto inicial en equipos. Una organización que exige infraestructura exclusiva puede elegir la nube privada. Una fábrica que necesita tiempos de respuesta locales muy breves puede mantener el control de las máquinas en sus instalaciones mientras usa la nube pública para el análisis. Los requisitos de cada carga de trabajo orientan la decisión de ubicación; usar más entornos aumenta el trabajo necesario para conectarlos y establecer su gobernanza.

La capacidad de la nube puede ajustarse a medida que cambia el trabajo. La escalabilidad describe esa capacidad de ajuste. La elasticidad añade una ampliación y reducción rápidas para que la capacidad siga de cerca la demanda. Ambas pueden reducir la necesidad de comprar equipos para la máxima carga posible.

Escala una máquina o cambia el número de máquinas

Cambiar una VM de 2 a 8 vCPU es escalado vertical. Pasar de 2 servidores web a 6 es escalado horizontal. Un equilibrador de carga distribuye las solicitudes entrantes entre las copias. Las copias adicionales también pueden proporcionar redundancia, siempre que se implementen para resistir los fallos pertinentes.

Una política de escalado automático podría añadir una VM después de que el uso de CPU permanezca por encima del 70 % durante cinco minutos y eliminar una cuando permanezca por debajo del 30 %. Un mínimo de dos y un máximo de diez mantienen la política dentro de un rango planificado. Una VM individual en la nube no se ajusta por sí sola simplemente por ejecutarse en ella. Algunos servicios administrados se encargan del escalado para el cliente.

Calcula la capacidad ahorrada mediante la elasticidad

Un sitio de venta de entradas necesita 4 servidores normalmente y 20 durante 10 horas en un mes de 730 horas. Mantener 20 funcionando todo el mes consume:

Con capacidad elástica, primero mantén los cuatro servidores normales durante todo el mes:

Después añade solo los 16 servidores adicionales durante el pico:

El total es de 3080 horas de servidor, aproximadamente el 21 % de 14 600. Contar 20 servidores adicionales durante el pico contaría dos veces los cuatro servidores de base. Mantener solo cuatro de forma permanente evitaría la capacidad inactiva, pero dejaría sin atender el pico.

Aprovisiona rápidamente y llega a usuarios de todo el mundo

La agilidad es la rapidez para obtener recursos, probar una idea y entregar un resultado. Un equipo puede alquilar 50 VM para un análisis de dos horas, usando 100 horas de VM, y después liberarlas. Así evita esperar a que se compren e instalen 50 máquinas. Los experimentos rápidos hacen menos costoso descartar una idea que fracasa.

El alcance global significa usar las ubicaciones del proveedor en todo el mundo sin construir centros de datos en el extranjero. Situar una aplicación más cerca de los usuarios puede reducir la latencia, el retraso en la comunicación. Aun así, es necesario elegir una ubicación adecuada y cumplir los requisitos de datos de la carga de trabajo.

El trabajo del proveedor con el hardware también libera tiempo del personal para productos y servicios.

La disponibilidad es la proporción de un período durante la cual un servicio funciona y se puede usar. La alta disponibilidad usa componentes redundantes para mantener bajo el tiempo de inactividad cuando algo falla. La fiabilidad también se refiere a seguir funcionando correctamente y recuperarse de los fallos.

Convierte un porcentaje en tiempo de inactividad

Usa la proporción del período en que el servicio no está disponible:

Un mes de 30 días tiene 43 200 minutos. Con un 99,95 %, la proporción de indisponibilidad es 0,0005, por lo que el tiempo de inactividad es de 21,6 minutos.

Un acuerdo de nivel de servicio (SLA) establece el compromiso formal de un proveedor y la compensación correspondiente. La compensación suele consistir en créditos de servicio, con condiciones para acceder a ellos y exclusiones, y no en una indemnización por todas las pérdidas del negocio. El SLA de un servicio puede depender del uso de varias instancias o ubicaciones. Las ofertas gratuitas o en versión preliminar pueden no tenerlo.

Distingue las dependencias de las copias redundantes

Si una aplicación necesita tanto su capa web como su base de datos, cualquiera de ellas puede interrumpirla. En un modelo simplificado con fallos independientes y mediciones comparables, multiplica sus disponibilidades expresadas como decimales:

Eso equivale aproximadamente al 99,94 %, por debajo de cualquiera de los componentes. Los compromisos de los SLA por sí solos no determinan el tiempo de actividad real de la aplicación; las dependencias compartidas y las reglas de medición también importan.

Para dos copias independientes cuando cualquiera de ellas es suficiente, ambas deben fallar para detener el servicio. Si cada una está disponible el 99 % del tiempo, cada una tiene una proporción de fallo del 1 %:

La independencia es fundamental. Las copias que dependen de la misma fuente de alimentación averiada no proporcionan esa protección.

Usa la protección y la medida adecuadas

Los proveedores ofrecen centros de datos separados llamados zonas de disponibilidad, varias regiones y replicación administrada. Las copias en zonas separadas pueden proteger frente al fallo de un centro de datos; una segunda región puede proteger frente a un incidente regional más amplio. Diseñar y pagar las copias adecuadas sigue siendo una decisión del cliente.

La tolerancia a fallos busca continuar sin interrupción después de que falle un componente. La alta disponibilidad puede permitir una breve interrupción. La recuperación ante desastres restaura el servicio y los datos después de un incidente grave. Las copias de seguridad protegen los datos, pero no mantienen un servidor averiado atendiendo solicitudes mientras se realiza la restauración.

La previsibilidad incluye un rendimiento uniforme y costos comprensibles. El escalado y el equilibrio de carga ayudan a gestionar el rendimiento; los informes de uso, las previsiones, los presupuestos y las alertas ayudan a gestionar el gasto. Una mayor disponibilidad suele necesitar recursos adicionales, por lo que el objetivo debe reflejar el costo del tiempo de inactividad para el negocio.

Los proveedores de nube aportan equipos de seguridad, controles físicos y supervisión a una escala que muchas organizaciones no pueden crear por sí mismas. También ofrecen herramientas que ayudan a los clientes a aplicar reglas uniformes. La ventaja proviene de usar esas herramientas y asignar el trabajo con claridad.

Usa la seguridad del proveedor y sus pruebas de cumplimiento

Los proveedores protegen los edificios, los equipos y las redes físicas. Mantienen su infraestructura y proporcionan actualizaciones de plataforma para los servicios administrados. Los clientes pueden usar controles de identidad, cifrado, cortafuegos, supervisión de seguridad y protección frente a ataques de denegación de servicio distribuida, en los que muchos sistemas saturan un servicio con tráfico.

Los proveedores también se someten a auditorías conforme a estándares y marcos como ISO/IEC 27001 y SOC 2. Esos informes aportan pruebas sobre los controles del proveedor. Las reglas de acceso, el tratamiento de datos y la configuración del servicio del cliente siguen debiendo cumplir los requisitos de la organización. La auditoría del proveedor es una parte de esas pruebas, no una aprobación de todas las aplicaciones que se ejecutan allí.

Mantén el uso de la nube dentro de las reglas de la organización

La gobernanza comprende las políticas, los procesos y los controles que alinean el uso de la nube con las reglas del negocio, las obligaciones legales y los presupuestos. Incluye mucho más que reducir las facturas.

Por ejemplo, una organización puede restringir la creación de VM a un conjunto aprobado de regiones. Una política rechaza una solicitud fuera de ese conjunto antes de que exista el recurso. Las etiquetas pueden identificar al equipo responsable de una VM, mientras que los registros muestran quién la cambió. Cada herramienta responde a una pregunta de gestión distinta.

Administra los recursos de forma uniforme

Microsoft distingue la gestión de la nube, las capacidades usadas para operar los recursos, de la gestión en la nube, los métodos que usan las personas para controlarlos. La primera incluye escalado automático, comprobaciones de estado, sustitución de recursos fallidos y alertas. La segunda incluye un portal, una interfaz de línea de comandos (CLI), API, kits de desarrollo de software (SDK) e infraestructura como código.

La infraestructura como código (IaC) describe recursos en archivos que las herramientas de implementación pueden leer. Una plantilla para dos VM web, un equilibrador de carga y una base de datos puede crear un entorno de prueba equivalente en minutos. La misma descripción de recursos puede volver a usarse sin recordar una secuencia de clics manuales. La configuración específica de la región y otros valores necesarios siguen debiendo ser correctos.

La automatización también puede programar apagados, aplicar actualizaciones o hacer copias de seguridad. Menos acciones manuales repetidas reducen las oportunidades de crear configuraciones inconsistentes y pueden reducir los costos operativos. Tras una prueba, eliminar sus recursos pone fin a los cargos específicos de esos recursos; las copias de seguridad, los discos u otros servicios conservados siguen siendo facturables. Llevar el control de esos recursos restantes forma parte de la gestión del entorno.

La computación en la nube traslada gran parte del gasto de la compra de activos al pago de servicios a medida que se usan. Comprender las unidades de medición es el primer paso para interpretar una factura y comparar la nube con los equipos propios.

Compara los tipos de gasto

El gasto de capital (CapEx) compra activos que se usan durante varios años, como servidores y equipos de almacenamiento. La contabilidad distribuye su costo mediante la depreciación. El gasto operativo (OpEx) paga costos continuos, como electricidad, suscripciones y servicios en la nube, a medida que se producen los gastos.

Los costos de capacidad local son en gran medida fijos: los equipos comprados, el espacio y el personal siguen costando dinero cuando las máquinas tienen poca actividad. Los cargos de nube basados en el consumo varían con el uso. Un compromiso o una suscripción por usuario aún pueden crear una parte fija en la factura de la nube.

El pago por uso permite a los clientes obtener recursos sin un compromiso de uso a largo plazo. Liberar un recurso pone fin a sus propios cargos de uso. Dejar de usar una VM asignada no la libera, y eliminar una VM puede dejar discos o copias de seguridad facturados por separado.

Interpreta una factura línea por línea

Usa un mes de 730 horas y tarifas ilustrativas. Dos VM funcionan todo el mes a 0,10 u.m. por hora. Una tercera funciona durante 120 horas. El almacenamiento es de 500 GB en promedio a 0,02 u.m. por GB·mes, y 200 GB salen a internet a 0,09 u.m. por GB.

• Cómputo de base: dos períodos de 730 horas suman 1460 horas de VM, con un costo de 146 u.m.
• Cómputo adicional: 120 horas cuestan 12 u.m.
• Almacenamiento: 500 GB·mes cuestan 10 u.m.
• Salida de datos: 200 GB cuestan 18 u.m.

Suma los cargos por separado:

El total mensual es de 186 u.m. La salida de datos es la transferencia desde la nube; la entrada de datos es la transferencia hacia ella. Muchas ofertas hacen gratuita la entrada y cobran por la salida a internet o las transferencias entre regiones. Un servicio multimedia que envía archivos grandes a los usuarios debe incluir esos volúmenes de salida en su estimación.

Compara el costo total de propiedad

El costo total de propiedad (TCO) compara todos los costos pertinentes durante el mismo período. Para la infraestructura informática propia, incluye equipos y sustitución, licencias de software, espacio, electricidad, refrigeración, seguridad física, redes y tiempo del personal. Para la nube, incluye cómputo, almacenamiento, transferencias, licencias, administración y los costos de migración pertinentes para la comparación.

Los grandes proveedores obtienen economías de escala al comprar y operar equipos en grandes volúmenes y compartir esos costos entre los clientes. Sus menores costos unitarios pueden permitir precios atractivos. El ahorro de una carga de trabajo concreta sigue dependiendo de la utilización, el dimensionamiento adecuado y el plan que use. Mantener continuamente en funcionamiento recursos sobredimensionados puede costar más que un servidor propio bien utilizado.

El gasto basado en el uso también necesita supervisión. Los recursos olvidados y el escalado inesperado pueden aumentar una factura variable. La supervisión, las previsiones, los presupuestos y las alertas ayudan al equipo a responder mientras los recursos siguen funcionando.

Los precios de la nube implican equilibrar la flexibilidad con los compromisos o el riesgo de interrupción. Empieza por el uso previsto de la carga de trabajo y después elige las condiciones adecuadas.

Relaciona las principales opciones de precios

AWS ofrece Reserved Instances y Savings Plans; Azure ofrece Reservations y planes de ahorro; Google Cloud ofrece descuentos por compromiso de uso. Las condiciones exactas varían, pero la cuestión central es si el uso previsible cubrirá el compromiso.

Entre los ejemplos de capacidad interrumpible están AWS Spot Instances, Azure Spot Virtual Machines y Google Cloud Spot VMs. Son adecuados para trabajos que pueden detenerse y reanudarse, como el análisis por lotes o la renderización. El aviso puede ser muy breve: AWS procura avisar con dos minutos de antelación de las interrupciones por detención o finalización; la hibernación puede comenzar de inmediato. Las notificaciones de Azure Spot pueden llegar hasta 30 segundos antes del desalojo. Un servicio de pago o una base de datos que se necesitan de forma continua requieren protección adicional a una instancia interrumpible.

Calcula el punto de equilibrio

Una VM ilustrativa cuesta 0,10 u.m. por hora bajo demanda. Un compromiso de un año cuesta 0,06 u.m. por cada una de las 8760 horas:

Divide ese costo anual entre la tarifa horaria bajo demanda:

Eso es el 60 % del año. Por encima de 5256 horas, el compromiso es más barato con estas tarifas. Con uso ininterrumpido, la opción bajo demanda cuesta 876 u.m., por lo que el ahorro es de 350,40 u.m. Con 2080 horas de oficina, la opción bajo demanda cuesta 208 u.m., menos que el compromiso completo. Aplicar la tarifa con descuento solo a las horas usadas dejaría fuera el pago contractual.

Reduce la necesidad antes de aplicar descuentos

El dimensionamiento adecuado ajusta los recursos a la demanda medida. Una VM de 8 vCPU con un uso promedio de CPU del 10 % es candidata a revisión. Antes de reducirla a 2 vCPU, comprueba los picos representativos y los requisitos de memoria, almacenamiento y red. Si el tamaño menor soporta esas demandas y el precio es proporcional, el costo de cómputo baja aproximadamente a una cuarta parte. Comprar primero un compromiso podría consolidar un recurso sobredimensionado.

La programación también importa. Un entorno de prueba que funciona 10 horas cada uno de cinco días laborables usa 50 de las 168 horas de una semana. Liberarlo fuera de esas horas reduce el tiempo de cómputo aproximadamente un 70 %.

Incluye el software y otras condiciones de precios

Los precios con licencia incluida contienen la licencia de software. El uso de licencias propias (BYOL) reutiliza licencias existentes cuando sus condiciones permiten usarlas en la nube; la Ventaja híbrida de Azure es un ejemplo. Siguen siendo aplicables los requisitos de elegibilidad, seguimiento y, en su caso, hardware dedicado.

Otras ofertas usan suscripciones por usuario, tramos por volumen, créditos de prueba o precios de hosts dedicados. Una combinación práctica puede usar compromisos para la base constante, pago por uso para la demanda incierta y capacidad interrumpible para trabajos por lotes que pueden reanudarse.

El modelo de responsabilidad compartida distribuye el trabajo de seguridad, cumplimiento normativo y operación entre el proveedor y el cliente. AWS llama a la parte del proveedor seguridad «de» la nube y a la del cliente seguridad «en» la nube. El límite cambia según el servicio, pero las decisiones sobre los datos y el acceso del cliente siempre tienen un responsable.

Empieza por las capas físicas

El proveedor protege y opera los edificios de los centros de datos, el acceso físico, la electricidad, la refrigeración, las redes físicas, los hosts y la virtualización. Los clientes se apoyan en esos controles y en las pruebas de auditoría. No aplican parches al hipervisor del proveedor como parte del uso ordinario de IaaS.

Los clientes deciden cómo se clasifican, protegen, conservan y comparten sus datos. Administran las cuentas, las identidades, los derechos de acceso y la configuración del servicio bajo su control. También protegen los dispositivos usados para acceder a los servicios. Un proveedor SaaS puede proporcionar funciones de gestión de dispositivos mientras la organización sigue siendo responsable de administrar los dispositivos de sus usuarios.

Identifica el límite que cambia

El mantenimiento de la plataforma tiene procedimientos específicos de cada servicio. Algunas ofertas PaaS requieren activar las actualizaciones administradas, pasar a una versión compatible o resolver actualizaciones fallidas. El cliente debe seguir esos procedimientos aunque no opere por sí mismo un servidor de propósito general.

Asigna tres incidentes

Una empresa usa un sitio web IaaS, una base de datos PaaS administrada y correo electrónico SaaS. Aparece una vulnerabilidad del sistema operativo invitado. La empresa aplica un parche a la VM de su sitio web; el proveedor mantiene los sistemas operativos que sustentan la base de datos administrada y la aplicación de correo, según las condiciones de actualización pertinentes.

Después, se roba la contraseña de un empleado. La empresa debe restablecer el acceso, investigar los permisos y reforzar la protección de la cuenta en todos los servicios afectados. Pasar a SaaS no ha transferido sus decisiones de identidad al proveedor.

Por último, los archivos de clientes quedan accesibles al público porque la empresa activó el uso compartido abierto. La empresa debe corregir esa configuración y ocuparse de la exposición. La seguridad física del centro de datos no puede impedir que un administrador autorizado elija una regla de uso compartido insegura.

Distribuye controles, no solo nombres

Algunos controles tienen una parte a cada lado. Los proveedores aplican parches a la infraestructura; los clientes aplican parches al software que controlan. Cada parte configura sus propias capas y forma a su propio personal. Los controles físicos se heredan del proveedor, mientras que la configuración de la aplicación corresponde al cliente.

El cumplimiento normativo sigue la misma división. La certificación de un proveedor cubre sus controles evaluados. El cliente necesita pruebas de que su configuración, tratamiento de datos y procesos cumplen los requisitos de su carga de trabajo. La documentación de responsabilidades y el contrato del servicio concreto explican el límite en detalle.

La adopción de la nube es una decisión que se toma para cada carga de trabajo. La elasticidad, la implementación rápida y los servicios administrados pueden ser valiosos, pero cada ventaja debe ajustarse a los requisitos de la organización. Identifica cada riesgo con suficiente precisión para elegir una respuesta.

Identifica las dependencias y los límites de control

La dependencia del proveedor se produce cuando las API, los servicios o los formatos de datos propietarios hacen que cambiar de proveedor sea lento o costoso. Exportar grandes cantidades de datos también puede generar cargos por salida. Los formatos abiertos, las herramientas portables, los contenedores y las exportaciones de datos probadas pueden reducir el esfuerzo de cambiar. Cada medida añade algún costo o limita las funciones disponibles, por lo que la portabilidad es una elección que debe evaluarse.

El proveedor controla sus equipos, el diseño de sus instalaciones y el ciclo de vida de sus servicios. Los clientes se apoyan en contratos, documentación y auditorías independientes para obtener pruebas sobre la infraestructura. También necesitan una respuesta para cuando un servicio cambia o se retira.

Comprueba las conexiones, la ubicación y el tiempo de respuesta

El acceso a la nube depende de la red. Un fallo de conexión en una oficina puede impedir que el personal use una aplicación en la nube que funciona correctamente. Una región distante añade retraso a la comunicación. El control de una fábrica que necesita respuestas en milisegundos puede permanecer en las instalaciones locales, mientras los servicios de nube analizan los datos resultantes.

La residencia de los datos es el lugar donde se almacenan y procesan los datos. La soberanía de los datos se refiere a las leyes y la jurisdicción que les son aplicables. Elegir una región resuelve la ubicación, pero los contratos, las condiciones de acceso y los requisitos legales también importan. Una organización puede necesitar una región aprobada, una oferta soberana adecuada o procesamiento local. No se presupone una norma legal concreta para todos los países.

Relaciona cada riesgo con una respuesta práctica

Una alerta de presupuesto señala un umbral; por sí sola no apaga los recursos. Los límites de escalado ayudan a restringir la capacidad, mientras que un plan de recuperación aborda las interrupciones. Estos controles resuelven problemas distintos.

Toma una decisión de adopción razonada

Un despacho de abogados de 40 personas considera usar gestión documental SaaS. Sus ventajas previstas son el acceso remoto, menos trabajo con servidores y la experiencia del proveedor en seguridad. El despacho comprueba que la ubicación de almacenamiento cumple sus requisitos, que los documentos pueden exportarse en formatos estándar y que todos los usuarios pueden usar autenticación multifactor.

Esas comprobaciones vinculan cada preocupación con pruebas: la región y el contrato para la residencia, una prueba de exportación para la portabilidad y los controles de cuentas para el acceso. El despacho puede decidir migrar cuando el servicio cumpla esos requisitos. Otra carga de trabajo, como un sistema local de control de máquinas, puede razonablemente permanecer en las instalaciones propias.

Las operaciones en la nube también necesitan personas que comprendan la seguridad, los costos y la automatización. El autoservicio rápido facilita la creación de recursos, por lo que la gobernanza debe dejar claros su responsable, finalidad y configuración permitida.

Una migración a la nube traslada aplicaciones, datos o infraestructura desde sistemas existentes a una nube. Comienza con un inventario de las aplicaciones, dependencias, uso, costos y valor para el negocio. Después elige una estrategia para cada carga de trabajo. Este enfoque de cartera evita obligar a todos los sistemas a pasar por el mismo traslado.

Compara las siete estrategias

Las 7 R de AWS proporcionan un vocabulario útil:

Google también usa términos como «trasladar y mejorar» para el cambio de plataforma y «reimaginar» para un cambio más amplio. La acción realizada es más útil que memorizar únicamente las palabras de un proveedor.

Distingue los traslados que se confunden fácilmente

El realojamiento deja sin cambios el código y el diseño central de la aplicación. Puede reducir el esfuerzo inmediato del traslado, pero conserva muchas responsabilidades de mantenimiento. La reubicación traslada un entorno de virtualización compatible completo y su forma de operación, no solo una aplicación a una plataforma de VM recién elegida.

El cambio de plataforma modifica una parte limitada del entorno. Una versión administrada del mismo motor de base de datos puede eliminar la administración del servidor mientras conserva el diseño central de la aplicación. La sustitución por otro producto reemplaza el producto mismo. Sustituir software propio de gestión de clientes por un CRM SaaS es sustituir por otro producto, aunque ambos sirvan al mismo propósito empresarial.

La refactorización cambia la arquitectura para obtener ventajas como componentes que pueden escalarse de forma independiente. Eso puede aportar un valor considerable a largo plazo, pero es posible que el trabajo inicial no compense para un sistema estable de bajo valor. Conservar una aplicación puede ser una decisión deliberada mientras se espera el vencimiento de un contrato, se trabaja en la compatibilidad o se realiza una revisión posterior.

Traslada los datos y planifica la transición

Una migración de base de datos con poco tiempo de inactividad puede comenzar copiando los datos a una nueva base de datos y después replicando los cambios posteriores mientras la original sigue en uso. El equipo comprueba que el destino se haya puesto al día antes de la transición al nuevo sistema, el cambio acordado de usuarios o tráfico al nuevo sistema.

La replicación reduce la cantidad de cambios que quedan por transferir en la transición. No elimina la necesidad de comprobar que los datos son correctos, coordinar el cambio final y planificar cómo responder a los problemas. Para conjuntos de datos muy grandes, los dispositivos físicos de transferencia pueden trasladar el grueso inicial de los datos cuando la transferencia por red no es práctica.

Revisa las dependencias antes de ordenar los traslados. Una aplicación que aún necesita una base de datos local puede requerir una conexión o una migración coordinada. El realojamiento puede ser un primer paso seguido de optimización; una cartera útil puede incluir retirada, conservación, sustitución y rediseño.