DevOps resolvió cómo pasar código a producción con calidad y velocidad. Pero en machine learning no solo cambia el código: cambian los datos y, cuando cambian los datos, cambian las predicciones. 

Ahí aparece MLOps, que aplica disciplina y automatización a todo el ciclo de datos + features + modelos para que el ML funcione de verdad en producción.

DevOps son las prácticas para que desarrollo y operaciones entreguen software de forma continua, con automatización (CI/CD), pruebas y observabilidad.

MLOps lleva esas ideas al machine learning. Además del código, gestiona datos, experimentos y modelos, con piezas como registro de modelos, entrenamiento continuo y monitorización del modelo y de los datos en producción.

En qué se parecen y en qué difieren

Ambas disciplinas buscan estabilidad y rapidez, pero MLOps añade piezas porque el modelo depende de datos que cambian con el tiempo.

La idea clave es que DevOps hace fiable el código hoy y MLOps mantiene fiable código + datos + modelo a lo largo del tiempo.

Cómo MLOps está cambiando el sector gracias a la IA

La IA se ha metido en productos y procesos de negocio. MLOps es el puente que lo hace posible a escala. Lleva modelos a producción, los mantiene sanos y convierte datos en valor continuo:

• De proyectos a productos vivos
  Antes había pilotos que morían tras la demo. Ahora hay modelos con ciclos de vida claros, SLOs y runbooks, que se actualizan solos (CT) cuando cambian los datos.
• Time-to-value mucho menor
  Pipelines y “plantillas” reducen meses a semanas. Los equipos lanzan canaries rápidos, miden impacto online y promueven modelos con evidencia, no con intuición.
• Datos como activo de producto
  Con feature stores, linaje y tests de calidad, las features se comparten entre equipos. Resultado: menos duplicidad, menos bugs y aprendizaje cruzado real.
• Coste y rendimiento bajo control
  MLOps añade autoscaling, elección batch/tiempo real y métricas de coste por predicción y coste de reentrenar. La IA deja de ser “caja negra cara” y pasa a ser predecible.
• Observabilidad de modelos (no solo de apps)
  Además de logs y latencia, se vigilan calidad de datos, drift y métricas del modelo (F1, AUC, MAE). Cuando el modelo se degrada, salta una alerta y se activa el reentrenamiento.
• Gobernanza y confianza
  Linaje, explicabilidad y auditoría permiten cumplir normativas y políticas internas. Decisiones sensibles (crédito, salud, precios) se explican y trazan.
• LLMOps: IA generativa con reglas
  Para GPT-like/LLMs, MLOps evoluciona: versionado de prompts, evaluación automática (calidad factual/toxicidad), RAG con control de fuentes y métricas de tokens, latencia y coste. Menos alucinaciones, más robustez.
• Casos con impacto directo (ejemplos típicos)
  Predicción de demanda y precios dinámicos, detección de fraude en tiempo real, mantenimiento predictivo, búsqueda/soporte con IA generativa, recomendadores y next-best-action.

Qué cambia en la práctica con MLOps

1. De “experimento” a “producto”: un owner, SLOs y métricas online.
2. Plantillas y pipelines: ingesta → features → entrenamiento → evaluación → despliegue → monitorización.
3. Medir y aprender: dashboards de negocio + modelo; reentrenos automáticos con aprobación.
4. Seguridad/ética integradas: control de accesos, privacidad, explicabilidad y sesgos monitorizados.

La IA crea valor cuando se opera. MLOps es esa operación: convierte modelos en capacidad repetible, con costes y riesgos controlados.

Componentes principales de MLOps

Este es el “kit” básico. No necesitas todo desde el día uno, pero conocer cada pieza te ahorra problemas después.

1. Ingesta y calidad de datos

Este bloque trae los datos desde sus fuentes y comprueba que tengan formato, rangos y reglas correctas. Si entran columnas nuevas o valores extraños, el modelo puede fallar sin avisar; por eso los tests de datos son tan importantes como los tests de código.

2. Feature engineering y feature store

Las features son las variables que usan los modelos. Un feature store guarda su definición y versiones para entrenamiento y producción. Así evitas el clásico error de “calcular una cosa en el notebook y otra diferente en el servicio”.

3. Seguimiento de experimentos (experiment tracking)

Cada entrenamiento produce métricas y artefactos. Registrar hiperparámetros, datasets y resultados permite comparar, repetir y justificar por qué elegiste “el modelo B” y no “el A”.

4. Registro de modelos (model registry)

Es el catálogo donde viven los modelos con sus versiones y estados (dev, staging, prod). Facilita promociones controladas, rollback rápido y auditoría de qué versión generó cada predicción.

5. Orquestación de pipelines

Automatiza la cadena datos → features → entrenamiento → evaluación → registro → despliegue. Un orquestador convierte pasos manuales en un proceso repetible, con reintentos y visibilidad de cada tarea.

6. CI/CD/CT

• CI comprueba el código y también puede validar esquemas de datos.
• CD despliega servicios y modelos con seguridad (blue-green/canary).
• CT reentrena cuando toca: por calendario o porque la calidad online cayó por debajo de un umbral.

7. Serving: cómo sirves predicciones

Hay tres modos principales: batch (jobs programados), tiempo real (API con autoscaling) y streaming (eventos). Lo crítico es mantener paridad de features entre entrenamiento y producción para no degradar el modelo por diferencias de cálculo.

8. Evaluación offline y online

Primero validas offline con conjuntos de prueba y checks de sesgo. Luego mides online con A/B o canary: así confirmas que el modelo nuevo mejora de verdad en tu entorno real.

9. Monitorización de modelo, datos y sistema

Además de logs y latencia, vigila calidad de datos, drift (cuando cambian las distribuciones) y métricas del modelo como precisión o MAE. Define umbrales y alertas con planes de acción para reaccionar a tiempo.

10. Gobernanza y cumplimiento

Incluye linaje (qué datos y qué versión de modelo generaron una predicción), explicabilidad para decisiones sensibles y controles de seguridad y privacidad. Esto no es adorno: reduce riesgos legales y operativos.

El ciclo de vida de un sistema de ML

Ver el proceso completo ayuda a priorizar. El flujo típico es el siguiente:

1. Define el objetivo de negocio y las métricas que importan.
2. Ingiere y valida los datos de entrada.
3. Crea y versiona features en un feature store.
4. Entrena y registra tus experimentos con sus resultados.
5. Promueve el mejor modelo en el registry.
6. Despliega con canary o shadow para reducir riesgos.
7. Monitoriza datos, modelo y sistema con alertas.
8. Reentrena (CT) si la calidad cae o llegan datos nuevos relevantes.

Arquitectura de referencia

Piensa en capas para no mezclar responsabilidades: 

• Una capa de datos con calidad y catálogo. 
• Una capa de features común para train y serve.
• Pipelines orquestados. 
• Tracking/registry para saber qué funciona. 
• Serving en batch o tiempo real. 
• Observabilidad que ve app + modelo + datos. 
• Gobernanza para auditar y explicar.

Herramientas por categoría 

No se trata de tener “la herramienta de moda”, sino de cubrir bien cada categoría y que todo integre fácil:

• Tracking/registry: MLflow, Weights & Biases, registries gestionados en nube.
• Orquestación: Airflow, Prefect, Dagster, Kubeflow.
• Feature store: Feast u opciones cloud (Vertex/Databricks/Tecton).
• Serving: KServe/Seldon, BentoML o endpoints gestionados.
• Monitoring de ML: Evidently, Arize, Fiddler, WhyLabs.
• Data quality: Great Expectations, Deequ.
• Base DevOps: Git, CI/CD (GitHub/GitLab/Jenkins), contenedores, Kubernetes y observabilidad clásica.

Métricas relevantes

Medir es lo que convierte un proyecto bonito en un sistema fiable. Sigue time-to-value (idea → primer canary), calidad online vs offline, tasa de drift y tiempo de reacción, coste por predicción y por reentrenamiento, además de SLOs (latencia, disponibilidad) y auditabilidad de predicciones.

Errores comunes y cómo evitarlos

• Todo en un notebook → añade tracking + registry + CI desde el inicio.
• Features distintas en train/serve → usa feature store y tests de paridad.
• Desplegar sin monitorizar → define métricas online y alertas obligatorias.
• Reentrenos sin control → aplica CT con aprobaciones y rollback.
• Lock-in prematuro → usa patrones portables y un plan de salida.

Ejemplo práctico 

Supón que detectas fraude en pagos: entrenas con 12 meses de datos, registras experimentos y promueves el mejor modelo. Despliegas una API con canary al 10% y monitorizas precision/recall, latencia y drift en variables clave (importe, país, dispositivo). 

Si la calidad baja, el CT reentrena con los últimos 30 días, valida offline, promueve a staging y vuelve a canary. Todo queda trazado con linaje, para saber qué datos y qué modelo generaron cada decisión.

Glosario rápido

• CT (Continuous Training): reentrenar modelos de forma automática y controlada.
• Drift: cambio en los datos o en su relación con la etiqueta que degrada el modelo.
• Model registry: catálogo de versiones de modelos con estados y metadatos.
• Feature store: capa común para definir, versionar y servir features coherentes.
• Canary/shadow: probar un modelo nuevo con poco tráfico o en paralelo, reduciendo riesgos.

La gran diferencia es simple

DevOps asegura el software; MLOps asegura el software + el modelo + los datos mientras todo cambia. 

Empieza por cubrir lo básico (tracking, registry, CI/CD, monitorización y paridad de features) y ve sumando piezas cuando el valor ya sea visible. Así pasas de prototipos brillantes a impacto sostenido en producción. 

¿Quieres saber más? Contacta con nuestro equipo de expertos.

La entrada Qué es MLOps y en qué se diferencia de DevOps se publicó primero en Geko Cloud.

¿Qué es el AWS Well-Architected Framework?

AWS Well-Architected Framework es una herramienta para evaluar y mejorar las arquitecturas de la nube. Se basa en seis pilares: excelencia operativa, seguridad, fiabilidad, eficiencia en el desempeño, optimización de costes y sostenibilidad. El marco proporciona las mejores prácticas y pautas para diseñar y operar entornos seguros, eficientes y rentables en la nube de AWS.

