Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Is green IT a relevant topic?

Slide 4

Slide 4 text

“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)

Slide 5

Slide 5 text

“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)

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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! 🥳

Slide 8

Slide 8 text

“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)

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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! 🥳

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Well, a lot ...

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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, ...

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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)

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

“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

Slide 56

Slide 56 text

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/

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

“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)

Slide 67

Slide 67 text

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)

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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/

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

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

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

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

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

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

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

“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

Slide 114

Slide 114 text

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

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

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

Slide 118

Slide 118 text

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

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

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

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

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

Slide 130

Slide 130 text

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

Slide 131

Slide 131 text

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

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

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

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

The bigger picture

Slide 143

Slide 143 text

Sustainability is more than just ecological sustainability

Slide 144

Slide 144 text

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

Slide 145

Slide 145 text

Sustainability lives in a bigger context

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

Summing up

Slide 148

Slide 148 text

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

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

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

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

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

Slide 154

Slide 154 text

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/

Slide 155

Slide 155 text

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/

Slide 156

Slide 156 text

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/

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

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

Slide 159

Slide 159 text

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