Construir una casa sobre cimientos débiles es un desastre asegurado. Aunque escribir software es muy parecido a construir una casa, tenemos margen de mejora con respecto a los cimientos que decidimos aprovechar. Sin embargo, en la mayoría de las situaciones, nuestras habilidades para hacer eso están limitadas, y en caso de necesitar cambios significativos, desafortunadamente algunas veces reescribir podría ser la única opción. AWS Well-Architected. Framework brinda a los arquitectos un conjunto de reglas bien definidas que pueden seguir desde el inicio del proyecto y con las que pueden estar seguros de trabajar de manera exitosa desde el principio. Además de los cinco pilares existentes, recientemente se introdujo uno nuevo, el Sustainability Pillar Podríamos dividir las mejores prácticas de este pilar en dos grupos: mejoras de infraestructura y de software/arquitectura. Luego echaremos un vistazo al posible camino hacia la producción. ¡De momento vamos a profundizar e intentemos reducir nuestra huella de carbono!
AWS es un proveedor de IaaS en esencia, y todos los servicios administrados que brinda tienen una infraestructura de última generación como base. Sin embargo, una vez que se toma la decisión de utilizar PaaS o SaaS, la mayoría de las veces no tenemos ese control detallado de su funcionamiento interno. AWS RDS sería un buen ejemplo. Sin embargo, siempre podemos controlar los tres grandes de la infraestructura: cómputo, almacenamiento y redes. Por lo tanto, siempre hay algo que podemos hacer para fortalecer que nuestras cargas de trabajo en estas áreas sean sostenibles.
En el área de redes, la mejora más evidente que podemos hacer al principio es la elección de la región. Siempre debe ser el más cercano a los clientes de nuestra aplicación. Otro paso que podemos dar para reducir el espacio de red es aprovechar AWS PrivateLink y los puntos de conexión de la VPC. Con estos, las cargas de trabajo que se ejecutan en AWS se enrutan directamente a través de la red troncal de AWS cuando se conectan a servicios como S3 o DynamoDB. Por lo general, viajarían a través de Internet.
Algunas de las mejoras informáticas más evidentes que mejoran la sostenibilidad de nuestras cargas de trabajo serían el escalado automático y el escalado programado. El punto de venta más significativo de la nube desde el inicio de la idea fue que sus cargas de trabajo siempre pueden tener esa cantidad ideal de poder de cómputo, de manera que tus clientes no se vean afectados por problemas de rendimiento cuando aumenta el tráfico, y para no tener que pagar de más por los recursos no utilizados cuando no hay tanto tráfico. No podemos olvidarnos de las instancias puntuales para los entornos de desarrollo, las cargas de trabajo intermitentes y las aplicaciones por lotes resistentes a las interrupciones. Hay mucho que ganar en términos de sostenibilidad utilizando estas técnicas básicas.
Finalmente, siempre debemos aprovechar las políticas de ciclo de vida nativas tanto como sea posible en el dominio de almacenamiento. Si tienes un depósito S3 para almacenar registros y sabes que se pueden archivar después de un mes y se pueden eliminar después de dos años, sería recomendable crear políticas automatizadas para mover un objeto a Glacier y luego permitir que S3 lo borre automáticamente. Trata el almacenamiento de imágenes en ECR exactamente de la misma manera. Además, piensa en el posible uso de la compresión siempre que sea posible. Esto también disminuirá la huella de tu red.
En general, si sigues la mayoría de las reglas existentes de los cinco pilares originales bien diseñados, deberías estar bien en términos de sostenibilidad en estas tres áreas principales de infraestructura.
Un par de mejoras en esta área serían relativamente rápidas de implementar. Una de ellas se presentará más adelante en este artículo. Sin embargo, otro tipo de mejoras serían más desafiantes y podrían requerir modificaciones incluso en todas las capas de la aplicación. Sin embargo, definitivamente podrían contribuir a reducir la huella de carbono, aumentar el rendimiento de la carga de trabajo y simplemente ahorrarte algo de dinero a largo plazo.
El procesamiento ad hoc y la reacción inmediata a todas las solicitudes entrantes sin una necesidad comercial justificable probablemente generará una sobrecarga innecesaria durante el inicio. Esto se refiere posiblemente a muchas áreas: puesta en funcionamiento, establecimiento de una conexión a la base de datos, búsqueda de recursos y otras comprobaciones. Imagina un escenario en el que desarrollas una aplicación para gestionar una flota de camiones. Una de las características es una visualización de la ruta para cada uno de los camiones de la flota. Esto se basa en los datos GPS enviados por dispositivos especiales ubicados en los camiones. Estos dispositivos envían información cada cinco segundos. Ahora, podríamos desarrollar un sistema que recibiría estas solicitudes e invocaría Lambdas para cada una de ellas por separado para actualizar el mapa. Si bien esto estaría cerca de un sistema en tiempo real, debemos preguntarnos si realmente necesitamos que los datos se actualicen tantas veces por minuto. Después de un par de reuniones con los analistas comerciales, se determina que una vez por minuto debería ser suficiente para tener una buena visión general de la situación. Entonces, la idea sería dejar que nuestro sistema envíe las señales de estos dispositivos a un AWS Kinesis Stream y permitir que un solo Lambda procese todos estos registros en un lote. Posiblemente tampoco necesitemos procesar los datos de forma independiente para cada camión. Si podemos esperar más de un minuto, deja que Lambda entregue los registros de todos los camiones a la vez. Independientemente de lo que elijamos, podríamos potencialmente ahorrar cientos de nuevos giros ambientales y reducir significativamente nuestra huella de carbono en esta situación. Ten eso en cuenta cuando diseñes la arquitectura para tu próxima aplicación.
Este es mi favorito, aunque por otra parte me llevo un tiempo comprender completamente esta forma de pensar sobre la administración de datos en las capas de una aplicación. Esta estrategia se aplica principalmente a las aplicaciones basadas en web, pero en teoría, cualquier aplicación con una capa de vista claramente separada que no esté renderizada en el lado del servidor debería poder usar esta estrategia. Básicamente el 90% del software desarrollado actualmente debería entrar en esta categoría. Creo que la mayoría de nosotros trabajamos en esas aplicaciones heredadas con esquemas de bases de datos muy normalizados que requerían consultas muy complejas o procedimientos almacenados masivos para obtener un cierto conjunto de datos. Un par de estas consultas se enviarían más tarde a la capa de servicio, donde un par de miles de líneas de código se encargarían del procesamiento. Todo eso para que la capa de presentación pueda recibir una estructura de datos a medida que solo necesita renderizar. Si este tipo de aplicación recibe cientos de solicitudes por segundo, entonces se requiere mucha potencia informática para que las capas de persistencia y servicio procesen todos estos datos. Sin duda ahí hay una gran huella.
A principios de la década de 2000, esta era probablemente la estrategia que se implementaba, ya que los navegadores web y las estaciones de trabajo de los clientes, para el caso, no estaban ni cerca de la potencia de procesamiento actual. Entonces, ¿por qué no aprovechar ese poder que se encuentra en el lado del cliente? Teniendo en cuenta la aplicación que mencioné anteriormente, podemos identificar los patrones de acceso. En base a esto, tendríamos una descripción general de cómo podríamos almacenar esos datos en una base de datos no relacional como DynamoDb. DynamoDb siempre tiene un tiempo de respuesta de mili segundos de un solo dígito y, dado que los datos ya están agregados, nuestro back-end podría servir literalmente como una manguera para moverlos al front-end tal como están. De ahora en adelante, permite que el front-end se encargue de las transformaciones y el procesamiento necesarios además del renderizado. Con la velocidad de los navegadores actuales y los dispositivos/estaciones de trabajo de los clientes, este cambio de arquitectura debería ser transparente para el usuario o apenas perceptible. Para nuestros objetivos eso significaría una posibilidad sustancial de reducción de escala, lo que permitiría grandes ahorros y un aumento significativo en la sostenibilidad.
"En el futuro, todo el código que escribas será lógica comercial".
Werner Vogels, CTO, Amazon.com
Nos guste o no, todos vamos en esa dirección. Para ser honesto, creo que a todos nos debería gustar y que no fuera un sacrificio tratar de consguir este tipo de estado. ¿Qué líder de equipo está perfectamente dispuesto a sacrificar semanas de trabajo de sus ingenieros para escribir una implementación personalizada de una biblioteca de saneamiento de solicitud/respuesta solo para que el equipo tenga control total sobre sus funciones? Al final, solo para darse cuenta de que en realidad le llevó meses, el auditor externo constantemente encuentra agujeros en él y requiere un mantenimiento constante. ¿No sería más inteligente simplemente reutilizar una biblioteca prefabricada mantenida y actualizada diariamente por una empresa de software que se especializa exclusivamente en el dominio de la seguridad? Además de eso, lo más probable es que esta empresa haya dominado el ajuste del rendimiento para que la potencia informática requerida para atender cada solicitud/respuesta sea siempre mínima. Sí, no tendremos un control absolutamente completo de sus características, pero la pregunta es ¿con qué frecuencia tendría una necesidad crítica de desviarse de un estándar bien establecido? No demasiado a menudo, en mi opinión; incluso entonces, deberías preguntarte si las decisiones de ingeniería que finalmente requirieron estas personalizaciones fueron válidas en primer lugar.
La mayoría de los servicios administrados de AWS se originaron a partir de necesidades y escenarios de la vida real de los clientes de AWS. El patrón de requisitos comenzó a ser tan común que surgió de forma natural una solución en forma de servicio gestionado. AWS actualmente tiene más de doscientos servicios que van desde IaaS hasta ofertas de SaaS. ¿Estás seguro de que realmente deseas implementar esa aplicación interna de reconocimiento facial? Simplemente utiliza AWS Rekognition. ¿Tal vez no necesitarás reconocer rostros en algún momento sino voz en su lugar? ¿Reescribiría su programa original (muy ineficiente) y desperdiciaría aún más dinero? Simplemente cambia a AWS Transcribe y utilícela bajo demanda. No creo que tengamos que discutir la escalabilidad de la computación en la nube frente a la escalabilidad local. Puedes estar seguro de que AWS tiene toda la excelencia operativa y de rendimiento detrás de sus servicios administrados. Esto pone implícitamente la sostenibilidad de las cargas de trabajo en los registros más altos posibles.
Con respecto a la medición de los resultados de las mejoras en el AWS Sustainability Pillar, las métricas girarán principalmente en torno a la reducción de los recursos aprovisionados y los recursos consumidos por unidad de trabajo. Antes de pasar a producción, asegúrate de probar primero estas métricas en un entorno de desarrollo/prueba dedicado. Idealmente, debe tener un conjunto de pruebas automatizadas que puedan ejecutar pruebas de extremo a extremo en paralelo, simulando que muchos usuarios usan el sistema simultáneamente. Se recomiendan algunas pruebas manuales solo para asegurarse de que la usabilidad de nuestra aplicación no sufra ninguna degradación.
Una vez que esté listo para la implementación en producción, intenta no hacerlo de forma continua. El Blue/Green deployment sería el más adecuado para este tipo de situación. Aunque es una de las opciones más costosas, tiene esa red de seguridad capaz de volver a tu entorno heredado casi en tiempo real. LaCanary deployment también podría ser una buena idea. Podríamos comenzar con un cauteloso tráfico del 5% re dirigido al nuevo entorno y aumentarlo gradualmente si no detectamos ningún problema significativo.
A largo plazo, el análisis de los informes de uso y costes de AWS podría aportarte mucha información sobre la nueva implementación. Esto es principalmente para verificar si todavía hay algunos puntos calientes y cuándo ocurren principalmente. En combinación junto a estas útiles consultas, AWS Athena podría serte de gran ayuda en este análisis.
Os traemos un capítulo más de nuestra serie "Píldoras técnicas sobre Platform Engineering: más allá de lo que encuentras en la documentación", donde..
Los humanos producimos datos de manera continua: aplicaciones y sistemas recopilan información y, además de monitorear nuestras aplicaciones,..
Codurance se enorgullece de anunciar que ha obtenido la AWS Lambda Service Delivery Designation en la red de socios de AWS (APN), un reconocimiento a..
Suscríbete a nuestra newsletter para que podamos hacerte llegar recomendaciones de expertos y casos prácticos inspiradores