¿Cómo migrar a AWS?

Los desafíos de migrar a la nube de AWS varían desde detalles técnicos hasta requisitos regulatorios. El marco de buena arquitectura de AWS permite identificar obstáculos de forma temprana y abordarlos de manera eficaz. Más allá de una simple tarea técnica, el uso de la nube se considera no solo como una tarea técnica, sino también como parte de la estrategia corporativa. 

Por esta razón, las organizaciones que adoptan una visión holística de la implementación y operación de sus servicios en la nube están mejor posicionadas para afrontar con éxito tanto los desafíos inmediatos como los objetivos comerciales a largo plazo.

Los seis pilares de un marco de buena arquitectura AWS  

El AWS Well-Architected Framework se estructura en seis pilares centrales, cada uno de los cuales aborda aspectos específicos de la arquitectura en la nube. Gracias a esta división, las empresas pueden crear un entorno robusto y eficiente.

• Excelencia operativa: apoyar y optimizar las operaciones para lograr mejores procesos de negocio a través de la automatización y flujos de trabajo optimizados.
• Seguridad: garantizar la protección de los datos y sistemas, con especial atención a la evaluación de riesgos, la integridad de los datos, la confidencialidad y la disponibilidad.
• Fiabilidad: sistemas robustos que permanecen estables incluso ante eventos inesperados y pueden recuperarse rápidamente.
• Eficiencia en el rendimiento: seleccionar los recursos y tecnologías adecuados y adaptar el rendimiento del sistema a los requisitos cambiantes.
• Optimización de costes: controlar el consumo de recursos y los costes para garantizar que las inversiones creen valor.
• Sostenibilidad: minimizar el impacto ambiental de las cargas de trabajo en la nube, reduciendo el consumo de energía y las emisiones de carbono.

Al aplicar estos principios, AWS Well-Architected Framework ayuda a las organizaciones a crear un entorno de nube de última generación.

¿Cómo debe ser el marco de buena arquitectura de AWS? 

El marco de buena arquitectura de AWS y el modelo de responsabilidad compartida son dos caras de la misma moneda. Mientras que el primero proporciona los principios y mejores prácticas para diseñar y operar una arquitectura de nube eficiente, el segundo define claramente las responsabilidades de AWS y sus clientes. 

Responsabilidad de AWS:

• Seguridad física de los centros de datos.
• Integridad de los dispositivos de red.
• Fiabilidad del hardware del host.
• Seguridad de la infraestructura global que respalda la disponibilidad de los servicios de AWS.

Responsabilidad del cliente:

• Implementación de la gestión del control de acceso.
• Cifrado de datos.
• Funcionamiento seguro de las aplicaciones.
• Gestión eficaz de parches y configuraciones de sistemas operativos y aplicaciones.

Si se malinterpreta el modelo de responsabilidad compartida, pueden generarse brechas en el cumplimiento y la seguridad. Por el contrario, los clientes que implementan este enfoque reducen los riesgos y logran un alto nivel de seguridad. 

El marco Well-Architected complementa este modelo proporcionando pautas claramente definidas para diseñar las tareas del cliente.

El marco Well-Architected para optimizar el rendimiento, la seguridad y los costes

El AWS Well-Architected Framework ha demostrado su eficacia para muchas empresas. Es el punto de partida para conceptos de seguridad mejorados y permite un importante ahorro de costes. Los siguientes ejemplos muestran cómo las empresas optimizan su infraestructura en la nube utilizando el marco.

Ejemplos de excelencia operacional:

• Las empresas pueden implementar pruebas de carga automatizadas para verificar el rendimiento de su arquitectura de nube en diferentes escenarios. Esto ayuda a identificar cuellos de botella de forma temprana y optimizar toda la infraestructura para lograr un rendimiento óptimo bajo alta carga.
• Al establecer KPI detallados, las empresas pueden monitorear continuamente el rendimiento de su arquitectura en la nube. Analizar estos datos ayuda a identificar tendencias y realizar optimizaciones proactivas para mejorar continuamente la eficiencia.

Ejemplos de mejoras de seguridad:

• La automatización de pruebas garantiza el cumplimiento de las políticas de seguridad. Los scripts proporcionados por el marco comprueban automáticamente las configuraciones durante las actualizaciones. Las vulnerabilidades se identifican y resuelven rápidamente antes de que lleguen a producción.
• Las pruebas de penetración ayudan a las empresas a evaluar la seguridad de su nube. Las pruebas identifican riesgos de seguridad ocultos a través de ataques simulados. De esta forma se mejoran continuamente los mecanismos de protección para hacer frente a las ciberamenazas.

Ejemplos de ahorro de costes:

• Dirigir la asignación de recursos a áreas críticas para el negocio aumenta la eficiencia de los costos operativos y mejora el ROI (retorno de la inversión).
• Las directrices marco para la gestión de recursos permiten a las empresas hacer un uso óptimo de sus recursos. Al escalar hacia arriba o hacia abajo según la carga de trabajo, se pueden optimizar los costos y gestionar los picos de carga.

Los escenarios ilustran cómo el  Well-Architected Framework ayuda a desarrollar enfoques personalizados que se adaptan a las necesidades específicas de las empresas.

Los partners de AWS como clave del éxito

Al adoptar el AWS Well-Architected Framework, existen obstáculos que pueden obstaculizar el progreso. A pesar de los beneficios del AWS Well-Architected Framework, las empresas pueden enfrentar obstáculos que dificultan su implementación. Por ello, colaborar con un partner de AWS resulta clave para maximizar su aprovechamiento. Además, esto les permite acceder a conocimientos especializados y una serie de otras ventajas:

• Conocimiento experto profundo: los partners de AWS tienen un conocimiento integral de los servicios y arquitecturas de AWS. Están familiarizados con los últimos avances y le ayudarán a crear un entorno de nube preparado para el futuro.
• Estrategias de implementación a medida: la implementación no es una solución única para todos, sino que requiere un enfoque individual. Los partners de AWS comprenden los desafíos específicos de cada negocio y ofrecen estrategias personalizadas.
• Acceso a los recursos de AWS: los partners de AWS tienen acceso privilegiado a sus recursos, herramientas y opciones de soporte. Esto abarca desde soporte técnico hasta materiales de capacitación y documentación de mejores prácticas.
• Aumenta la eficiencia y reduce los costes: con sus muchos años de experiencia en proyectos, los partners de AWS pueden ayudar a aumentar el rendimiento del entorno. Ayudan a identificar y eliminar costos innecesarios.
• Mitigación de riesgos: los partners de AWS están familiarizados con los errores comunes al implementar el marco. Ayudan a identificar problemas antes de que tengan un impacto en el negocio.

Como partners de AWS desde hace tiempo, Claranet y Geko combinamos experiencia y conocimientos en tecnologías de la nube con un profundo entendimiento del ecosistema de AWS. Esto garantiza una optimización eficiente del entorno y una migración sin problemas a la infraestructura existente.

¿Quieres aprovechar al máximo las oportunidades del AWS Well-Architected Framework? Contacta con nuestro equipo de expertos. 

La entrada Cómo migrar a la nube con AWS Well-Architected Framework se publicó primero en Geko Cloud.

Introducción a SSM

SSM son las siglas de Systems Manager, un conjunto de herramientas que nos facilitan la vida, no sólo para acceder a las máquinas a través de una consola virtual, sino también para la ejecución de comandos remotos, extraer registros de los equipos, y como no, aplicar actualizaciones.

Con la suite de programas de SSM se pueden actualizar no sólo instancias EC2, si no también equipos on-prem, así como máquinas virtuales, equipos on-the-edge (IoT) como raspberrys, etc.

Systems Manager es un servicio que ejecuta un agente en el propio equipo (ec2 / on-prem, etc), del mismo modo que los agentes virtuales en entornos VMware, usados para extraer métricas de las instancias, pero en el caso de SSM la consola de gestión es remota, o lo que es lo mismo, se encuentra dividida en diferentes end-points. Es por ello por lo que el agente debe comunicarse con el servicio de SSM a través de red. Los equipos que quieran ser gestionados, deberán tener no sólo el agente instalado sino también conectividad de red para llegar a los endpoints de AWS SSM.

En este artículo hemos usado un par de instancias EC2 , una Linux y otra Windows:

Para la Linux hemos usado una AMI de RedHat, y en el caso del equipo Windows, se trata de la versión 2019.

Novedades de AWS Systems Manager (SSM) y Patch Manager 2024

AWS ha lanzado nuevas actualizaciones que mejoran la automatización y escalabilidad de SSM, haciendo que el parcheado en entornos multi-cloud y on-premise sea aún más eficiente. Entre las novedades destacan:

• Optimizaciones en tiempos de parcheado: Se ha mejorado la velocidad de instalación y actualización de parches, lo que reduce significativamente las ventanas de mantenimiento.
• Compatibilidad ampliada: AWS Systems Manager ahora soporta un mayor número de sistemas operativos, permitiendo gestionar más entornos desde una sola interfaz.
• Actualización automática de agentes: Una nueva funcionalidad permite actualizar el agente SSM de manera automática, garantizando que las máquinas gestionadas siempre operen con la versión más segura y eficiente del software.

Role para SSM

Para que el equipo pueda comunicarse con SSM, es necesario disponer de un role. Por ello vamos a generar un “service role” nuevo, accediendo al apartado IAM y seleccionado la opción “Roles” y clicando en el botón “Create role”:

Seleccionamos como “Trusted entity” el “AWS Service”, y abajo en el apartado “Use case”, el servicio EC2. Seleccionamos siguiente y añadimos las políticas que son necesarias:

Para ello introducir en la casilla de búsqueda el nombre “ssm”, y escoger entre las opciones que aparecen la “AmazonSSMManagedInstanceCore”

Asignamos el nombre que deseemos y nos aseguramos de que en el apartado de “trusted entities”, el valor de “principal” seleccionado es el servicio “ec2.amazonaws.com”, servicio con el que se va a invocar este role y al que estamos dando permiso:

