Green Software Patterns
The Green Software Foundation comenzó a trabajar en Green Software Patterns.
Dado que estamos muy alineados con los objetivos de la Green Software Foundation, queríamos dar a conocer a todo el mundo algunos de esos patrones aplicados en el contexto de DownToZero.Cloud.
Inteligencia Artificial (IA)
https://patterns.greensoftware.foundation/catalog/ai/
Como no ofrecemos servicios relacionados con IA, omitimos esta sección del catálogo.
Nube
https://patterns.greensoftware.foundation/catalog/cloud/
Almacenar en caché datos estáticos
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 almacenando en caché en muchas instancias mientras procesamos solicitudes; por ejemplo, nuestro runtime de trabajos asíncronos almacena localmente en caché las imágenes de Docker, por lo que no necesitaremos un pull completo en cada invocación.
También usamos hashes de imagen para las imágenes de contenedor en la medida de lo posible para reducir la carga en tiempo real al instanciar nuevos contenedores.
Elegir la región más cercana a los usuarios
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 el diseño regional de nuestra infraestructura, esto no puede ser influenciado por un usuario. Internamente tratamos de optimizar la regionalidad tanto como sea posible, sin sacrificar la durabilidad y la disponibilidad.
Comprimir datos almacenados
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 Observability tiene un mecanismo interno de tiering que mueve los datos desde un nivel de almacenamiento caliente a un formato más frío y mejor comprimido tras un período de retención fijo.
Comprimir datos transmitidos
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.
Conteneriza tus cargas de trabajo
Los contenedores permiten que los recursos se utilicen con mayor flexibilidad, ya que las cargas de trabajo se pueden mover fácilmente entre máquinas. Los contenedores permiten el 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 contenerizadas. Poder mover cargas de trabajo entre ubicaciones es necesario en el núcleo de DTZ para permitir desplazar cargas a entornos de ejecución más eficientes bajo demanda.
Eliminar recursos de almacenamiento no usados
Desde la perspectiva del carbono incorporado, es mejor eliminar los recursos de almacenamiento no usados para ser eficientes con el hardware y para que la capa de almacenamiento esté optimizada para la tarea.
Nuestro Objectstore admite expiraciones en objetos, de modo que cada entidad puede limpiarse después de que deje de usarse. Nuestro Container Registry también ejecuta trabajos de limpieza configurables para reducir la cantidad de objetos almacenados.
Cifrar solo lo 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. 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 computacional. Además, el cifrado puede aumentar los requisitos de almacenamiento al inflar el tamaño de los datos almacenados porque típicamente contiene metadatos y relleno adicionales, lo que es especialmente notable en archivos pequeños. Además, el cifrado es una tarea repetitiva que debe realizarse cada vez que se recuperan o actualizan datos. Esta naturaleza repetitiva puede contribuir a un mayor consumo de energía, especialmente en sistemas de alto rendimiento.
Evaluar otras arquitecturas de CPU
Las aplicaciones se construyen con una arquitectura de software que mejor se ajusta a la necesidad de negocio que están sirviendo. 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 un buen rendimiento por vatio.
Por ahora solo soportamos una arquitectura de CPU, X86. Actualmente no tenemos los recursos para evaluar diferentes arquitecturas.
Usar un service mesh solo si es necesario
Un service mesh despliega contenedores adicionales para la comunicación, típicamente en un patrón sidecar, para proporcionar más capacidades operacionales. 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 fuera de la capa de aplicación y hacia la capa de infraestructura.
Dado que nuestra red no depende de abstracciones de Kubernetes, tampoco necesitamos un service mesh.
Terminar TLS en la puerta de enlace perimetral
Transport Layer Security (TLS) garantiza que todos los datos transmitidos entre el servidor web y los navegadores web permanezcan privados y cifrados. Sin embargo, terminar y reestablecer TLS incrementa 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 en disco necesarios para que un servicio funcione. El estado incluye las estructuras de datos y las 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 ofrecen esas capacidades a nuestros usuarios.
Ajustar tus objetivos de nivel de servicio a las necesidades del negocio
Si los tiempos de inactividad del servicio son aceptables, es mejor no aspirar a la máxima disponibilidad sino diseñar la solución según las necesidades reales del negocio. Garantías de menor disponibilidad pueden ayudar a reducir el consumo de energía al usar menos componentes de infraestructura.
Nuestro SLO es proporcionar el mejor servicio posible, sin comprometer la eficiencia y la sostenibilidad. Por eso nuestros servicios dependen en gran medida del escalado automático para siempre proporcionar un nivel de servicio apropiado con la mínima sobrecarga.
Ajustar los requisitos de utilización de las máquinas virtuales (VMs)
Es mejor tener una VM ejecutándose con una mayor utilización que dos ejecutándose con 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 VMs. Todas nuestras ofertas de infraestructura se basan en contenedores para ofrecer una experiencia más simplificada.
Ajustar los requisitos de utilización con servidores preconfigurados
Es mejor tener una VM ejecutándose con una mayor utilización que dos ejecutándose con 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.
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, 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 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 forma drástica según los requisitos computacionales. Cuanto mayor sea la variación entre los valores promedio y pico de utilización de CPU, más recursos deben ser aprovisionados en modo de espera para absorber esos picos de tráfico.
Optimizar el impacto en los dispositivos y equipos del cliente
Las aplicaciones se ejecutan en hardware del cliente o se muestran en él. El hardware usado por el cliente tiene una huella de carbono incorporada por la producción y la electricidad requerida mientras está en funcionamiento. Optimizar el diseño y la arquitectura del software para alargar 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.
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 forma drástica según los requisitos computacionales. Cuanto mayor sea la variación entre los valores promedio y pico de utilización de CPU, más recursos deben ser aprovisionados en modo de espera para absorber esos picos de tráfico.
Poner en cola las solicitudes de procesamiento no urgentes
Todos los sistemas tienen períodos de carga máxima 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 nos aseguramos de 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 los datos transmitidos
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.
Eliminar activos no utilizados
Monitorea y analiza la aplicación y la factura de la nube para identificar recursos que ya no se usan o que pueden reducirse.
Reducir Kubernetes applications cuando no están en uso
Para reducir las emisiones de carbono y los costes, los clústeres Kubernetes de Dev&Test pueden apagar nodos (VMs) fuera del horario laboral (por ejemplo, por la noche y durante los fines de semana). => por tanto, la optimización se implementa a nivel de clúster.
No ofrecemos servicios basados en Kubernetes.
Escalar aplicaciones hacia abajo cuando no están en uso
Las aplicaciones consumen CPU incluso cuando no están activamente en uso. Por ejemplo, temporizadores en segundo plano, recolección de basura, comprobaciones de estado, etc. Incluso cuando la aplicación está apagada, el hardware subyacente consume energía en reposo. Esto también puede ocurrir con aplicaciones de desarrollo y prueba o hardware fuera del horario de oficina.
DownToZero, como indica el nombre, reducir la escala está en el núcleo de lo que hacemos. Por eso aspiramos a que todos los servicios proporcionen escalado hacia abajo.
Escalar la 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 tener esto en cuenta. Como resultado, los recursos están infrautilizados e ineficientes.
Escalar cargas de trabajo de Kubernetes según métricas de demanda relevantes
Por defecto, Kubernetes escala 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 que impulsan la demanda de tu aplicación con la utilización de CPU y RAM.
No ofrecemos servicios de Kubernetes.
Escalar componentes lógicos de forma independiente
Una arquitectura de microservicios puede reducir la cantidad de recursos de cómputo necesarios, ya que permite que cada componente independiente se escale según su propia demanda.
Escanear en busca de vulnerabilidades
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.
Establecer políticas de retención de almacenamiento
Desde la perspectiva del carbono incorporado, es mejor tener un mecanismo automatizado para eliminar recursos de almacenamiento no usados para ser eficientes con el hardware y para que la capa de almacenamiento esté optimizada para la tarea.
Descartar 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 requisitos de tráfico incrementados introduce más carbono incorporado y más demanda de electricidad. Continuar atendiendo todas las solicitudes durante periodos de alta intensidad de carbono aumentará las emisiones globales de tu sistema. Eliminar tráfico que tenga menor prioridad durante estos escenarios ahorrará recursos y emisiones de carbono. Este enfoque requiere comprender tu tráfico, incluyendo qué solicitudes son críticas y cuáles pueden soportar mejor reintentos y fallos.
Desplazar en el tiempo los cron jobs de Kubernetes
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 puede ser ineficiente para reducir sus emisiones de carbono globales.
Aunque no ofrecemos servicios de Kubernetes, nuestros Container Jobs ofrecen la posibilidad de un modelo de programación flexible. Consulta nuestras docs para más información.
Usar llamadas de red asíncronas en lugar de síncronas
Al realizar llamadas a través de límites de proceso, ya sea a bases de datos, sistemas de archivos o APIs REST, confiar en llamadas síncronas puede hacer que el hilo llamante quede bloqueado, generando carga adicional en la CPU.
Usar patrones de circuito de protección (circuit breaker)
Las aplicaciones modernas necesitan comunicarse con otras aplicaciones con regularidad. Dado que estas otras aplicaciones tienen su propio calendario de despliegue, tiempos de inactividad y disponibilidad, la conexión de red con estas aplicaciones puede tener problemas. Si la otra aplicación no es accesible, todas las solicitudes de red hacia esa aplicación fallarán y las futuras solicitudes de red serán inútiles.
Usar herramientas y controles de seguridad de red nativos en la nube
Los firewalls de red y de aplicaciones web proporcionan protección contra los ataques más comunes y permiten reducir la carga causada por bots maliciosos. Estas herramientas ayudan a eliminar transmisiones de datos innecesarias y a reducir la carga en la infraestructura de la nube, al mismo tiempo que usan menos ancho de banda y menos infraestructura.
Usar protección contra DDoS
Los ataques de denegación de servicio distribuido (DDoS) se usan para aumentar la carga del servidor hasta que no pueda responder a solicitudes legítimas. Esto generalmente se hace 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 con procesadores nativos de la nube
Las máquinas virtuales en la nube vienen con diferentes capacidades según los procesadores de hardware. Por tanto, usar máquinas virtuales basadas en la eficiencia de sus procesadores impactaría en la eficiencia del hardware y reduciría las emisiones de carbono.
Usar servicios serverless en la nube
Los servicios serverless en la nube 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 buenas 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 la web, omitimos esta sección del catálogo.