¿Qué es Elastic Beanstalk?

Elastic Beanstalk es un servicio de AWS que simplifica el despliegue de aplicaciones en la nube. ¿Cómo lo hace? Este servicio tiene más de 100 servicios asociados y es compatible con aplicaciones desarrolladas en los lenguajes Go, Java, .NET, Node.js, PHP, Python y Ruby, y los orquesta creando una infraestructura basada en el código desplegado de la aplicación y archivos de configuración adicionados en el despliegue.

El desarrollador no tiene que aprovisionar nada.. o casi nada manualmente.

¿Porqué este tutorial?

Actualmente, existen muchos ejemplos de cómo desplegar aplicaciones en Elastic Beanstalk, y los puedes encontrar aquí. Sin embargo, ninguno de ellos aborda específicamente el despliegue de una aplicación Java con Spring Boot y Docker en Elastic Beanstalk. Este artículo asume que tienes conocimientos básicos de este servicio, por lo que si aún no estás familiarizado con el mismo, revisa aquí.

Contenido

En este tutorial, vamos a ver cómo desplegar una aplicación de ejemplo desarrollada con Java, utilizando el framework Spring Boot y diseñada para ser desplegada como contenedor Docker.

Además, realizaremos el proceso manualmente (por línea de comandos) y no a través de la consola web de AWS, ya que interactuar con la consola web cada vez que queremos hacer cambios en una aplicación y subirla a la nube, no es automatizable y puede ser largo y complejo.

Por lo tanto, los pasos a seguir son:

1. Descargar la aplicación y probarla localmente.
2. Instalar y configurar el cliente Elastic Beanstalk CLI.
3. Desplegar una primera versión en desarrollo (dev).
4. Desplegar una versión en QA (próximamente).

Descargar la aplicación y probarla localmente

La aplicación de ejemplo es un simple CRUD, que puedes descargar aquí con el comando:

git clone https://github.com/pazfernando/crud-spring-boot-example.git

Ve a la carpeta donde se descargó y compílala con (requieres tener instalado Java 17+):

cd crud-spring-boot-example
./mvnw clean install

Ejecuta la aplicación con:

java -jar target/crud-0.0.1-SNAPSHOT.war

Prueba la aplicación en tu navegador con:

http://localhost:8080/

Instalar y configurar el cliente Elastic Beanstalk CLI

IMPORTANTE: El procedimiento a continuación es para ambiente Linux, ya que tiene mejor soporte para herramientas y frameworks de desarrollo en general. Si no tienes Linux o Mac, instala WSL en Windows. Mira las instrucciones aquí. Por defecto tendrás un Ubuntu instalado en Windows y podrás usarlo ejecutando en PowerShell lo siguiente:

wsl

Listo, asumimos desde aquí que tienes Linux, Mac o WSL en Windows.

Instalación de pyenv

Empezamos instalando un manejador de versiones de Python llamado pyenv. Encuentra cómo aquí.

Post instalación de pyenv

Añade o verifica estas líneas en .bashrc de $HOME:

export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

Actualiza tu .bashrc con:

source ~/.bashrc

Instala la última versión estable de Python

Encuentra la documentación de versiones estables en https://devguide.python.org/versions/. La instalación es con el comando:

pyenv install 3.11

IMPORTANTE: A la fecha de creación de este artículo, puedes usar Python 3.11 máximo.

Configura esta versión como la de defecto en tu ambiente:

pyenv global 3.11

Instala virtualenv para aislar tu ambiente de Python

Encuentra cómo hacerlo aquí.

Instala Elastic Beanstalk CLI

Encuentra cómo hacerlo aquí.

Actualiza tu .bash_profile para incluir los ejecutables de Elastic Beanstalk CLI en tu PATH:

echo 'export PATH="/home/pazfernando/.ebcli-virtual-env/executables:$PATH"' >> ~/.bash_profile

Refresca tus archivos de ambiente en tu $HOME:

source ~/.bash_profile
source ~/.profile

Desplegar una primera versión en desarrollo (dev)

Ve a la carpeta del proyecto (donde se descargó).

Configura el Elastic Beanstalk CLI, mira cómo hacerlo aquí.

Aspectos importantes previos

Antes de desplegar la aplicación, hay ciertos puntos esenciales a entender acerca de Elastic Beanstalk, ya que este conocimiento nos dará el entendimiento de por qué se despliega una aplicación de una forma u otra.

Ignorando archivos con .ebignore

Cuando desplegamos aplicaciones con Elastic Beanstalk CLI, debemos saber qué archivos son ejecutables, cuáles son de configuración, cuáles son de apoyo, etc. Esto se debe a que CLI empaqueta dichos archivos en un archivo .zip para luego extraerlo y desplegarlo en la instancia o instancias de la infraestructura que sirve la aplicación.

Por defecto, Elastic Beanstalk CLI busca el archivo .gitignore para saber, desde la carpeta donde se están ejecutando los comandos, qué archivos debe excluir de este archivo .zip. Pero como sabemos, para los proyectos Java, el archivo .gitignore excluye el directorio target/, el cual es esencial pues tiene el artefacto compilado del proyecto, y en su lugar empaqueta src/ y otros archivos que son fuentes de la aplicación, y que en este caso no aplican.

Esta estrategia funciona muy bien en proyectos tipo Python o PHP donde no hay compilados, pero no en el caso de Java. Aquí aparece otro archivo, .ebignore, que es otro recurso que busca por defecto Elastic Beanstalk CLI ante la ausencia de un archivo .gitignore o incluso lo precede si existiera. Por esta razón, el archivo .ebignore en este tipo de proyectos es tan importante, y por eso nosotros tenemos en los fuentes este contenido:

HELP.md
src/
*
!Dockerfile
!target/
!.ebextensions

Esto asegura y le dice a Elastic Beanstalk CLI qué ignorar y por ende qué sí empaquetar. En nuestro caso, es importante Dockerfile, target/ y .ebextensions.

Configuración avanzada con .ebextensions

Desplegar una aplicación con Elastic Beanstalk no es siempre, o nunca lo es, algo tan simple como desplegar un artefacto. Si bien la infraestructura se aprovisiona automáticamente, la aplicación suele requerir de variables de ambiente, datos de conexión con servicios externos, capacidades mínimas, etc.

¿Cómo especificamos esto sin tocar el código? La respuesta es con archivos de configuración o archivos .ebextensions.