El siguiente paso será añadir este role a las instancias. El modo más sencillo será marcar desde el panel la instancia a modificar, tal como se muestra en la imagen.

En el desplegable asignarle el role que acabamos de crear.

Nuevas amenazas de seguridad y la importancia del parcheado

En 2023, una serie de vulnerabilidades críticas, como la CVE-2023-30799, demostraron cómo los ataques a sistemas desactualizados pueden comprometer rápidamente la seguridad de las empresas. Esto subraya la importancia de mantener todos los equipos parcheados para mitigar riesgos. Los ciberataques que explotan vulnerabilidades en sistemas operativos, software empresarial y aplicaciones no solo generan pérdidas económicas, sino también daño a la reputación de la empresa.

La gestión de parches se convierte en una primera línea de defensa. Tener un sistema centralizado como AWS Patch Manager garantiza que no se pasen por alto actualizaciones críticas, eliminando puntos débiles.

Mejores prácticas en el parcheado de equipos

Hoy en día, la automatización inteligente y el uso de herramientas basadas en inteligencia artificial son tendencias clave en la gestión de parches. Algunas de las mejores prácticas incluyen:

• Priorizar parches con IA: Herramientas basadas en inteligencia artificial pueden analizar vulnerabilidades y recomendar qué parches son más urgentes, reduciendo la sobrecarga operativa y minimizando el riesgo de ataques.
• Simulación de vulnerabilidades: Realizar simulaciones para entender cómo una vulnerabilidad podría impactar a la organización permite priorizar la aplicación de parches. Las organizaciones pueden usar estas simulaciones para ajustar sus cronogramas de parcheado, asegurándose de que los sistemas críticos están protegidos primero.
• Pruebas en entornos de desarrollo: La implementación de canary testing es ahora más común. Con esta técnica, los parches se aplican primero en entornos de prueba antes de su implementación en producción, reduciendo el riesgo de interrumpir servicios críticos.

Automatización de la aprobación de parches: Para evitar el impacto negativo de parches no probados, se puede configurar la aprobación automática escalonada, donde los parches se aprueban para ciertos entornos (como desarrollo o pruebas) antes de ser aplicados en producción.

Instancias EC2 / managed nodes

En nuestro caso, hemos desplegado un equipo RedHat para la variedad Linux por un motivo: las AMI oficiales distribuidas por RedHat no llevan incorporado el agente, mientras que las AMI de Windows distribuidas por Microsoft o las AMI de Amazon Linux sí lo tienen.

La nueva funcionalidad de actualización automática de agentes permite que los equipos gestionados siempre cuenten con la última versión del agente SSM, lo cual mejora la eficiencia del parcheado y la seguridad de los nodos.

En caso de que nuestra distribución no tenga el agente, se puede instalar manualmente. Puedes revisar el siguiente enlace para ver qué distribuciones están soportadas:

Manual de instalación del agente SSM

Fleet Manager

Ahora que ya tenemos los equipos con el agente de SSM instalado y con el “service role” asociado, podríamos acceder al apartado de “fleet manager”, lugar donde se visualiza a modo de registro los equipos gestionados con SSM, tanto equipos EC2, como equipos on-prem, etc. Esta herramienta está dentro de las opciones de SSM:

Los equipos gestionados a través de SSM, reciben el nombre de nodos, es por ello por lo que, en la vista de este servicio, los equipos registrados se identifican en la columna de “Node Id”:

Los equipos que aparecen son los que están registrados en la región actual. Tener en cuenta que AWS SSM es un servicio regional, eso quiere decir que si tenemos una cuenta en varias regiones, será necesario repetir el proceso descrito en este artículo para cada región de manera independiente.

Como todo software, el agente de SSM recibe constantes mejoras. Es por ello recomendable habilitar en el apartado “settings”, la actualización automática:

Impacto en cumplimiento normativo

El parcheado constante también es fundamental para cumplir con normativas de seguridad como GDPR y las nuevas regulaciones de protección de datos. Empresas de todo el mundo deben asegurarse de que sus sistemas estén protegidos contra vulnerabilidades que podrían exponer información confidencial. El mantenimiento regular de sistemas y la capacidad de auditar el historial de parches aplicados se han vuelto componentes clave en auditorías de cumplimiento.

Tendencias recientes en ciberseguridad y parcheado

El enfoque Zero Trust ha ganado popularidad como estrategia de seguridad. Este modelo asume que ninguna entidad, dentro o fuera de la red corporativa, es de confianza, lo que hace que el parcheado continuo y la actualización de todos los sistemas sea aún más crucial. Con la federación de entornos multinube y la dispersión de recursos en diferentes plataformas, Patch Manager facilita la gestión centralizada de parches en un ecosistema diverso.

Baselines

Las “baselines” son manifiestos que definen un determinado nivel de cumplimiento con una política de seguridad. En el servicio de “patch manager” existen diferentes “baselines”, pero es muy recomendable crear propia una con las configuraciones que nos interese. Es un proceso realmente sencillo.

Para acceder al apartado de las “baselines”, ir a “Node Management” y seleccionar la opción “Patch Manager”:

Y en la pantalla que aparece acceder al botón “View predifined baselines”

En la vista de “baselines”, aparecen muchísimas, cada una para un sistema operativo diferente. Es en este momento cuando vamos a crear una personalizada. Para ello clicar sobre el botón “Create patch baseline”

En el nuevo apartado, seleccionar un nombre y una familia de SO que va a estar asociada a la “baseline”:

Definir la versión del SO, así como otros aspectos que definirán el nivel de cumplimiento:

Hay opciones como el “auto approval”, que permiten aprobar la instalación de una determinada actualización, al cabo de unos días de su publicación, o a partir de una determinada fecha, evitando así que parches día 0, no muy testeados, pudieran romper la estabilidad de los equipos. Incluso esto permitiría tener equipos de PRE o TEST donde instalar parches días antes que en los equipos de producción a modo de “canary testing”.

Igual de importante es el apartado de excepciones de paquetes. Con ello se evita la instalación de determinados paquetes que pueden romper el servicio (sistemas con kernels compilados a mano, paquetes Windows que no se llevan bien con algún otro programa de terceros, etc).

Para añadir excepciones debe usarse el siguiente formato:

En este momento ya tenemos una “baseline” propia. Cuando las “baselines” son propias, para encontrarlas luego, hay que especificar que el propietario somos nosotros. Para ello en el buscador de baselines, especificar “Owner: Self” tal como se muestra a continuación:

De lo contrario la vista por defecto sólo muestra “baselines” estándar provisionadas por AWS.

Patch groups

Una vez tenemos definidas las “baselines”, vamos a definir los “patch groups”. Un “patch group” establece la relación entre las “baselines” y los equipos sobre los que se van a aplicar, en función del valor de un tag que especificaremos más tarde en los equipos.

Para crear un “patch group”, es muy sencillo, sólo tenemos que seleccionar la “baseline” que acabamos de crear, desplegamos el menú “Actions” y seleccionamos la opción “Modify patch groups”

Se abrirá un apartado para generar los patch groups, introduciendo un nombre. En nuestro caso “Windows_Production”

Una vez introducido el nombre, fijándonos en respetar la nomenclatura, clicamos en el botón “Add” y cerramos el asistente.

Tags

Los tags son metadatos que nos ayudan a identificar a quien pertenece un recurso, una unidad de imputación de costes, etc. En este caso, con los tags también podemos asociar los nodos a los “patch groups” correspondientes. Para ello se usa siempre el mismo valor de tag “Patch Group”. Ojo! Es “case sensitive”

Vamos al apartado de las instancias, seleccionamos una de ellas, y editamos el apartado de tags para añadir el de “Patch Group”:

Si al introducir el tag, nos encontráramos con un error de tipo “’Patch Group’ is not a valid tag key.”

Es necesario deshabilitar la check box de metadata tagging en la configuración de la instancia:

Dejar la casilla siguiente deseleccionada y volver a probar a añadir el tag en el equipo.

Maintainance Windows

Recapitulemos. En este momento ya tenemos la instancia con el agente de SSM instalado y el role para interactuar con el servicio. Hemos creado una “baseline” propia, y luego la hemos asignado a unos “patch groups”. Finalmente hemos “tageado” las instancias con un tag que apunta directamente al “pach group” que nos interesa.

Las ventanas de mantenimiento son un apartado importante porque no sólo contiene la calendarización de las actualizaciones, sino también el listado de ejecuciones.

Vamos a proceder creando una ventana de mantenimiento a través del siguiente apartado:

Debemos introducir el nombre para la ventana, y fijar el cron. Se pueden establecer expresiones de cron con la nomenclatura típica o bien seleccionando las preestablecidas de cada hora o cada día.

Los valores de “Duration” y “Stop initiating task”, son obligatorios, y es recomendable dejarlos con unos valores como los siguientes:

Finalmente escoger zona horaria para hacer coincidir los horarios de la ventana con la que nos interese.

Al terminar tendremos un listado de las ventanas programadas, y datos interesantes como su próxima ejecución:

Configuración del parcheado

En este momento vamos a realizar el proceso que aglutina todos los pasos anteriores, y que capacita a “patch manager” para realizar las actualizaciones de los sistemas. Para ello acceder al apartado de “Patch Manager” y clicar en “Configure Patching”

Escoger los “patch groups” que se quieran actualizar:

Escoger la ventana de mantenimiento que se ha creado en el paso anterior:

Y dejar la operación que más se ajuste a lo que queremos hacer. En este caso vamos a escoger “Scan and Install”

En este momento, en el “dashboard” de de “Patch Manager”, deberíamos tener una vista de equipos pendientes de actualizar. Los valores en este apartado irán cambiando en función de si hay paquetes pendientes, fallos en las actualizaciones, etc.

Para poder realizar un seguimiento de las acciones realizadas, las podemos consultar en el “Run Command”

En este apartado hay dos pestañas. Una con los comandos en ejecución en este momento, que saldrán con un reloj al lado:

Y otra pestaña con el histórico de acciones:

Si en el proceso de instalación de actualizaciones, hay algún paquete marcado como reinicio necesario, el equipo se reiniciará inmediatamente. Tener esto en cuenta para establecer las ventanas de acuerdo con las necesidades del negocio:

