Patterns of sustainability - Going green in IT

This slide deck addresses four questions:

1. Is Green IT a relevant topic? (Yes, it is)
2. Is Software a significant contributor to the ecological footprint of IT? (Yes, it is)
3. What can we do as software engineers working in different roles to reduce the ecological footprint of IT? (A lot)
4. Is Green IT the only relevant topic of the upcoming years? (No, it is part of a bigger challenge)

As a lot of studies and presentations already exist that address the first and second question in depth, this slide deck keeps these parts short.

The main focus is on the third question. Here, a lot of patterns are presented that software engineers can use in different roles to reduce the ecological footprint of IT.

Finally, the topic "Green IT" is embedded in a bigger picture describing the core challenges, IT faces in a more and more uncertain VUCA world while becoming more and more indispensable at the same time. Still, as the focus of this presentation is on the patterns of the third part, this part is also kept short.

At the end, a lot of references that were used when preparing this presentations are included for everyone who would like to dig deeper into the topic.

As always, the voice track is missing. Hopefully, this slide deck still gives you some useful ideas to ponder ...

Transcript

1. Patterns of sustainability
   Going green in IT
   Uwe Friedrichsen – codecentric AG – 2020-2023
   

   View Slide

2. Uwe Friedrichsen
   Works @ codecentric
   https://twitter.com/ufried
   https://www.speakerdeck.com/ufried
   https://ufried.com/
   

   View Slide

3. Is green IT a relevant topic?
   

   View Slide

