Green Software Patterns
La Green Software Foundation comenzó a trabajar en Green Software Patterns.
Dado que estamos muy alineados con los objetivos de la Green Software Foundation, quisimos traer algunos de esos patrones aplicados en el contexto de DownToZero.Cloud a la atención de todos.
Artificial Intelligence (AI)
https://patterns.greensoftware.foundation/catalog/ai/
Como no ofrecemos servicios relacionados con AI, omitimos esta sección del catálogo.
Cloud
https://patterns.greensoftware.foundation/catalog/cloud/
Cache static data
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 remotamente por la red.
Estamos usando caché en muchas instancias mientras procesamos solicitudes, por ejemplo, nuestro runtime de trabajos asíncronos hace caché localmente de las imágenes docker, para no necesitar un pull completo en cada invocación.
También usamos hashes de imagen para las imágenes de contenedores tanto como es posible para reducir la carga en tiempo real al instanciar nuevos contenedores.
Choose the region that is closest to users
Desde una perspectiva de eficiencia energética, es mejor acortar la distancia que un paquete de red recorre para que se requiera menos energía para transmitirlo. De manera similar, desde una perspectiva de carbono incorporado, cuando un paquete de red atraviesa menos equipos computacionales, 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 tratamos de optimizar por regionalidad tanto como sea posible, sin sacrificar durabilidad y disponibilidad.
Compress stored data
Almacenar demasiados datos sin comprimir puede resultar en desperdicio de ancho de banda e incrementar los requerimientos de capacidad de almacenamiento.
Nos comprometemos a almacenar únicamente datos comprimidos.
Tanto nuestro Objectstore como el Container Registry soportan compresión a nivel de almacenamiento. Esto está incorporado en ambos servicios. El servicio de Observabilidad tiene un mecanismo interno de tiering que mueve datos de un almacenamiento caliente a un formato más frío y mejor comprimido después de un periodo de retención fijo.
Compress transmitted data
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 la reducción del tráfico de red.
Containerize your workloads
Los contenedores permiten usar los recursos de forma más flexible, 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 de cómputo.
Solo soportamos cargas de trabajo containerizadas. Poder mover cargas entre ubicaciones es necesario en el núcleo de DTZ para permitir desplazar cargas de trabajo a entornos de ejecución más eficientes bajo demanda.
Delete unused storage resources
Desde una perspectiva de carbono incorporado, es mejor eliminar recursos de almacenamiento no usados para ser eficientes con el hardware y optimizar la capa de almacenamiento para la tarea.
Nuestra object store soporta expiraciones en objetos, para que cada entidad pueda ser limpiada después de que ya no se use. Nuestro container registry también ejecuta trabajos de limpieza configurables para reducir la cantidad de objetos almacenados.
Encrypt what is necessary
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 en 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 potencia computacional. Además, el cifrado puede aumentar los requisitos de almacenamiento al inflar el tamaño de los datos debido a metadatos adicionales y relleno, especialmente en archivos pequeños. Asimismo, el cifrado es una tarea repetitiva que se realiza cada vez que se recuperan o actualizan datos. Esta naturaleza repetitiva puede contribuir a un mayor consumo energético, especialmente en sistemas de alto rendimiento.
Evaluate other CPU architectures
Las aplicaciones se construyen con una arquitectura de software que mejor se adapta a la necesidad de negocio que atienden. Los proveedores cloud facilitan evaluar otros tipos de CPU, como x86-64, que pueden ser incluidos en la evaluación junto con muchas alternativas rentables que ofrecen buen rendimiento por watt.
Por ahora solo soportamos una arquitectura de CPU, X86. Actualmente no tenemos los recursos para evaluar diferentes arquitecturas.
Use a service mesh only if needed
Un service mesh despliega contenedores adicionales para comunicación, típicamente en un patrón sidecar, para proveer más capacidades operativas. Esto puede resultar en aumento de uso de CPU y tráfico de red pero también permite desacoplar tu aplicación de estas capacidades, moviéndolas de la capa de aplicación a la capa de infraestructura.
Dado que nuestra red no depende de abstracciones de Kubernetes, tampoco tenemos uso para un service mesh.
Terminate TLS at border gateway
Transport Layer Security (TLS) asegura que todos los datos intercambiados entre el servidor web y los navegadores sigan siendo privados y cifrados. Sin embargo, terminar y restablecer TLS incrementa el uso de CPU y puede ser innecesario en ciertas arquitecturas.
Implement stateless design
El estado del servicio se refiere a los datos en memoria o en disco que necesita un servicio para funcionar. El estado incluye las estructuras de datos y variables miembro que el servicio lee y escribe. Dependiendo de cómo esté arquitecturado el servicio, el estado puede incluir también archivos u otros recursos almacenados en disco.
Nuestros servicios existentes, como Container Services y Container Jobs, se basan en diseño sin estado y también ofrecen esas capacidades a nuestros usuarios.
Match your service level objectives to business needs
Si son aceptables los tiempos de inactividad del servicio, es mejor no buscar la más alta 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, sin comprometer eficiencia y sostenibilidad. Por eso nuestros servicios dependen mucho del escalado automático para siempre proveer un nivel de servicio adecuado con mínima sobrecarga.
Match utilization requirements of virtual machines (VMs)
Es mejor tener una VM funcionando a una mayor utilización que dos a baja utilización, no solo en términos de proporcionalidad energética sino también en carbono incorporado.
Hasta ahora no ofrecemos servicios basados en VM. Todas nuestras ofertas de infraestructura están basadas en contenedores para ofrecer una experiencia más optimizada.
Match utilization requirements with pre-configured servers
Es mejor tener una VM funcionando a una mayor utilización que dos a baja utilización, no solo en términos de proporcionalidad energética sino también en carbono incorporado.
Buscamos alta utilización en nuestra infraestructura, pero esos componentes no son visibles al usuario final. El usuario solo ve contenedores como abstracción. Dado que proveemos métricas de eficiencia energética, estas pueden variar según la utilización de la infraestructura subyacente.
Minimize the total number of deployed environments
En una aplicación dada, puede ser necesario utilizar múltiples entornos en el flujo de trabajo. Típicamente, se usa un entorno de desarrollo para actualizaciones regulares, mientras que los entornos de staging o testing se usan para asegurarse de que no hay problemas antes de que el código llegue a producción donde los usuarios pueden tener acceso.
Optimise storage utilization
Es mejor maximizar la utilización del almacenamiento para optimizar la capa de almacenamiento para la tarea, no solo en términos de proporcionalidad energética sino también en carbono incorporado.
Optimize average CPU utilization
El uso y utilización de CPU varía a lo largo del día, a veces drásticamente según los requerimientos computacionales. Cuanto mayor sea la variación entre los valores promedio y pico de utilización de CPU, más recursos deben estar provisionados en modo standby para absorber esos picos de tráfico.
Optimize impact on customer devices and equipment
Las aplicaciones se ejecutan o se muestran en hardware del cliente. El hardware usado por el cliente tiene una huella de carbono incorporada a través de su producción y electricidad requerida durante su uso. Optimizar el diseño y arquitectura de software 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 quede obsoleto.
Optimize peak CPU utilization
El uso y utilización de CPU varía a lo largo del día, a veces drásticamente según los requerimientos computacionales. Cuanto mayor sea la variación entre los valores promedio y pico de utilización de CPU, más recursos deben estar provisionados en modo standby para absorber esos picos de tráfico.
Queue non-urgent processing requests
Todos los sistemas tienen periodos de carga máxima y baja. Desde una perspectiva de eficiencia hardware, somos más eficientes minimizando el impacto de picos de solicitudes con una implementación que permita una utilización pareja de componentes. Desde una perspectiva energética, somos más eficientes asegurando que los recursos en espera sean mínimos.
Nuestro servicio Container Jobs es la manifestación de ese objetivo como servicio dentro de DTZ.
Reduce transmitted data
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 la reducción del tráfico de red.
Remove unused assets
Monitorizar y analizar la aplicación y la factura cloud para identificar recursos que ya no se usan o pueden reducirse.
Scale down kubernetes applications when not in use
Para reducir emisiones de carbono y costos, los clústeres Dev&Test Kubernetes pueden apagar nodos (VMs) fuera del horario laboral (por ejemplo por la noche y fines de semana). => de esta manera, la optimización se implementa a nivel de clúster.
No ofrecemos servicios basados en Kubernetes.
Scale down applications when not in use
Las aplicaciones consumen CPU incluso cuando no están en uso activo. Por ejemplo, temporizadores en segundo plano, recolección de basura, chequeos de estado, etc. Incluso al cerrar la aplicación, el hardware subyacente consume energía en modo inactivo. Esto también sucede con aplicaciones de desarrollo y prueba o hardware fuera del horario laboral.
DownToZero, como su nombre indica, el escalado hacia abajo está en el núcleo de nuestras acciones. Por eso buscamos que todos los servicios provean escalados hacia abajo.
Scale infrastructure with user load
La demanda de recursos depende de la carga de usuarios en un momento dado. Sin embargo, la mayoría de las aplicaciones funcionan sin tener esto en cuenta. Como resultado, los recursos se subutilizan y son ineficientes.
Scale Kubernetes workloads based on relevant demand metrics
Por defecto, Kubernetes escala cargas basándose en utilización de CPU y RAM. En la práctica, sin embargo, es difícil correlacionar los factores de demanda de tu aplicación con la utilización de CPU y RAM.
No ofrecemos servicios Kubernetes.
Scale logical components independently
Una arquitectura de microservicios puede reducir la cantidad de recursos computacionales requeridos, pues permite escalar cada componente independiente según su propia demanda.
Scan for vulnerabilities
Muchos ataques a infraestructura cloud buscan usar recursos desplegados indebidamente, lo que genera picos innecesarios en uso y costos.
Set storage retention policies
Desde una perspectiva de carbono incorporado, es mejor tener un mecanismo automatizado para eliminar recursos de almacenamiento no usados para ser eficientes con el hardware y optimizar la capa de almacenamiento para la tarea.
Shed lower priority traffic
Cuando los recursos están limitados durante eventos de alto tráfico o cuando la intensidad de carbono es alta, se generan más emisiones de carbono desde tu sistema. Añadir más recursos para soportar mayor tráfico introduce más carbono incorporado y más demanda eléctrica. Seguir manejando todas las solicitudes durante alta intensidad de carbono aumentará las emisiones globales del sistema. Reducir tráfico de menor prioridad en estos escenarios ahorrará recursos y emisiones de carbono. Este enfoque requiere entender tu tráfico, incluyendo qué solicitudes son críticas y cuáles pueden tolerar reintentos y fallos.
Time-shift Kubernetes cron jobs
Las emisiones de carbono de un sistema de software dependen de la energía consumida por ese software, pero también de la intensidad de carbono de la electricidad que lo alimenta. Por esa razón, ejecutar software eficiente en energía sobre una red eléctrica intensiva en carbono puede ser ineficiente para reducir sus emisiones globales de carbono.
Aunque no ofrecemos servicios Kubernetes, nuestros Container Jobs ofrecen la posibilidad de un modelo de programación flexible. Consulta nuestra documentación para más info.
Use Asynchronous network calls instead of synchronous
Al hacer llamadas a través de límites de proceso a bases de datos, sistemas de archivos o APIs REST, depender de llamadas síncronas puede causar que el hilo llamado se bloquee, poniendo carga adicional en la CPU.
Use circuit breaker patterns
Las aplicaciones modernas necesitan comunicarse con otras regularmente. Dado que estas otras aplicaciones tienen su propio calendario de despliegue, tiempos de inactividad y disponibilidad, la conexión de red puede presentar problemas. Si la otra aplicación no es accesible, todas las solicitudes fallarán y las futuras serán inútiles.
Use cloud native network security tools and controls
Los firewalls de red y de aplicaciones web proporcionan protección contra los ataques más comunes y ayudan a filtrar bots maliciosos. Estas herramientas ayudan a eliminar transmisión innecesaria de datos y reducir la carga en la infraestructura cloud, usando menos ancho de banda y menos infraestructura.
Use DDoS protection
Los ataques distribuídos de denegación de servicio (DDoS) se usan para aumentar la carga del servidor hasta que no pueda responder 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 usan en solicitudes sin sentido.
Use cloud native processor VMs
Las máquinas virtuales cloud tienen diferentes capacidades según los procesadores que usan. Usar VMs basadas en la eficiencia de sus procesadores impactaría en la eficiencia del hardware y reduciría emisiones de carbono.
Use serverless cloud services
Los servicios serverless son servicios que el proveedor cloud maneja para la aplicación. Estos escalan dinámicamente según la carga para cumplir la tarea y aplican buenas prácticas para mantener el uso de recursos al mínimo.
Todas las ofertas de DownToZero son servicios cloud serverless.
Web
https://patterns.greensoftware.foundation/catalog/web/
Como no ofrecemos servicios relacionados con Web, omitimos esta sección del catálogo.