Tras la instalación de los parches, y los reinicios en caso de haberlos, en el “dashboard” de “Patch Manager” saldrán ahora las instancias como conformes de acuerdo a las “baselines” establecidas:

Cloudwatch

En la consola del histórico de comandos, podemos ver las tareas ejecutadas, como en este caso. Si clicamos sobre el id de la tarea, podemos acceder a su detalle:

Dentro podemos ver los equipos sobre los que se ha ejecutado la acción, y podemos , seleccionando uno de esos equipos, ver el detalle de las operaciones. Para ello seleccionar y clicar sobre el botón “View output”

Las operaciones van probando todas las plataformas, por ello primero intentarán ejecutar el parcheado sobre un Windows, luego sobre un Linux y finalmente sobre un MacOS. Por ello para ver el estado de las actualizaciones, escogemos la plataforma del equipo que estamos consultando.

En la ventana “Output” veremos el registro, pero a menudo este se trunca por ser excesivamente largo:

Si queremos consultar esos datos podemos enviarlo a un “log group” de Cloudwatch. Para ello, primero vamos a CloudWatch y creamos un “log group”:

Ponemos un nombre y especificamos el periodo de retención.

El segundo paso es modificar el role de la máquina para que tenga permisos para escribir en Cloudwatch, por ello habrá que añadir una “in-line policy” como esta:

Le ponemos un nombre a esta “policy” y la guardamos:

Quedando el role del equipo como:

Volvemos a system manager, apartado “Mantainance Window”  y dentro de las tareas (marco la tarea y selecciono edit):

Y en el apartado “Output Options” , escribir el nombre del log group a donde lo vamos a enviar:

Guardamos los cambios, y a partir de ahora al seleccionar el output de las tareas, veremos que nos aparece un enlace hacia Cloudwatch:

Y si consultamos ese enlace, nos llevará a la información de salida, pero ya sin truncar:

Con las mejoras recientes de AWS Systems Manager y Patch Manager, la gestión de parches se ha vuelto más eficaz, abarcando más sistemas operativos y mejorando la seguridad a través de la actualización automática de agentes. Estas mejoras, combinadas con buenas prácticas y la automatización, permiten a las organizaciones mitigar riesgos de seguridad y cumplir con las normativas más estrictas, garantizando la continuidad de sus operaciones. 

¿Quieres saber más? Contacta con nuestro equipo

La entrada Parcheado de equipos con Patch Manager se publicó primero en Geko Cloud.

• 6 formas de modernizar las apps en AWS para hacerlas más sostenibles
• Migración de infraestructura a AWS: recompra, replatforming y refactorización

El vínculo entre modernización y sostenibilidad

Si quieres hacer que tu entorno informático sea más sostenible, probablemente empieces por pensar en cómo alimentar tu tecnología, mantenerla refrigerada, etc. 

Básicamente, se trata de accionar palancas a nivel de hardware que te ayuden a consumir menos energía o a utilizar esa energía de forma más eficiente. 

Sin embargo, existen otras palancas que puedes utilizar a nivel de software y plataformas, que optimizan aún más tu consumo de energía. Las aplicaciones y plataformas modernas, nativas de la nube, están diseñadas para utilizar los recursos sólo cuando es necesario -incluso para la infraestructura de aplicaciones que tradicionalmente está siempre encendida, como la recuperación de desastres- sin dejar de ofrecer la misma calidad de experiencia al usuario final. Al utilizar los recursos de forma más eficiente, se reduce aún más el consumo de energía y el hardware necesario y, por tanto, la huella de carbono.

¿Por qué AWS?

Si ya dispones de una nube privada, puedes intentar modernizarla tú mismo. Sin embargo, los proveedores de public cloud como AWS pueden ayudarte a modernizar y hacer más sostenible tu entorno de forma más rápida, eficaz y, probablemente, más barata. Esto se debe a lo siguiente: 

• Migrar a AWS significa adoptar un modelo de infraestructura como servicio (IaaS). Esto significa que muchas de las modernizaciones que podrías planificar (y presupuestar) para tu centro de datos privado ya han sido implementadas por AWS: obtendrás todos los beneficios, sin la inversión en una nube privada para que rinda al mismo nivel.

• AWS puede escalar tus operaciones de maneras que quizás sean demasiado complicadas para ti. Por su tamaño puede acceder a economías de escala en lo que se refiere a refrigeración, bienes inmuebles y consumo de energía que permiten a AWS gestionar sus centros de datos de forma increíblemente eficiente.

• Como AWS existe para prestar servicios en la nube a sus clientes, se centra en innovar para reducir su consumo de energía y ser así más sostenible. Por ejemplo, ha diseñado un nuevo chip, el Graviton3, que puede reducir el consumo de energía hasta en un 60%, y ha creado un nuevo medio de refrigeración que reduce el consumo de energía de refrigeración en un 20%.

Últimamente, AWS ha dado grandes pasos para garantizar que sus centros de datos sean lo más sostenibles posible. Se ha comprometido a reducir a cero las emisiones de carbono para 2040 y a alimentar sus operaciones con energías 100% renovables para 2025. Un proyecto reciente ha convertido a AWS en el mayor comprador corporativo de energía renovable del mundo, y también ha anunciado un nuevo centro de datos en Nueva Zelanda que funcionará con energía 100% renovable.

Empieza tu viaje hacia una infraestructura sostenible en la nube

Paso 1: Determina tu estado actual

El primer paso en cualquier transformación hacia la sostenibilidad es conocer la huella de carbono actual de tu infraestructura informática. Hay muchos puntos a tener en cuenta a la hora de calcularla:

• ¿Cuánto hardware incluye exactamente tu patrimonio?
• ¿Dónde están todos tus servidores? Asegúrate de examinar a fondo toda tu organización para descubrir cualquier TI en la sombra.
• ¿Cuánta energía utilizas para mantener tu parque en funcionamiento? Esto incluye el funcionamiento de los servidores del centro de datos, pero también la energía utilizada para refrigerar los equipos, iluminar las salas de servidores, etc.
• ¿Qué proporción de esa energía se genera a partir de fuentes sostenibles?
• ¿Cuánta electricidad renovable compras?

Más allá de estos parámetros relativamente obvios, hay otros factores que se suman a la huella de carbono:

• Si tienes un centro de datos en una instalación específica, ¿cuál es el nivel de carbono incorporado en el edificio?
• El carbono incorporado es material que genera emisiones durante su fabricación y que puede reutilizarse, como el vidrio, el acero y el ladrillo.
• Si tienes personal dedicado a gestionar tu centro de datos, ¿va en coche al trabajo? ¿Qué emisiones genera?

Por supuesto, junto con la recopilación de esta información también es prudente reunir información sobre los costes de funcionamiento de tu parque informático. En un escenario ideal, pasar a la nube y hacer que tu parque sea más sostenible también supondrá un ahorro de costes, lo que será vital a la hora de justificar la migración a la empresa.

Paso 2: Elabora el plan

Una vez que conozcas tu estado actual, puedes empezar a pensar en la transición. Empieza por priorizar tus aplicaciones para la migración. Puede que desees priorizar, por criticidad empresarial o por consumo de energía, para reducir rápidamente tu huella de carbono.

Es importante empezar a pensar en cómo será la migración de cada aplicación, porque hay distintas opciones. Por ejemplo, puedes trasladar una aplicación a AWS, lo que se conoce como realojamiento. O bien, puedes optar por descartar tu aplicación actual y pagar por una nueva aplicación, lo que se conoce como recompra. También puedes reconstruir tu aplicación para aprovechar las características nativas de la nube, lo que llamamos refactorización. 

Además de esto, empieza a analizar las competencias de tu organización. Por ejemplo, ¿tienes ya alguien con experiencia en AWS que pueda ayudarte a migrar y, posteriormente, a gestionar tu nueva infraestructura? Lo ideal es que tenga experiencia en algunas tecnologías específicas, como Apps2Container, Elastic Compute Cloud (EC2), Elastic Container Service y Fargate. Si no dispones de estos recursos en tu empresa, es muy probable que debas invertir en formación o recurrir a un socio de confianza que pueda aportar estos conocimientos a tu migración.

Por último, en esta fase debes proyectar las mejoras que esperas obtener de la migración, tanto en términos de huella de carbono como de rendimiento.

Esta información, combinada con la imagen de tu estado actual, te dará los fundamentos de tu business case. Este documento dará a tu proyecto de migración un plan y unos objetivos claros, y también ayudará a las partes interesadas a entender los beneficios que obtendrás, lo que facilitará que se adhieran al plan.

¿Cómo sería esto en la vida real?

Todo esto suena muy bien, pero… ¿cuál es la realidad? Para que no te parezca una idea descabellada, te presentamos a Charlie Loud Migrations Ltd. (CLM): 

CLM es una empresa ficticia especializada en seguir e informar sobre las pautas migratorias de los animales con fines de conservación y desarrollo. Charlie Loud, director de tecnología y fundador de CLM, sabe que la empresa necesita crear una infraestructura más sostenible. Por un lado, la sostenibilidad es muy importante para los grupos conservacionistas y las organizaciones del sector público que constituyen la mayor parte de sus clientes. 

Por otro lado, a medida que CLM ha ido creciendo para hacer un seguimiento de cada vez más animales, aprovechando la tecnología IoT y otras innovaciones, su parque informático se ha ido extendiendo y Charlie sabe que el equipo podría gestionar las cosas de forma más eficiente desde una perspectiva operativa y ecológica.

CLM decide desde el principio que necesitará apoyo en esta tarea. Por ello, designa a Geko como socio de modernización y migración a la nube, y rápidamente elige a AWS como proveedor de la nube.

El primer paso del proceso es mapear la arquitectura existente. Juntos, Geko y CLM descubren un total de 75 aplicaciones independientes que se ejecutan en toda la empresa. Esto incluye 25 aplicaciones SaaS que Charlie y el equipo de TI desconocían, y la aplicación principal de la empresa, un software personalizado que les ayuda a gestionar todos los datos de los dispositivos de seguimiento que colocan en los animales y a analizarlos. La aplicación se ejecuta en un servidor heredado y, debido a su complejidad, nunca se ha actualizado. El equipo examina el consumo eléctrico de la empresa y descubre que no tiene un contrato de energía 100% renovable con un proveedor de confianza.