4. “The IT sector accounts for 4% of global GHG emissions
   and this could double by 2025”
   Source: Center for sustainable systems, Green IT Factsheet (https://css.umich.edu/publications/factsheets/built-environment/green-it-factsheet)
   

   View Slide

5. “Software can also be an enabler of climate solutions. Software
   can be built to help accelerate decarbonization across all sectors
   in industry and society.”
   Source: Green Software Foundation, What is green software? (https://greensoftware.foundation/articles/what-is-green-software)
   

   View Slide

6. But Green IT is a problem of hardware manufacturers and
   datacenter designers and operators only, isn't it?
   

   View Slide

7. Patterns of sustainability
   (Software engineering perspective)
   Hardware manufacturing
   & data center design
   * Somebody Else’s Problem (https://en.wikipedia.org/wiki/Somebody_else%27s_problem)
   S.E.P. *
   We are done! 🥳
   

   View Slide

8. “The hope is that the progress in hardware will cure all software ills.
   However, a critical observer may observe that software manages
   to outgrow hardware in size and sluggishness.”
   (Wirth’s law)
   Source: Wikipedia, Wirth’s law (https://en.wikipedia.org/wiki/Wirth%27s_law)
   

   View Slide

9. “Software efficiency halves every 18 months,
   compensating Moore's Law”
   (May's law)
   Source: Wikipedia, Algorithmic efficiency (https://en.wikipedia.org/wiki/Algorithmic_efficiency)
   

   View Slide

10. Patterns of sustainability
    (Software engineering perspective)
    Hardware manufacturing
    & data center design
    * Somebody Else’s Problem (https://en.wikipedia.org/wiki/Somebody_else%27s_problem)
    S.E.P. *
    We are done! 🥳
    

    View Slide

11. What can we as software engineers
    do to make IT greener?
    

    View Slide

12. Well, a lot ...
    

    View Slide

13. Patterns of sustainability
    (Software engineering perspective)
    Requirements
    Hardware manufacturing
    & data center design
    

    View Slide

14. Requirements
    (Responsible: Product manager, architecture)
    Offline first
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality of Service
    

    View Slide

15. Offline first
    Requirements
    (Responsible: Product manager, architecture)
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality of Service
    

    View Slide

16. Balance quality of service (QoS)
    • Counterforce to other quality goals, e.g.
    • Availability
    • Response time
    • Quality of response
    • Goal is to find a sensible balance between
    • QoS quality goals
    • Required resource/energy consumption
    • Supported by design latency-tolerant user interfaces
    

    View Slide

17. Offline first
    Requirements
    (Responsible: Product manager, architecture)
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality of Service
    

    View Slide

18. Fight feature creep
    • Feature creep is wasteful in many ways
    • including resource and energy consumption
    • Validate feature viability before implementation
    • Monitor feature usage and remove rarely used features
    • Give users option to deactivate unneeded features
    • Also supports maintainability, evolvability, robustness, ...
    

    View Slide

19. Offline first
    Requirements
    (Responsible: Product manager, architecture)
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality of Service
    

    View Slide

20. Mind footprint of requirements
    • Make estimated ecological footprint of requirements explicit
    • Requires good measuring of energy consumption
    • Requires approach to estimate footprint of new requirements
    • Umbrella pattern for other requirements-related patterns
    • Also consider footprint of “nice-to-have” requirements
    • E.g., UI animations – looking nice, but require lots of energy
    • Supported by make energy-consumption visible
    

    View Slide

21. Offline first
    Requirements
    (Responsible: Product manager, architecture)
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality of Service
    

    View Slide

22. Optimize for temporal decoupling
    • Temporally decouple request, processing and response
    • Functional design issue
    • Technology only augments it
    • Supports maximize hardware utilization
    • Supports delay execution of compute-intensive tasks to
    times of low carbon intensity
    

    View Slide

23. Offline first
    Requirements
    (Responsible: Product manager, architecture)
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality of Service
    

    View Slide

24. Data austerity
    • The more data you store and process, the more
    • storage capacity you need
    • memory you need
    • compute power you need
    • network bandwidth you need
    • Store and process only the data you really need
    • Reduces environmental footprint significantly
    • Side effect: Improves security and GDPR compliance
    • Counterforce to widespread “big data” handling practice
    

    View Slide

25. Offline first
    Requirements
    (Responsible: Product manager, architecture)
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality of Service
    

    View Slide

26. Offline first
    • Targeted at mobile applications
    • Do not require a continuous connection to the backend
    • Leads to different designs
    • Less network traffic and bandwidth required
    • Often also less data required overall
    • Supports data austerity
    • Supported by optimize for temporal decoupling
    

    View Slide

27. Offline first
    Requirements
    (Responsible: Product manager, architecture)
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality of Service
    

    View Slide

28. Offline first
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality
    of Service
    Requirements
    Patterns of sustainability
    (Software engineering perspective)
    Hardware manufacturing
    & data center design
    Design
    

    View Slide

29. Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Design carbon-aware
    applications
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

30. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

31. Minimize redundancy
    • Redundancy often used as default to improve availability
    • Multiplies resource consumption
    • Leads to poor utilization (unless combined with autoscaling)
    • Only use redundancy if really needed
    • Evaluate how high availability really needs to be
    • Ponder alternative approaches (e.g., Erlang’s “let it crash”)
    • Supported by balance quality of service (QoS)
    • Supported by minimize startup time
    

    View Slide

32. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

33. Remove unneeded components
    • Continuously monitor usage patterns of system landscape
    • Remove components that are not used anymore
    • Also consider removing rarely used components
    • Results in less overall resource consumption
    • Also leads to less technical debt and improved
    maintainability, evolvability, robustness, and more
    

    View Slide

34. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

35. Design carbon-aware applications
    • Build carbon-awareness into applications
    • Make aware of own current energy consumption
    • Connect with current carbon-intensity of power supplier
    • Use to build in optimization of own ecological footprint, e.g.
    • Reduce QoS if ecological footprint becomes too high
    • Shift workloads to times of lower carbon intensity
    • Shift workloads to data centers with lower carbon intensity
    • Supported by balance quality of service (QoS)
    • Supported by optimize for temporal decoupling
    

    View Slide

36. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

37. Design latency tolerant UIs
    • Design user interfaces to support progressive data loading
    • Pre-render structure, fill in data later
    • Load visible parts first, load other data later
    • Design UIs that compute-intensive data can be loaded later
    • Reduces pressure for very short response times
    • Supports reducing ecological footprint
    • Supported by balance quality of service (QoS)
    • Supported by optimize for temporal decoupling
    

    View Slide

38. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

39. Slice services by resource usage
    • Split functionality by resource consumption
    • Turn resource-intensive functionality in dedicated services
    • Group resource-economical features apart in other services
    • Frequency of use can be used as sub-criterion for slicing
    • Allows for better utilization of underlying resources
    • Additional force in functional service design
    • Supports maximize utilization
    

    View Slide

40. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

41. Avoid polling
    • Polling continuously needs energy even if no new data exists
    • Wastes energy
    • Impedes implementation of patterns like scale to zero
    • Use push mechanisms instead wherever possible
    • Supports scale to zero
    

    View Slide

42. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

43. Reduce transmitted data
    • Sending data over the network costs a lot of energy
    • Only send the data that is really needed
    • Do not send unneeded data because it is easier
    • Do not send data that “might be needed in the future”
    • Data not sent is better than the best data compression
    • Avoid chatty communication protocols and frameworks
    • Counterforce to other design forces
    • Supported by compress data at transit and rest
    

    View Slide

44. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

45. Delete unneeded data
    • Delete data you do not need anymore
    • Requires less storage, memory, compute and network
    • Reduces environmental footprint
    • Side effect: Improves security and GDPR compliance
    • Implement data lifecycle and retention policies
    • Makes clear which data to keep and which data to delete
    • Supports data austerity
    

    View Slide

46. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

47. Keep data local
    • Loading data over the network costs a lot of energy
    • Keep the data you need local
    • Do not load it from remote sources
    • Temporally decouple data synchronization needs
    • Requires carefully considered data architecture
    • Makes design and implementation more complicated
    • Supports reduce transmitted data
    

    View Slide

48. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

49. Use optimized data stores/formats
    • Data stores and formats optimized for the use case
    • reduce storage and memory needed
    • allow for optimized data access patterns,
    reducing compute and network needed
    • Consider, e.g., columnar data stores and/or Apache Parquet
    • Always carefully consider the use case
    • Offset potential data duplication footprint
    

    View Slide

50. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

51. Cache static data
    • Repeatedly loading the same data costs a lot of energy
    • Cache static data locally instead of continuously reloading it
    • Trades memory consumption for network traffic
    • Requires certain access frequency to become energy-positive
    • Cached data may become outdated
    • Cache coherency challenges need to be handled
    • Supports keep data local
    

    View Slide

52. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

53. Prefer lazy loading
    • Eagerly loaded data often is not used
    • Only load data when it is actually needed
    • Only load web page content when it is displayed
    • Only load table data when it is displayed
    • ...
    • Supports reduce transmitted data
    • Supported by balance quality of service (QoS)
    

    View Slide

54. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

55. “Hardware manufacture and use dominate the carbon output of
    personal-computing companies (e.g., Apple).
    More emissions come from designing and manufacturing
    integrated circuits (e.g., SoCs, DRAM, and storage) than from
    hardware use and mobile energy consumption.”
    Source: Udit Gupta et al., "Chasing Carbon: The Elusive Environmental Footprint of Computing", https://arxiv.org/abs/2011.02839
    

    View Slide

56. Mind the impact on user devices
    • Design applications that also run on older user devices
    • Test operability on older devices
    • Measure mobile efficiency *
    • Use managed device farms for testing
    • Test with older hardware/browsers and alike
    • Reduces environmental footprint significantly
    • Often ignored for various reasons
    * see, e.g., https://mobile-efficiency-index.com/en/
    

    View Slide

57. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

58. Programming languages differ widely with respect to
    energy, time and memory consumption
    

    View Slide

59. Source: Pereira et al. "Energy Efficiency across Programming Languages: how do energy, time, and memory relate?”, https://dl.acm.org/doi/10.1145/3136014.3136031
    

    View Slide

60. Choose the right language
    • Programming languages differ regarding
    • Energy consumption
    • Time consumption
    • Memory consumption
    • ...
    • Consider using energy-efficient programming languages
    • At least for the most resource-intensive parts of workload
    • Creates additional force regarding language choice
    

    View Slide

61. Design carbon-aware
    applications
    Design
    (Responsible: Architecture, sometimes
    in coordination with product manager)
    Delete unneeded data
    Choose the right
    programming language
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Cache static data
    Mind the impact
    on user devices
    Avoid polling
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    

    View Slide

62. Design carbon-aware
    applications
    Delete unneeded data
    Mind the impact
    on user devices
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Avoid polling
    Choose the right
    programming language
    Cache static data
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    Design
    Requirements
    Patterns of sustainability
    (Software engineering perspective)
    Implementation
    Hardware manufacturing
    & data center design
    Offline first
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality
    of Service
    

    View Slide

63. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

64. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

65. “Software efficiency halves every 18 months,
    compensating Moore's Law”
    (May's law)
    Source: Wikipedia, Algorithmic efficiency (https://en.wikipedia.org/wiki/Algorithmic_efficiency)
    

    View Slide

66. “In ubiquitous systems, halving the instructions executed can double the
    battery life and big data sets bring big opportunities for better software and
    algorithms:
    Reducing the number of operations from N×N to N×log(N) has a dramatic
    effect when N is large ... for N = 30 billion, this change is as good as 50
    years of technology improvements.”
    Source: David May, The return of innovation (https://web.archive.org/web/20160303181322/http://www.cs.bris.ac.uk/~dave/iee.pdf)
    

    View Slide

67. Algorithms and data structures
    • Use the best algorithms and data structures for the task
    • Avoid O(n2) or worse, aim for O(n log(n)) or better
    • Sometimes intermediate transformation steps can help
    • Balance random access and memory consumption
    • Can reduce environmental footprint significantly
    • Foundations more and more often not known
    • Effects of library calls often not understood
    Erik D. Demaine et al., "Energy-Efficient Algorithms" (https://arxiv.org/abs/1605.08448)
    

    View Slide

68. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

69. Economize on libs & frameworks
    • Oversized libraries and frameworks waste resources
    • And often also increase cognitive load of developers
    • And increase the attack surface
    • Use as few libraries and frameworks as possible
    • Prefer lightweight libraries and frameworks
    • Implement simple solutions on your own
    • Counterforce to widespread development best practices
    

    View Slide

70. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

71. Optimize wasteful code
    • Continuously monitor resource usage of application parts
    • Identify parts with very high resource consumption
    • Optimize these parts, e.g.,
    • Find better algorithms and data structures
    • Avoid unneeded sorting, formatting, transformations, ...
    • Consider hardware acceleration for extremely wasteful parts
    • Note: Avoid falling in the premature optimization trap
    

    View Slide

72. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

73. Mind the Minifesto *
    • The most energy-efficient code is code not written
    • Avoid everything not needed to solve the task, e.g.
    • Do not over-design
    • Do not implement ahead
    • Strive for simple solutions
    • Simple does not mean easy
    • Simple usually is a lot harder to achieve than complicated
    * http://minifesto.org/
    

    View Slide

74. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

75. Minimize startup time
    • Long startup times are wasteful
    • Impedes fast, demand-driven application scaling
    • Results in overprovisioning of capacity
    • Strive for short startup times
    • Fosters resource-economical designs
    • Supports auto-scale resources
    • Supports scale to zero
    

    View Slide

76. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

77. Scan for vulnerabilities
    • Attackers often want access to foreign resources, e.g., for
    • Crypto-mining
    • DDoS attacks
    • Wastes a lot of energy for malicious purposes
    • Minimize risk by regular scanning for vulnerabilities
    • Best make it part of your CI/CD pipeline
    • Do not forget the other parts of a good security practice
    

    View Slide

78. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

79. Shift left carbon-efficiency
    • Pondering carbon-efficiency after deployment is too late
    • Hard to change ecologically questionable decision during
    • Requirements gathering
    • Software design
    • Software development
    • Software build and deployment
    • Make carbon-efficiency part of your quality goals
    • Take goal satisfaction into account from the very beginning
    

    View Slide

80. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

81. Do not build on each code change
    • CI/CD pipelines require energy
    • The more comprehensive, the more energy they consume
    • The more often run, the more energy they consume
    • Running the CI/CD pipelines less often saves energy
    • Maybe do not run the pipeline for each minor change
    • Relevant regarding “commit early, commit often” practices
    • Counterforce to widespread development best practices
    

    View Slide

82. Implementation
    (Responsible: Development, architecture)
    Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    

    View Slide

83. Mind the Minifesto
    Make carbon-efficiency part of your
    software development and test process
    Use efficient algorithms
    and data structures
    Optimize
    wasteful code
    Do not run builds after
    each minor code change
    Minimize
    startup time
    Scan for vulnerabilities
    Economize on libraries
    and frameworks
    Implementation
    Design
    Requirements
    Patterns of sustainability
    (Software engineering perspective)
    Runtime
    Hardware manufacturing
    & data center design Design carbon-aware
    applications
    Delete unneeded data
    Mind the impact
    on user devices
    Remove unneeded
    components
    Keep data local
    Minimize redundancy
    Use data stores and formats
    optimized for the use case
    Avoid polling
    Choose the right
    programming language
    Cache static data
    Prefer lazy loading
    Reduce transmitted data
    Slice services by
    resource usage
    Design latency-tolerant
    user interfaces
    Offline first
    Mind the energy-consumption
    of functional requirements
    Optimize for
    temporal decoupling
    Fight feature creep
    Data austerity
    Balance Quality
    of Service
    

    View Slide

84. Runtime
    (Responsible: Operations, sometimes
    in coordination with architecture)
    Base scaling on
    significant metrics
    Delay execution of compute-intensive
    tasks to times of low carbon intensity
    Maximize hardware utilization
    Monitor power consumption
    Shed low-priority traffic
    Compress data at
    transit and rest
    Deduplicate data
    Auto-scale resources
    Scan for vulnerabilities
    Scale to Zero
    

    View Slide

85. Runtime
    (Responsible: Operations, sometimes
    in coordination with architecture)
    Base scaling on
    significant metrics
    Delay execution of compute-intensive
    tasks to times of low carbon intensity
    Maximize hardware utilization
    Monitor power consumption
    Shed low-priority traffic
    Compress data at
    transit and rest
    Deduplicate data
    Auto-scale resources
    Scan for vulnerabilities
    Scale to Zero
    

    View Slide

86. Source: Barroso et al., The Case for Energy-Proportional Computing, IEEE Computer Dec 2007, pp. 33-37, vol. 40
    

    View Slide

87. Maximize hardware utilization
    • Always watch server utilization
    • Run workload on fewer servers with higher utilization
    • Avoid servers with low utilization
    • Also ponder development environments, CI/CD pipelines, ...
    • Supported by slice services by resource usage
    • Supported by use managed services
    • Supports buy only the hardware you need
    

    View Slide

88. Runtime
    (Responsible: Operations, sometimes
    in coordination with architecture)
    Base scaling on
    significant metrics
    Delay execution of compute-intensive
    tasks to times of low carbon intensity
    Maximize hardware utilization
    Monitor power consumption
    Shed low-priority traffic
    Compress data at
    transit and rest
    Deduplicate data
    Auto-scale resources
    Scan for vulnerabilities
    Scale to Zero
    

    View Slide

89. Monitor power consumption
    • Always monitor power consumption, using, e.g.
    • Public cloud: https://www.cloudcarbonfootprint.org/
    • Kubernetes: https://sustainable-computing.io/
    • and more: https://github.com/Green-Software-Foundation/
    awesome-green-software
    • Supports make energy-consumption visible
    • Supports delay execution of compute-intensive tasks
    to times of low carbon intensity
    

    View Slide

90. Runtime
    (Responsible: Operations, sometimes
    in coordination with architecture)
    Base scaling on
    significant metrics
    Delay execution of compute-intensive
    tasks to times of low carbon intensity
    Maximize hardware utilization
    Monitor power consumption
    Shed low-priority traffic
    Compress data at
    transit and rest
    Deduplicate data
    Auto-scale resources
    Scan for vulnerabilities
    Scale to Zero
    

    View Slide

91. Auto-scale resources
    • Auto-scale resources up and down based on demand
    • Usually works best in public cloud environment
    due to optimized resource elasticity
    • Can be applied to all types of resources
    • E.g., Scale data storage on demand (do not overprovision)
    • Different resource types may need different scaling strategies
    

    View Slide

92. Runtime
    (Responsible: Operations, sometimes
    in coordination with architecture)
    Base scaling on
    significant metrics
    Delay execution of compute-intensive
    tasks to times of low carbon intensity
    Maximize hardware utilization
    Monitor power consumption
    Shed low-priority traffic
    Compress data at
    transit and rest
    Deduplicate data
    Auto-scale resources
    Scan for vulnerabilities
    Scale to Zero
    

    View Slide

93. Scale to zero
    • Extension of auto-scale resources
    • “The most energy-efficient system is the one not running”
    • Consider switching off application services if not used
    • Only run a gateway that launches services if needed
    • Supported by minimize startup time
    • Must be supported by data center operator for best efficiency
    • Usually supported by “serverless” out of the box
    

    View Slide

94. Runtime
    (Responsible: Operations, sometimes
    in coordination with architecture)
    Base scaling on
    significant metrics
    Delay execution of compute-intensive
    tasks to times of low carbon intensity
    Maximize hardware utilization
    Monitor power consumption
    Shed low-priority traffic
    Compress data at
    transit and rest
    Deduplicate data
    Auto-scale resources
    Scan for vulnerabilities
    Scale to Zero
    

    View Slide

95. Base scaling on significant metrics
    • Scaling is often based on default metrics (CPU, memory, ...)
    • Not always suitable to reflect actual scaling needs
    • Use significant metrics to control scaling, e.g.
    • Request processing time (also applicable to events)
    • Number of queued requests/events
    • Number of active concurrent users
    • Might require exposing custom metrics to auto-scalers
    • Supports auto-scale resources
    

    View Slide

96. Runtime
    (Responsible: Operations, sometimes
    in coordination with architecture)
    Base scaling on
    significant metrics
    Delay execution of compute-intensive
    tasks to times of low carbon intensity
    Maximize hardware utilization
    Monitor power consumption
    Shed low-priority traffic
    Compress data at
    transit and rest
    Deduplicate data
    Auto-scale resources
    Scan for vulnerabilities
    Scale to Zero
    

    View Slide

97. Compress data at transit and rest
    • Data requires resources at transit and rest
    • Compress data to reduce resource consumption
    • Includes minimizing web assets
    • Reduces storage and network footprint
    • Do not forget to offset (de)compression footprint
    

    View Slide

98. Runtime
    (Responsible: Operations, sometimes
    in coordination with architecture)
    Base scaling on
    significant metrics
    Delay execution of compute-intensive
    tasks to times of low carbon intensity
    Maximize hardware utilization
    Monitor power consumption
    Shed low-priority traffic
    Compress data at
    transit and rest
    Deduplicate data
    Auto-scale resources
    Scan for vulnerabilities
    Scale to Zero
    

    View Slide

99. Shed low-priority traffic
    • High-traffic situations lead to high resource consumption
    • Shed low-priority requests to reduce resource demands
    • Not applicable to all use cases
    • Can help to reduce ecological footprint
    • Especially useful in times of high carbon intensity
    • Complements auto-scale resources
    

    View Slide

100. Runtime
     (Responsible: Operations, sometimes
     in coordination with architecture)
     Base scaling on
     significant metrics
     Delay execution of compute-intensive
     tasks to times of low carbon intensity
     Maximize hardware utilization
     Monitor power consumption
     Shed low-priority traffic
     Compress data at
     transit and rest
     Deduplicate data
     Auto-scale resources
     Scan for vulnerabilities
     Scale to Zero
     

     View Slide

101. Scan for vulnerabilities
     • Attackers often want access to foreign resources, e.g., for
     • Crypto-mining
     • DDoS attacks
     • Wastes a lot of energy for malicious purposes
     • Minimize risk by regular scanning for vulnerabilities
     • Best make it part of your CI/CD pipeline
     • Do not forget the other parts of a good security practice
     

     View Slide

102. Runtime
     (Responsible: Operations, sometimes
     in coordination with architecture)
     Base scaling on
     significant metrics
     Delay execution of compute-intensive
     tasks to times of low carbon intensity
     Maximize hardware utilization
     Monitor power consumption
     Shed low-priority traffic
     Compress data at
     transit and rest
     Deduplicate data
     Auto-scale resources
     Scan for vulnerabilities
     Scale to Zero
     

     View Slide

103. Deduplicate data
     • Duplicated data requires additional resources
     • Deduplicate data to reduce environmental footprint
     • Reduces storage needs
     • Requires less storage hardware to be built
     • Do not forget to offset deduplication efforts footprint
     

     View Slide

104. Runtime
     (Responsible: Operations, sometimes
     in coordination with architecture)
     Base scaling on
     significant metrics
     Delay execution of compute-intensive
     tasks to times of low carbon intensity
     Maximize hardware utilization
     Monitor power consumption
     Shed low-priority traffic
     Compress data at
     transit and rest
     Deduplicate data
     Auto-scale resources
     Scan for vulnerabilities
     Scale to Zero
     

     View Slide

105. Delay carbon-intensive tasks
     • Carbon-intensity of electricity production varies
     based on location and time
     • Shift compute-intensive tasks to times and locations with
     lower carbon-intensity
     • Use, e.g., API of https://www.electricitymaps.com/ for
     tracking carbon-intensity of electricity production
     • Supported by optimize for temporal decoupling
     • Supported by design carbon-aware applications
     

     View Slide

106. Source: https://app.electricitymaps.com/map
     

     View Slide

107. Runtime
     (Responsible: Operations, sometimes
     in coordination with architecture)
     Base scaling on
     significant metrics
     Delay execution of compute-intensive
     tasks to times of low carbon intensity
     Maximize hardware utilization
     Monitor power consumption
     Shed low-priority traffic
     Compress data at
     transit and rest
     Deduplicate data
     Auto-scale resources
     Scan for vulnerabilities
     Scale to Zero
     

     View Slide

108. Base scaling on
     significant metrics
     Delay execution of compute-intensive
     tasks to times of low carbon intensity
     Maximize hardware
     utilization
     Monitor power
     consumption
     Shed low-priority traffic
     Compress data
     at transit and rest
     Deduplicate data
     Auto-scale resources
     Scan for vulnerabilities
     Scale to Zero
     Runtime
     Implementation
     Design
     Requirements
     Patterns of sustainability
     (Software engineering perspective)
     On-Premises
     Hardware manufacturing
     & data center design
     Mind the Minifesto
     Make carbon-efficiency part of your
     software development and test process
     Use efficient algorithms
     and data structures
     Optimize
     wasteful code
     Do not run builds after
     each minor code change
     Minimize
     startup time
     Scan for vulnerabilities
     Economize on libraries
     and frameworks
     Design carbon-aware
     applications
     Delete unneeded data
     Mind the impact
     on user devices
     Remove unneeded
     components
     Keep data local
     Minimize redundancy
     Use data stores and formats
     optimized for the use case
     Avoid polling
     Choose the right
     programming language
     Cache static data
     Prefer lazy loading
     Reduce transmitted data
     Slice services by
     resource usage
     Design latency-tolerant
     user interfaces
     Offline first
     Mind the energy-consumption
     of functional requirements
     Optimize for
     temporal decoupling
     Fight feature creep
     Data austerity
     Balance Quality
     of Service
     

     View Slide

109. On-premises
     (Responsible: Operations)
     Buy energy-efficient hardware
     Shut down unneeded hardware,
     infrastructure and applications
     Buy only the hardware you need
     

     View Slide

110. On-premises
     (Responsible: Operations)
     Buy energy-efficient hardware
     Shut down unneeded hardware,
     infrastructure and applications
     Buy only the hardware you need
     

     View Slide

111. Shutdown unneeded parts
     • Unused hardware, infrastructure, applications waste energy
     • Shut down all parts not used
     • Turn off hardware reserved for peak load or future demand
     • Includes, e.g., turning off test environments while not needed
     • In cloud environments, shut down all instances not used
     • Does not only reduce costs, but also your carbon footprint
     • Complements maximize hardware utilization
     

     View Slide

112. On-premises
     (Responsible: Operations)
     Buy energy-efficient hardware
     Shut down unneeded hardware,
     infrastructure and applications
     Buy only the hardware you need
     

     View Slide

113. “For data-center operators and cloud providers, most emissions
     are capex-related – for example, construction, infrastructure,
     and hardware manufacturing.”
     Source: Udit Gupta et al., "Chasing Carbon: The Elusive Environmental Footprint of Computing", https://arxiv.org/abs/2011.02839
     

     View Slide

114. Buy only the hardware you need
     • Often, more hardware is bought than currently needed
     • To satisfy peak loads
     • To be prepared for unexpected future demands
     • Producing the hardware has a big environmental footprint
     • Usually exceeds environmental footprint at runtime
     • Do not buy hardware currently not needed
     • Especially relevant for on-premises data centers
     • Cloud providers can better balance diverse demand patterns
     

     View Slide

115. On-premises
     (Responsible: Operations)
     Buy energy-efficient hardware
     Shut down unneeded hardware,
     infrastructure and applications
     Buy only the hardware you need
     

     View Slide

116. Buy energy-efficient hardware
     • There are big differences in energy-efficiency of hardware
     • Buy hardware with best W/Tx ratio for your use cases
     • Can significantly reduce your carbon footprint
     • Complements maximize hardware utilization
     • Complements buy only the hardware you need
     

     View Slide

117. On-premises
     (Responsible: Operations)
     Buy energy-efficient hardware
     Shut down unneeded hardware,
     infrastructure and applications
     Buy only the hardware you need
     

     View Slide

118. Buy energy-efficient hardware
     Shut down unneeded hardware,
     infrastructure and applications
     Buy only the
     hardware you need On-Premises Runtime
     Implementation
     Design
     Requirements
     Patterns of sustainability
     (Software engineering perspective)
     Public cloud
     Hardware manufacturing
     & data center design
     Base scaling on
     significant metrics
     Delay execution of compute-intensive
     tasks to times of low carbon intensity
     Maximize hardware
     utilization
     Monitor power
     consumption
     Shed low-priority traffic
     Compress data
     at transit and rest
     Deduplicate data
     Auto-scale resources
     Scan for vulnerabilities
     Scale to Zero
     Mind the Minifesto
     Make carbon-efficiency part of your
     software development and test process
     Use efficient algorithms
     and data structures
     Optimize
     wasteful code
     Do not run builds after
     each minor code change
     Minimize
     startup time
     Scan for vulnerabilities
     Economize on libraries
     and frameworks
     Design carbon-aware
     applications
     Delete unneeded data
     Mind the impact
     on user devices
     Remove unneeded
     components
     Keep data local
     Minimize redundancy
     Use data stores and formats
     optimized for the use case
     Avoid polling
     Choose the right
     programming language
     Cache static data
     Prefer lazy loading
     Reduce transmitted data
     Slice services by
     resource usage
     Design latency-tolerant
     user interfaces
     Offline first
     Mind the energy-consumption
     of functional requirements
     Optimize for
     temporal decoupling
     Fight feature creep
     Data austerity
     Balance Quality
     of Service
     

     View Slide

119. Public cloud
     (Responsible: Architecture, operations)
     Shift workloads to data centers
     with lower carbon intensity
     Move workloads to the public cloud
     Align data access frequency
     and storage classes
     Use managed services
     Move close to the users
     

     View Slide

120. Public cloud
     (Responsible: Architecture, operations)
     Shift workloads to data centers
     with lower carbon intensity
     Move workloads to the public cloud
     Align data access frequency
     and storage classes
     Use managed services
     Move close to the users
     

     View Slide

121. Move workloads to public cloud
     • Public cloud providers put much effort in energy-efficiency
     • More than on-premises data centers can afford
     • Can achieve much better utilization of hardware
     • Provide many options for reducing energy consumption
     • Support observing energy consumption
     • Yet no altruism, but part of their a business model
     • But you get better support than possible in on-premises DCs
     

     View Slide

122. Public cloud
     (Responsible: Architecture, operations)
     Shift workloads to data centers
     with lower carbon intensity
     Move workloads to the public cloud
     Align data access frequency
     and storage classes
     Use managed services
     Move close to the users
     

     View Slide

123. Use managed services
     • Complements move workloads to the public cloud
     • Managed services typically allow for optimizing utilization
     • Also supports scale to zero out of the box
     • Supports maximize hardware utilization
     • Supports scale to zero
     

     View Slide

124. Public cloud
     (Responsible: Architecture, operations)
     Shift workloads to data centers
     with lower carbon intensity
     Move workloads to the public cloud
     Align data access frequency
     and storage classes
     Use managed services
     Move close to the users
     

     View Slide

125. Follow the carbon intensity
     • Data centers have different carbon intensity
     • Some data centers use more clean energy by default
     • Some data centers have varying patterns over the day
     • Cloud providers usually provide data about carbon intensity
     • Shift workloads to data centers with lower carbon intensity
     • Balance with reduce transmitted data
     • Balance with keep data local
     

     View Slide

126. Public cloud
     (Responsible: Architecture, operations)
     Shift workloads to data centers
     with lower carbon intensity
     Move workloads to the public cloud
     Align data access frequency
     and storage classes
     Use managed services
     Move close to the users
     

     View Slide

127. Use adequate storage classes
     • Different storage classes use different amounts of energy
     • SSD require more energy than HDD
     • HDD require more energy than archival-class storage
     • ...
     • Align data access frequency and storage classes used
     • Complements data austerity
     

     View Slide

128. Public cloud
     (Responsible: Architecture, operations)
     Shift workloads to data centers
     with lower carbon intensity
     Move workloads to the public cloud
     Align data access frequency
     and storage classes
     Use managed services
     Move close to the users
     

     View Slide

129. Move close to the users
     • Reducing network traffic reduces your ecological footprint
     • Move closer to the users, e.g.
     • Choose a region that is closer to the users
     • Use a CDN or leverage edge computing
     • Can be applied to data and to workloads
     • Supports reduce transmitted data
     • Balance with keep data local
     

     View Slide

130. Public cloud
     (Responsible: Architecture, operations)
     Shift workloads to data centers
     with lower carbon intensity
     Move workloads to the public cloud
     Align data access frequency
     and storage classes
     Use managed services
     Move close to the users
     

     View Slide

131. Shift workloads to data centers
     with lower carbon intensity
     Move workloads
     to the public cloud
     Align data access frequency
     and storage classes
     Use managed
     services
     Move close
     to the users
     On-Premises Runtime
     Implementation
     Design
     Requirements
     Public cloud
     Patterns of sustainability
     (Software engineering perspective)
     Cross-cutting
     Hardware manufacturing
     & data center design
     Buy energy-efficient hardware
     Shut down unneeded hardware,
     infrastructure and applications
     Buy only the
     hardware you need
     Base scaling on
     significant metrics
     Delay execution of compute-intensive
     tasks to times of low carbon intensity
     Maximize hardware
     utilization
     Monitor power
     consumption
     Shed low-priority traffic
     Compress data
     at transit and rest
     Deduplicate data
     Auto-scale resources
     Scan for vulnerabilities
     Scale to Zero
     Mind the Minifesto
     Make carbon-efficiency part of your
     software development and test process
     Use efficient algorithms
     and data structures
     Optimize
     wasteful code
     Do not run builds after
     each minor code change
     Minimize
     startup time
     Scan for vulnerabilities
     Economize on libraries
     and frameworks
     Design carbon-aware
     applications
     Delete unneeded data
     Mind the impact
     on user devices
     Remove unneeded
     components
     Keep data local
     Minimize redundancy
     Use data stores and formats
     optimized for the use case
     Avoid polling
     Choose the right
     programming language
     Cache static data
     Prefer lazy loading
     Reduce transmitted data
     Slice services by
     resource usage
     Design latency-tolerant
     user interfaces
     Offline first
     Mind the energy-consumption
     of functional requirements
     Optimize for
     temporal decoupling
     Fight feature creep
     Data austerity
     Balance Quality
     of Service
     

     View Slide

132. Cross-cutting
     (Responsible: Everyone)
     Continuously improve
     Make energy-consumption visible
     Do not feed the resource troll
     

     View Slide

133. Cross-cutting
     (Responsible: Everyone)
     Continuously improve
     Make energy-consumption visible
     Do not feed the resource troll
     

     View Slide

134. Make energy-consumption visible
     • Make energy-consumption visible at all levels
     • Make visible to business experts (e.g., at feature level)
     • Make visible to software engineers (e.g., for apps and CI/CD)
     • Make visible to users (e.g., at feature level)
     • Transparency supports balancing feedback loops
     • Visibility leads to changed behavior and usage patterns
     • Visibility leads to different decisions
     • Does not require explicit “education” or alike
     

     View Slide

135. Cross-cutting
     (Responsible: Everyone)
     Continuously improve
     Make energy-consumption visible
     Do not feed the resource troll
     

     View Slide

136. Continuously improve
     • Becoming ecological sustainable is not a one-time effort
     • It is a long journey without an end state
     • You will not be able to do everything at once
     • Constantly reserve time and resources
     • Make sustainability a continuous improvement process
     

     View Slide

137. Cross-cutting
     (Responsible: Everyone)
     Continuously improve
     Make energy-consumption visible
     Do not feed the resource troll
     

     View Slide

138. Do not feed the resource troll
     • Avoid resource-hungry solutions
     • Try not to use them
     • Try not to recommend them
     • E.g., be reserved regarding resource-hungry AI solutions *
     • Extensive use fosters disproportional energy consumption
     • Only use if really needed
     • Prefer (AI) solutions with comparatively smaller footprint
     * see, e.g., “Deep learning’s diminishing returns”, https://spectrum.ieee.org/deep-learning-computational-cost
     or “The Carbon Footprint of ChatGPT”, https://towardsdatascience.com/the-carbon-footprint-of-chatgpt-66932314627d
     

     View Slide

139. Cross-cutting
     (Responsible: Everyone)
     Continuously improve
     Make energy-consumption visible
     Do not feed the resource troll
     

     View Slide

140. Continuously improve
     Make energy-
     consumption visible
     Do not feed the
     resource troll
     On-Premises Runtime
     Implementation
     Design
     Requirements
     Public cloud
     Cross-cutting
     Patterns of sustainability
     (Software engineering perspective)
     Hardware manufacturing
     & data center design
     Shift workloads to data centers
     with lower carbon intensity
     Move workloads
     to the public cloud
     Align data access frequency
     and storage classes
     Use managed
     services
     Move close
     to the users
     Buy energy-efficient hardware
     Shut down unneeded hardware,
     infrastructure and applications
     Buy only the
     hardware you need
     Base scaling on
     significant metrics
     Delay execution of compute-intensive
     tasks to times of low carbon intensity
     Maximize hardware
     utilization
     Monitor power
     consumption
     Shed low-priority traffic
     Compress data
     at transit and rest
     Deduplicate data
     Auto-scale resources
     Scan for vulnerabilities
     Scale to Zero
     Mind the Minifesto
     Make carbon-efficiency part of your
     software development and test process
     Use efficient algorithms
     and data structures
     Optimize
     wasteful code
     Do not run builds after
     each minor code change
     Minimize
     startup time
     Scan for vulnerabilities
     Economize on libraries
     and frameworks
     Design carbon-aware
     applications
     Delete unneeded data
     Mind the impact
     on user devices
     Remove unneeded
     components
     Keep data local
     Minimize redundancy
     Use data stores and formats
     optimized for the use case
     Avoid polling
     Choose the right
     programming language
     Cache static data
     Prefer lazy loading
     Reduce transmitted data
     Slice services by
     resource usage
     Design latency-tolerant
     user interfaces
     Offline first
     Mind the energy-consumption
     of functional requirements
     Optimize for
     temporal decoupling
     Fight feature creep
     Data austerity
     Balance Quality
     of Service
     

     View Slide

141. Core messages
     • Do less
     • Optimize at all levels
     • Ensure observability
     • Counterforce
     • Nice side effect: Smaller attack surfaces *
     * https://portswigger.net/daily-swig/lean-green-coding-machine-how-sustainable-computing-drive-can-reduce-attack-surfaces
     

     View Slide

142. The bigger picture
     

     View Slide

143. Sustainability is more than just ecological sustainability
     

     View Slide

144. Dimensions of sustainability
     • Ecological sustainability – going green in IT
     • Economical sustainability – surviving in the long run
     • Technical sustainability – creating dependable systems
     • Social sustainability – sustainable for everyone involved
     

     View Slide

145. Sustainability lives in a bigger context
     

     View Slide

146. Core IT challenges
     of the 21st century
     (Responsible: Everyone)
     Resilience
     Sustainability
     Simplification
     

     View Slide

147. Summing up
     

     View Slide

148. Summing up
     • Ecological sustainability has become an important IT topic
     • IT is responsible for more and more GHG emissions
     • IT can support decarbonization in other sectors
     • Software is a big driver of IT GHG emissions
     • Software engineers can positively influence GHG emissions
     • Requires improvements from requirements to production
     • Many patterns available
     • Often counterforce to widespread “best practices”
     • Ecological sustainability is part of a bigger challenge
     

     View Slide

149. A journey of a thousand miles begins with a single step
     -- Chinese proverb
     

     View Slide

150. References and further reading
     Foundations & core principles
     • Principles of Green Software Engineering
     https://principles.green/
     • Greenhouse Gas Protocol
     https://ghgprotocol.org/
     • Green Software Foundation
     https://greensoftware.foundation/
     • Software Carbon Intensity (SCI) specification:
     https://github.com/Green-Software-Foundation/
     software_carbon_intensity/blob/main/Software_Carbon_Intensity/
     Software_Carbon_Intensity_Specification.md
     

     View Slide

151. References and further reading
     Foundations & core principles
     • Gupta et al., “Chasing Carbon: The Elusive Environmental
     Footprint of Computing”
     https://arxiv.org/abs/2011.02839
     • Barroso et al., “The Case for Energy-Proportional
     Computing”
     https://www.researchgate.net/publication/2962080_The_Case_for_Energy-
     Proportional_Computing
     • Wikipedia
     https://en.wikipedia.org/wiki/Energy_proportional_computing
     https://en.wikipedia.org/wiki/Algorithmic_efficiency
     

     View Slide

152. References and further reading
     Patterns
     • Green Software Patterns
     https://patterns.greensoftware.foundation/
     • SoftAWERE Principles for Sustainable Software Design
     https://knowledge.sdialliance.org/softawere/principles-for-sustainable-
     software-design
     • Sustainability Pillar – AWS Well-Architected Framework
     https://docs.aws.amazon.com/wellarchitected/latest/sustainability-
     pillar/sustainability-pillar.html
     • Reduce your Google Cloud carbon footprint
     https://cloud.google.com/architecture/reduce-carbon-footprint
     

     View Slide

153. References and further reading
     Patterns
     • Pereira et al., “Energy Efficiency across Programming
     Languages: how do energy, time, and memory relate?”
     https://www.researchgate.net/publication/320436353_Energy_efficiency_
     across_programming_languages_how_do_energy_time_and_memory_relat
     e
     • Demaine et al. “Energy-Efficient Algorithms”
     https://arxiv.org/abs/1605.08448
     

     View Slide

154. References and further reading
     Guides
     • Measuring Your Application Power and Carbon Impact
     https://devblogs.microsoft.com/sustainable-software/measuring-your-
     application-power-and-carbon-impact-part-1/
     • How to measure the power consumption of your backend
     service
     https://devblogs.microsoft.com/sustainable-software/how-to-measure-
     the-power-consumption-of-your-backend-service/
     • How To Measure The Power Consumption of Your
     Frontend Application
     https://devblogs.microsoft.com/sustainable-software/how-to-measure-
     the-power-consumption-of-your-frontend-application/
     

     View Slide

155. References and further reading
     Tools
     • Cloud Carbon Footprint
     https://www.cloudcarbonfootprint.org/
     • Electricity Maps
     https://www.electricitymaps.com/
     • PowerAPI
     https://github.com/powerapi-ng/powerapi
     • CodeCarbon
     https://mlco2.github.io/codecarbon/
     

     View Slide

156. References and further reading
     Tools
     • AWS Customer Carbon Footprint Tool
     https://aws.amazon.com/de/aws-cost-management/aws-customer-
     carbon-footprint-tool/
     • Google Cloud Carbon Footprint
     https://cloud.google.com/carbon-footprint
     • Emissions Impact Dashboard for Azure
     https://appsource.microsoft.com/en-us/product/power-bi/coi-
     sustainability.emissions_impact_dashboard
     • KEDA – Kubernetes Event-driven Autoscaling
     https://keda.sh/
     

     View Slide

157. References and further reading
     Miscellaneous
     • Center for Sustainable Systems, “Green IT fact sheet”
     https://css.umich.edu/publications/factsheets/built-environment/green-it-
     factsheet
     • The Carbon Benefits of Cloud Computing: a Study of the
     Microsoft Cloud
     https://www.microsoft.com/en-us/download/details.aspx?id=56950
     • 451 Research, “The Carbon Reduction Opportunity of
     Moving to Amazon Web”
     https://d39w7f4ix9f5s9.cloudfront.net/e3/79/42bf75c94c279c67d777f00
     2051f/carbon-reduction-opportunity-of-moving-to-aws.pdf
     

     View Slide

158. References and further reading
     Miscellaneous
     • Center for Sustainable Systems, “Green IT fact sheet”
     https://css.umich.edu/publications/factsheets/built-environment/green-it-
     factsheet
     • BCS, “Green IT and net zero”
     https://www.bcs.org/articles-opinion-and-research/green-it/
     • Minifesto
     http://minifesto.org/
     • Thompson et al., “Deep Learning’s diminishing Returns”
     https://spectrum.ieee.org/deep-learning-computational-cost
     

     View Slide

159. Uwe Friedrichsen
     Works @ codecentric
     https://twitter.com/ufried
     https://www.speakerdeck.com/ufried
     https://ufried.com/
     

     View Slide