Green Software Patterns
La Green Software Foundation mantiene los Green Software Patterns: una colección seleccionada de prácticas para construir software más ecológico.
El catálogo está organizado por el ciclo de vida del software y también puede explorarse por rol:
Los patrones a continuación son los más relevantes para la plataforma DownToZero. Cada encabezado enlaza con la ubicación actual del patrón en el catálogo, seguido de cómo lo aplicamos—o dónde aún no se aplica—en DownToZero.
Patterns at DownToZero
Cache static data
Desde la perspectiva de la 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 usando cachés en muchas instancias mientras procesamos solicitudes, p. ej. nuestro runtime de trabajos asíncronos almacena en caché localmente las imágenes docker, por lo que no necesitaremos una descarga completa en cada invocación.
También usamos hashes de imagen para las imágenes de contenedor tanto como es posible para reducir la carga en tiempo real al instanciar nuevos contenedores.
Choose the region that is closest to users
Desde la perspectiva de la eficiencia energética, es mejor acortar la distancia que recorre un paquete de red para que se requiera menos energía para transmitirlo. De manera similar, desde la perspectiva del 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.
Compress stored data
Almacenar demasiados datos sin comprimir puede resultar en un desperdicio de ancho de banda y aumentar los requisitos 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 los datos de una capa de almacenamiento caliente a un formato más frío y mejor comprimido tras un periodo de retención fijo.
Compress transmitted data
Desde la perspectiva de la 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 empaquetado binario (bin packing) y requieren menos recursos de cómputo 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 conteinerizadas. Poder mover las cargas de trabajo entre ubicaciones es necesario en el núcleo de DTZ para permitir desplazar cargas hacia entornos de ejecución más eficientes bajo demanda.
Delete unused storage resources
Desde la perspectiva del carbono incorporado, es mejor eliminar los recursos de almacenamiento no utilizados para ser eficientes con el hardware y para que la capa de almacenamiento esté optimizada para la tarea.
Nuestro object store soporta expiraciones en objetos, de modo que cada entidad puede limpiarse una vez que ya no se usa. 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. En primer lugar, la cantidad de CPU requerida para el cifrado varía según el algoritmo elegido, y los algoritmos más complejos tienden a demandar mayor potencia de cómputo. Además, el cifrado puede conducir a mayores requisitos de almacenamiento ya que infla el tamaño de los datos almacenados porque típicamente contiene metadatos adicionales y padding, lo que es especialmente notable en archivos pequeños. Asimismo, el cifrado es una tarea repetitiva que necesita realizarse cada vez que los datos se recuperan o actualizan. Esta naturaleza repetitiva puede contribuir a un mayor consumo de energía, especialmente en sistemas de alto rendimiento.
Evaluate other CPU architectures
Las aplicaciones se construyen con una arquitectura de software que mejor se ajusta a la necesidad del negocio que sirven. Los proveedores de nube facilitan evaluar otros tipos de CPU, como x86-64, que pueden incluirse en la evaluación junto con muchas alternativas rentables que ofrecen buen rendimiento por vatio.
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 la comunicación, típicamente en un patrón sidecar, para proporcionar más capacidades operativas. Esto puede resultar en un aumento del uso de CPU y del tráfico de red, pero también permite desacoplar tu aplicación de estas capacidades, moviéndolas desde la capa de aplicación hacia la capa de infraestructura.
Puesto 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 que se transmiten entre el servidor web y los navegadores web permanezcan privados y cifrados. Sin embargo, terminar y restablecer TLS incrementa el uso de CPU y podría ser innecesario en ciertas arquitecturas.
Implement stateless design
El estado del servicio se refiere a los datos en memoria o en disco que requiere 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é arquitectado el servicio, el estado también puede incluir archivos u otros recursos almacenados en disco.
Nuestros servicios existentes, como Container Services y Container Jobs, se basan en un diseño sin estado y también aportan esas capacidades a nuestros usuarios.
Match your service level objectives to business needs
Si los tiempos de inactividad del servicio son aceptables, es mejor no esforzarse por 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 de energía al usar menos componentes de infraestructura.
Nuestro SLO es proporcionar el mejor servicio posible, pero sin comprometer la eficiencia y la sostenibilidad. Por ello nuestros servicios dependen en gran medida del escalado automático para siempre proveer un nivel de servicio apropiado con un sobrecoste mínimo.
Match utilization requirements of virtual machines (VMs)
Es mejor tener una VM funcionando a una mayor utilización que dos funcionando a bajas tasas de utilización, no solo en términos de proporcionalidad energética sino también en términos de 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 simplificada.
Match utilization requirements with pre-configured servers
Es mejor tener una VM funcionando a una mayor utilización que dos funcionando a bajas tasas de utilización, no solo en términos de proporcionalidad energética sino también en términos de carbono incorporado.
Apuntamos a una alta utilización en nuestra infraestructura, pero esos componentes no están expuestos al usuario final. El usuario solo 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.
Minimize the total number of deployed environments
En una aplicación dada, puede ser necesario utilizar múltiples entornos en el flujo de trabajo de la aplicación. Típicamente, un entorno de desarrollo se usa para actualizaciones regulares, mientras que entornos de staging o testing se usan para asegurar que no haya problemas antes de que el código llegue a un entorno de producción al que los usuarios puedan tener acceso.
Optimise storage utilisation
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.
Optimize average CPU utilization
El uso y la utilización de la CPU varían a lo largo del día, a veces de forma drástica según los requisitos computacionales. Cuanto mayor sea la variación entre los valores promedio y pico de utilización de la CPU, más recursos deben aprovisionarse en modo de espera para absorber esos picos de tráfico.
Optimize impact on customer devices and equipment
Las aplicaciones se ejecutan en hardware del cliente o se muestran en él. El hardware utilizado por el cliente tiene una huella de carbono incorporada a través de la producción y la electricidad requerida mientras funciona. Optimizar el diseño y la arquitectura de tu software para extender la vida 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 la utilización de la CPU varían a lo largo del día, a veces de forma drástica según los requisitos computacionales. Cuanto mayor sea la variación entre los valores promedio y pico de utilización de la CPU, más recursos deben aprovisionarse en modo de espera para absorber esos picos de tráfico.
Queue non-urgent processing requests
Todos los sistemas tienen periodos de carga pico y baja. Desde la perspectiva de la eficiencia del hardware, somos más eficientes si minimizamos el impacto de los picos de solicitudes con una implementación que permita una utilización uniforme de los componentes. Desde la perspectiva de la 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.
Reduce transmitted data
Desde la perspectiva de la 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
Monitoriza y analiza la aplicación y la factura de la nube para identificar recursos que ya no se usan o que pueden reducirse.
Scale down kubernetes applications when not in use
Para reducir las emisiones de carbono y los costes, los clusters Kubernetes de desarrollo y prueba pueden apagar nodos (VMs) fuera del horario laboral (p. ej. por la noche y durante los fines de semana), implementando así la optimización 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 activamente en uso. Por ejemplo, temporizadores en segundo plano, recolección de basura, health checks, etc. Incluso cuando la aplicación está apagada, el hardware subyacente consume potencia en reposo. Esto también puede ocurrir con aplicaciones de desarrollo y prueba o hardware fuera del horario laboral.
DownToZero, como indica el nombre, tiene la reducción de escala en el centro de nuestras acciones. Por eso aspiramos a que todos los servicios provean escalados descendentes.
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 están infrautilizados e ineficientes.
Scale Kubernetes workloads based on relevant demand metrics
Por defecto, Kubernetes escala las cargas de trabajo en función de la 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 de Kubernetes.
Scale logical components independently
Una arquitectura de microservicios puede reducir la cantidad de recursos de cómputo requeridos ya que permite que cada componente independiente escale según su propia demanda.
Scan for vulnerabilities
Muchos ataques a la infraestructura en la nube buscan hacer un mal uso de los recursos desplegados, lo que conduce a un aumento innecesario del uso y del coste.
Set storage retention policies
Desde la perspectiva del carbono incorporado, es mejor tener un mecanismo automatizado para eliminar recursos de almacenamiento no utilizados para ser eficientes con el hardware y para que la capa de almacenamiento esté optimizada para la tarea.
Shed lower priority traffic
Cuando los recursos están restringidos 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 requisitos de tráfico incrementados introduce más carbono incorporado y más demanda de electricidad. Continuar manejando todas las solicitudes durante alta intensidad de carbono aumentará las emisiones totales de tu sistema. Descartar tráfico de menor prioridad durante estos escenarios ahorrará recursos y emisiones de carbono. Este enfoque requiere comprender tu tráfico, incluyendo qué solicitudes de llamada son críticas y cuáles pueden soportar mejor 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 con la que se alimenta. Por esta razón, ejecutar software eficiente en energía en una red eléctrica con alta intensidad de carbono, podría ser ineficiente para reducir sus emisiones globales de carbono.
Aunque no ofrecemos servicios de Kubernetes, nuestros Container Jobs ofrecen la posibilidad de un modelo de programación flexible. Consulta nuestra documentación para más información.
Use Asynchronous network calls instead of synchronous
Al realizar llamadas a través de límites de proceso ya sea a bases de datos, sistemas de archivos o APIs REST, depender de llamadas sincrónicas puede causar que el hilo que llama quede bloqueado, poniendo carga adicional en la CPU.
Use circuit breaker patterns
Las aplicaciones modernas necesitan comunicarse con otras aplicaciones de forma regular. Dado que estas otras aplicaciones tienen su propio calendario de despliegues, tiempos de inactividad y disponibilidad, la conexión de red a estas aplicaciones puede tener problemas. Si la otra aplicación no es accesible, todas las solicitudes de red contra esa aplicación fallarán y las solicitudes de red 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 la reducción de bots maliciosos. Estas herramientas ayudan a eliminar transmisiones de datos innecesarias y reducir la carga en la infraestructura de la nube, además de usar menos ancho de banda y menos infraestructura.
Use DDoS protection
Los ataques de denegación de servicio distribuido (DDoS) se usan para aumentar la carga del servidor de modo que sea incapaz de responder a solicitudes legítimas. Esto generalmente se hace para dañar al propietario del servicio o del hardware. Debido a la naturaleza del ataque, muchos recursos ambientales se consumen por solicitudes sin sentido.
Use cloud native processor VMs
Las máquinas virtuales en la nube vienen con diferentes capacidades basadas en distintos procesadores de hardware. Como tal, usar máquinas virtuales basadas en la eficiencia de sus procesadores impactaría la eficiencia del hardware y reduciría las emisiones de carbono.
Use serverless cloud services
Los servicios en la nube serverless son servicios que el proveedor de nube gestiona para la aplicación. Estos escalan dinámicamente con la carga de trabajo necesaria para cumplir la tarea del servicio y aplican las mejores prácticas para mantener el uso de recursos al mínimo.
Todas las ofertas de DownToZero son servicios en la nube serverless.