Con una visión completa de su infraestructura de TI, CLM puede calcular la verdadera huella de carbono de su parque informático y calcula que puede reducir su consumo de energía en un 85% si se traslada a AWS y moderniza sus aplicaciones.

CLM necesita crear un equipo directivo de expertos en la nube que le ayude a migrar, modernizar y sacar el máximo partido de su tecnología AWS. Geko y CLM ya han revisado las competencias de la empresa y han descubierto un grupo de personas con experiencia previa en AWS. Sin embargo, Charlie y el equipo saben que no tienen a nadie que esté familiarizado con la contenedorización, que saben que será vital para crear aplicaciones serverless más adelante. Geko acepta ayudar a CLM a dotar de personal a su CCoE con expertos de Geko que puedan cubrir esas carencias, para que desde el principio del proyecto Charlie y su equipo estén tomando decisiones basadas en las mejores prácticas y las últimas innovaciones tecnológicas.

Charlie y su equipo priorizan qué aplicaciones migrar primero. Eligen su sistema de portero automático como prueba de concepto para demostrar que el proceso es válido y (suponiendo que todo vaya bien) deciden dar prioridad a la aplicación personalizada que constituye el núcleo de la empresa, por dos razones: en primer lugar, para poder migrar con más éxito las distintas aplicaciones que dependen de la aplicación principal y, en segundo lugar, para poder desconectar rápidamente los servidores en los que se ejecuta actualmente, ya que son algunas de las piezas tecnológicas menos eficientes del patrimonio de CLM. Al final de este trabajo, el equipo crea un business case formal para presentarlo al consejo de administración de CLM. En él se afirma que esperan reducir el consumo de energía en un 85%, aumentar el uso de electricidad generada a partir de fuentes renovables y reducir el trabajo pesado que el equipo tiene que hacer para gestionar sus instalaciones.

¿Y ahora qué?

A lo largo de nuestra trayectoria, desde Geko hemos ayudado a organizaciones a trasladar sus aplicaciones y bases de datos a AWS para obtener un conjunto moderno de aplicaciones y herramientas, y para impulsar su agenda de sostenibilidad. 

Si quieres saber si podemos ayudarte a cumplir tus objetivos de sostenibilidad y sacar el máximo partido de sus aplicaciones mediante la migración a AWS, puedes contactar con nuestros expertos.

La entrada Diseño de una infraestructura de TI moderna y sostenible en AWS se publicó primero en Geko Cloud.

En este artículo, identificamos y explicamos algunas de las tecnologías clave que puedes aprovechar una vez que tu infraestructura esté en la nube. También compartimos un caso para ejemplificar cómo funciona este proceso en la práctica.

¿Qué significa modernizar aplicaciones?

En pocas palabras, ejecutar una aplicación en AWS significa que puedes hacerlo de maneras diferentes en comparación con cómo lo harías en un servidor local, o incluso cómo lo harías en una nube privada. Con AWS, tienes acceso a nuevos servicios y tecnologías preconstruidas que puedes incorporar a sus aplicaciones, con lo que puedes conseguir:

• Más rapidez, ofreciendo a los usuarios una mejor experiencia (ya sean tus empleados, clientes o socios).
• Más resistencia a cortes u otros problemas, manteniendo tu negocio en marcha cuando antes las cosas podrían haberse detenido.
• Más eficiencia, utilizando los recursos informáticos solo cuando sea necesario.

Aunque este último punto es el que hace que la modernización de las aplicaciones sea tan importante para un plan de sostenibilidad, solo por estar en AWS ya habrás reducido tu huella de carbono; modernizando tus aplicaciones, puedes asegurarte de que no estás utilizando recursos (y por tanto energía) que no necesitas, haciendo que tus TI sea aún más sostenibles. Y, por supuesto, la reducción del consumo de energía debido a la creación de aplicaciones modernas que son más rápidas y utilizan menos recursos conllevan también una reducción de tus costes.

¿Qué opciones tienes para modernizar las aplicaciones y en qué te benefician?

Autoescalado

Esta es posiblemente la tecnología de cloud más importante y, como tal, dependiendo de cómo se hayan migrado sus aplicaciones, es probable que ya esté activada. Es la tecnología que permite a AWS aumentar o disminuir automáticamente la cantidad de recursos informáticos que utilizan sus aplicaciones en función de sus necesidades. El autoescalado garantiza que no se utilicen ni se pague por recursos que no se necesitan, por lo que es ideal para el control de costes y la sostenibilidad.

El autoescalado es adecuado para cualquier aplicación que se ejecute en la nube, ya sea en EC2, Fargate, Aurora o EKS, siempre que la aplicación se haya creado para permitir el autoescalado (si estás migrando una aplicación muy antigua o personalizada, asegúrate de comprobar esto de antemano). Además, su implementación es gratuita, por lo que no hay razón para no incluirla en el mayor número posible de aplicaciones, aunque, por supuesto, habrá que pagar por los recursos informáticos adicionales que se utilicen al escalar.

SNS y SQS

Simple Notification Service (SNS) y Simple Queue Service (SQS) son otras de las tecnologías fundamentales que impulsan muchas ventajas en las aplicaciones en la nube. SNS permite que las aplicaciones se envíen mensajes entre sí, o a personas como usuarios o clientes a través de correo electrónico, SNS o notificaciones push. Por otro lado, SQS es un servicio de colas de mensajes totalmente gestionado para esos mensajes.

SNS y SQS trabajan juntos para que las aplicaciones se comuniquen, ya sea entre sus propias aplicaciones, sus aplicaciones y la plataforma de AWS, o incluso los diferentes microservicios que componen una aplicación (monolitos o microservicios, como veremos más abajo). Sin ellas se pierde la capacidad de acoplar aplicaciones de forma fácil y flexible, que es lo que impulsa gran parte de la resiliencia, la automatización y la inteligencia en la nube.

La refactorización de una aplicación para utilizar SNS y SQS hace posibles muchas de las innovaciones y, por tanto, también aportan múltiples beneficios, como la sostenibilidad. Al igual que con todos los servicios de AWS también se puede autoescalar, lo que significa que no utiliza recursos o energía que no se necesite, al mismo tiempo que garantiza que sus aplicaciones puedan realizar su trabajo las 24 horas del día, los 7 días de la semana, y comunicarse entre sí de forma segura.

Instancias de subasta

Las instancias de subasta son esencialmente recursos informáticos sobrantes que AWS subasta a bajo precio. Es específico de las instancias EC2 de AWS, por lo que es ideal para cualquier aplicación o servicio que se ejecute en EC2, cuyo uso puntual puede ahorrar hasta un 90% del coste. En relación a la sostenibilidad, las instancias spot disminuyen su huella de carbono al utilizar recursos que ya han sido provisionados (como hacer que un lavavajillas funcione de manera más eficiente asegurándonos de que está completamente lleno antes de iniciar un ciclo).

Sin embargo, debemos tener cuidado con las instancias de subasta; se utilizan recursos sobrantes, por lo que existe el riesgo de que se apaguen o se retiren si AWS los necesita en otro lugar. Por lo tanto, no son adecuadas para actividades que requieren que los recursos estén disponibles 24 horas al día, 7 días a la semana, como el almacenamiento de datos. 

Sin embargo, el procesamiento por lotes de datos almacenados en otra instancia es un buen ejemplo de actividad adecuada para el uso de instancias de subasta, ya que el proceso puede detenerse sin perder los datos y reanudarse cuando haya otra instancia de subasta disponible.

De monolitos a microservicios

En el pasado, las aplicaciones solían construirse como monolitos, es decir, todo lo que la aplicación necesitaba para funcionar existía como una sola unidad. En cambio, en la nube se pueden crear aplicaciones que son colecciones de microservicios (básicamente, aplicaciones más pequeñas que gestionan funciones específicas de la aplicación más grande) que trabajan juntas para ofrecer la función de la aplicación al usuario final. De hecho, SQS, SNS y Lambda son ejemplos de microservicios disponibles en AWS.

Las aplicaciones de microservicios tienen el potencial de ser mucho más sostenibles que las aplicaciones monolíticas, y son mucho más modernas:

• Si quieres escalar una aplicación monolítica, tienes que escalarla entera, incluso si es solo una sección de la aplicación la que está ocupada, como una pasarela de pago. Esto es costoso y consume muchos más recursos de los necesarios. Si tu aplicación utiliza microservicios, cada uno de ellos puede ampliarse o reducirse según sea necesario, lo que te permite utilizar los recursos de forma mucho más eficiente.
• Si deseas actualizar una parte de una aplicación monolítica, debes desconectarla por completo para actualizarla. Con los microservicios, puedes actualizar componentes individuales mientras el resto de la aplicación sigue funcionando.
• Si una parte de una aplicación monolítica se rompe, toda la aplicación se cae. Si falla un microservicio, el resto de la aplicación sigue funcionando, ofreciendo a los usuarios un mejor servicio y permitiéndole hacer un mejor uso de sus recursos (ya que no está alojando una aplicación que no hace nada).

Reestructurar una aplicación de un monolito a microservicios no es tarea fácil, por lo que deberías evaluar detenidamente tu conjunto de habilidades internas y buscar un socio de confianza que te ayude. Una aplicación de RRHH sería un buen ejemplo de ello, ya que gestiona funciones como la gestión de vacaciones, nóminas, hojas de horas, etc. Todas ellas podrían desacoplarse entre sí y ser gestionadas por microservicios que se unan para hacer que la aplicación funcione. Las aplicaciones que son buenas candidatas para una arquitectura de microservicios probablemente se volvieron a hospedar en la migración inicial, lo que significa que se ejecutan en AWS pero funcionan exactamente igual que antes, o no se migraron en absoluto debido a su tamaño y complejidad.

Informática serverless (AWS Lambda)