En nuestro caso, tenemos el archivo env-vars.config donde configuramos ciertas variables de ambiente para que funcione la aplicación:

option_settings:
  aws:elasticbeanstalk:application:environment:
    SPRING_PROFILES_ACTIVE: dev
    CRUD_DB_URL: 'jdbc:postgresql://${RDS_ENDPOINT}/crud_spring_boot_example'
    CRUD_DB_USERNAME: ebroot
    CRUD_DB_PASSWORD: clave

Algo a destacar es SPRING_PROFILES_ACTIVE que determina cómo va a funcionar la aplicación Java + Spring Boot. En la vida real, tenemos cientos de configuraciones posibles que podemos hacer a través de estos archivos. Puedes aprender más aquí.

La documentación es un poco confusa, por eso te dejo dos enlaces más de los tipos de opciones: comando opciones y de las opciones a detalle aquí.

Trabajando con aplicaciones del tipo Docker

Para empezar, necesitas un Dockerfile que en nuestro caso contiene:

FROM amazoncorretto:17.0.11-alpine
ARG JAR_FILE=target/*.war
COPY ${JAR_FILE} app.jar
EXPOSE 8080
CMD ["java", "-jar", "/app.jar"]

Muy simple y claro, y que será incluido en el archivo .zip gracias a nuestro archivo .ebignore.

No tenemos en este caso Docker Compose y lo haremos a partir de ese archivo. Sin embargo, si quieres saber más de las opciones de despliegue, puedes mirarlo aquí.

IMPORTANTE: Hay otra forma de hacerlo en un clúster de Amazon ECS (Elastic Container Service), que está fuera de esta explicación pero que puedes consultarla aquí.

Despliega la aplicación

Excelente, ahora para desplegar vamos a ejecutar el comando:

eb create --single

El --single nos ayuda a desplegar una infraestructura simple, sin redundancia y alta disponibilidad, y que aplica en este caso del tutorial.

Verás algo como:

Enter Environment Name
(default is crud-spring-boot-example-dev): 
Enter DNS CNAME prefix
(default is crud-spring-boot-example-dev): 

Would you like to enable Spot Fleet requests for this environment? (y/N): 
Creating application version archive "app-0048-240801_111838855018".
Uploading: [##################################################] 100% Done...
...
2024-08-01 16:21:52    INFO    Application available at crud-spring-boot-example-dev.us-east-1.elasticbeanstalk.com.
2024-08-01 16:21:54    INFO    Successfully launched environment: crud-spring-boot-example-dev

IMPORTANTE: Si no eliges --single, adicionalmente te preguntarán alguna información necesaria para el despliegue, sigue las siguientes recomendaciones:

• Usa Application Load Balancer ALB (por defecto)
• Di que no a Spot Fleet (por defecto)
• Todo lo demás que no sepas deja por defecto.

Prueba tu aplicación visitando precisamente el url de la salida:

http://crud-spring-boot-example-dev.us-east-1.elasticbeanstalk.com/

Finaliza el despliegue IMPORTANTE IMPORTANTE IMPORTANTE

Si fallas este paso tu factura puede salir muy alta, especialmente si no usaste --single, así que ejecuta este comando para finalizar el tutorial:

eb terminate

Pensamientos finales

Desplegar una aplicación Java con Spring Boot en Elastic Beanstalk de AWS utilizando Docker es algo más complejo, pero siguiendo estos pasos detallados, el proceso se vuelve manejable y entendible, por lo que espero que sea de valor para ustedes.

Elastic Beanstalk de AWS simplifica enormemente el proceso de despliegue y gestión de aplicaciones, permitiendo enfocarte en el desarrollo sin preocuparte por la infraestructura. Utilizar Docker agrega una capa de consistencia y portabilidad, asegurando que tu aplicación funcione de la misma manera en cualquier entorno.

Es vital seguir entender prácticas como el uso adecuado de archivos .ebignore y .ebextensions para asegurar que solo los archivos necesarios se incluyan en el despliegue y que la configuración de tu aplicación sea flexible y segura. Además, siempre finaliza los entornos no utilizados para evitar costos innecesarios.

Usar perfiles de Maven es un poco más complicado, pero la idea es trabajar con .ebextension para configurar los valores requeridos, si hay recursos relacionados como bases de datos servicios colas y demás, la recomendación es que se creen fuera de el scope de la aplicación.

La implementación de una aplicación en la nube es un proceso iterativo. A medida que te familiarices con Elastic Beanstalk y Docker, encontrarás formas de optimizar y mejorar tu flujo de trabajo. Comparte tus experiencias y cualquier obstáculo que encuentres, y sigue aprendiendo de la documentación y la comunidad de AWS.

Explorando Límites de AWS Lambda – Porque

Es muy común implementar una solución Serverless en AWS utilizando los servicios API Gateway, AWS Lambda y DynamoDB, y, probar esta arquitectura para nuestro caso de uso es crucial al diseñar una solución.

Así, cuando trabajamos la charla ¿Como manejar 100K conexiones simultáneas en AWS? en Serverless o probamos los nuevos límites de AWS Lambda de acuerdo al anuncio Las funciones de AWS Lambda ahora escalan 12 veces más rápido cuando manejan solicitudes de gran volumen, nos vimos en la necesidad de crear recursos y ambientes, una y otra vez hasta crear el escenario perfecto.

Por eso decidimos crear un proyecto base como infraestructura como código que pueda apoyarlos para sus propias pruebas. El repositorio es público y de código abierto, y lo pueden encontrar aquí serverless-limits-playbook-test.

Arquitectura

La idea principal en esta versión es crear una arquitectura de un API RESTful con API Gateway integrado a un función AWS Lambda para llamadas sincrónicas, y crear una instancia EC2 con una instalación de JMeter para lanzar pruebas de carga.

Aunque en el código podrán observar también:

• Habilitación de CORS
• Bloque de código para llamadas asincrónicas (comentado)
• Configuración para reserve concurrency en AWS Lambda.
• El script setup.sh para adicionar configuraciones a su instancia EC2.
• El script index.mjs para definir la implementación real de su función AWs Lambda.
• Un identificador único para peticiones desde a lambda (opcional podrían eliminarlo).

Prerequisitos

Dependiendo de su caso de uso necesitarán configuraciones generales en su cuenta, pero aquí presentamos las básicas.

• Tener una Default VPC en la region que vayan a probar.
• Crear un Role en IAM que permita escribir desde API Gateway a CloudWatch.
• Asignar dicho rol a las configuraciones del servicio API Gateway en la región donde se va ha hacer pruebas.
• Tener los Server Limits adecuados a su prueba, especialmente los de AWS Lambda “Burst Concurrency” y “Concurrent Executions“.

Despliegue de recursos

Al ser un proyecto IaaC construido con AWS CDK, pues evidentemente usamos los comando apropiados. A continuación la lista de pasos:

• Cambiar las variables const targetRegion y const targetAccount en el archivo de los fuentes /bin/infra.ts apropiadamente.
• Instala AWS CLI la última versión.
• Instala Node.js 20 o superior.
• Instala el último AWS CDK.
• En la carpeta del proyecto corre cdk boostrap para preparar la región para IaaC.
• Ejecuta cdk synth para verificar que tus fuentes estén correctos.
• Ejecuta cdk deploy para crear los recursos descritos en la arquitectura.

Usamos AWS CDK para este proyecto, pero podrías reemplazar o hacer tus versiones con Terraform u OpenTofu respectivamente. Hacerlo con AWS Cloud Formation es otra opción aunque no lo recomiendo.

Lanzamiento de carga masiva

Para ejecutar las pruebas masivas con JMeter es necesario ingresar a la instancia EC2 creada a través de la Consola Web y con EC2 Instance Connect, dado que no se asoció un server key al momento de su creación.

Una vez en el shell los comandos son los siguientes:

• Cambia a root el usuario: sudo -i.
• Edita el archivo LambdaConcurrencyLimits.jmx con vi /tmp/LambdaConcurrencyLimits.jmx con el url de tu API RESTful (esa url la obtienes como salida del comando cdk deploy al final del log).

Ejecuta los test JMeter de carga con

rm -Rf /var/www/html/stats/* && rm -f /tmp/stats.jtl && /opt/apache-jmeter-5.6.2/bin/jmeter -n -t /tmp/LambdaConcurrencyLimits.jmx -l /tmp/stats.jtl -e -o /var/www/html/stats.

Pruebas en JMeter

Mientras se puede escribir un blog entero de pruebas en JMeter, el archivo creado esta compuesto de las siguintes características:

• Cinco grupos de usuarios (hilos)
• Primer grupo lanza 1001 usuarios en 10 segundos.
• Segundo grupo lanza 2001 usuarios en 20 segundos.
• Tercer grupo lanza 3001 usuarios en 30 segundos.
• Cuarto y quinto grupo lanza 0 usuarios, y están en el archivo jmx para que los usen como lo prefieran para su caso de prueba.
• Se prueba una URL con un HTTP Request de tipo GET al API RESTful creado.
• El URL del API Gateway RESTful esta externalizado en el argumento url-api-gateway.

Evidentemente estas pruebas no se ajustan a tu caso de uso y deberás cambiarlas apropiadamente, sin embargo el mecanismo de lanzamiento y la instancia EC2 configurada va a reducir el tiempo para esta operación.

Métricas

Una vez desplegada la infraestructura, y ejecutados las pruebas podremos monitorear los recursos y tomar las acciones correspondientes.

A continuación algunos gráficos que vamos a poder obtener:

API Gateway

AWS Lambda

Además siempre vamos a tener Grupos de Logs en Amazon CloudWatch apropiados para el caso de uso y por servicio para analizar los resultados:

IMPORTANTE: siempre al finalizar las pruebas no olviden ejecutar cdk destroy para decomisar los recursos usados y evitar facturación innecesaria.

Conclusiones y Pensamientos Finales

En este Playbook Explorando Límites de AWS Lambda, hemos podido plasmar un proyecto de código abierto para que puedan acelerar sus pruebas de implementaciones. Sin embargo hay mucho que mejorar en el mismo, como la inclusión de secrets con Secrets Manager para gestionar números de cuenta y otros parámetros sensibles y que NO deben estar en su repositorio de fuentes.

También este proyecto nos ayuda en la inmersión en el mundo apasionante que significa AWS CDK, y con el cual pueden gestionar su infraestructura de forma completamente automatizada.

Vale mencionar que en un proyecto de AWS CDK jamás deben subir el directorio cdk.out, dado que aquí como resultado de la compilación de los archivos Typescript a archivos propios de AWS Cloud Formation ((JSON por ejemplo), puede y va a quedar información sensible como números de cuenta y/o claves.

Para hacer uso de este enfoque de despliegue es necesario estar familiarizado con AWS CLI ya que con este generarán perfiles que contengan accesos de los usuarios de su cuenta, y con tales accesos se crearán los recursos. Entonces es importante que los usuarios asociados tengan los permisos correspondientes.

Los límites que tengan para su cuenta y por región van a incidir directamente en sus pruebas en caso de altas cargas de procesamiento, por lo que se debe tener en cuenta los mismos al momento de planificar la implementación.

Les animamos a dejar su feedback para mejorar el proyecto, sea aquí o en el repositorio de GitHub, y esperamos que sea de utilidad este proyecto “Explorando Límites de AWs Lambda”.

Esta estrategia, Endpoint Proxy en API Gateway, es muy adecuada especialmente porque tenemos los siguientes beneficios:con

• Implementar el escenario Rehost (lift and shift) para una migración.
• No realizar ninguna modificación a la implementación del API.
• Mantener el servicio web en una red privada y sin acceso a internet.
• Acceder a mejoras de seguridad del API de negocio y poder monitorearlo, dado que vamos a usar API Gateway.
• Posibilita el versionamiento del API de negocio con menor esfuerzo.
• Integración con el escudo de seguridad AWS WAF.

Tutorial Endpoint Proxy con API Gateway

Se piensa en implementar con Amazon API Gateway un Endpoint Proxy de tipo HTTP API, que puede brindar la solución a lo requerido.

Escenario API Público

Para este escenario vamos a utilizar el API ejemplo de Swagger https://petstore.swagger.io/ como referencia, que nos ayuda a probar operaciones RESTful comunes.

Probamos la operación https://petstore.swagger.io/#/pet/findPetsByStatus para mirar los datos disponibles.

Ok, el API está funcionando correctamente.

Definimos una arquitectura Cloud para este efecto en AWS.

Creamos el API Gateway HTTP con el nombre proxy-swagger-api.

Creamos la ruta $default.

La ruta $default actúa como un “catch-all” es decir gestiona cualquier petición que no coincida con otras rutas definidas. Puedes saber más aquí.

Creamos la integración.

Probamos el API RESTful de la misma forma que lo hicimos al inicio.

Debemos cambiar el Endpoint a el nuevo del API Gateway: https://gl1p0rt1gc.execute-api.us-east-2.amazonaws.com/ (reemplaza para tu caso con el apropiado).

Esta vez la prueba la vamos ha hacer desde Postman.

¡Excelente! Funciona igual y como un Endpoint Proxy con las ventajas y funcionalidades que ofrece API Gateway.

Escenario API Privado

¿En la vida real como sería un ejemplo?

Vamos a ver una arquitectura donde este API es una implementación privada que esta en una instancia EC2 en una subred privada de una VPC de la empresa. Por tanto el único que permite acceso y controla los flujos es el API Gateway.

Para este escenario vamos a usar la implementación de un CRUD API RESTful construído con Spring de Código Libre / Opensource en GitHub.

Descargamos el proyecto en la instancia EC2 en la red privada, lo compilamos y corremos de acuerdo a las instrucciones del archivo README.mb en el código .fuente.

Seguido a esto hacemos una prueba. En este caso nos ayudamos de AWS CloudShell.

Son dos comandos curl, que insertan un registro visita y luego recuperan todas los registros visitas.

Cabe mencionar que antes debemos conectarnos a esa máquina con los protocoles estándar de SSH + Server Key, y, primero pasando por un Bastion Host… ya se mucha información pero ese es el camino dado que el servidor EC2 esta en una subred privada.

Creamos un Endpoint Proxy de tipo HTTP API, igual que en primer escenario.

Creamos una Route (ruta) proxy $default.

Para poder direccionar el tráfico a un recurso en una red privada, vamos a usar un Aplication Load Balancer (ALB), el mismo que va incluir en su Target Group a la instancia EC2 que provee el API privado.

El ALB debe ser de tipo “internal” es decir solo se puede usar dentro de la VPC (no desde Internet).

Evidentemente necesitas tener un Target Group que contenga el servidor EC2 privado donde esta el API al cual el ALB va a dirigir las peticiones. Por esto en medio de la creación del ALB tendrás que crear este Target Group.

Debes asegurarte que el grupo de seguridad del ALB permite el tráfico al puerto donde esta el listener.

Continúa con la creación del ALB.

Bien, vamos a continuar con la creación de la integración de nuestro API proxy-api-crud, para esto vamos al servicio API Gateway para iniciar.

La integración debe ser de tipo “Private resource” y en método seleccionamo9s “Select manually” para tener la opción de elegir un ALB/NLB como Target service.

En la lista desplegada de los ALBs, seleccionamos nuestro proxy-alb recién creado.. Además vamos a tener que crear “Create new VPC link” en la selección correspondiente, ya que este será el puente entre nuestro API creado con API Gateway y por defecto en una red propia de AWS, con nuestra VPC propia de la empresa.

Para este caso la VPC es proxy-vpc-vpx, pero debes elegir la correspondiente en tu infraestructura.

Aquí una ampliación al concepto de VPC Link, un VPC Link es un recurso que permite crear una integración con los recursos privados de una VPC desde una ruta del API Gateway de tipo HTTP. De esta forma no tienes que exponer ningún recurso de la VPC al público e igual puedes usarlo como destino final de un API Gateway que si sea público. Si quieres saber más de integraciones privadas para API Gateway HTTP a recursos de tu VPC puedes mirar aquí.

Luego en las opciones siguientes es importante elegir a qué subredes tiene acceso este nuevo VPC Link y que grupos de seguridad se le asignan.

Las subredes son importantes porque deben ser las subredes asociadas a tu ALB y su correspondiente Target Group.

El grupo de seguridad, es que que permite el acceso al puerto correspondiente donde el Listener del ALB esta escuchando peticiones.

Realizada la integración vamos a identificar el url (Invoke URL) del Endpoint Proxy con API Gateway creado.

Listo, con ese url, si todo es correcto podemos hacer las siguientes peticiones:

Para crear una visita:

curl --location 'https://bg4gmloull.execute-api.us-east-2.amazonaws.com/api/visits' \
--header 'Content-Type: application/json' \
--data '{"date":"2024-01-19","name":"Fer","comment":"by CloudIO Strategy"}'

Para consultar visitas:

curl --location 'https://bg4gmloull.execute-api.us-east-2.amazonaws.com/api/visits'

Son las mismas peticiones que usamos con consultar el servicio web RESTful desde el shell de la instancia EC2 mostrada en el ejemplo.

¡Excelente! Hemos creado un Endpoint Proxy con API Gateway, son tocar la implementación, con la funcionalidad esperada y todos los beneficios que tenemos en el servicio Amazon API Gateway.

Conclusiones y pensamientos finales

Hoy en este tutorial hemos visto como podemos implementar un Endpoint Proxy con API Gateway, un requerimiento que viene a partir de una migración al estilo Rehost del cliente que no desea entrar en temas de modificación a sus aplicaciones.

Presentamos dos escenarios, un proxy para un API público, que es infrecuente, y, un proxy a un API privado que si es muy frecuente y en ambos casos el servicio Amazon API Gateway nos permite implementar tal necesidad.

Nuestra arquitectura es solo una posibilidad de implementación del requerimiento, sin embargo en nuestra opinión es la más simple y rápida para dar una respuesta adecuada.

Vimos un concepto “VPC Link” que es importantísimo a la hora de integrar un API HTTP con recursos privados en la VPC, y en nuestro caso, nos integramos a un ABL o Aplication Load Balancer, sin embargo podríamos habernos integrado por ejemplo a AWS Cloud Map. Dado esto, no es la única forma de integración que podrían usar.

El ALB nos habilita todas las ventajas que tenemos de un Load Balancer por ejemplo resiliencia o escalamiento horizontal, y aunque representa un costo adicional es justificable frente a un lineamiento SRT (Server Response Time) del negocio.

Evidentemente, falta muchas configuraciones complementarias a una arquitectura de este estilo, como por ejemplo lo relacionado a las decisiones de stages del API, las seguridades, el monitoreo y la trazabilidad. Además la buena práctica es conectar este API Gateway a un dominio o subdominio apropiado de su empresa para facilidad de uso y estrategias de contingencia, entre otros.

Las instancias EC2 tipo T están en el grupo de propósito general, lo cual significa que su configuración es la más estándar posible y podría usarse para cargas de trabajo (workloads) que impliquen un balanceo moderado de recursos, tanto de CPU, memoria, red y acceso al almacenamiento.

Concretamente los siguientes son los casos de uso de las instancias EC2 tipo T recomendados por Amazon Web Services:

1. En desarrollo y pruebas: ¿necesitas un lugar para probar nuevas ideas sin estresar tus principales servidores? las instancias tipo T pueden ser la respuesta, ya que manejan a la perfección picos ocasionales de CPU.
2. En sitios Web y aplicaciones de bajo tráfico: ¿tu sitio Web o aplicación no tiene tráfico masivo 24/7? las instancias tipo T podrían ser tu solución ideal, ya que tienen un costo más económico (especialmente la Txg), y puedes servir ese sistema ERP, CRM, etc. con una inversión moderada.
3. En microservicios: si tus microservicios necesitan un picos ocasionales para manejar tareas intensivas de CPU, las instancias tipo T están listas y pueden ayudar. Aunque hay otras opciones de cómputo, puedes usar este esquema y pasar a otro si la carga es intensiva o impredecible.
4. Para pequeñas bases de datos: para bases de datos que no necesitan siempre estar a pleno rendimiento, una instancia tipo T podría ser una opción eficiente y económica. Cabe señalar que si tienes muchos I/O en el disco es recomendable combinar esta instancia con volúmenes #AmazonEBS de tipo io2.
5. Para servidores de respaldo: ¿tienes servidores que están en stand-by la mayoría del tiempo?, es decir están ahí para planes de continuidad. Las instancias tipo T son ideales gracias a su modelo de rendimiento “burstable” que ayudarán hasta reactivar tu esquema principal.

Hay que tomar en cuenta que las instancias tipo T no son las más adecuadas para cargas de trabajo que requieren un alto rendimiento constante de CPU (ahí necesitaras instancias tipo C o M). pero para muchas otras tareas, son excelentes.

Hay otros tipos de instancias de propósito general y puedes ver más información en Tipos de instancias EC2 en AWS., donde encontrarás sus variantes como T4g, T3, T3a y T2.

Cada variante tienen unas características de hardware específicas, así T4g significa que usa el procesador Graviton o T3a significa que usa el procesador AMD.

En este articulo vamos a presentar los aspectos más importantes a considerar al implementar WordPress en AWS, de forma que tengamos una instalación segura escalable y con tolerancia a fallos.

Arquitectura WordPress

Lo primero a considerar es que WordPress es un sistema monolítico, por lo que el despliegue de nuevas versiones, su performance y la estrategia de alta disponibilidad debe ser concebida como un todo, y, no esta en un paradigma distribuido como es la propuesta de la Arquitectura de Microservicios.

El segundo aspecto es que hablamos de una arquitectura en tres capas: presentación, lógica y datos. La capa de presentación esta compuesta por archivos HTML, CSS, JS y PHP, la capa lógica esta compuesta por archivos PHP, y, la capa de datos esta administrada por el gestor de base de datos MySQL.

Explicado esto, dichos componentes están distribuidos en el sistema de archivos de la siguiente forma:

• wp-admin: Ejecutables de las herramientas de administración del sitio.
• wp-content: Todos los archivos que no son parte del CORE de WordPress y que son adicionados o eliminados de acuerdo a las decisiones del webmaster.
• wp-includes: Todos los archivos CORE para que el sitio web funcione, y ejecute funcionalidad como publicaciones, páginas, widgets y otras características.
• wp-config.php: Archivo maestro de credenciales de conexión y configuraciones principales de funcionamiento.

En esta lista faltan otros archivos, que han sido omitidos porque no son importantes para esta implementación de WordPress en AWS.

Plugins

Como es de dominio público, WordPress trae la funcionalidad básica de un CMS, pero al mismo tiempo es fácil extender su funcionalidad a través de plugins.

Los plugins añaden características al CMS como protecciones de seguridad, gestión avanzada de usuarios, integración con plataformas de terceros e incluso funcionalidad de tiendas en línea (e-commerce) o plataformas educativas online.

Adicionalmente, a través de plugins se puede incrementar plantillas gráficas o temas gráficos, que modifican la apariencia del sitio de acuerdo a lo deseado por el cliente.

Todos los archivos que forman parte de estas extensiones de funcionalidad son almacenados en la carpeta wp-content/plugins o wp-content/themes, y son gestionados por el administrador del CMS.

wp-content

Cabe señalar aparte este directorio, ya que como se explico en la arquitectura, allí se almacenan los archivos de la funcionalidad no estándar de WordPress.

Además en la carpeta wp-content/uploads, se almacenan los archivos multimedia del CMS (fotos, video y documentos).

Entonces, es de especial importancia entender que su contenido es dinámico, y que por lo tanto su contenido debería ser el mismo en caso de tener dos o más servidores que provean funcionalidad como un solo CMS.

Más adelante, veremos que es necesario externalizar esta carpeta, para permitir un escalamiento del CMS WordPress con más de un servidor.

Implementando WordPress en AWS en 5 minutos

Para implementar WordPress en AWS, inicialmente desde un punto de vista monolítico, vamos a utilizar el servicio de AWS llamado Amazon Lightsail (https://lightsail.aws.amazon.com/ls/webapp/home), porque nos da las herramientas más adecuadas para este primer paso.

Una vez dentro del servicio, creamos una instancia (https://lightsail.aws.amazon.com/ls/webapp/create/instance).

Luego seleccionamos el blueprint WordPress

Selecciona el plan mínimo (instance plan) para esta prueba y da finalizar.

En 5 minutos tendrás la instancia lista.

Deberías ver el servidor aprovisionado en la región Ohio Zone A.

Adicionalmente para los siguientes pasos, requieres saber que versión exacta de MySQL o MariaDB tienen instalado. Para esto puedes ir a la página http://<servidor-ip>/wp-admin/site-health.php?tab=debug y en la pestaña “Database” encontrarás esa información.

El usuario es “user” y el password lo puedes saber consultando el archivo “/home/bitnami/bitnami_credentials” mediante el terminal (icono siguiente).

Habilitando VPC Peering en Amazon Lightsail

En primer lugar debemos habilitar el VPC Peering entre Amazon Lightsail y los recursos aprovisionados fuera de este servicio, como es el caso de una base de datos Amazon RDS MySQL o unidad de red NFS gestionada con el servicioAmazon EFS.

Para esto ve a Amazon Lightsail (https://lightsail.aws.amazon.com/ls/webapp/home).

En la esquina superior derecha encontraras el menú “Account”, allí selecciona la opción también llamada “Account”.

En la pestaña “Advanced” vas a encontrar las opciones “VPC Peering” donde debes habilitarlo para los recursos aprovisionados fuera de Amazon Lightsail (en mi caso en Ohio).

Listo, ahora desde Amazon Lightsail podrás ver a nivel de red (exactamente de VPC) los recursos desplegados en la region de Ohio.

Conectando WordPress con Amazon RDS

El primer paso para poder aspirar a un esquema altamente disponible y resiliente es separar la base de datos.

En la implementación de WordPress en AWS usando un blueprint de Amazon Lightsail, el servidor resultante tiene tanto WordPress como la base de datos. Eso no es escalable dado que, a la base de datos, no podríamos ponerla en un esquema de alta disponibilidad sin afectar el todo.

Vamos a externalizar la base de datos con Amazon RDS, que nos permitirá en su modalidad Multi-AZ implementar este requerimiento.

Primero vamos a aprovisionar la base de datos en Amazon RDS (https://us-east-1.console.aws.amazon.com/rds/home).

En la parte superior derecha asegúrate que estas en la misma región donde creaste el servidor en Amazon Lightsail (en mi caso, si miras el gráfico es en Ohio Zona A)

Para la configuración elige las siguientes opciones:

• Creación estándar.
• Engine MariaDB con la versión 10.6.12 de acuerdo a lo identificado al crear el servidor en Amazon Lghtsail.
• Template Dev/Test para permitir Multi-AZ.
• Coloca una clave maestra (solo caracteres alfanuméricos).
• Tipo de instancia db.m6g.large por ser la menos costosa al día de esta publicación.
• Opción “Multi-AZ DB instance” para despliegue, creando una instancia standby.
• En configuraciones adicionales, crear una base de de datos inicial, como por ejemplo “wordpress”.
• Las demás opciones por defecto

La creación de una base de datos Multi-AZ va a tomar entre 10 a 20 minutos, por lo que deberás esperar antes de poder seguir al siguiente paso.

Aprovisionar una base de datos en Amazon RDS es fácil, pero configurarla apropiadamente de acuerdo a tu requerimiento real requiere conocer más este servicio. Esto tanto para no incurrir en gastos como para no subestimar o sobrestimar la instancia apropiada.

Si deseas conocer mas de este servicios te invito a visitar la Introducción a las bases de datos relacionales en Amazon RDS.

Por último obtén el endpoint de tu nueva base de datos, en el detalle de la base de datos creada.

Habilitación el Grupo de Seguridad

La habilitación del VPC Peering anterior permite la conexión entre la VPC de la región de Amazon Lightsail con la VPC por defecto de la región Ohio para nuestra cuenta.

Sin embargo, no existe una regla que permita el acceso al puerto de la base de datos Amazon RDS aprovisionada. Esto se debe hacer modificando el el grupo de seguridad al que pertenece la base de datos. En mi caso el sg-238da74a:

Así que dando click en el mismo, puedes ir al grupo y adicionar un “Inbound rule” con la IP interna del servidor WordPress en Lightsail, de forma que pueda acceder al puerto 3306 a cualquier instancia que este en ese grupo.

Usando Amazon RDS con WordPress

Bien, una vez que tenemos la base de datos creada, el grupo de seguridad configurado y habilitado el VPC Peering, podemos iniciar el proceso de conexión de nuestra instalación WordPress con esta base de datos.

Este es un tema más bien relacionado a DBAs, pero vamos a dejar las principales ideas de la migración y conexión:

En la consola de Amazon Lighsail identifica la instancia creada y da clic en el icono de linea de comandos “Terminal”.

mysqldump -u root -p bitnami_wordpress > /tmp/backup.sql

Para encontrar el password consulta el siguiente archivo:

cat bitnami_application_password

Restaura los datos en el endpoint de tu nueva base de datos Amazon RDS, por ejemplo con:

mysql -u dbmasteruser -p dbwordpress -h ls-cee65cedbb6cf04dde8adaebc6723f90c1471ab8.cygwzfiaau2b.us-east-2.rds.amazonaws.com < /tmp/backup.sql

Detén la base de datos local con:

sudo /opt/bitnami/ctlscript.sh stop mariadb

Modifica el archivo wp-config.php en la sección de conexión para que tu WordPress apunte a la instancia Amazon RDS.

Normalmente este archivo está en: “/home/bitnami/stack/wordpress” y debes editarlo como root.

Reinicia el servidor apache:

sudo /opt/bitnami/ctlscript.sh restart apache

Excelente, en este punto tu servidor WordPress ya esta trabajando en conjunto con Amazon RDS.

Externalizando el sistema de archivos WordPress en Amazon EFS

Para independizar los archivos que son dinámicos en WordPress, es necesario externalizar idealmente toda la carpeta wp-content.

Sin embargo, muchos archivos de plugins PHP son ejecutados en tiempo real cuando los usuarios del sitio Web acceden al contenido del CMS. Por esta razón se debe combinar esta estrategia con otras técnicas de memoria cache de dichos archivos, de forma que su ejecución sea en memoria o no acudiendo al fuente del sistema de archivos.

En este tutorial de WordPress en AWS no vamos a tomar en cuenta la configuración de cache, pero es un tema que debes considerar en una implementación de estas características.

El primer paso es crear una unidad de disco en el servicio Amazon EFS (https://us-east-1.console.aws.amazon.com/efs/home).

Asegúrate que estés el la misma región del servidor en Amazon Lightsail.

A continuación, selecciona la opción personalizada (Customize) al crearlo y configura los siguiente:

• Ubica un nombre para tu unidad
• Selecciona “Enhanced” en las opciones de Performance y deja la sub opción “Elastic”.
• Deja todas las demás opciones por defecto hasta finalizar la creación.

Verás la lista de unidades EFS una vez creada la unidad. Selecciona de la lista la unidad que acabas de crear y ingresa a la edición de la misma.

En el detalle selecciona la pestaña “Access points” y crea uno para que a través de este puedan conectarse tus servidores WordPress.

Deja todas las opciones por defecto y crea el Access point.

Una vez creado ingresa al Access point y a continuación da clic en “Attach” para ver las instrucciones de como montar esta unidad EFS en los servidores.

Toma nota de ese comando que lo necesitaremos más adelante.

Habilitación el Grupo de Seguridad

Del mismo modo que al aprovisionar la base de datos, al crear una unidad de almacenamiento en red Amazon RDS, vas a necesitar crear una regla “Inbound rule” para permitir que el servidor de Amazon Lightsail pueda ver dicho recurso.

El VPC Peering no va a ser suficiente ya que te garantiza que exista una camino para que las redes se vean, pero no para acceder al recurso específico.

Entonces, lo primero es identificar a que grupo de seguridad pertenece esta unidad, y eso se lo puede ver en la pestaña networking al visualizar la unidad Amazon EFS.

En mi caso es el mismo al que pertenece la base de datos, el sg-283da74a. Sobre este adicionamos la regla para permitir el acceso desde la IP privada del servidor Amazon Lightsail al puerto 2049 que es el usado por el servicio Amazon EFS.

Ve entonces a los grupos de seguridad (https://us-east-2.console.aws.amazon.com/ec2/home?region=us-east-2#SecurityGroups:) y ubica el mismo.

Adiciona la regla.

Listo, con esto tu servidor puede acceder a la unidad de red.

Conectar la unidad Amazon EFS con el servidor WordPress

La tarea aún no ha finalizado, pues debemos montar esta unidad en nuestro servidor Amazon Lightsail y redireccionar el contenido de wp-content en la instalación a esta unidad Amazon EFS.

A continuación , vamos a ingresar al servidor a través de la línea de comandos.

Una vez allí ejecutamos los siguientes comandos:

sudo apt-get install -y netcat
sudo apt-get install -y nfs-common
sudo apt-get install -y nfs-common

nc -zv <ip-access-point> 2049
sudo mkdir /mnt/efs
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport <ip-access-point>:/ /mnt/efs

Ve al directorio de instalación de WordPress, normalmente en “/home/bitnami/stack/wordpress”.

Sincronizar directorio wp-content en /mnt/efs/wp-content/ (‘sudo rsync -a –progress wp-content/ /mnt/efs/wp-content/’)

Renombra los directorios: wp-content a wp-content_old (‘sudo mv wp-content wp-content_old’)

Elimina el directorio antiguo y crea un symlink al nuevo para wp-content

sudo rm -Rf ./wp-content
sudo ln -s /mnt/efs/wp-content/ ./wp-content

Desactiva y desinstala el plugin jetpack (por un tema de cache), y a continuación reinicia el servidor apache:

sudo wp plugin deactivate jetpack
sudo wp plugin uninstall jetpack
sudo /opt/bitnami/ctlscript.sh restart apache

Felicitaciones, has conectado exitosamente tu instalación de WordPress con Amazon EFS, y de esta forma has externalizado tus archivos dinámicos.

Habilitando WordPress con Amazon Elastic Load Balancer (ELB)

Para implementar WordPress en AWS en alta disponibilidad y con tolerancia a fallos necesitamos más de un servidor que atienda las peticiones de los clientes.

Para esto AWS nos proveer de balanceadores de carga, que direccionarán las peticiones a el servidor menos cargado y que este disponible.

El primer paso es ir a la consola de Amazon Lightsail en la pestaña de opciones “Networking” (https://lightsail.aws.amazon.com/ls/webapp/home/networking).

Creamos un balanceador con un nombre apropiado para nuestra instalación.

Al crear el balanceador, el siguiente paso es adicionar el servidor WordPress a este balanceador.

Ahora, ya tendrás publicado el balanceador y podrás acceder a tu sitio web a través de tu endpoint del mismo.

Implementando Alta Disponibilidad (HA) en WordPress

Finalmente vamos a crear un servidor adicional del mismo WordPress para adicionarlo a la configuración y obtener el beneficio de alta disponibilidad en caso de muchas peticiones y tolerancia a fallos en caso de que falle el original.

El primer paso es ingresar a la consola Amazon Lightsail (https://lightsail.aws.amazon.com/ls/webapp/home/instances) y ingresar a la edición del servidor actual de WordPress.

En la pestaña “Snapshots” creamos un snapshot del servidor.

Creado el snapshot vamos a lanzar un servidor con este como template.

Asegúrate que el servidor a aprovisionar este en la misma región (en mi caso Ohio) y sea el mismo tipo de instancia.

Deja las demás opciones por defecto y dar “Crear Instancia”.

Ingresa a este nuevo servidor, a la línea de comandos.

Identifica la IP privada del servidor.

ip addr

Añade la IP (en mi caso 172.26.14.214) con “Inbound Rule” al grupo de seguridad sg-238da74a, de la siguiente forma:

• Una regla para acceso al puerto donde se accede a la unidad Amazon EFS.
• Una regla para acceso al puerto donde se accede a la base de datos Amazon RDS.

Monta la unidad Amazon EFS en el nuevo servidor con el mismo comando inicial del servidor original.

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 172.31.3.222:/ /mnt/efs

Listo, tu servidor esta lito para adicional al stack de servidores gestionados por el balanceador.

A continuación ve a Amazon Lightsail en la pestaña “Networking” (https://lightsail.aws.amazon.com/ls/webapp/home/networking), e ingresa al balanceador.

Adiciona el nuevo servidor al stack.

¡FELICITACIONES! haz implementado WordPress en AWS en alta disponibilidad y tolerancia a fallos.

Resumen de la arquitectura WordPress en AWS.

Acabamos de implementar WordPress en AWS en una arquitectura de alta disponibilidad y tolerancia a fallos. Los punto a destacar son:

• Tenemos una base de datos redundante gracias a el aprovisionamiento en Amazon RDS Multi-AZ.
• Tenemos resiliencia en el sistema de archivos dinámico de WordPress gracias a la unidad aprovisionada en Amazon EFS.
• Tenemos alta disponibilidad y tolerancia a fallos, con dos servidores que entregan el servicio y un balanceador que gestiona las peticiones; esto gracias a Amazon Lightsail.

Video implementacion WordPress en AWS

Si deseas seguir este tutorial paso a paso en video puedes verlos aquí:

Recomendaciones

• Esta arquitectura es referencial, y por supuesto en una real hay muchas cosas que se pueden mejorar como el tema de cache, dimensionamiento de los tipos de instancias y adición de un CDN por ejemplo.
• Un tema delicado es Amazon EFS, puesto que la capacidad de I/O va a ser fundamental en el desempeño del todo. Por esto es importante optimizarla y monitorearla de forma contante.
• Hay que tomar en cuenta que la base de datos, en mi experiencia, es un 50% del desempeño del sitio. Al tener este recurso en Amazon RDS no obliga a pensar en las capacidades que tiene que tener, en red en I/O y el afinamiento de performance. Además al estar en un esquema Multi-AZ, cualquier cambio puede tardar más de 20 minutos, por lo tanto en importante seleccionar las opciones de este recurso con cuidado y a vista de un 50% adicional de rendimiento.
• Hay temas omitidos acá, como los certificados SSL, que son un no negociable en un esquema de producción.
• Adicionar un CDN es una fantástica idea, por dos motivo principales: uno el performance que se ba a ganar en la solicitud de recursos de imágenes y multimedia, y, la más importante es que nos va a ayudar a minimizar múltiples ataques de red previamente a la solicitud al servicio WordPress.
• Exite un whitepaper dedicado a las mejores prácticas de este caso de uso, lo puedes mirar en Mejores prácticas para WordPress en AWS.

Esperamos que sea útil esta tutoríal para implementar WordPress en AWS en HA y Failover y les animamos para que dejen sus comentarios y opiniones para aprender en comunidad.

La respuesta corta a esta pregunta es a través de su servicio AWS Systems Manager (con la abreviatura SSM) y en concreto con la funcionalidad Patch Manager.

Sin embargo, hay que mencionar que la solución AWS Systems Manager no solamente nos ayuda con la aplicación de parches a nivel del Sistema Operativo y a nivel del Software instalado, también nos ofrece una administración y monitorización completa de los recursos desplegados en AWS e incluso de los recursos On-premises que deseemos adicionar a su gestión.

Es realmente impresionante el nivel de gestión que se puede alcanzar con esta herramienta para toda tu infraestructura, te animo mirar todas las posibilidades en la página Características de AWS Systems Manager. Por supuesto, si deseas tener una versión resumida de esta herramienta, me dejas saber en los comentarios .

Aplicando parches en instancias EC2 en AWS

Vale resaltar que no es lo mismo parchear 2 o 3 instancias EC2 que parchear decenas, cientos o miles de instancias distribuidas en varias regiones a lo largo de AWS.

A continuación vamos a describir un conjunto de pasos para poder aplicar los parches en instancias EC2 en AWS:

El primer paso, y parte de las buenas prácticas de aprovisionamiento de recursos en AWS, es marcar los mismos a través de AWS Tags, que son etiquetas asociadas a los recursos aprovisionados en AWS que nos permitirán identificarlos y clasificarlos de acuerdo a nuestra estrategia de Gobierno TI.

Ya ingresando al servicio AWS Systems Manager o SSM, el segundo paso es usar una Línea Base (Baseline) predefinida en la opción Patch Manager de este servicio; esta es una definición de Sistema Operativo y criticidad de actualizaciones preestablecida, y que es aplicable a nuestras instancias EC2.

Claro que tú puedes crear tu propia Línea Base, si tienes algún requerimiento especial que no encuentres en las múltiples opciones que encontrarás predefinidas allí.

Luego, como tercer paso, y que mi criterio es muy recomendado, especialmente si tienes desde decenas de servidores o un nivel de continuidad de negocio que lo exige, es crear Grupos para Parches (Patch groups) en tu definición de Línea Base. La idea es identificar con una etiqueta a un grupo de instancias a parchear que contengan esa definición en sus AWS Tags.

¡Ten cuidado!, y por esto es importante tener definidos Grupos para Parches, ya que AWS no prueba los parches antes de ponerlos a disposición en Patch Manager, porque pertenecen en su mayoría a los fabricantes del Software.

AWS no prueba los parches antes de ponerlos a disposición en Patch Manager.

La definición de una ventana de cambios (Maintenance Windows) viene a ser el cuarto paso, y se la define a través del servicio AWS Systems Manager. Aquí vamos a especificar el horario, la duración y la recurrencia en la cual se va a ejecutar las acciones asociadas a la misma.

El quinto paso, y el más largo, es asociar la ventana de mantenimiento con la Línea Base y el Grupo para Parches, aunque también podrías asociarla con instancias específicas EC2 lo cual no sería recomendado y práctico.

El comando objetivo para correr la Línea Base definida es “AWS-RunPatchBaseline” y lo observarás en las opciones correspondientes en Patch Manager.

Patch Manager no admite actualizaciones de versiones principales (major versions) de Sistemas Operativos como ir de Windows Server 2019 a 2022 o RHEL 7 a RHEL 8.

¡Listo!, una vez realizado estos pasos, está automatizado el proceso de aplicación de parches en tus instancias EC2 en AWS y lo podrás monitorizar desde la opción Managed Instances en el servicio AWS Systems Manager.

Te recomiendo ver una versión más detallada de este proceso en el Blog Aplicación de parches a sus instancias de Windows EC2 con AWS Systems Manager Patch Manager de Stefan Minhas .

Conclusiones

Es completamente posible automatizar la aplicación de parches en los recursos en AWS incluso en instancias On-premises que han sido asociadas al servicio AWS Systems Manager.

AWS Systems Manager es un servicio para la gestión y monitorización de los recursos en AWS que nos permite mantener una administración adecuada de la Nube.

Patch Manager nos provee de Líneas Base predefinidas para mantener actualizados a nuestros servidores de forma automática, pero es importante comprender que AWS no prueba estás actualizaciones previamente ya que en su mayoría son de terceros, por lo que debemos considerarlo en nuestra estrategia de gestión.

Patch Manager maneja solamente actualizaciones menores (minor versions), no está pensado para hacer migraciones de versiones principales.

Hay muchas otras opciones de Patch Manager que no se han visto en esta guía de como parchear los servidores en AWS, como notificaciones, reportes y evaluación de cumplimiento; sin embargo, son muy útiles ya en un escenario empresarial y deberían considerarse.