Blog de Amazon Web Services (AWS)
Cómo decidir dónde alojar aplicaciones .NET en AWS
Por Adi Simon
Con Amazon Web Services (AWS), usted cuenta con tres opciones para cómputo: instancias, contenedores y funciones como servicio. Si bien todos ellos se pueden utilizar para alojar aplicaciones .NET, elegir el tipo correcto puede ayudarle a conseguir la mejor arquitectura posible para su aplicación. En esta entrada de blog, se revisan casos de uso comunes con aplicaciones .NET, luego se profundizará, en base a lo anterior, qué servicios de cómputo son óptimos para estas aplicaciones.
Servicios de cómputos para aplicaciones .NET
Las aplicaciones .NET pueden ejecutarse en cualquiera de los servicios de cómputo de AWS. A continuación se presentan los más comunes que se usan para ejecutar aplicaciones .NET en AWS:
- Instancias: Son servidores virtuales, las cuales permiten cambiar capacidades o características con un botón o también, con llamados a la API. AWS ofrece estas instancias bajo el servicio de Amazon Elastic Compute Cloud (EC2), los cuales vienen en diferentes familias y tamaños.
- Contenedores: Estos se presentan como un método de virtualización de sistemas operativos que le permiten al cliente ejecutar una aplicación y sus dependencias en procesos aislados de recursos. Los contenedores se pueden utilizar sí se necesita controlar la instalación, configuración y administración de un entorno informático. AWS, en este caso, proporciona dos plataformas de orquestación de contenedores: Amazon Elastic Container Service (ECS) y Amazon Elastic Kubernetes Service (EKS). Por otra parte, AWS Fargate es el motor informático que se puede usar para ejecutar contenedores sin necesidad de administrar los servidores subyacentes.
- Funciones: Representa un entorno para el código que se desea aplicar respecto al tiempo de ejecución del mismo. AWS Lambda le permite ejecutar código sin necesidad de instancias o contenedores de Amazon EC2 y sin necesidad de configurar servidores.
Aplicaciones web y APIs
En términos generales, las aplicaciones web y las API responden a solicitudes de visualización de datos y mutación a través del protocolo HTTP. Algunas de sus características deseadas incluyen:
- Tiempo de respuesta rápido: los usuarios finales esperan respuestas rápidas, tanto que, incluso retrasos leves pueden afectar significativamente su experiencia y tasas de conversión, como se explica en un artículo de investigación del Nielsen Norman Group.
- Carga impredecible: Es un reto predecir con precisión el volumen de las solicitudes. Asi mismo, es posible que desee no utilizar toda la carga de trabajo durante periodos de reposo para tener una mayor rentabilidad. Pero que de la misma forma pueda escalar automáticamente los recursos en respuesta al aumento de la demanda.
- Alta disponibilidad: Las aplicaciones web y móviles son las principales vitrinas digitales para muchas empresas. Esto implica que un corto tiempo de inactividad puede afectar significativamente a estas compañías, debdio a la experiencia del cliente.
En los desarrollos tradicionales se suelen alojar aplicaciones web y API en máquinas virtuales que ejecutan Internet Information Services (IIS) en Windows Server. En este caso se puede optar por usar las instancias de Windows de Amazon EC2, estas pueden imitar en gran medida una configuración local tradicional. Sin embargo, si se está desarrollando una nueva aplicación o se quieren más beneficios de computación en la nube, puede seguir leyendo.
Usualmente, las aplicaciones web suelen consistir en una mezcla de contenido estático y dinámico. El contenido estático incluye activos como HTML, CSS, imágenes y videos que no cambian con frecuencia. El contenido dinámico se personaliza para cada espectador de la aplicación web y requiere procesamiento del lado del servidor, como por ejemplo, la recuperación de datos de una base de datos. Se necesita muy poca potencia computacional para servir contenido estático, por lo que es más rentable y óptimo alojar contenido estático en servicios de almacenamiento como Amazon Simple Storage Service (Amazon S3). También se puede configurar Amazon CloudFront como punto de entrada para que los usuarios de nuestros clientes, así estén en cualquier parte del mundo accedan al contenido con baja latencia. La arquitectura que se muestra en la Figura 1 es lo que se va a utilizar como línea base para discutir las opciones de cómputo.
Figura 1: Amazon CloudFront con dos orígenes que sirven contenido estático y dinámico
Un servicio informático sin servidor, como AWS Lambda, tiene como ventaja que permite cumplir con las funcionalidades de una aplicación deseados sin la sobrecarga de administrar la infraestructura subyacente. Adicionalmente, la computación sin servidor viene con escalado automático, alta disponibilidad incorporada, mayor agilidad y un modelo de facturación de pago por uso. La Figura 2 muestra una arquitectura que puede servir con una aplicación web ASP.NET o, también, una web basada en API implementada en AWS Lambda:
Figura 2: Arquitectura de aplicaciones web sin servidor en AWS
Cabe resaltar que esta arquitectura requiere .NET 6.0 o posterior. Para nuevos proyectos, esta arquitectura puede ser una buena opción. Sin embargo, es posible que primero sea necesario convertir la base de código de aplicaciones heredadas existentes para usar una versión más reciente de .NET.
Para ello, puede utilizar herramientas como AWS Toolkit for .NET Refactoring o Porting Assistant para .NET que sirve para ayudar a convertir sus aplicaciones C# o VB.NET de .NET Framework 3.5 o posterior a las modernas.
Después de portar la base de código de la aplicación, aún puede tomar mucho tiempo y esfuerzo rediseñarla. Para tales escenarios, puede ser viable contenerizar estas aplicaciones y ejecutarlas en servicios como Amazon ECS o Amazon EKS. Los contenedores son livianos y generalmente se inician más rápido que las máquinas virtuales. Si ya tiene habilidades de Kubernetes dentro de su organización, entonces es buena idea optar por Amazon EKS, ya que puede brindarle una transición operativa más fluida.
Ambos servicios de contenedores se pueden desplegar usando AWS Fargate. (Tenga en cuenta que al momento de escribir este artículo, Amazon EKS no admite contenedores de Windows con AWS Fargate). Con AWS Fargate, no es necesario aprovisionar, configurar ni escalar clústeres de máquinas virtuales para ejecutar contenedores. Esto incluso elimina la necesidad de elegir entre tipos de servidor, cuándo hay que escalar los clústeres y como optimizar el empaque de clústeres.
La figura 3 a continuación muestra la implementación de una aplicación web ASP.NET en AWS Fargate, con un balanceador de carga entre dos zonas de disponibilidad (AZ). Se puede usar una arquitectura similar para las API web, aunque las API web suelen utilizar Amazon API Gateway frente al blanaceador de carga de la aplicación.
Figura 3: Cargas de trabajo con balanceador de carga en AWS Fargate
Servicios en segundo plano
A diferencia de las aplicaciones web y las API web, los servicios que funcionan en segundo plano, como los servicios de trabajo, generalmente no tienen una interfaz de usuario. Son “sin cabeza” y a menudo se activan a intervalos de tiempo regulares o en respuesta a eventos del sistema en lugar de eventos de usuario. Estos se pueden dividir en dos subcategorías:
- Trabajos por lotes: estos se ejecutan a intervalos establecidos y requieren recursos de cómputos constantes. Pueden tardar horas en completarse. Los ejemplos incluyen trabajos de conciliación de fin de mes o procesamiento por lotes durante la noche.
- Procesadores en segundo plano: estos deben estar disponibles para realizar el procesamiento asíncrono bajo demanda. Suelen completar su trabajo en un plazo mucho más corto, en rangos de segundos o minutos. Como ejemplo se tienen la generación de informes y el procesamiento de colas.
Las opciones para trabajos por lotes de larga duración incluyen Amazon EC2, Amazon ECS o Amazon EKS (incluido el tipo de lanzamiento de AWS Fargate). Para todas estas opciones, si se tienen trabajos tolerantes a fallas, es decir que una caída del servicio no comprometa a la compañía, se pueden aprovechar las instancias de tipo Spot de Amazon EC2, que ofrecen costos hasta un 90% más bajos en comparación con los precios bajo demanda.
Aquí la migración de cargas de trabajo, desde entornos locales existentes y desde servicios de Windows, a la nube brinda una oportunidad perfecta para empezar a modernizar. Por ejemplo, en lugar de implementar un servicio de Windows, una versión .NET moderna permite que las aplicaciones de servicio de trabajo se ejecuten en Linux utilizando el administrador de servicios “systemd”. En el caso de los trabajos por lotes a gran escala basados en contenedores, AWS Batch elimina la necesidad de configurar y administrar la infraestructura informática, al tiempo que simplifica la coordinación de trabajos entre varias zonas de disponibilidad dentro de una región de AWS. Sin embargo, no todas las cargas de trabajo son adecuadas para AWS Batch. Visite AWS Batch lo que debe y no debe hacer , aquí puede obtener más información sobre las características de las cargas de trabajo adecuadas.
Para aplicaciones que suelen ser de corta duración y necesitan estar disponibles bajo demanda, se pueden utilizar servicios informáticos sin servidor para el procesamiento en segundo plano. Estos procesos en segundo plano se pueden completar en muy poco tiempo (por ejemplo, en segundos) y pueden aprovechar en gran medida el servicio de AWS Lambda, el cual puede programarse usando Amazon EventBridge Scheduler o usarse desde una cola de Amazon SQS (Figura 4).
Figura 4: Uso de Lambda para procesadores de fondo de corta duración
Para procesos en segundo plano que tengan un cliclo de vida más largo, una opción es alojarlos con Amazon EC2, Amazon ECS o Amazon EKS. Sin embargo, al utilizar esos servicios, es importante considerar los requisitos de tiempo de actividad y sus implicaciones de costos. Las instancias tipo spot de Amazon EC2 pueden ayudarle a minimizar los costos, pero tenga en cuenta que los precios relacionados pueden fluctuar por encima del precio máximo que haya establecido a priori cuando la demanda de capacidad es alta, por lo que se recomienda para cargas de trabajo tolerantes a fallas. Otra opción es dividir el procesador en segundo plano en múltiples pasos más pequeños que pueden ser realizados por múltiples funciones Lambda, que pueden ser orquestadas usando AWS Step Functions, como se muestra en la Figura 5:
Figura 5: Uso del flujo de trabajo estándar de Step Function para encadenar múltiples funciones lambda
Conclusión
La ejecución de cargas de trabajo .NET en instancias de Windows de Amazon EC2 o en contenedores de Windows, Amazon ECS o Amazon EKS se pueden considerar como el enfoque por defecto. Sin embargo, es importante considerar las características de la aplicación y otros factores que influyen, como las operaciones, la eficiencia del rendimiento y el costo para llegar al servicio adecuado para alojar cargas de trabajo.
Así sea que esté buscando crear una nueva aplicación .NET o migrar las existentes a la nube, con la opción de por ejemplo ejecutar .NET en Linux mientras se puede beneficiar de los servicios sin servidor, como AWS Lambda, AWS Step Functions y AWS Fargate; e integrándose con otros servicios basados en la nube, como Amazon EventBridge, Amazon S3 y Amazon SQS, usar la integración de los servicios aquí descritos tienden a lograr los mejores resultados.
AWS tiene muchos más servicios y más funciones dentro de esos servicios que cualquier otro proveedor de nube, lo que hace que sea más rápido, fácil y rentable trasladar sus aplicaciones existentes a la nube y crear casi cualquier cosa que pueda imaginar. Puede implementar sus aplicaciones de Microsoft en la infraestructura que necesitan para impulsar los resultados comerciales que desea. Visite nuestros blogs de .NET on AWS y AWS Database para obtener orientación y opciones adicionales para sus cargas de trabajo de Microsoft. Contáctenos para comenzar su viaje de migración y modernización hoy mismo.
Este blog es una traducción del blog en ingles Deciding where to host .NET applications on AWS
Acerca de los autores
 |
|
Traductores y Revisores
 |
|
 |
|