La informática serverless es la siguiente capa de abstracción por encima de la nube. En la nube, no tienes que operar la infraestructura en la que se ejecutan sus recursos informáticos, pero debes seguir aprovisionándola, con un mayor o menor grado de automatización. En la computación serverless, ni siquiera se aprovisionan los recursos. Especificas el código que desea ejecutar y AWS aprovisiona automáticamente los recursos para ejecutar ese código como y cuando sea necesario mediante Lambda, su servicio de informática serverless.

El uso de Lambda te hace subir otro peldaño en la escalera de la sostenibilidad al ofrecer otro nivel de escalabilidad. Solo pagas por los recursos que utilizas, hasta el milisegundo, y eso significa, por supuesto, que puedes utilizar los recursos que aumentan tu huella de carbono de forma aún más eficiente. Al dar a AWS el control sobre qué recursos utiliza para ejecutar su código y cómo lo hace, la forma en que su código utiliza los recursos también puede ser más eficiente.

Lambda es ideal para actividades basadas en eventos, en las que no se ejecuta código 24 horas al día, 7 días a la semana, y por lo tanto solo se necesitan recursos listos para cuando se produzca el evento. Por ejemplo, un usuario que sube una foto a una aplicación que ejecutas, donde la subida desencadena un evento en Lambda que redimensiona automáticamente la foto para el usuario.

Revisiones bien diseñadas

AWS quiere asegurarse de que todos los usuarios de su nube la aprovechan al máximo. Para ello, ha creado el marco Well-Architected, que le permite revisar cómo están configuradas tus operaciones en la nube y qué puedes hacer para mejorarlas. Como era de esperar, la sostenibilidad es uno de los pilares de este marco, por lo que la revisión de tus operaciones utilizando el marco es una gran manera de descubrir más oportunidades para modernizar e impulsar la sostenibilidad.

Una revisión bien diseñada puede realizarse para una sola aplicación o para todo el conjunto, pero la mejor forma de llevarla a cabo es a través de un socio acreditado como Geko Cloud. Esto garantiza que el marco y su herramienta asociada se utilicen de forma óptima y, por tanto, que se les saque el máximo partido.

Caso práctico

Existen otros servicios y productos que AWS ofrece para ayudarte a modernizar tus aplicaciones: son tecnologías clave que debes tener en cuenta y que te proporcionarán beneficios con mayor rapidez. Ahora que las hemos cubierto con un poco de detalle, es hora de ver cómo funcionan en la vida real. Para ello, simularemos un caso práctico a través de la empresa ficticia Charlie Loud Migrations, una empresa que se asocia con Geko Cloud para migrar su parque informático a AWS. CLM se dedica a seguir las migraciones de animales en todo el mundo utilizando las últimas tecnologías y nos unimos a ellos ahora que entran en la fase final de su migración.

CLM ha completado su migración inicial y ya disfruta de una huella de carbono considerablemente menor una vez que ha podido desactivar la mayor parte de su arquitectura local. La modernización de sus aplicaciones no solo les proporcionará los mejores beneficios de sostenibilidad ahora, sino que también les ayudará a crecer de forma más sostenible en el futuro.

El primer punto es la aplicación central de la empresa, que gestiona todos los datos que recibe sobre los animales que rastrea y los convierte en información sobre migración. Durante la migración inicial, la aplicación se volvió a alojar en EC2, pero sin cambios en su funcionamiento. La aplicación es un monolito, por lo que el Centro de Excelencia en la Nube que CLM creó al inicio de la migración recomienda que el equipo dedique tiempo a refactorizar la aplicación para utilizar una arquitectura de microservicios. Geko Cloud realiza la mayor parte del trabajo en este proyecto, ya que es quien tiene más conocimientos técnicos, pero también participa un pequeño equipo de desarrolladores de CLM, con el objetivo de incorporar esas habilidades internamente para el futuro.

A continuación, el equipo examina la aplicación que gestiona las cargas de fotos y NFC. Una de las formas en que CLM rastrea los movimientos de los animales es proporcionando etiquetas con NFC a los grupos conservacionistas. Una vez que los animales han sido etiquetados, cuando otro grupo de conservación se encuentra con el animal, puede hacerle una foto y escanear su etiqueta NFC; estos datos se envían a CLM, junto con la ubicación del dispositivo del usuario, son procesados por la aplicación y, a continuación, se pasan a la aplicación personalizada para su análisis. Durante la migración, la aplicación se replanteó para ejecutarse con Amazon DynamoDB como repositorio de datos; ahora el equipo decide reconstruir esta aplicación para incluir AWS Lambda. En lugar de ejecutarse permanentemente en una instancia EC2, la aplicación ahora se basa en eventos, solo ejecuta código y utiliza recursos cuando se carga un nuevo conjunto de datos. Lambda se encarga del procesamiento de los datos de imagen y NFC, los envía a DynamoDB y llama a la aplicación central para comenzar el análisis de los nuevos datos.

CLM también examina su entorno de recuperación ante desastres (DR). Antes de la migración, la recuperación consistía en copias de seguridad en cinta magnética y una instancia local de Zerto para la recuperación instantánea. Durante la migración, las cintas magnéticas se copiaron en Amazon S3 Glacier mediante AWS Snowball con Tape Gateway; se decidió cambiar de Zerto a AWS Elastic Disaster Recovery (EDR). Las capacidades de DR de CLM se dejaron inicialmente como estaban en Zerto, que mantenía un entorno multisite completo que era costoso y consumía mucha energía. Ahora, el CCOE recomienda que AWS EDR se reconfigure de manera que la conmutación por error multisite solo esté disponible para la aplicación principal de la empresa; todo lo demás utiliza un sistema piloto en su lugar, lo que significa que la región en espera se mantiene en funcionamiento a una escala muy pequeña, lista para escalar rápidamente si la región principal se cae. Como resultado, la RD de CLM consume mucha menos energía sin dejar de ofrecer el nivel de servicio que necesita para mantenerse operativa.

CLM también decide alojar su sistema de nóminas y aplicaciones similares en instancias puntuales. Dado que estas aplicaciones se ejecutan con poca frecuencia y tienden a procesar lotes de datos, se adaptan bien a las instancias puntuales y permiten a CLM ahorrar una media del 70% en el coste de sus instancias EC2.

Al final del proceso, el equipo examina sus objetivos iniciales y los compara con los resultados obtenidos. El objetivo era reducir el consumo energético de su parque informático en un 85%. La migración inicial redujo el consumo de energía en un 40%; una vez finalizada la modernización de las aplicaciones, el equipo calcula que el consumo de energía de la empresa se ha reducido en un 87%. Además, las aplicaciones de CLM funcionan ahora más rápido que antes, requieren menos mantenimiento por parte del equipo informático interno y, con la nueva experiencia que han adquirido.

¿Y ahora qué?

Los proyectos de migración de este tipo son complejos y requieren conocimientos especializados para sacarles el máximo partido.

A lo largo de nuestra trayectoria, desde Geko hemos ayudado a organizaciones a trasladar sus aplicaciones y bases de datos a AWS para obtener un conjunto moderno de aplicaciones y herramientas, y para impulsar su agenda de sostenibilidad. 

Si quieres saber si podemos ayudarte a cumplir tus objetivos de sostenibilidad y sacar el máximo partido de sus aplicaciones mediante la migración a AWS, puedes contactar con nuestros expertos. 

La entrada 6 formas de modernizar las apps en AWS para hacerlas más sostenibles se publicó primero en Geko Cloud.

Los contenedores se han convertido en una tecnología imprescindible para las empresas que desean modernizar su infraestructura informática, ya que ofrecen mayor flexibilidad y portabilidad que las máquinas virtuales. Sin embargo, es importante ser consciente de ciertas ideas equivocadas, como que los contenedores son una simple secuencia «lógica» de servidor físico > servidor virtual > contenedor. En este artículo, veremos 5 de los errores más comunes que se deben evitar al configurar contenedores.

1. Pensar que un contenedor es igual a un mini VM

El primer error común es considerar que un contenedor es equivalente a una pequeña máquina virtual (VM) y que funcionará de la misma manera en cuanto a infraestructura. Los contenedores son, ante todo, procesos aislados basados en el sistema operativo subyacente, y su formato transportable mediante imágenes los hace más ligeros, flexibles y rápidos de (re)arrancar que una máquina virtual. Esto les permite mejorar la alta disponibilidad y resistencia de una aplicación en caso de fallo de un componente subyacente o por simple mantenimiento, pero más allá de los aspectos infraestructurales, también permiten replantear fundamentalmente la forma en que se despliegan las aplicaciones y posibilitan un escalado más eficiente. Como consecuencia, han relegado a un segundo plano los métodos de migración tipo P2V o “lift & shift”, que marcaron la era de la máquina virtual. 

2. Confundir la contenerización con los microservicios

El segundo error más común es confundir la contenerización con los microservicios. La contenerización es una técnica para empaquetar una aplicación y sus dependencias en una imagen y ejecutarla en un contenedor. Los microservicios son una arquitectura de software que consiste en dividir una aplicación en servicios pequeños e independientes, por lo que el formato contenedor es ideal para ello. Aunque a menudo y de forma bastante natural se asocian los dos, es importante considerarlos como dos proyectos potencialmente distintos para adoptar la mejor estrategia y evitar embarcarse sistemáticamente en métodos y herramientas específicas para microservicios. 

3. No tener en cuenta el almacenaje y la gestión de datos

El tercer error común es no tener en cuenta la gestión de datos. Los contenedores son efímeros, lo que significa que los datos escritos durante la vida del contenedor se perderán cuando se destruya, por ejemplo, cuando se reinicie. Existen soluciones de almacenamiento de datos persistentes para todo tipo de necesidades, por lo que es importante hacer balance de sus usos para elegir la solución adecuada que maximice el rendimiento, la disponibilidad y la integridad sin disparar los costes. Esto puede significar adaptar la aplicación, por ejemplo, en el caso del almacenamiento de objetos, o seleccionar la tecnología de almacenamiento adecuada, sin olvidar, por supuesto, las copias de seguridad.

4. Descuidar el flujo de trabajo de despliegue de la aplicación

