Patrones de Software Verde
La Green Software Foundation comenzó a trabajar en Patrones de Software Verde.
Dado que estamos muy alineados con los objetivos de la Green Software Foundation, queríamos llamar la atención de todos sobre algunos de esos patrones aplicados en el contexto de DownToZero.Cloud.
Inteligencia Artificial (IA)
https://patterns.greensoftware.foundation/catalog/ai/
Dado que no ofrecemos servicios relacionados con IA, omitimos esta sección del catálogo.
Nube
https://patterns.greensoftware.foundation/catalog/cloud/
Cachear datos estáticos
Desde una perspectiva de eficiencia energética, es mejor reducir el tráfico de red leyendo los datos localmente a través de una caché en lugar de acceder a ellos de forma remota a través de la red.
Estamos haciendo caching en muchas instancias durante el procesamiento de solicitudes, por ejemplo, nuestro runtime de trabajos asíncronos cachea localmente imágenes docker, para no necesitar una descarga completa en cada invocación.
También usamos hashes de imágenes para las imágenes de contenedores tanto como sea posible para reducir la carga en tiempo real al instanciar nuevos contenedores.
Elegir la región más cercana a los usuarios
Desde una perspectiva de eficiencia energética, es mejor acortar la distancia que recorre un paquete de red para que se requiera menos energía para transmitirlo. De forma similar, desde una perspectiva de carbono incorporado, cuando un paquete de red atraviesa menos equipos informáticos, somos más eficientes con el hardware.
Como no somos multi-región, ni exponemos directamente la disposición regional de nuestra infraestructura, esto no puede ser influenciado por un usuario. Internamente intentamos optimizar la regionalidad tanto como sea posible, sin sacrificar durabilidad y disponibilidad.
Comprimir datos almacenados
Almacenar demasiados datos sin comprimir puede resultar en un desperdicio de ancho de banda y aumentar los requerimientos de capacidad de almacenamiento.
Estamos comprometidos a almacenar únicamente datos comprimidos.
Tanto Objectstore como Container Registry soportan compresión a nivel de almacenamiento. Esto está integrado en ambos servicios.
El servicio de Observabilidad tiene un mecanismo interno de tiering que mueve datos de una capa de almacenamiento caliente a un formato más frío y mejor comprimido después de un período fijo de retención.
Comprimir datos transmitidos
Desde una perspectiva de eficiencia energética, es mejor minimizar el tamaño de los datos transmitidos para que se requiera menos energía debido a que se reduce el tráfico de red.
Contenerizar tus cargas de trabajo
Los contenedores permiten usar los recursos con mayor flexibilidad, ya que las cargas de trabajo pueden moverse fácilmente entre máquinas. Los contenedores permiten el bin packing y requieren menos recursos computacionales que las máquinas virtuales, lo que significa una reducción en la asignación innecesaria de recursos y un aumento en la utilización de los recursos computacionales.
Sólo soportamos cargas de trabajo contenerizadas. Poder mover cargas de trabajo entre ubicaciones es fundamental en el núcleo de DTZ para permitir desplazarlas a entornos de ejecución más eficientes según demanda.
Eliminar recursos de almacenamiento no utilizados
Desde una perspectiva de carbono incorporado, es mejor eliminar los recursos de almacenamiento no usados para ser eficientes con el hardware y optimizar la capa de almacenamiento para la tarea.
Nuestro object store soporta expiraciones en objetos, de modo que cada entidad puede ser limpiada después de que ya no se use. Nuestro registro de contenedores también ejecuta trabajos de limpieza configurables para reducir la cantidad de objetos almacenados.
Encriptar lo que sea necesario
La protección de datos mediante cifrado es un aspecto crucial de nuestras medidas de seguridad. Sin embargo, el proceso de cifrado puede ser intensivo en recursos a múltiples niveles. Primero, la cantidad de CPU requerida varía según el algoritmo elegido, y los algoritmos más complejos suelen demandar mayor poder computacional. Además, el cifrado puede aumentar los requerimientos de almacenamiento, ya que infla el tamaño de los datos almacenados porque generalmente contiene metadatos adicionales y relleno, especialmente notorio en archivos pequeños. Por otro lado, el cifrado es una tarea repetitiva que debe realizarse cada vez que se obtiene o actualiza un dato. Esta naturaleza repetitiva puede contribuir a un mayor consumo energético, especialmente en sistemas de alto rendimiento.
Evaluar otras arquitecturas de CPU
Las aplicaciones se construyen con una arquitectura de software que mejor se adapte a la necesidad del negocio que están atendiendo. Los proveedores cloud facilitan la evaluación de otros tipos de CPU, como x86-64, que pueden incluirse en la evaluación junto con muchas alternativas rentables que ofrecen buen desempeño por vatio.
Por ahora sólo soportamos una arquitectura de CPU, X86. Actualmente no tenemos recursos para evaluar diferentes arquitecturas.
Usar un service mesh sólo si es necesario
Un service mesh despliega contenedores adicionales para la comunicación, típicamente en un patrón sidecar, para proveer más capacidades operativas. Esto puede incrementar el uso de CPU y el tráfico de red, pero también permite desacoplar tu aplicación de estas capacidades, trasladándolas desde la capa de aplicación a la capa de infraestructura.
Dado que nuestra red no depende de ninguna abstracción de kubernetes, tampoco necesitamos un service mesh.
Terminar TLS en el gateway de borde
El protocolo Transport Layer Security (TLS) asegura que todos los datos transmitidos entre el servidor web y los navegadores permanezcan privados y cifrados. Sin embargo, terminar y restablecer TLS aumenta el uso de CPU y podría ser innecesario en ciertas arquitecturas.
Implementar diseño sin estado
El estado del servicio se refiere a los datos en memoria o disco que requiere un servicio para funcionar. El estado incluye estructuras de datos y variables miembro que el servicio lee y escribe. Dependiendo de cómo se arquitecte el servicio, el estado también podría incluir archivos u otros recursos almacenados en el disco.
Nuestros servicios existentes, como Container Services y Container Jobs, se basan en diseño sin estado y también proveen esas capacidades a nuestros usuarios.
Ajustar los objetivos de nivel de servicio a las necesidades del negocio
Si son aceptables los tiempos de inactividad del servicio, es mejor no buscar la máxima disponibilidad sino diseñar la solución según las necesidades reales del negocio. Garantías de disponibilidad más bajas pueden ayudar a reducir el consumo energético usando menos componentes de infraestructura.
Nuestro SLO es proveer el mejor servicio posible, pero sin comprometer la eficiencia ni la sostenibilidad. Por lo tanto, nuestros servicios dependen fuertemente del escalado automático para siempre proveer un nivel adecuado de servicio con mínima sobrecarga.
Ajustar los requisitos de utilización de máquinas virtuales (VM)
Es mejor tener una VM funcionando a alta utilización que dos a baja utilización, no sólo en términos de proporcionalidad energética, sino también en términos de carbono incorporado.
Hasta ahora no ofrecemos servicios basados en VM. Toda nuestra infraestructura se basa en contenedores para ofrecer una experiencia más fluida.
Ajustar los requisitos de utilización con servidores preconfigurados
Es mejor tener una VM funcionando a alta utilización que dos a baja utilización, no sólo en términos de proporcionalidad energética, sino también en términos de carbono incorporado.
Buscamos alta utilización en nuestra infraestructura, pero esos componentes no están expuestos al usuario final. El usuario sólo ve contenedores como abstracción. Dado que proporcionamos métricas de eficiencia energética, estas pueden variar según la utilización de la infraestructura subyacente.
Minimizar el número total de entornos desplegados
En una aplicación dada, puede ser necesario utilizar múltiples entornos en el flujo de trabajo de la aplicación. Normalmente, un entorno de desarrollo se usa para actualizaciones regulares, mientras que entornos de staging o pruebas se usan para asegurar que no hay problemas antes de que el código llegue a un entorno de producción al que los usuarios puedan acceder.
Optimizar la utilización del almacenamiento
Es mejor maximizar la utilización del almacenamiento para que la capa de almacenamiento esté optimizada para la tarea, no solo en términos de proporcionalidad energética sino también en términos de carbono incorporado.
Optimizar la utilización media de CPU
El uso y la utilización de la CPU varían a lo largo del día, a veces de manera considerable para diferentes requerimientos computacionales. Cuanto mayor sea la variación entre la utilización media y máxima de CPU, más recursos deben estar provisionados en modo espera para absorber esos picos de tráfico.
Optimizar el impacto en dispositivos y equipos del cliente
Las aplicaciones se ejecutan o muestran en el hardware del cliente. El hardware utilizado por el cliente tiene una huella de carbono incorporada a través de su producción y la electricidad requerida durante su uso. Optimizar el diseño de software y arquitectura para extender la vida útil de los dispositivos del cliente reduce la intensidad de carbono de la aplicación. Idealmente, el cliente puede usar el hardware hasta su fallo o hasta que se vuelva obsoleto.
Optimizar la utilización máxima de CPU
El uso y la utilización de la CPU varían a lo largo del día, a veces de manera considerable para diferentes requerimientos computacionales. Cuanto mayor sea la variación entre la utilización media y máxima de CPU, más recursos deben estar provisionados en modo espera para absorber esos picos de tráfico.
Poner en cola solicitudes de procesamiento no urgentes
Todos los sistemas tienen períodos de carga pico y baja. Desde una perspectiva de eficiencia del hardware, somos más eficientes si minimizamos el impacto de picos de solicitud con una implementación que permita una utilización uniforme de los componentes. Desde una perspectiva de eficiencia energética, somos más eficientes si aseguramos que los recursos inactivos se mantengan al mínimo.
Nuestro servicio Container Jobs es la manifestación de ese objetivo como servicio dentro de DTZ.
Reducir datos transmitidos
Desde una perspectiva de eficiencia energética, es mejor minimizar el tamaño de los datos transmitidos para que se requiera menos energía debido a que se reduce el tráfico de red.
Eliminar activos no usados
Monitorear y analizar la aplicación y la factura cloud para identificar recursos que ya no se usan o pueden reducirse.
Reducir aplicaciones Kubernetes cuando no se usan
Para reducir las emisiones de carbono y costos, los clústeres Dev&Test Kubernetes pueden apagar nodos (VMs) fuera del horario laboral (p.ej. en la noche y durante fines de semana). => así, la optimización se implementa a nivel de clúster.
No ofrecemos servicios basados en Kubernetes.
Reducir aplicaciones cuando no se usan
Las aplicaciones consumen CPU incluso cuando no están activamente en uso. Por ejemplo, temporizadores en segundo plano, recolección de basura, comprobaciones de salud, etc. Incluso cuando la aplicación está apagada, el hardware subyacente consume energía en modo inactivo. Esto también puede ocurrir con aplicaciones y hardware de desarrollo y prueba fuera del horario laboral.
DownToZero, como dice su nombre, tiene el escalado hacia abajo como núcleo de nuestras acciones. Así que buscamos que todos los servicios ofrezcan escalados hacia abajo.
Escalar infraestructura con la carga de usuarios
La demanda de recursos depende de la carga de usuarios en un momento dado. Sin embargo, la mayoría de las aplicaciones funcionan sin considerar esto. Como resultado, los recursos están infrautilizados e ineficientes.
Escalar cargas de trabajo Kubernetes según métricas relevantes de demanda
Por defecto, Kubernetes escala cargas de trabajo basado en la utilización de CPU y RAM. En la práctica, sin embargo, es difícil correlacionar los impulsores de demanda de tu aplicación con la utilización de CPU y RAM.
No ofrecemos servicios Kubernetes.
Escalar componentes lógicos independientemente
Una arquitectura basada en microservicios puede reducir la cantidad de recursos computacionales requeridos, ya que permite escalar cada componente independiente según su propia demanda.
Escanear en busca de vulnerabilidades
Muchos ataques a la infraestructura en la nube buscan malutilizar recursos desplegados, lo que conduce a un pico innecesario en uso y costo.
Establecer políticas de retención de almacenamiento
Desde una perspectiva de carbono incorporado, es mejor tener un mecanismo automatizado para eliminar recursos de almacenamiento no usados para que seamos eficientes con el hardware y la capa de almacenamiento esté optimizada para la tarea.
Eliminar tráfico de menor prioridad
Cuando los recursos están limitados durante eventos de alto tráfico o cuando la intensidad de carbono es alta, se generarán más emisiones de carbono desde tu sistema. Añadir más recursos para soportar mayores requerimientos de tráfico introduce más carbono incorporado y demanda más electricidad. Continuar manejando todas las solicitudes durante alta intensidad de carbono incrementará las emisiones globales para tu sistema. Eliminar tráfico de menor prioridad durante estos escenarios ahorrará recursos y emisiones de carbono. Este enfoque requiere entender tu tráfico, incluyendo qué solicitudes de llamada son críticas y cuáles pueden soportar intentos de reintento y fallos.
Cambiar el horario de jobs cron Kubernetes
Las emisiones de carbono de un sistema software dependen de la energía consumida por ese software, pero también de la intensidad de carbono de la electricidad con que se alimenta. Por esta razón, ejecutar software eficiente en energía sobre una red eléctrica con alta intensidad de carbono podría no ser eficiente para reducir emisiones globales.
Aunque no ofrecemos servicios Kubernetes, nuestro Container Jobs ofrece la posibilidad de un modelo de horarios flexibles. Consulta nuestra documentación para más información.
Usar llamadas de red asíncronas en vez de síncronas
Cuando se hacen llamadas a través de límites de proceso a bases de datos, sistemas de archivos o APIs REST, confiar en llamadas síncronas puede bloquear el hilo que llama, generando carga adicional en la CPU.
Usar patrones de interruptor de circuito (circuit breaker)
Las aplicaciones modernas necesitan comunicarse con otras aplicaciones regularmente. Dado que estas otras aplicaciones tienen su propio calendario de despliegue, tiempos de inactividad y disponibilidad, la conexión de red podría presentar problemas. Si la otra aplicación no es accesible, todas las solicitudes de red hacia ella fallarán y las futuras serán inútiles.
Usar herramientas y controles nativos de seguridad de red cloud
Firewalls de red y de aplicaciones web protegen contra ataques comunes y mitigan bots maliciosos. Estas herramientas ayudan a eliminar transmisiones de datos innecesarias y reducen la carga en la infraestructura cloud, usando menor ancho de banda y menos infraestructura.
Usar protección DDoS
Los ataques de denegación de servicio distribuida (DDoS) se usan para aumentar la carga del servidor hasta impedir que responda a solicitudes legítimas. Esto suele hacerse para dañar al propietario del servicio o hardware. Debido a la naturaleza del ataque, muchos recursos ambientales se consumen con solicitudes sin sentido.
Usar VMs procesadoras nativas de la nube
Las máquinas virtuales cloud tienen diferentes capacidades según los procesadores de hardware. Por lo tanto, usar máquinas virtuales basadas en la eficiencia de sus procesadores impactaría la eficiencia del hardware y reduciría las emisiones de carbono.
Usar servicios serverless en la nube
Los servicios serverless son gestionados por el proveedor cloud para la aplicación. Escalan dinámicamente según la carga necesaria para cumplir la tarea del servicio y aplican mejores prácticas para mantener el uso de recursos al mínimo.
Todas las ofertas de DownToZero son servicios serverless en la nube.
Web
https://patterns.greensoftware.foundation/catalog/web/
Como no ofrecemos servicios relacionados con Web, omitimos esta sección del catálogo.