El cuarto error es descuidar el flujo de trabajo de despliegue de aplicaciones y la gestión de versiones. Por un lado, no solo es necesaria la cadena CI/CD, sino que también hay que revisar el ciclo de vida del entregable (gestión de liberación de imágenes) y los manifiestos de despliegue, a menudo en forma de helm chart versionado en el caso de Kubernetes. Debemos integrar la noción de gestión de parches para estas imágenes, el mantenimiento de los gráficos, definir nuestra política de etiquetado, etc.

Durante la fase de implementación de la aplicación, el objetivo también es apuntar al esquema de drain resistant application, lo que implica una alta resiliencia, tolerancia a errores momentáneos (dependencias de servicios) y los reinicios más rápidos posibles de los distintos servicios. 

5. Centrarse en la gestión y el despliegue del orquestador

El quinto error común es centrar la mayor parte del esfuerzo en la gestión y el despliegue del orquestador, que es un trabajo de infraestructura que puede dispersarse demasiado debido a la riqueza del ecosistema. Aunque el orquestador es un elemento clave en la implementación de contenedores, es esencial no sacrificar otros temas para que la transformación tenga éxito, como el flujo de trabajo de despliegue de aplicaciones, el flujo de trabajo de construcción de imágenes, la optimización y la gestión de recursos, sin olvidar la seguridad a nivel de contenedor. Lo óptimo es centrarse en las necesidades y repartir el esfuerzo entre todos ellos. También es importante concienciar sobre el enfoque Cloud Native y ser capaz de cuestionar sus procesos y su organización para poder adaptarse.

En conclusión, la implementación de contenedores puede aportar muchos beneficios, pero es importante abordar el tema desde el ángulo correcto y evitar estos errores comunes. Es crucial comprender que los contenedores no son una solución mágica para reducir costes o mejorar la resiliencia de sus aplicaciones sin esfuerzo, y que requieren una planificación e implementación cuidadosas para cosechar sus beneficios. Sin embargo, se pueden maximizar las ventajas de los contenedores y minimizar los riesgos al evitar estos cinco errores comunes.  

¿Necesitas ayuda para tu migración a contenedores? Contacta con nuestro equipo.

La entrada 5 errores comunes al migrar a contenedores se publicó primero en Geko Cloud.

Comprobar que las copias de seguridad se están realizando correctamente es una práctica bastante habitual, pero en muchas ocasiones, eso no es suficiente. En algunos casos hay problemas que pasan inadvertidos hasta que llega la hora de recuperar los datos. Estos, si se dan en sistemas críticos, pueden afectar al negocio de forma directa.

Además de comprobar que las copias de seguridad se están realizando correctamente, es muy importante:

• Disponer de un documento operativo de recuperación, accesible a todo el personal que deba llevar a cabo la restauración.
• Llevar a cabo restauraciones periódicas simuladas para comprobar que somos capaces de restaurar un sistema crítico dentro de los RTOs y RPOs establecidos.

El siguiente ejemplo demuestra porqué es importante disponer de una documentación operativa así como una política de backup adecuada al negocio:

Caso de estudio: Restauración tras un ataque de ransomware

Recientemente, un cliente sufrió un ataque de ransomware, afectando de forma directa a sus sistemas de producción y nos pidió ayuda para restablecer sus servicios. En sus sistemas de producción, basado en tecnología Kubernetes, se realizaban copias de seguridad. Estas copias, aparentemente se realizaban correctamente, y estaban alojadas en un almacenamiento de objetos utilizando Velero como software de backup.

Una vez analizados los posibles escenarios para restablecer el servicio, determinamos que lo más efectivo era desplegar el clúster de Kubernetes desde cero, ya que la infraestructura estaba desplegada mediante IaC y las aplicaciones mediante Helm, para los datos persistentes, decidimos llevar a cabo una restauración de los backups.  

Durante el ataque y la restauración de datos pasaron 8 días y la política de retención de backups era de 7 días. Aunque la creación y despliegue de las aplicaciones fue relativamente sencilla, y ya estábamos en situación de restaurar los datos, al conectar Velero con el almacenamiento de objetos en un recurso no crítico, nos llevamos una sorpresa:

• Al conectar el primer backup, Velero detectó que el tiempo de retención se había superado. A causa de esto, el garbage collector se activó y eliminó aquellos backups con retención superior a 7 días. Esto nos dejó con 1 único día de retención, es decir, el RPO quedó en el último día.
• Para evitar esta casuística tuvimos que modificar todos los ficheros de Velero alojados en el almacenamiento de objetos para modificar el tiempo de expiración.
• Generamos un script para llevar a cabo dicha acción, lo que consumió directamente al tiempo disponible de restauración:

• También nos encontramos con que algunos recursos de Kubernetes, no disponían de copias de seguridad. Por suerte estos no eran críticos y se podían reproducir.
• Una vez llevada a cabo esta modificación restauramos los datos de forma habitual y restauramos los datos del cliente y finalmente el servicio.

Esta incidencia nos demostró lo importante que es disponer de una documentación operativa de restauración que nos permita reaccionar con el tiempo suficiente e identificar los ítems necesarios de las copias de seguiridad ágilmente.

Lecciones aprendidas y recomendaciones de mejores prácticas

Desde Geko recomendamos, elaborar un plan de continuidad de negocio que incluya:

• Políticas de backup a aplicar para cumplir con RTOs y RPOs necesarios.
• Realizar procedimientos de backup y restauración.
• Describir procedimientos de validación de las copias de seguridad.
• Realizar restauraciones periódicas de sistemas críticos en entornos no productivos.
• Redactar un plan de contingencia y disaster recovery.

Estrategias específicas para Kubernetes

Si usas tecnologías de Kubernetes:

• Utiliza IaC para la infraestructura para que sea repetible en cualquier momento.
• Implementa un sistema basado en Gitops para levantar tus aplicaciones más rápidamente.
• Asegúrate que estás haciendo backups de todos los recursos necesarios. Los PVCs son un recurso importante.
• Cuando realices restauraciones en nuevos clústers deshabilita backups, schedules y gargabe collection durante el disaster recovery.

Opciones de contingencia en AWS

Si tu cloud predilecto es AWS puedes utilizar los siguientes servicios para la contingencia de tus aplicaciones:

• AWS backup
• AWS Vault lock para implementar WORM (write-once, read-many) en las copias de seguridad.
• EBS Snapshot
• EBS Snapshot schedules
• Continuos backups para los servicios soportados.
• Si usas Organizations utiliza AWS backup policies para centralizar las políticas y aplicarlas a toda la organización.
• S3 replication para replicar los datos a otras regiones.
• S3 Glacier para almacenar largas retenciones.

Esperamos que esta guía te haya sido útil para entender las mejores prácticas con tu estrategia de backup en la nube y Kubernetes. Si tienes alguna pregunta o necesitas más detalles, no dudes en contactar con nosotros o dejar un comentario.

La entrada Consejos para tu estrategia de backup en la nube y Kubernetes se publicó primero en Geko Cloud.

Basándonos en las tendencias actuales y en las opiniones de expertos en la industria de la nube, os dejamos algunas de las tendencias que podrían tomar forma en el mercado de la nube en 2023:

Mayor adopción de la nube híbrida:

La nube híbrida es una combinación de nube pública y privada, lo que permite a las empresas utilizar la infraestructura de la nube pública para cargas de trabajo no críticas y utilizar la infraestructura de la nube privada para cargas de trabajo críticas que requieren un alto nivel de control y seguridad. La nube híbrida permite a las empresas obtener lo mejor de ambos mundos, lo que significa que pueden aprovechar la escalabilidad y la flexibilidad de la nube pública y la seguridad y el control de la nube privada. Además, la nube híbrida permite una fácil migración de cargas de trabajo entre la nube pública y privada, lo que es ideal para las empresas que necesitan una infraestructura de TI ágil y flexible.

Mayor enfoque en la seguridad de la nube:

Con el aumento de la cantidad de datos almacenados en la nube, la seguridad se ha convertido en una preocupación cada vez más importante para las empresas. En 2023, se espera que las empresas inviertan en herramientas y servicios de seguridad de la nube para garantizar la protección de sus datos. Las soluciones de seguridad en la nube pueden incluir autenticación y autorización, encriptación de datos, monitoreo y análisis de seguridad, así como herramientas de prevención de amenazas. Además, las empresas también pueden adoptar prácticas de seguridad de la nube, como la segmentación de red, la gestión de identidades y acceso, y la evaluación regular de riesgos de seguridad.

Mayor adopción de la inteligencia artificial y el aprendizaje automático en la nube:

La nube es una plataforma ideal para el procesamiento y análisis de grandes cantidades de datos, y se espera que el uso de la inteligencia artificial y el aprendizaje automático se expanda en la nube para mejorar la eficiencia y la productividad empresarial.

Mayor énfasis en la sostenibilidad:

Las empresas están buscando formas de reducir su impacto ambiental, y la nube puede ser una solución en términos de eficiencia energética. Se espera que las empresas se centren cada vez más en soluciones de nube sostenibles en 2023.

Mayor adopción de la nube sin servidor (Serverless):

La nube sin servidor o serverless permite a las empresas reducir costos y aumentar la eficiencia mediante el pago solo por los recursos que utilizan. En lugar de tener que pagar por una infraestructura completa, las empresas solo pagan por las solicitudes de servicio que utilizan. Esto permite una mayor escalabilidad y agilidad en la implementación de aplicaciones y servicios. Además, la nube sin servidor también elimina la necesidad de gestionar y mantener la infraestructura, lo que permite a las empresas centrarse en el desarrollo y la innovación de aplicaciones. Se espera que la adopción de la nube sin servidor continúe en aumento en 2023, a medida que más empresas se den cuenta de los beneficios de esta tecnología y de la facilidad de uso que ofrece.

En conclusión, el mercado de la nube sigue evolucionando rápidamente y las empresas están adoptando nuevas estrategias para aprovechar al máximo las capacidades de la nube. La adopción de la nube híbrida permite a las empresas combinar lo mejor de ambos mundos, la escalabilidad de la nube pública y el control y seguridad de la nube privada. Además, las empresas están enfocándose cada vez más en la seguridad de la nube, con la adopción de herramientas y servicios de seguridad para proteger sus datos críticos. La inteligencia artificial y el aprendizaje automático también se están expandiendo en la nube para mejorar la eficiencia y la productividad empresarial. Además, las empresas están adoptando soluciones de nube sostenibles y centrándose en la reducción de su impacto ambiental. Finalmente, la nube sin servidor sigue siendo una tendencia importante, ya que permite a las empresas reducir costos y aumentar la eficiencia mediante el pago solo por los recursos que utilizan. Resumiendo todo lo mencionado, se espera que estas tendencias continúen en el futuro y que las empresas sigan adoptando nuevas estrategias para aprovechar los beneficios de la nube.

Si quieres estar en las últimas tendencias del cloud, en Geko Cloud te podemos ayudar a poder establecer nuevas estrategias en tu nube híbrida para evolucionar en tu negocio.

Solo tienes que dejarnos tu contacto y nosotros te escribiremos!

La entrada PRINCIPALES TENDENCIAS EN LA NUBE PARA EL 2023 se publicó primero en Geko Cloud.

Engineering Culture es el nombre bonito que se le ha dado al concepto que se intenta arraigar en las nuevas empresas de compartir el conocimiento que se tenga, las herramientas que se vean útiles, o la ayuda que pueda darse a otros proyectos. Va con la idea de la metodología DevOps de eliminar los silos de conocimiento y trabajo y que compartir estos conocimientos genera beneficios para todo el mundo implicado.

¿Qué beneficios tiene?

Compartir conocimientos con el resto de equipos internos, por ejemplo a través de un canal de slack o de pruebas de concepto compartidas, o con el resto del mundo a través de proyectos abiertos o posts en blogs (como este!) no sólo ayuda a que se reciban contribuciones externas para mejorar ideas y procesos, sino que también es una muy buena forma de ganar publicidad y alcance público de calidad, el cual genera mejores leads y es positivo a nivel de imagen.

Algunos valores y prácticas que suelen estar asociados con este cultura son:

1. Excelencia técnica, que incluye la búsqueda continua de la mejora en los procesos.
2. Empoderamiento y autonomía para tomar decisiones y liderar proyectos.
3. Colaboración  y comunicación abierta y transparente que ayuda a garantizar que los miembros del equipo estén alineados en objetivos y responsabilidades.ç

¿De qué formas puedo impulsar Engineering Culture?

Hay muchas formas de impulsar esta cultura en tu empresa para aprovechar sus muchos beneficios:

• Crear contenido de calidad con lecciones aprendidas en blogs, vídeos o redes sociales
• Dedicar tiempo interno para enseñanza y formación de herramientas a nivel técnico por parte de los propios equipos
• Dedicación de recursos a creación de herramientas de código abierto para el público
• Dedicación de recursos a “dar de vuelta” a los proyectos open source que se usen, sea económicamente o en tiempo de programación o bug fixing, así como documentación

El guardarse las cosas internamente ya no está de moda, parte de tu estrategia de márketing y creación de lead puede, y quizá debería, incluir dar de vuelta a la comunidad que sostiene tu producto a diario! 

La entrada Engineering Culture: guardarse el conocimiento ya no está de moda se publicó primero en Geko Cloud.

A medida que vamos explotando nuestra infraestructura hospedada en el cloud de Amazon, nuestra factura también empieza a “explotar”. Es por esto que llegados a cierto punto (o no), conviene empezar a buscar recursos para que tu factura no sea tan abultada.

El primer paso antes de todo, es tener claro qué y cuántos recursos necesitas para que tu aplicación y/o infraestructura tenga el performance adecuado y hacer una previsión sobre cuánto tiempo crees que como poco, necesitarás dichos recursos funcionando.

Para dicha estimación, debes tener un buen conocimiento de tu arquitectura y llevar un tiempo trabajando en ella, ya que si no, no tendrás la capacidad suficiente para prever como se comportará tu infra en situaciones atípicas.

Vamos a ponernos en situación. Vamos a simular varias formas de ahorrar en la factura de EC2.

Reserved Instances

Consiste en hacer una previsión de instancias EC2 que necesitarás como mínimo, a 1 o 3 años vista (depende del tiempo de compromiso que escojas).

Una buena práctica sería jugar con la equivalencia que tienen los tipos de instancia en EC2. Por ejemplo, reservar 2 t3.small por cada t3.medium. De esta manera todo tu hardware se repartirá en función de las necesidades de tu infraestructura, y si en algún momento cambia el número o el tipo de instancias, ese hardware reservado seguirá repartiéndose y aprovechándose de la manera más óptima.

¿Cuál es el premio por hacer esta gran previsión y comprometerse? Pues que AWS te hace descuentos de mínimo un 25-30% y hasta un 50-60% en la factura de EC2!

Cuanto más tiempo de compromiso y más pagues por adelantado, mayor será el descuento.

Spot Requests

Este tipo de instancia te permiten aprovechar la capacidad de EC2 sin usar en la nube de AWS. Las instancias de spot están disponibles con un descuento de hasta el 90 % en comparación con los precios on-demand.

¿Dónde está el truco? Aunque cueste de creer, son unas instancias que si AWS necesita para otro usuario o finalidad, te las puede quitar al instante solo con un aviso de 2 minutos (si te das cuenta, apaga las máquinas y no te las quitarán )

Es por esto que se recomienda usar estas instancias solo para entornos de contenedores, CI/CD, testing… o bien combinarlas en un ASG con tus instancias on-demand.

Scheduled Instances

Una práctica­­ efectiva si sabes detectar en qué horas o días de la semana tu infra procesa más carga de lo normal.

Se trata de programar un número de máquinas durante un tiempo concreto. Si por ejemplo hay un momento del día donde hay más tráfico de lo normal y el resto del día es mucho más tranquilo, podrías programar que se añada una o dos instancias más a tu ASG.

¿Y por qué es una buena opción para ahorrar? Porqué ajustas el número de máquinas al máximo en función de las necesidades del momento, y nunca pagas por lo que no usas.

Saving Plans

Si tienes un número más o menos grande de instancias y llevas ya bastante tiempo con ese número y crees que por ahora no variará en exceso, personalmente un Saving Plan es tu mejor opción.

El saving plan básicamente lo que hace es hacer un análisis de los recursos y potencia que necesita tu infra (te quita ese trabajo) y proponerte un ahorro a cambio de un compromiso.

La verdad es la medida más cómoda y si quieres dedicar un tiempo a comprobar por ti mismo que los precios que te proponen son realistas, hazlo y verás que aunque reserves instancias por tus propios medios, el descuento que te proponen es igual o mayor.

Hay 3 tipos de Saving Plans:

• Compute: proporciona más flexibilidad y reduce costes hasta en un 66%. Se basan en el uso de EC2, AWS Fargate y AWS Lambda, independientemente de la familia de la instancia, tamaño, zona, región, SO y tenencia
• EC2 Instance: proporciona los precios más bajos y reduce costes hasta en un 72%, a cambio del compromiso de uso de familias de instancias individuales en una región.
• SageMaker: reduce costes de hasta un64% en SageMaker. Se basan en el uso de SageMaker independientemente de la familia de instancias, tamaño, componente y región de AWS.

Para aplicar un Saving Plan, seleccionamos esta opción:

Una vez dentro, podemos escoger el tiempo y los ratios de precio que estamos dispuestos a pagar y ver qué descuento se aplica, o bien, hacer click aquí y ver las recomendaciones que nos propone AWS basándose en los últimos X días.

En las recomendaciones, en función del tiempo de compromiso y el upfront veremos unos precios u otros.

Mi propuesta personal 

¿Una vez conoces todos estos métodos, por qué no combinarlos?

Puedes combinar fácilmente las instancias de spot con instancias bajo demanda, reservadas y de Savings Plans para optimizar aún más el costo de la carga de trabajo con rendimiento.

También puedes apagar máquinas mientras no las uses o usar el método de las Scheduled Instances.

Otros servicios donde las reservas son un buen aliado

En este post, hemos querido hacer énfasis en la reserva de instancias y los Saving Plans de EC2, pero AWS ofrece bastantes servicios donde gracias a la previsión de recursos que vas a necesitar como mínimo en un tiempo concreto, puedes ahorrarte un buen pellizco.

Por ejemplo, en el servicio de DynamoDB, puedes reservar la capacidad. Funciona igual que reservar instancias, a cambio de un buen descuento, puedes reservar una capacidad de disco durante un tiempo concreto con diferentes formatos de pago por adelantado.

Otro ejemplo es Opensearch, el SAS de ELK (Elasticsearch, Logstash y Kibana) que incorpora AWS. En este servicio puedes hacer reservas de instancias, pero con una peculiaridad muy importante a tener en cuenta.

A diferencia de otras reservas, en este servicio tienes que reservar exactamente el tipo y el número exacto de instancias que usa tu Opensearch. Básicamente, no sirve reservar 2 instancias t3.small para que una t3.medium use sus recursos, por ejemplo. Si tu Opensearch usa 2 Data Nodes t3.medium y 3 Master Nodes m5.large, deberás hacer exactamente la reserva de estos tipos y números de instancias.

Personalmente lo recomiendo igualmente, el ahorro es muy notable.

Conclusión

Como bien indica el título de este post, la mejor opción que tienes para ahorrarte dinero en todos los servicios de AWS donde hay máquinas involucradas es la previsión. Si tu infraestructura tiene el performance esperado y conoces bien su comportamiento, sabrás prever el número de instancias o recursos que necesitas a 1 o 3 años vista.

Vale la pena hacer un esfuerzo en el análisis de tus recursos y tomarte unas horas o días observando tus ASG y demás servicios, podrás reducir tranquilamente un 50% en tu siguiente factura.

Si quieres ayuda para poder llevar a cabo estas prácticas, no dudes en ponerte en Contacto con nosotros!

El equipo de Geko cuenta con la experiencia en diferentes ámbitos, trabajando con metodología DevOps, acompañando a nuestros clientes en todo el proceso desde la migración hasta la gestión en el cloud, y adaptándonos 100% a sus infraestructuras y tecnologías.

Autor: Pol

La entrada LA PREVISIÓN. Tu mejor aliada para ahorrar en tu factura de AWS se publicó primero en Geko Cloud.