├── .github ├── ISSUE_TEMPLATE │ ├── bug_report.md │ ├── feature_request.md │ ├── meeting-template.md │ └── new_pattern_request.md ├── PULL_REQUEST_TEMPLATE.md └── workflows │ └── deploy.yml ├── .gitignore ├── ADOPTERS.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── ENABLEMENT.md ├── README.md ├── TEMPLATE.md ├── babel.config.js ├── docs ├── catalog │ ├── .keep │ ├── ai │ │ ├── .keep │ │ ├── compress-ml-models-for-inference.md │ │ ├── efficent-format-for-model-training.md │ │ ├── energy-efficent-ai-edge.md │ │ ├── energy-efficent-framework.md │ │ ├── energy-efficent-models.md │ │ ├── index.md │ │ ├── leverage-sustainable-regions.md │ │ ├── pre-trained-transfer-learning.md │ │ ├── right-hardware-type.md │ │ └── serverless-model-development.md │ ├── cloud │ │ ├── .keep │ │ ├── cache-static-data.md │ │ ├── choose-region-closest-to-users.md │ │ ├── compress-stored-data.md │ │ ├── compress-transmitted-data.md │ │ ├── containerize-your-workload-where-applicable.md │ │ ├── delete-unused-storage-resources.md │ │ ├── encrypt-what-is-necessary.md │ │ ├── evaluate-other-cpu-architectures.md │ │ ├── evaluate-using-a-service-mesh.md │ │ ├── evaluate-whether-to-use-TLS-termination.md │ │ ├── implement-stateless-design.md │ │ ├── index.md │ │ ├── match-slo.md │ │ ├── match-utilization-requirements-of-vm.md │ │ ├── match-utilization-requirements-with-pre-configured-server.md │ │ ├── minimizing-deployed-environments.md │ │ ├── optimise-storage-resource-utilisation.md │ │ ├── optimize-avg-cpu-utilization.md │ │ ├── optimize-impact-on-customer-equipment.md │ │ ├── optimize-peak-cpu-utilization.md │ │ ├── queue-non-urgent-requests.md │ │ ├── reduce-network-traversal-between-VMs.md │ │ ├── reduce-transmitted-data.md │ │ ├── remove-unused-assets.md │ │ ├── scale-down-kubernetes-workloads.md │ │ ├── scale-down-unused-applications.md │ │ ├── scale-infrastructure-with-user-load.md │ │ ├── scale-kubernetes-workloads-based-on-events.md │ │ ├── scale-logical-components-independently.md │ │ ├── scan-for-vulnerabilities.md │ │ ├── set-retention-policy-on-storage-resources.md │ │ ├── shed-lower-priority-traffic.md │ │ ├── time-shift-kubernetes-cron-jobs.md │ │ ├── use-async-instead-of-sync.md │ │ ├── use-circuit-breaker.md │ │ ├── use-cloud-native-network-security-tools-and-controls.md │ │ ├── use-compiled-languages.md │ │ ├── use-ddos-protection.md │ │ ├── use-energy-efficient-hardware.md │ │ └── use-serverless.md │ ├── index.md │ └── web │ │ ├── .keep │ │ ├── avoid-chaining-critical-requests.md │ │ ├── avoid-excessive-dom-size.md │ │ ├── avoid-tracking-unnecessary-data.md │ │ ├── defer-offscreen-images.md │ │ ├── deprecate-gifs.md │ │ ├── enable-text-compression.md │ │ ├── index.md │ │ ├── keep-request-counts-low.md │ │ ├── minify-web-assets.md │ │ ├── minimize-main-thread-work.md │ │ ├── properly-sized-images.md │ │ ├── remove-unused-css.md │ │ ├── serve-images-in-modern-formats.md │ │ └── use-server-side-rendering.md ├── guide │ ├── .keep │ ├── index.md │ ├── initial-reviewer-guide.md │ ├── sme-reviewer-guide.md │ └── suggested-tags.md ├── index.mdx └── tags │ └── index.md ├── docusaurus.config.js ├── license.md ├── package.json ├── sidebars.js ├── src ├── components │ ├── HomepageFeatures │ │ ├── index.tsx │ │ └── styles.module.css │ └── TeamMember │ │ ├── index.tsx │ │ └── styles.module.css ├── css │ └── custom.css └── images │ ├── GSF_Principles_Patterns_Practices_v2.png │ ├── test.txt │ └── time-shift.png ├── static ├── .nojekyll ├── CNAME └── img │ ├── favicon.ico │ ├── logo.png │ ├── logo.svg │ └── og-image.png ├── tsconfig.json └── yarn.lock /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Describe the bug** 11 | A clear and concise description of what the bug is. 12 | 13 | **To Reproduce** 14 | Steps to reproduce the behavior: 15 | 1. Go to '...' 16 | 2. Click on '....' 17 | 3. Scroll down to '....' 18 | 4. See error 19 | 20 | **Expected behavior** 21 | A clear and concise description of what you expected to happen. 22 | 23 | **Screenshots** 24 | If applicable, add screenshots to help explain your problem. 25 | 26 | **Desktop (please complete the following information):** 27 | - OS: [e.g. iOS] 28 | - Browser [e.g. chrome, safari] 29 | - Version [e.g. 22] 30 | 31 | **Smartphone (please complete the following information):** 32 | - Device: [e.g. iPhone6] 33 | - OS: [e.g. iOS8.1] 34 | - Browser [e.g. stock browser, safari] 35 | - Version [e.g. 22] 36 | 37 | **Additional context** 38 | Add any other context about the problem here. 39 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/feature_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Feature request 3 | about: Suggest an idea for this project 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Is your feature request related to a problem? Please describe.** 11 | A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 12 | 13 | **Describe the solution you'd like** 14 | A clear and concise description of what you want to happen. 15 | 16 | **Describe alternatives you've considered** 17 | A clear and concise description of any alternative solutions or features you've considered. 18 | 19 | **Additional context** 20 | Add any other context or screenshots about the feature request here. 21 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/meeting-template.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Meeting Template 3 | about: To track patterns project meeting agenda, minutes and attendance 4 | title: YYYY-MM-DD - Green Software Principles & Patterns Agenda 5 | labels: agenda 6 | assignees: '' 7 | 8 | --- 9 | 10 | ## Date 11 | YYYY-MM-DD - 15:00 UTC - See the time in your timezone https://everytimezone.com/s/ab85f7c5 12 | 13 | ## Roll Call 14 | Please *add a comment* to this issue during the meeting to denote attendance. 15 | Any untracked attendees will be added by the GSF team below: 16 | - Full Name, Affiliation, (optional) GitHub username 17 | 18 | ### Previous Meeting 19 | 20 | Notes from the previous meeting: ... 21 | 22 | ## Agenda 23 | - [ ] Convene & Roll Call 24 | - [ ] Review the agenda and suggest new agenda points 25 | - [ ] [Agenda Items] 26 | - [ ] Green Software for Practitioners 27 | - [ ] Green Software Patterns 28 | - [ ] AOB, Q&A & Adjourn 29 | 30 | ## Green Software for Practitioners 31 | 32 | * OKRs & KPIs 33 | 34 | ## Green Software Patterns 35 | 36 | * OKRs & KPIs 37 | 38 | ## Use Cases 39 | 40 | ## Any Other Business 41 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/new_pattern_request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: New Pattern request 3 | about: Suggest a new pattern for consideration 4 | title: '' 5 | labels: 'Proposed Pattern' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Describe the pattern you'd like to propose** 11 | A clear and concise description of what you think the pattern should be. 12 | 13 | **Describe specific emission impact from this pattern** 14 | A clear and concise description of how you see this pattern impacting software emissions. 15 | 16 | **References to this pattern** 17 | Is this a new concept or does this pattern exist somewhere already? Please provide any references you have to existing examples. 18 | 19 | **Additional context** 20 | Add any other context or screenshots about the proposed pattern here. 21 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | Title of the pattern 3 | 4 | ## Version 5 | Designation of iteration on the pattern. This will initially be assigned by the patterns working group 6 | 7 | ## Submitted By 8 | The name of the person(s) submitting the pattern 9 | 10 | ## Published Date 11 | The date this version of the pattern is published. This will be provided by the patterns working group upon approval 12 | 13 | ## Intent 14 | Subtitle describing what this pattern is expected to do 15 | 16 | ## Tags 17 | Pre-defined list of tags which might apply to the pattern (e.g. Cloud, Web) 18 | ``` 19 | --- 20 | tags: 21 | - cloud 22 | - web 23 | --- 24 | ``` 25 | 26 | ## Problem 27 | What is the problem this pattern is solving 28 | 29 | ## Solution 30 | How will this patter solve the problem 31 | 32 | ## SCI Impact 33 | How will this pattern affect an SCI score of an application and why 34 | 35 | ``` 36 | `SCI = (E * I) + M per R` 37 | ``` 38 | 39 | ## Assumptions 40 | What are the assumptions being made 41 | 42 | ## Pros & Cons 43 | Discussion section for pros and cons of this pattern 44 | ``` 45 | - **PRO**: 46 | - **CON**: 47 | ``` 48 | -------------------------------------------------------------------------------- /.github/workflows/deploy.yml: -------------------------------------------------------------------------------- 1 | name: Deploy to GitHub Pages 2 | 3 | on: 4 | push: 5 | branches: 6 | - main 7 | # Review gh actions docs if you want to further define triggers, paths, etc 8 | # https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#on 9 | 10 | jobs: 11 | deploy: 12 | name: Deploy to GitHub Pages 13 | runs-on: ubuntu-latest 14 | steps: 15 | - uses: actions/checkout@v2 16 | - uses: actions/setup-node@v3 17 | with: 18 | node-version: 18 19 | cache: yarn 20 | 21 | - name: Install dependencies 22 | run: yarn install --frozen-lockfile 23 | - name: Build website 24 | run: yarn build 25 | 26 | # Popular action to deploy to GitHub Pages: 27 | # Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus 28 | - name: Deploy to GitHub Pages 29 | uses: peaceiris/actions-gh-pages@v3 30 | with: 31 | github_token: ${{ secrets.GITHUB_TOKEN }} 32 | # Build output to publish to the `gh-pages` branch: 33 | publish_dir: ./build 34 | # The following lines assign commit authorship to the official 35 | # GH-Actions bot for deploys to `gh-pages` branch: 36 | # https://github.com/actions/checkout/issues/13#issuecomment-724415212 37 | # The GH actions bot is used by default if you didn't specify the two fields. 38 | # You can swap them out with your own user credentials. 39 | user_name: github-actions[bot] 40 | user_email: 41898282+github-actions[bot]@users.noreply.github.com 41 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Dependencies 2 | /node_modules 3 | 4 | # Production 5 | /build 6 | 7 | # Generated files 8 | .docusaurus 9 | .cache-loader 10 | 11 | # Misc 12 | .DS_Store 13 | .env.local 14 | .env.development.local 15 | .env.test.local 16 | .env.production.local 17 | 18 | npm-debug.log* 19 | yarn-debug.log* 20 | yarn-error.log* 21 | -------------------------------------------------------------------------------- /ADOPTERS.md: -------------------------------------------------------------------------------- 1 | # Adopters 2 | 3 | If you're using the Green Software Patterns, we'd love to add you to this list. Please reach out to principles@greensoftware.foundation or raise a pull request. 4 | 5 | | Organization | Description of Use | Contact | 6 | |--------------|--------------------|---------| 7 | | [AVEVA](https://www.aveva.com/en/) | Used the patterns as a way to measure the green software maturity of products teams. For additional details, please refer to our [Wiki](https://github.com/Green-Software-Foundation/patterns/wiki/Adoption-Stories#aveva). | Daniel Lazaro
:email: daniel.lazaro@aveva.com | 8 | | [Mastercard](https://www.mastercard.co.uk/en-gb.html) | The Mastercard-specific catalogue enhances the GSF reference by providing tailored patterns across five categories—Architectural, Technology Stack & Tooling, Code and Algorithm, Methodology, and Operational Patterns—focused on optimizing efficiency and minimizing CO2 emissions while addressing the unique needs of Mastercard team. For additional details, please refer to our [Wiki](https://github.com/Green-Software-Foundation/patterns/wiki/Adoption-Stories#mastercard) | Sébastien Le Callonnec
:email: Sebastien.LeCallonnec@mastercard.com | 9 | 10 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | We as members, contributors, and leaders pledge to make participation in our 6 | community a harassment-free experience for everyone, regardless of age, body 7 | size, visible or invisible disability, ethnicity, sex characteristics, gender 8 | identity and expression, level of experience, education, socio-economic status, 9 | nationality, personal appearance, race, caste, color, religion, or sexual identity 10 | and orientation. 11 | 12 | We pledge to act and interact in ways that contribute to an open, welcoming, 13 | diverse, inclusive, and healthy community. 14 | 15 | ## Our Standards 16 | 17 | Examples of behavior that contributes to a positive environment for our 18 | community include: 19 | 20 | - Demonstrating empathy and kindness toward other people 21 | - Being respectful of differing opinions, viewpoints, and experiences 22 | - Giving and gracefully accepting constructive feedback 23 | - Accepting responsibility and apologizing to those affected by our mistakes, 24 | and learning from the experience 25 | - Focusing on what is best not just for us as individuals, but for the 26 | overall community 27 | 28 | Examples of unacceptable behavior include: 29 | 30 | - The use of sexualized language or imagery, and sexual attention or 31 | advances of any kind 32 | - Trolling, insulting or derogatory comments, and personal or political attacks 33 | - Public or private harassment 34 | - Publishing others' private information, such as a physical or email 35 | address, without their explicit permission 36 | - Other conduct which could reasonably be considered inappropriate in a 37 | professional setting 38 | 39 | ## Enforcement Responsibilities 40 | 41 | Community leaders are responsible for clarifying and enforcing our standards of 42 | acceptable behavior and will take appropriate and fair corrective action in 43 | response to any behavior that they deem inappropriate, threatening, offensive, 44 | or harmful. 45 | 46 | Community leaders have the right and responsibility to remove, edit, or reject 47 | comments, commits, code, wiki edits, issues, and other contributions that are 48 | not aligned to this Code of Conduct, and will communicate reasons for moderation 49 | decisions when appropriate. 50 | 51 | ## Scope 52 | 53 | This Code of Conduct applies within all community spaces, and also applies when 54 | an individual is officially representing the community in public spaces. 55 | Examples of representing our community include using an official e-mail address, 56 | posting via an official social media account, or acting as an appointed 57 | representative at an online or offline event. 58 | 59 | ## Enforcement 60 | 61 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 62 | reported to the community leaders responsible for enforcement. 63 | All complaints will be reviewed and investigated promptly and fairly. 64 | 65 | All community leaders are obligated to respect the privacy and security of the 66 | reporter of any incident. 67 | 68 | ## Enforcement Guidelines 69 | 70 | Community leaders will follow these Community Impact Guidelines in determining 71 | the consequences for any action they deem in violation of this Code of Conduct: 72 | 73 | ### 1. Correction 74 | 75 | **Community Impact**: Use of inappropriate language or other behavior deemed 76 | unprofessional or unwelcome in the community. 77 | 78 | **Consequence**: A private, written warning from community leaders, providing 79 | clarity around the nature of the violation and an explanation of why the 80 | behavior was inappropriate. A public apology may be requested. 81 | 82 | ### 2. Warning 83 | 84 | **Community Impact**: A violation through a single incident or series 85 | of actions. 86 | 87 | **Consequence**: A warning with consequences for continued behavior. No 88 | interaction with the people involved, including unsolicited interaction with 89 | those enforcing the Code of Conduct, for a specified period of time. This 90 | includes avoiding interactions in community spaces as well as external channels 91 | like social media. Violating these terms may lead to a temporary or 92 | permanent ban. 93 | 94 | ### 3. Temporary Ban 95 | 96 | **Community Impact**: A serious violation of community standards, including 97 | sustained inappropriate behavior. 98 | 99 | **Consequence**: A temporary ban from any sort of interaction or public 100 | communication with the community for a specified period of time. No public or 101 | private interaction with the people involved, including unsolicited interaction 102 | with those enforcing the Code of Conduct, is allowed during this period. 103 | Violating these terms may lead to a permanent ban. 104 | 105 | ### 4. Permanent Ban 106 | 107 | **Community Impact**: Demonstrating a pattern of violation of community 108 | standards, including sustained inappropriate behavior, harassment of an 109 | individual, or aggression toward or disparagement of classes of individuals. 110 | 111 | **Consequence**: A permanent ban from any sort of public interaction within 112 | the community. 113 | 114 | ## Attribution 115 | 116 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], 117 | version 2.0, available at 118 | [https://www.contributor-covenant.org/version/2/0/code_of_conduct.html][v2.0]. 119 | 120 | Community Impact Guidelines were inspired by 121 | [Mozilla's code of conduct enforcement ladder][mozilla coc]. 122 | 123 | For answers to common questions about this code of conduct, see the FAQ at 124 | [https://www.contributor-covenant.org/faq][faq]. Translations are available 125 | at [https://www.contributor-covenant.org/translations][translations]. 126 | 127 | [homepage]: https://www.contributor-covenant.org 128 | [v2.0]: https://www.contributor-covenant.org/version/2/0/code_of_conduct.html 129 | [mozilla coc]: https://github.com/mozilla/diversity 130 | [faq]: https://www.contributor-covenant.org/faq 131 | [translations]: https://www.contributor-covenant.org/translations 132 | 133 | --- -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # GSF Member Contribution Guide 2 | 3 | Welcome to the GSF Patterns Working Group, and thank you for contributing to this project. This guide outlines the steps for working within the Patterns Working Group and the approved contribution process that members should follow. 4 | 5 | **Please contact the project owners for individual contributions. Working Group meetings and the internal communication channels are only open to GSF Members.** 6 | 7 | ## Table of Contents 8 | 9 | - [GSF Member Contribution Guide](#gsf-member-contribution-guide) 10 | - [Table of Contents](#table-of-contents) 11 | - [Summary Steps](#summary-steps) 12 | - [Become A Subject Matter Expert](#become-a-subject-matter-expert) 13 | - [Public Issues](#public-issues) 14 | 15 | ## Summary Steps 16 | 17 | For the following: 18 | 19 | "Member and "Contributor" refer to the GSF member looking to make a feature contribution. 20 | "Chair" refers to the Chair, Co-Chair or other accountable authority within GSF. 21 | 22 | ### Submitting A New Pattern For Consideration 23 | 1. Submit a new Pull Request (PR) to `GSF/green-software-patterns/dev` 24 | 2. The PR will be initially reviewed within 1 week to enforce format, structure, and relevance. The submitter must make any requested changes to advance the PR 25 | 3. The PR will be assigned a Subject Matter Expert (SME) for deeper analysis and evaluation for 2 weeks. The submitter must make any requested changes from the SME to advance the PR. 26 | 4. Once the Pattern has been approved by the SME it will begin the team review phase. The PR requires consensus before approval and merge and the Patterns team has 2 weeks to comment/object to the pattern. 27 | 5. Upon approval, the Pattern will be merged into `GSF/green-software-patterns/dev` 28 | 6. Every quarter, `GSF/green-software-patterns/dev` will be merged to `GSF/green-software-patterns/main` which will trigger a consistency review allowing anyone in the Foundation 2 weeks to comment or object. GSF-wide consensus is required for the patterns to be published. 29 | 30 | 31 | ### All Other Change Requests & Feedback 32 | 1. Submit a Public Issue using the Issue Template 33 | 2. The Issue will be looked at by a Chair and approved. 34 | 3. The Contributor is assigned an "Approved Reviewer" who will help shepherd the feature into the GSF Repository 35 | 4. Fork `GSF/green-software-patterns/dev` into a member repository, `member/green-software-patterns/dev` 36 | 5. Open a Draft PR from `member/dev` into `GSF/green-software-patterns/dev` using the PR Template 37 | 6. Once development is over, the Approved Reviewer pushes the PR into the "Ready for Review" state 38 | 7. If the Chair accepts the PR, it merges into `GSF/green-software-patterns/dev` 39 | 40 | ## Become A Subject Matter Expert 41 | We are looking for new subject matter experts (SMEs) to help provide feedback and guidance for submitted patterns. If you would like to become a SME for Green Software Patterns, please [fill out the request form](https://docs.google.com/forms/d/e/1FAIpQLSdNxIGsD-02GS5oDy53YgswzmIN7PDFUDW6bcDMRHTnAtTNjg/viewform) and one of our leads will contact you. You can see the list of available areas in the [Suggested Tags](https://patterns.greensoftware.foundation/tags) section of the website. 42 | 43 | ## Public Issues 44 | 45 | All contributions to the GSF are tracked through public issues. Please make a public issue and fill out details on the proposed feature contribution. The issue serves as a commitment by the contributor to developing the feature. 46 | 47 | The Issue is **not** a feature request, but tracks expected feature work. Please do **not** open an issue to request features. 48 | -------------------------------------------------------------------------------- /ENABLEMENT.md: -------------------------------------------------------------------------------- 1 | # Enablement Guide for Green Software Patterns (GSP) 2 | 3 | ## What is Green Software Patterns? 4 | 5 | The **Green Software Patterns (GSP)** is an open-source database of software patterns designed to reduce software emissions. It provides actionable, vendor-agnostic guidance across various categories that can be applied to real-world situations. 🌱 6 | 7 | ## How to Navigate the Patterns Catalog 8 | ### Step 1: Identify the Appropriate Category 9 | 10 | The GSP database is meticulously organized into three primary categories: 11 | 12 | 1. Artificial Intelligence 13 | 2. Cloud 14 | 3. Web 15 | 16 | 17 | Each category encompasses a diverse array of patterns tailored to address specific challenges and opportunities within that domain. It is important to recognize that not all patterns need to be implemented simultaneously; often, only a select few will be relevant to your particular use case. 18 | 19 | ### Step 2: Explore Available Patterns 20 | Within each category, you will find a collection of distinct patterns that offer strategies and best practices for reducing software emissions. Take the time to review the descriptions and intended applications of each pattern to determine which ones align best with your objectives. 21 | 22 | ### Step 3: Engage with Subject Matter Experts 23 | To enhance your understanding and application of the patterns, each category is supported by designated Subject Matter Experts (SMEs). These experts are available to provide insights, answer questions, and offer guidance tailored to your specific context. Should you require assistance or wish to delve deeper into a particular pattern, do not hesitate to reach out to the associated SME for support. 24 | 25 | ### Step 4: Implement and Iterate 26 | Once you have identified the relevant patterns for your use case, proceed with their implementation. Monitor the outcomes and gather feedback to assess the effectiveness of the chosen strategies. Continuous improvement is key—feel free to iterate on your approach and explore additional patterns as your project evolves. 27 | 28 | ### Step 5: Share Your Experiences 29 | As you implement Green Software Patterns, we encourage you to share your experiences and insights with us. Your contributions can help others in their journey towards sustainable software development and foster a collaborative environment focused on reducing software emissions. 30 | 31 | ### Conclusion 32 | The Green Software Patterns catalog serves as a vital resource for organizations seeking to align their software development practices with sustainability goals. By leveraging the structured guidance provided within the GSP, you can make meaningful strides towards reducing your software's carbon footprint while fostering innovation and efficiency. Together, we can pave the way for a greener digital future. 33 | 34 | 35 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Patterns of Green Software Engineering 2 | 3 | ## Scope 4 | An open-source database of software patterns that, if applied, will reduce software emissions. Each pattern has been thoroughly reviewed by experts and agreed upon by all members of the Foundation. The patterns are the next step in the Foundation's goal to create an ecosystem of people with the knowledge of how to build greener applications. 5 | 6 | For the longest time, the feedback we've received is that people need actionable advice they can apply immediately to their software products. However, the correct choices can change dramatically from one technology to another. For example, a good pattern for an AI product might be a wrong pattern for a web application. The information is out there but hard to find. We need one place where everyone can go for green software patterns regardless of their role or the technology and trust that if they apply the pattern, it will reduce emissions. 7 | 8 | The catalog of green software patterns is an online open-source database of software patterns reviewed and curated by the Green Software Foundation across a wide range of categories. Any software practitioner can find the patterns related to their field, technology, or domain. Anyone can submit a pattern that triggers a detailed review process by the Foundation. You can be confident that applying any patterns that have completed that process will reduce your software emissions. 9 | 10 | The intention is that patterns are vendor agnostic, for instance there should not be Azure, AWS and GCP patterns. There should be generic cloud patterns which could be applied to specific vendors, but the patterns themselves are vendor agnostic. We encourage specific platforms/vendors to create vendor-specific versions of these patterns for their specific products on their platforms. 11 | 12 | To use the patterns, head to https://patterns.greensoftware.foundation and search for your field or technology. Each pattern is atomic and applicable to real-world situations and applications. 13 | 14 | ## Appointments 15 | 16 | The project is led by: 17 | 18 | * [Franziska Warncke](https://github.com/franziska-warncke) (NTT DATA) 19 | * [Liya Mathew](https://github.com/LiyaMath) (Goldman Sachs) 20 | 21 | ## Components of a Green Software Pattern 22 | * **Title**: Title of the pattern 23 | * **Version**: Designation of iteration on the pattern. This will initially be assigned by the patterns working group 24 | * **Submitted By**: The name of the person(s) submitting the pattern 25 | * **Published Date**: The date this version of the pattern is published. This will be provided by the patterns working group upon approval 26 | * **Tag Category**: Select the most appropriate category from: Artificial Intelligence, Cloud, or Web which might apply to this pattern 27 | * **Tags**: A [pre-defined list of additional tags](https://patterns.greensoftware.foundation/tags/) which might apply to the pattern (e.g. Machine Learning, Gaming, Mobile). 28 | * **Description**: A full description of what problem this pattern is solving 29 | * **Solution**: How will this patter solve the problem 30 | * **SCI Impact**: How will this pattern affect an SCI score of an application and why 31 | * **Assumptions**: What are the assumptions being made 32 | * **Considerations**: Discussion section anything that should be taken into consideration when implementing this pattern 33 | * **References**: If this pattern, or components of it, is defined somewhere else the web please add links to those resources in this section 34 | 35 | ## Stages of a Green Software Pattern 36 | 37 | ### Discussion 38 | Anyone (member or non-members) can discuss patterns via the GitHub Issues tab of the repository. There will be an issue template to suggest new patterns or suggest changes to existing patterns. Once they are ready then can go ahead and create a PR to add a pattern to the database. 39 | 40 | ### Draft 41 | Anyone (member or non-members) can create a PR matching the template for Green Software Patterns to be merged into the dev branch. This starts an internal process of review. 42 | 43 | ### Initial Review 44 | An initial review by one member of the principles and patterns project. The goal of this stage is just to make sure the pattern meets core requirements for what a pattern should contain, is it the right format, syntax etc…? 45 | 46 | The initial reviewer will also decide what subject matter experts are required to review this pattern. 47 | 48 | This needs an explicit approval from the initial reviewer before the pattern can move to the next stage. 49 | 50 | ### SME Review 51 | One or more subject matter experts in the GSF are asked to review the pattern and give their feedback. E.g. If the pattern is in the machine-learning catalog we ask a machine learning expert to review. 52 | 53 | This needs an explicit approval from the SME reviewer before the pattern can move to the next stage. 54 | 55 | 56 | ### Team Consensus 57 | Once the pattern has been approved by the SME it starts the team review phase. The principles and patterns team has 2 weeks to comment/object to the pattern. It needs consensus before the PR can be approved and merged into dev. 58 | 59 | The pattern is merged into dev but is not published on our website. 60 | 61 | 62 | ### Consistency Review 63 | Every quarter the dev branch is merged to the main branch and this triggers a consistency review where anyone in the Foundation has 2 weeks to comment or object. We need GSF wide consensus for the patterns to be published. 64 | 65 | This is done in batches every quarter to reduce the noise to the rest of the Foundation. 66 | 67 | ## Internal Review Timelines 68 | The working group will regularly review submitted patterns along the following timeline: 69 | 70 | * Initial Review: 1 week 71 | * SME Review: 2 weeks (plus additional iteration time based on feedback) 72 | * Team Consensus: 2 weeks 73 | 74 | ## Copyright 75 | The Green Software Patterns projects are copyrighted under [Creative Commons Attribution 4.0](https://creativecommons.org/licenses/by/4.0/). 76 | 77 | ## Patent 78 | No Patent License. No patent licenses are granted for the Draft Deliverables or Approved Deliverables developed by this Working Group. 79 | 80 | ## License 81 | The Green Software Patterns projects are licensed under the MIT License - see the [License.md](license.md) file for details. 82 | -------------------------------------------------------------------------------- /TEMPLATE.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: [PATTERN_AUTHOR_GITHUB_ALIAS] 4 | published_date: TBD 5 | category: [PATTERN_TAG_CATEGORY] 6 | description: [PATTERN_DESCRIPTION_METADATA] 7 | tags: 8 | - [PATTERN_TAGS] 9 | --- 10 | 11 | # [PATTERN_TITLE_ACTION_ON_RESOURCE] 12 | 13 | ## Description 14 | 15 | [PATTERN_PROBLEM_DESCRIPTION] 16 | 17 | ## Solution 18 | 19 | [PATTERN_SOLUTION] 20 | 21 | ## SCI Impact 22 | 23 | `SCI = (E * I) + M per R` 24 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 25 | 26 | [PATTERN_SCI_IMPACT] 27 | 28 | - `E`: [PATTERN_ENERGY_SCI_IMPACT] 29 | - `I`: [PATTERN_INTENSITY_SCI_IMPACT] 30 | - `M`: [PATTERN_EMBODIED_SCI_IMPACT] 31 | - `R`: [PATTERN_RATE_SCI_IMPACT] 32 | 33 | ## Assumptions 34 | 35 | [PATTERN_ASSUMPTIONS] 36 | 37 | ## Considerations 38 | 39 | [PATTERN_CONSIDERATIONS] 40 | 41 | ## References 42 | 43 | [PATTERN_REFERENCES] -------------------------------------------------------------------------------- /babel.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | presets: [require.resolve('@docusaurus/core/lib/babel/preset')], 3 | }; 4 | -------------------------------------------------------------------------------- /docs/catalog/.keep: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Green-Software-Foundation/patterns/fd7495df4925530e2dc61a99188e6aae7149d7aa/docs/catalog/.keep -------------------------------------------------------------------------------- /docs/catalog/ai/.keep: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /docs/catalog/ai/compress-ml-models-for-inference.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: ai 6 | description: Large-scale AI/ML models require significant storage space and take more resources to run as compared to optimized models. 7 | tags: 8 | - ai 9 | - machine-learning 10 | - role:data-scientist 11 | - size:small 12 | --- 13 | 14 | # Optimize the size of AI/ML models 15 | 16 | ## Description 17 | 18 | Large-scale AI/ML models require significant storage space and take more resources to run as compared to optimized models. 19 | 20 | 21 | ## Solution 22 | Optimizing the size of the AI/ML model can save on storage space and take up less memory. Apply strategies like quantization and evaluate the optimization changes against the desired accuracy. 23 | 24 | 25 | ## SCI Impact 26 | `SCI = (E * I) + M per R` 27 | 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Optimizing the AI/ML model impacts SCI as follows: 31 | - `E`: Having an optimized AI model would reduce the energy consumption for your AI/ML inference, save storage space and network bandwidth and consequently, the E number should decrease. 32 | 33 | ## Assumptions 34 | None 35 | 36 | ## Considerations 37 | None 38 | 39 | ## References 40 | [Model optimization](https://www.tensorflow.org/lite/performance/model_optimization) 41 | -------------------------------------------------------------------------------- /docs/catalog/ai/efficent-format-for-model-training.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: ai 6 | description: Efficient storage of the model becomes extremely important to manage the data used for ML model development. 7 | tags: 8 | - ai 9 | - machine-learning 10 | - role:data-scientist 11 | - size:small 12 | --- 13 | 14 | # Use efficient file formats for AI/ML development 15 | 16 | ## Description 17 | Data processing and storage constitute a significant portion of AI/ML development and impact the carbon footprint of your application. Variety and volumes of data might need to be captured and pre-processed for building the ML model. Efficient storage of the model becomes extremely important to manage the data used for ML model development. 18 | 19 | 20 | ## Solution 21 | Use efficient file formats for building your ML models. For instance, column-oriented data file formats like Parquet provide efficient data storage and retrieval as compared to formats like CSV. 22 | 23 | 24 | ## SCI Impact 25 | `SCI = (E * I) + M per R` 26 | 27 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | 29 | Using efficient file formats for ML development impacts SCI as follows: 30 | - `E`: A more efficient file format for ML development means more efficient data storage and retrieval, resulting in lower overall energy consumption. 31 | - `M`: A more efficient file format for ML development reduces the amount of storage space and number of servers needed, resulting in a lower overall embodied carbon. 32 | 33 | ## Assumptions 34 | None 35 | 36 | ## Considerations 37 | Evaluate and consider the most energy efficient formats required for your application. 38 | 39 | ## References 40 | [Apache Parquet](https://parquet.apache.org/) 41 | -------------------------------------------------------------------------------- /docs/catalog/ai/energy-efficent-ai-edge.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: ai 6 | description: Data computation for ML workloads and ML inference is a significant contributor to the carbon footprint of the ML application. Also, if the ML model is running on the cloud, the data needs to be transferred and processed on the cloud to the required format that can be used by the ML model for inference. 7 | tags: 8 | - ai 9 | - machine-learning 10 | - role:data-scientist 11 | - size:small 12 | --- 13 | 14 | # Run AI models at the edge 15 | 16 | ## Description 17 | Data computation for ML workloads and ML inference is a significant contributor to the carbon footprint of the ML application. Also, if the ML model is running on the cloud, the data needs to be transferred and processed on the cloud to the required format that can be used by the ML model for inference. 18 | 19 | 20 | 21 | ## Solution 22 | Evaluate and run AI models at the edge, based on your application requirements. Also running data and compute processing tasks (i.e. data cleansing, feature generation) directly on the edge resources, ensure better utilization, and low latency and limit the transfer of data over the network to the cloud. 23 | 24 | 25 | ## SCI Impact 26 | `SCI = (E * I) + M per R` 27 | 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Running energy efficient AI at the edge would impact SCI as follows: 31 | - `E`: An energy efficient AI at the edge would reduce energy consumption by providing local computing and storage for data. Running the inference at the edge in this way would reduce the network transfer to the cloud, reducing the overall energy consumed. 32 | 33 | ## Assumptions 34 | None 35 | 36 | ## Considerations 37 | Consider the operational and embodied emissions of the edge devices as part of your overall solution and how it can reduce the carbon impact of your overall application. 38 | 39 | ## References 40 | - [Green AI for IIoT: Energy Efficient Intelligent Edge Computing for Industrial Internet of Things](https://ieeexplore.ieee.org/document/9520303) 41 | -------------------------------------------------------------------------------- /docs/catalog/ai/energy-efficent-framework.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: ai 6 | description: Training an AI model implies a significant carbon footprint. The underlying framework used for the development, training, and deployment of AI/ML needs to be evaluated and considered to ensure the process is as energy efficient as possible. 7 | tags: 8 | - ai 9 | - machine-learning 10 | - role:data-scientist 11 | - size:small 12 | --- 13 | 14 | # Select a more energy efficient AI/ML framework 15 | 16 | ## Description 17 | Training an AI model implies a significant carbon footprint. The underlying framework used for the development, training, and deployment of AI/ML needs to be evaluated and considered to ensure the process is as energy efficient as possible. 18 | 19 | Typically, AI/ML frameworks built on languages like C/C++ are more energy efficient than those built on other programming languages. 20 | 21 | 22 | ## Solution 23 | Evaluate and select an energy-efficient framework/module for AI/ML development, training and inference. 24 | 25 | ## SCI Impact 26 | `SCI = (E * I) + M per R` 27 | 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Selecting an energy-efficient AI/ML would impact SCI as follows: 31 | - `E`: Having an energy-efficient framework reduces energy consumption for AI/ML training and inference and consequently. 32 | 33 | ## Assumptions 34 | None 35 | 36 | ## Considerations 37 | None 38 | 39 | ## References 40 | [Green AI: Do Deep Learning Frameworks Have Different Costs?](https://stefanos1316.github.io/my_curriculum_vitae/GKSSZ22.pdf) 41 | -------------------------------------------------------------------------------- /docs/catalog/ai/energy-efficent-models.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: ai 6 | description: Evaluate and use alternative, more energy efficient, models that provide similar functionality. 7 | tags: 8 | - ai 9 | - machine-learning 10 | - role:data-scientist 11 | - size:small 12 | --- 13 | 14 | # Use energy efficient AI/ML models 15 | 16 | ## Description 17 | 18 | Large AI/ML and deep learning network models have a significant carbon footprint. Evaluate and use alternative, more energy efficient, models that provide similar functionality. 19 | 20 | 21 | ## Solution 22 | Evaluate energy efficient AI/ML models for development and inference. For example, DistilBERT provides similar functionality to the BERT model, running 60% faster while preserving 97% of BERT's performance. GPT-Neo 125M provides balanced results for energy consumption and accuracy compared to GPT-J 6B or GPT Neo 2.7B models. 23 | 24 | 25 | ## SCI Impact 26 | `SCI = (E * I) + M per R` 27 | 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Using energy efficient AI/ML models impacts SCI as follows: 31 | 32 | - `E`: Having an energy-efficient AI/ML model would provide efficient resource utilization and reduces the energy consumption of the compute resources and consequently, the E number should decrease. 33 | 34 | ## Assumptions 35 | None 36 | 37 | ## Considerations 38 | None 39 | 40 | ## References 41 | - [DistilBERT](https://blog.tensorflow.org/2020/05/how-hugging-face-achieved-2x-performance-boost-question-answering.html) 42 | - [SCI Foundation Models Results](https://github.com/Green-Software-Foundation/eval_sci_of_foundation_models/blob/main/Report/SCI_Foundation_Models_Preliminary_Results.pdf) 43 | -------------------------------------------------------------------------------- /docs/catalog/ai/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 5 3 | --- 4 | 5 | import TeamMember, { TeamMembers } from "@site/src/components/TeamMember"; 6 | import Image from "@theme/IdealImage"; 7 | 8 | # Artificial Intelligence (AI) 9 | 10 | ## Subject Matter Experts 11 | 12 | 13 | Navveen Balani 14 | 15 | -------------------------------------------------------------------------------- /docs/catalog/ai/leverage-sustainable-regions.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: ai 6 | description: Depending on the model parameters and training iterations, training an AI/ML model consumes a lot of power and requires many servers which contribute to embodied emissions. 7 | tags: 8 | - ai 9 | - machine-learning 10 | - role:data-scientist 11 | - size:small 12 | --- 13 | 14 | # Use sustainable regions for AI/ML training 15 | 16 | ## Description 17 | Training an AI model has a significant carbon footprint. Depending on the model parameters and training iterations, training an AI/ML model consumes a lot of power and requires many servers which contribute to embodied emissions. 18 | 19 | 20 | ## Solution 21 | Use a cloud region which has a lower carbon intensity value for running your AI/ML training workloads. 22 | 23 | 24 | ## SCI Impact 25 | `SCI = (E * I) + M per R` 26 | 27 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | 29 | Using a lower carbon intensity region for AI/ML training impacts SCI as follows: 30 | - `E`: Using a lower carbon intensity region for ML training would reduce the carbon emissions of ML applications, therefore decreasing the amount of energy consumed. 31 | 32 | ## Assumptions 33 | The migration of workloads to other regions assumes you have taken into consideration privacy, security, or data sovereignty based on your application requirements. 34 | 35 | ## Considerations 36 | Consider the trade-offs between carbon footprint, cost, and latency when selecting a region. 37 | 38 | ## References 39 | - [Faster, cheaper, greener? Pick the Google Cloud region that’s right for you](https://cloud.google.com/blog/topics/sustainability/google-cloud-region-picker-helps-you-make-the-green-choice) 40 | - [Amazon’s sustainability regions](https://sustainability.aboutamazon.com/around-the-globe?energyType=true) 41 | - [Azure sustainability](https://azure.microsoft.com/en-us/explore/global-infrastructure/sustainability/) 42 | - [Google Cloud sustainability regions](https://cloud.google.com/sustainability/region-carbon) 43 | -------------------------------------------------------------------------------- /docs/catalog/ai/pre-trained-transfer-learning.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: ai 6 | description: As part of your AI/ML process, you should evaluate using a pre-trained model and use transfer learning to avoid training a new model from scratch. 7 | tags: 8 | - ai 9 | - machine-learning 10 | - role:data-scientist 11 | - size:small 12 | --- 13 | 14 | # Leverage pre-trained models and transfer learning for AI/ML development 15 | 16 | ## Description 17 | Training an AI model has a significant carbon footprint. As part of your AI/ML process, you should evaluate using a pre-trained model and use transfer learning to avoid training a new model from scratch. 18 | 19 | 20 | ## Solution 21 | Evaluate and select pre-trained models and use transfer learning to avoid training a new model from scratch. 22 | 23 | ## SCI Impact 24 | `SCI = (E * I) + M per R` 25 | 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | Leveraging a pre-trained model would impact SCI as follows: 29 | - `E`: Having a pre-trained model reduces energy consumption for your AI/ML development as you don’t need to train the entire model from scratch. 30 | - `M`: Transfer learning does not require as many servers as you don’t need to train the entire model from scratch. By reducing the total number of servers required to run a process, the total embodied carbon is lower. 31 | 32 | ## Assumptions 33 | None 34 | 35 | ## Considerations 36 | None 37 | 38 | ## References 39 | - [Transfer learning and fine-tuning](https://www.tensorflow.org/tutorials/images/transfer_learning) 40 | -------------------------------------------------------------------------------- /docs/catalog/ai/right-hardware-type.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: ai 6 | description: Selecting the right hardware/VM instance types for training is one of the choices you should make as part of your energy-efficient AI/ML process. 7 | tags: 8 | - ai 9 | - machine-learning 10 | - role:data-scientist 11 | - size:small 12 | --- 13 | 14 | # Select the right hardware/VM instance types for AI/ML training 15 | 16 | ## Description 17 | Training an AI model has a significant carbon footprint. Selecting the right hardware/VM instance types for training is one of the choices you should make as part of your energy-efficient AI/ML process. For instance, custom application-specific integrated circuits (ASICs) and field-programmable gate arrays (FPGAs) are provided or supported by cloud vendors which provide better energy efficiency and inference for AI models than conventional chips. 18 | 19 | 20 | ## Solution 21 | Evaluate and leverage the right hardware/VM instance types for training and inference of AI/ML development. 22 | 23 | ## SCI Impact 24 | `SCI = (E * I) + M per R` 25 | 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | Selecting the right hardware/VM types impacts SCI as follows: 29 | - `E`: The right hardware/VM type provides better energy efficiency and inference for AI models, reducing the energy consumption of your AI/ML processes overall. 30 | - `M`: By reducing the total number of servers required to run a process, the total embodied carbon is lower. 31 | 32 | ## Assumptions 33 | None 34 | 35 | ## Considerations 36 | None 37 | 38 | ## References 39 | - [Energy and Policy Considerations for Deep Learning in NLP](https://arxiv.org/pdf/1906.02243.pdf) 40 | - [Deploy ML models to field-programmable gate arrays (FPGAs) with Azure Machine Learning](https://learn.microsoft.com/en-us/azure/machine-learning/v1/how-to-deploy-fpga-web-service) 41 | - [Quantifying the performance of the TPU, our first machine learning chip](https://cloud.google.com/blog/products/gcp/quantifying-the-performance-of-the-tpu-our-first-machine-learning-chip) 42 | -------------------------------------------------------------------------------- /docs/catalog/ai/serverless-model-development.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: ai 6 | description: Building an ML model takes significant computing resources that need to be optimized for efficient utilization. 7 | tags: 8 | - ai 9 | - machine-learning 10 | - serverless 11 | - role:data-scientist 12 | - size:small 13 | --- 14 | 15 | # Adopt serverless architecture for AI/ML workload processes 16 | 17 | ## Description 18 | 19 | Building an ML model requires a series of steps, such as building a data pipeline for data capture, data cleansing, feature generation, and running multiple training iterations and experiments to get the desired accuracy. All of these steps take significant computing resources that need to be optimized for efficient utilization. 20 | 21 | ## Solution 22 | Adopt a serverless architecture for maximum resource utilization for your entire AI/ML model development process like data pipeline, training and experiments. Going serverless ensures the resources are launched only when required. 23 | 24 | ## SCI Impact 25 | 26 | `SCI = (E * I) + M per R` 27 | 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | For the SCI equation, adopting serverless architecture for AI/ML workload process would impact the following: 31 | 32 | - `E`: A serverless architecture for the AI/ML development process provides efficient resource utilization and reduces the energy consumption of the compute resources. 33 | - `M`: A serverless architecture for the AI/ML development process would lead to effective hardware utilization as the resources would be provisioned only when required. 34 | 35 | ## Assumptions 36 | 37 | None 38 | 39 | ## Considerations 40 | 41 | Evaluate and consider what AI/ML workloads can be moved to serverless. Consider if your application can afford cold start during serverless resource initialization. 42 | 43 | ## References 44 | 45 | - [Serverless Pipeline on Google Cloud](https://cloud.google.com/blog/products/ai-machine-learning/serverless-machine-learning-pipelines-on-google-cloud) 46 | - [Machine learning inference at scale using AWS serverless](https://aws.amazon.com/blogs/machine-learning/machine-learning-inference-at-scale-using-aws-serverless/) 47 | -------------------------------------------------------------------------------- /docs/catalog/cloud/.keep: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /docs/catalog/cloud/cache-static-data.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: greenhsu123 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: From an energy-efficiency perspective, it's better to reduce network traffic by reading the data locally through a cache rather than accessing it remotely over the network. Shortening the distance a network packet travels means that less energy is required to transmit it. Similarly, from an embodied carbon perspective, we are more efficient with hardware when a network packet traverses through less computing equipment. 7 | tags: 8 | - networking 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Cache static data 14 | 15 | 16 | 17 | ## Description 18 | From an energy-efficiency perspective, it's better to reduce network traffic by reading the data locally through a cache rather than accessing it remotely over the network. 19 | 20 | Shortening the distance a network packet travels means that less energy is required to transmit it. Similarly, from an embodied carbon perspective, we are more efficient with hardware when a network packet traverses through less computing equipment. 21 | 22 | ## Solution 23 | Caching static data, such as images or audio, instead of transferring it over the network. 24 | 25 | ## SCI Impact 26 | 27 | `SCI = (E * I) + M per R` 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Reducing the distance travelled will impact SCI as follows: 31 | 32 | - `E`: By reducing the distance a packet travels, less total electricity is required. 33 | - `M`: By reducing the total amount of computing equipment traversed, the total embodied carbon is lower. 34 | 35 | ## Assumptions 36 | Suppose we transfer all the data of an application across the network as often as needed because some of the data may require a regular update. A better solution would be to consider a caching mechanism for static data that doesn't require frequent updates. This will reduce network traffic because we are doing local readings of the static data. 37 | 38 | 39 | ## Considerations 40 | - It may reduce cloud bills because shortening the path that a network packet travels will cost less. 41 | - If data is not static anymore, there is more overhead to re-architect the application to deal with the new data requirement. 42 | - It is assumed that a local in-memory cache of the server(s) is used to implement this pattern. If any external cache infrastructure is leveraged, then SCI score may not reduce considerably as we have to account for the E and M values of the external infrastructure in the equation. 43 | 44 | ## References 45 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency) 46 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency) 47 | 48 | -------------------------------------------------------------------------------- /docs/catalog/cloud/choose-region-closest-to-users.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: greenhsu123 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: From an energy-efficiency perspective, it's better to shorten the distance a network packet travels so that less energy is required to transmit it. Similarly, from an embodied-carbon perspective, when a network packet traverses through less computing equipment, we are more efficient with hardware. 7 | tags: 8 | - networking 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Choose the region that is closest to users 14 | 15 | ## Description 16 | From an energy-efficiency perspective, it's better to shorten the distance a network packet travels so that less energy is required to transmit it. Similarly, from an embodied-carbon perspective, when a network packet traverses through less computing equipment, we are more efficient with hardware. 17 | 18 | ## Solution 19 | Choose a region that is the closest to the majority of where the network packets are going. 20 | 21 | ## SCI Impact 22 | 23 | `SCI = (E * I) + M per R` 24 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 25 | 26 | Reducing the distance will impact SCI as follows: 27 | 28 | - `E`: By reducing the distance a packet travels, less total electricity is required. 29 | - `M`: By reducing the total number of computing equipment traversed, the total embodied carbon is lower. 30 | 31 | ## Assumptions 32 | Suppose we choose a region that is further away from our users to deploy our applications because the region is more popular and may be first in line to receive new features or updates. A better solution would be to consider choosing a region closer to our users, so the data we transmit doesn't need to travel as far. 33 | 34 | ## Considerations 35 | - It may reduce cloud bills because shortening the path that a network packet travel will cost less. 36 | - If the closer region to your users is missing some features, there may be an overhead to finding a workaround in the meantime. 37 | 38 | ## References 39 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency) 40 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency) 41 | -------------------------------------------------------------------------------- /docs/catalog/cloud/compress-stored-data.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: franziska-warncke 4 | published_date: 2024-03-14 5 | category: cloud 6 | tags: 7 | - cloud 8 | - size:medium 9 | --- 10 | 11 | # Compress stored data 12 | 13 | ## Description 14 | 15 | Storing too much uncompressed data can result in bandwidth waste and increase the storage capacity requirements. 16 | 17 | ## Solution 18 | 19 | Using the right compression tool for each use case reduces the storage requirements. This includes both the capacity and required bandwidth to write or retrieve data. 20 | 21 | ## SCI Impact 22 | 23 | `SCI = (E * I) + M per R` 24 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 25 | 26 | Using compression when storing data impacts SCI as follows: 27 | 28 | - `E`: Decreasing the amount of storage means less energy is consumed for the storage. However, compressing and de-compressing data may also cause a slight increase in energy consumed. 29 | - `M`: Decreasing the amount of storage means there is less embodied carbon emitted. 30 | 31 | ## Assumptions 32 | - You have the ability to choose whether you use compression or not. This is not the case if you store a lot of data, as compression is needed to keep storage costs reasonable. In the same way, if you have a limited amount of storage space, you will be forced to use a high compression (even when a high CPU is required). 33 | 34 | ## Considerations 35 | - The benefit of compression should always be considered in terms of the trade-off with the increased carbon cost of the resources (e.g. CPU, RAM) needed to perform the compression/decompression. 36 | 37 | ## References 38 | - [Microsoft Azure Well-Architected Framework](https://learn.microsoft.com/en-us/azure/well-architected/sustainability/sustainability-storage#enable-storage-compression) 39 | -------------------------------------------------------------------------------- /docs/catalog/cloud/compress-transmitted-data.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: greenhsu123 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: From an energy-efficiency perspective, it's better to minimise the size of the data transmitted so that less energy is required because the network traffic is reduced. 7 | tags: 8 | - networking 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Compress transmitted data 14 | 15 | ## Description 16 | From an energy-efficiency perspective, it's better to minimise the size of the data transmitted so that less energy is required because the network traffic is reduced. 17 | 18 | ## Solution 19 | Minimise the size of data transmitted by compressing files or payloads. 20 | 21 | ## SCI Impact 22 | 23 | `SCI = (E * I) + M per R` 24 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 25 | 26 | Reducing the distance will impact SCI as follows: 27 | 28 | - `E`: We reduce the total electricity required by reducing network traffic. However, we should be wary that there may be a slight increase in energy consumed due to compressing and de-compressing data. 29 | - `I`: We may also have a slight increase in location-based marginal carbon emissions due to compressing and de-compressing data at different locations. 30 | 31 | 32 | ## Assumptions 33 | Suppose we choose to transfer data (e.g. files or payloads) to the client side because that is the only format the client side can handle. A better solution would be to consider a compressing mechanism for large files or payloads before sending them across the network to the client side to reduce overall network traffic. 34 | 35 | 36 | ## Considerations 37 | - It may reduce cloud bills because minimising the size of the data transmitted will cost less. 38 | - If a compressed asset cannot be dealt with, there is more overhead to resend the asset in the correct format. 39 | 40 | ## References 41 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency) 42 | 43 | 44 | -------------------------------------------------------------------------------- /docs/catalog/cloud/containerize-your-workload-where-applicable.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2024-03-14 5 | category: cloud 6 | tags: 7 | - cloud 8 | - compute 9 | - kubernetes 10 | - role:cloud-engineer 11 | - size:medium 12 | --- 13 | 14 | # Containerize your workloads 15 | 16 | ## Description 17 | Containers allow resources to be used more flexibly, as workloads can be easily moved between machines. Containers allow for bin packing and require less compute resources than virtual machines, meaning a reduction in unnecessary resource allocation and an increase in utilization of the compute resources. 18 | 19 | ## Solution 20 | Containerize your applications with their minimal dependencies. This can be done using tools for generating Dockerfiles and Kubernetes manifests. 21 | 22 | ## SCI Impact 23 | `SCI = (E * I) + M per R` 24 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 25 | 26 | Containerizing workloads impacts SCI as follows: 27 | 28 | - `E`: By reducing CPU and RAM usage, we reduce the amount of energy required. 29 | - `M`: Reducing compute resources decreases the embodied carbon emissions. 30 | 31 | ## Assumptions 32 | - The application supports containerization. 33 | 34 | ## Considerations 35 | - Using containers may not be enough to reduce the carbon impact of a large monolith application. 36 | - Consider modernizing your applications into micro-service architectures that allow independent sizing and scaling of their logical components. 37 | - You may use a container orchestration system for automating software deployment, scaling, and management. 38 | 39 | ## References 40 | Microsoft Azure Well Architected Framework [sustainability patterns](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-application-platform) 41 | -------------------------------------------------------------------------------- /docs/catalog/cloud/delete-unused-storage-resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: greenhsu123 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: From an embodied carbon perspective, it's better to delete unused storage resources so we are efficient with hardware and so that the storage layer is optimised for the task. 7 | tags: 8 | - storage 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Delete unused storage resources 14 | 15 | ## Description 16 | From an embodied carbon perspective, it's better to delete unused storage resources so we are efficient with hardware and so that the storage layer is optimised for the task. 17 | 18 | ## Solution 19 | Delete any unused storage resource. 20 | 21 | ## SCI Impact 22 | 23 | `SCI = (E * I) + M per R` 24 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 25 | 26 | Deleting storage volumes will impact SCI as follows: 27 | - `M`: By reducing the total number of storage volumes required, the total embodied carbon is lower. 28 | 29 | ## Assumptions 30 | If we choose not to delete *all* storage resources because they might be needed in the future, then storing them permanently will take up a lot of unnecessary storage resources. A better solution would be to remove idle resources so that no hardware is wasted. 31 | 32 | ## Considerations 33 | - It may reduce cloud bills, as reducing idle storage resources will cost less. 34 | - We may lose access to data that might be needed in the future 35 | 36 | ## References 37 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency) 38 | -------------------------------------------------------------------------------- /docs/catalog/cloud/encrypt-what-is-necessary.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: amexboy,gopaltayal,samudurand,shainu-x 4 | published_date: 2023-12-14 5 | category: cloud 6 | description: Data protection through encryption is a crucial aspect of our security measures. However, the encryption process can be resource-intensive at multiple levels. 7 | tags: 8 | - size:medium 9 | - cloud 10 | - security 11 | - role:cloud-engineer 12 | --- 13 | # Encrypt what is necessary 14 | 15 | ## Description 16 | Data protection through encryption is a crucial aspect of our security measures. However, the encryption process can be resource-intensive at multiple levels. 17 | Firstly, the amount of CPU required for encryption varies depending on the chosen algorithm, and more complex algorithms tend to demand higher computational power. 18 | Additionally, encryption can lead to increased storage requirements as it inflates the size of the data being stored because it typically contains additional metadata and padding, which is especially noticeable for smaller files. 19 | Furthermore, encryption is a repetitive task that needs to be performed each time data is fetched or updated. This repetitive nature can contribute to increased energy consumption, especially in high-throughput systems. 20 | 21 | ## Solution 22 | - Carefully consider the sensitivity of the data that the application processes to understand if encryption is needed or not. 23 | - Revise policy of what is considered sensitive and understand which environments can impact this sensitivity. 24 | - Choose the appropriate algorithm and number of iterations in case of hashing, based on your application's performance and security needs. 25 | 26 | ## SCI Impact 27 | `SCI = (E * I) + M per R` [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | Only encrypting what is necessary impacts SCI as follows: 29 | - E: Reducing the amount of data that needs encryption will reduce the amount of energy needed to encrypt/decrypt and store the data. 30 | 31 | ## Assumptions 32 | - There is an assumption that a significant amount of data is not sensitive and can be stored unencrypted. 33 | 34 | ## Considerations 35 | - Segregate data into sensitive and non-sensitive data and only encrypt the sensitive data. 36 | - Separate storage for encrypted and non-encrypted data. 37 | - Hard to implement post application design. 38 | 39 | ## References 40 | - [Comparative Analysis of Energy Costs of Asymmetric vs Symmetric Encryption-Based Security Applications](https://doi.org/10.1109/ACCESS.2022.3192970) 41 | -------------------------------------------------------------------------------- /docs/catalog/cloud/evaluate-other-cpu-architectures.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2023-10-25 5 | category: cloud 6 | description: Applications are built with a software architecture that best fits the business need they are serving. Cloud providers make it easy to evaluate other CPU types 7 | tags: 8 | - cloud 9 | - size:small 10 | --- 11 | 12 | # Evaluate other CPU architectures 13 | 14 | ## Description 15 | 16 | Applications are built with a software architecture that best fits the business need they are serving. Cloud providers make it easy to evaluate other CPU types, such as x86-64, which can be included in the evaluation along with many cost effective alternatives that feature good performance per watt. 17 | 18 | 19 | ## Solution 20 | 21 | Other CPU architectures besides x86_64 should be evaluated for the application with energy efficiency and execution performance in mind. 22 | 23 | ## SCI Impact 24 | 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | Evaluating other CPU architectures can impact SCI as follows: 29 | 30 | - `E`: Other CPU architectures may provide better energy efficiency for the application use case and, as such, reduce the overall energy consumption 31 | 32 | ## Assumptions 33 | 34 | - Assumes that the framework can be executed on other CPU architectures as well and is optimized for it 35 | 36 | ## Considerations 37 | 38 | - Also consider specialized accelerators for workloads that cloud providers might offer 39 | 40 | ## References 41 | 42 | - [Azure Well-Architected Framework Sustainability Pillar](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-application-design) 43 | 44 | -------------------------------------------------------------------------------- /docs/catalog/cloud/evaluate-using-a-service-mesh.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2024-03-14 5 | category: cloud 6 | tags: 7 | - cloud 8 | - security 9 | - network 10 | - kubernetes 11 | - role:cloud-engineer 12 | - size:medium 13 | --- 14 | 15 | # Use a service mesh only if needed 16 | 17 | ## Description 18 | A service mesh deploys additional containers for communication, typically in a sidecar pattern, to provide more operational capabilities. This can result in an increase in CPU usage and network traffic but also allows you to decouple your application from these capabilities, moving them out from the application layer and down to the infrastructure layer. 19 | 20 | ## Solution 21 | Use a service mesh if your application lacks features that can be added one by one, such as distributed tracing or traffic encryption. However, use it for required applications only, and not the entire platform. 22 | 23 | ## SCI Impact 24 | `SCI = (E * I) + M per R` 25 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 26 | 27 | Not using a service mesh impacts SCI as follows: 28 | 29 | - `E`: By reducing CPU usage and network traffic, we reduce the amount of energy required. 30 | - `M`: reducing CPU usage and network data reduces the amount of resources required, which decreases the embodied carbon emissions. 31 | 32 | ## Assumptions 33 | The application does not have compliance requirements for using a service mesh. 34 | 35 | ## Considerations 36 | Consider alternative methods outside of an service mesh to fulfill application requirements, for example custom DNS servers or a configuration that is injected into the application 37 | -------------------------------------------------------------------------------- /docs/catalog/cloud/evaluate-whether-to-use-TLS-termination.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: Transport Layer Security (TLS) ensures that all data passed between the web server and web browsers remain private and encrypted. However, terminating and re-establishing TLS increases CPU usage and might be unnecessary in certain architectures. 7 | tags: 8 | - cloud 9 | - security 10 | - compute 11 | - kubernetes 12 | - role:software-engineer 13 | - size:medium 14 | --- 15 | 16 | # Terminate TLS at border gateway 17 | 18 | ## Description 19 | Transport Layer Security (TLS) ensures that all data passed between the web server and web browsers remain private and encrypted. However, terminating and re-establishing TLS increases CPU usage and might be unnecessary in certain architectures. 20 | 21 | 22 | ## Solution 23 | Terminate TLS at your border gateway and continue with non-TLS to your application load balancer and onwards to your workload. 24 | 25 | 26 | ## SCI Impact 27 | `SCI = (E * I) + M per R` 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Implementing non-TLS communication will impact SCI as follows: 31 | 32 | - `E`: By reducing CPU, the amount of energy needed to support the communication transport is reduced. 33 | - `M`: By reducing the compute resource requirements, the total embodied carbon emissions are reduced. 34 | 35 | ## Assumptions 36 | The application does not have compliance requirements for using end-to-end TLS. 37 | 38 | ## Considerations 39 | A balanced level of security can offer a more sustainable and energy efficient workload while a higher level of security may increase the requirements on compute resources. 40 | 41 | Consider applying the *Just Enough Security* (JES) model and terminate TLS at your border gateway for most standard applications that do not have strict compliance requirements. 42 | 43 | 44 | ## References 45 | [Microsoft Azure Well-Architected Framework Sustainability Patterns](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-security) 46 | 47 | -------------------------------------------------------------------------------- /docs/catalog/cloud/implement-stateless-design.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: Service state refers to the in-memory or on-disk data required by a service to function. State includes the data structures and member variables that the service reads and writes. Depending on how the service is architected, the state might also include files or other resources stored on the disk. Applications that consume large memory or on-disk data require larger VM sizes, especially for cloud computing where you would need larger VM SKUs to support high RAM capacity and multiple data disks. 7 | tags: 8 | - cloud 9 | - compute 10 | - kubernetes 11 | - role:software-engineer 12 | - size:medium 13 | --- 14 | 15 | # Implement stateless design 16 | 17 | ## Description 18 | Service state refers to the in-memory or on-disk data required by a service to function. State includes the data structures and member variables that the service reads and writes. Depending on how the service is architected, the state might also include files or other resources stored on the disk. 19 | 20 | Applications that consume large memory or on-disk data require larger VM sizes, especially for cloud computing where you would need larger VM SKUs to support high RAM capacity and multiple data disks. 21 | 22 | ## Solution 23 | Remove state from your design to reduce the in-memory or on-disk data required by the workload to function, hence requiring smaller compute sizes for hosting. 24 | 25 | State can be either externalized in a noSQL database or an in-memory cache service. 26 | 27 | ## SCI Impact 28 | `SCI = (E * I) + M per R` 29 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 30 | 31 | Implementing stateless design will impact SCI as follows: 32 | 33 | - `E`: Rightsizing the compute VM increases its utilization and therefore its energy efficiency. 34 | - `M`: Stateless applications require smaller compute VMs, which means lower total embodied carbon emissions. 35 | 36 | 37 | ## Assumptions 38 | The application design supports externalization of state. 39 | 40 | ## Considerations 41 | Follow the [The 12-factor app methodology](https://12factor.net/) to design stateless applications. 42 | -------------------------------------------------------------------------------- /docs/catalog/cloud/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 5 3 | --- 4 | 5 | import TeamMember, { TeamMembers } from "@site/src/components/TeamMember"; 6 | import Image from "@theme/IdealImage"; 7 | 8 | # Cloud 9 | 10 | ## Subject Matter Experts 11 | 12 | 13 | Aoife Fitton 14 | Bill Johnson 15 | Cameron Casher 16 | Navveen Balani 17 | Sarah Hsu 18 | Tammy McClellan 19 | Yassine El Ghali 20 | 21 | -------------------------------------------------------------------------------- /docs/catalog/cloud/match-slo.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: danielmeixner 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: If service downtimes are acceptable it's better to not strive for highest availability but to design the solution according to real business needs. Lower availability guarantees can help reduce energy consumption by using less infrastructure components. 7 | tags: 8 | - Cloud 9 | - Reliability/Availability 10 | - Monitoring 11 | --- 12 | 13 | # Match your service level objectives to business needs 14 | 15 | ## Description 16 | 17 | If service downtimes are acceptable it's better to not strive for highest availability but to design the solution according to real business needs. Lower availability guarantees can help reduce energy consumption by using less infrastructure components. 18 | 19 | ## Solution 20 | 21 | Adjust your solution design to the service level your actual end users require. 22 | 23 | ## SCI Impact 24 | 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | - `E`: We reduce the total electricity required by reducing the number of infrastructure components running. 29 | - `M`: Depending on the solution used it might also reduce the number of physical infrastructure components used. 30 | 31 | ## Assumptions 32 | 33 | Suppose you offer a service level objective (SLO) for availability for your service. Engineering teams target to fulfill this objective and will try to exceed this service level objective. In some cases, engineering teams tend to strive for very sophisticated solutions to not run into any danger of falling below the SLO. 34 | High availability comes often for the cost of additional resources used, in the case of hot stand-by designs even with full duplication of infrastructure where half of the infrastructure is not even used. 35 | Ideally you validate the business reason for a specific SLO target and use it to design a solution that matches business requirements with a reasonable design for reliability and availability. 36 | 37 | ## Considerations 38 | - This can impact the end user experience negatively because you are working towards a specifc SLO instead of highest availability. 39 | - This can reduce overall cloud cost because you will use less resources. 40 | 41 | ## References 42 | - [Uptime](https://en.wikipedia.org/wiki/Uptime) 43 | - [Availability](https://en.wikipedia.org/wiki/Availability_(system)) 44 | - [Service Level Objective (SLO)](https://en.wikipedia.org/wiki/Service-level_objective) 45 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency/) 46 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency/) 47 | -------------------------------------------------------------------------------- /docs/catalog/cloud/match-utilization-requirements-of-vm.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: dubrie 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: It's better to have one VM running at a higher utilization than two running at low utilization rates, not only in terms of energy proportionality but also in terms of embodied carbon. Two servers running at low utilization rates will consume more energy than one running at a high utilization rate. In addition, the unused capacity on the underutilized server could be more efficiently used for another task or process. 7 | tags: 8 | - compute 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Match utilization requirements of virtual machines (VMs) 14 | 15 | ## Description 16 | 17 | It's better to have one VM running at a higher utilization than two running at low utilization rates, not only in terms of energy proportionality but also in terms of embodied carbon. 18 | 19 | Two servers running at low utilization rates will consume more energy than one running at a high utilization rate. In addition, the unused capacity on the underutilized server could be more efficiently used for another task or process. 20 | 21 | ## Solution 22 | 23 | Rightsize your VMs by changing the number of resources allocated to a VM to match the utilization requirements of the VM. For example, adding a vCPU if the VM is running high CPU utilization or removing memory if the server is not using all of its allocated memory. 24 | 25 | ## SCI Impact 26 | 27 | `SCI = (E * I) + M per R` 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Rightsizing oversized VMs will impact SCI as follows: 31 | 32 | - `E`: Rightsizing oversized VMs will *increase* the total server utilization. The more a server is utilized, the more efficient it becomes at turning energy into useful operations. Therefore rightsizing VMs should reduce the energy consumption of your processes. 33 | - `M`: By reducing the total number of servers required to run a process, the total embodied carbon is lower. 34 | 35 | ## Assumptions 36 | 37 | If we choose an oversized VM because *occasionally* there is a burst of work (peak load) then undersizing them will reduce the margin available to handle the peak traffic. A better solution would be to consider an auto-scaling architecture that would automatically scale the number of VMs. 38 | 39 | ## Considerations 40 | - It may reduce your cloud bill as reducing the spec of your VMs will cost less. 41 | - If you do not have an auto-scaling architecture, there is less overhead for handling spikes in load. 42 | 43 | ## References 44 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency) 45 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency) 46 | -------------------------------------------------------------------------------- /docs/catalog/cloud/match-utilization-requirements-with-pre-configured-server.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: dubrie 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: It's better to have one VM running at a higher utilization than two running at low utilization rates, not only in terms of energy proportionality but also in terms of embodied carbon. Two servers running at low utilization rates will consume more energy than one running at a high utilization rate. In addition, the unused capacity on the underutilized server could be more efficiently used for another task or process. 7 | tags: 8 | - compute 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Match utilization requirements with pre-configured servers 14 | 15 | ## Description 16 | 17 | It's better to have one VM running at a higher utilization than two running at low utilization rates, not only in terms of energy proportionality but also in terms of embodied carbon. 18 | 19 | Two servers running at low utilization rates will consume more energy than one running at a high utilization rate. In addition, the unused capacity on the underutilized server could be more efficiently used for another task or process. 20 | 21 | ## Solution 22 | 23 | Rightsize your machine by selecting a pre-configured server that better matches the utilization requirements of the process. 24 | 25 | ## SCI Impact 26 | 27 | `SCI = (E * I) + M per R` 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Rightsizing oversized VMs will impact SCI as follows: 31 | 32 | - `E`: Rightsizing oversized VMs will *increase* the total server utilization. The more a server is utilized, the more efficient it becomes at turning energy into useful operations. Therefore rightsizing VMs should reduce the energy consumption of your processes. 33 | - `M`: By reducing the total number of servers required to run a process, the total embodied carbon is lower. 34 | 35 | ## Assumptions 36 | 37 | If we choose an oversized VM because *occasionally* there is a burst of work (peak load) then undersizing them will reduce the margin available to handle the peak traffic. A better solution would be to consider an auto-scaling architecture that would automatically scale the number of VMs. 38 | 39 | ## Considerations 40 | 41 | - It may reduce your cloud bill as reducing the spec of your VMs will cost less. 42 | - If you do not have an auto-scaling architecture, there is less overhead for handling spikes in load. 43 | 44 | ## References 45 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency) 46 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency) 47 | -------------------------------------------------------------------------------- /docs/catalog/cloud/minimizing-deployed-environments.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: camcash17 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: In a given application, there may be a need to utilize multiple environments in the application workflow. Typically, a development environment is used for regular updates, while staging or testing enviroments are used to make sure there are no issues before code reaches a production environment where users may have access. Each added environment has an increasing energy impact, which in turn creates more emissions. As such, it is important to understand the necessity of each enviroment and it's environmental impact. 7 | tags: 8 | - cloud 9 | - deployment 10 | --- 11 | 12 | # Minimize the total number of deployed environments 13 | 14 | ## Description 15 | 16 | In a given application, there may be a need to utilize multiple environments in the application workflow. Typically, a development environment is used for regular updates, while staging or testing environments are used to make sure there are no issues before code reaches a production environment where users may have access. 17 | 18 | Each added environment has an increasing energy impact, which in turn creates more emissions. As such, it is important to understand the necessity of each environment and it's environmental impact. 19 | 20 | ## Solution 21 | 22 | From an energy-efficiency perspective, it's better to minimize the amount of deployed environments for an application so that less resources are provisioned and less energy is required. 23 | 24 | ## SCI Impact 25 | 26 | `SCI = (E * I) + M per R` 27 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | 29 | Reducing the amount of deployed environments will impact SCI as follows: 30 | 31 | - `E`: We reduce the total electricity required by reducing provisioned resources. 32 | - `M`: By reducing the amount of nodes running on underlying machines, the total embodied carbon is lower. 33 | 34 | ## Assumptions 35 | 36 | Suppose we choose to remove a deployed performance environment for an application. Another existing environment like `QA` could be repurposed for both quality assurance and performance testing to save and optimize existing resources. 37 | 38 | ## Considerations 39 | 40 | It may reduce cloud bills because minimising the total amount of provisioned resources will cost less. It may also create a bottleneck in the application life cycle, losing an environment created for the sole purpose of performance or QA testing. 41 | 42 | ## References 43 | 44 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency) 45 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency/) 46 | -------------------------------------------------------------------------------- /docs/catalog/cloud/optimise-storage-resource-utilisation.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: greenhsu123 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: It's better to maximise storage utilisation so the storage layer is optimised for the task, not only in terms of energy proportionality but also in terms of embodied carbon. Two storage units running at low utilization rates will consume more energy than one running at a high utilization rate. In addition, the unused capacity on the underutilised storage unit could be more efficiently used for another task or process. 7 | tags: 8 | - storage 9 | - role:cloud-engineer 10 | - role:software-engineer 11 | - size:small 12 | --- 13 | 14 | # Optimise storage utilization 15 | 16 | ## Description 17 | It's better to maximise storage utilisation so the storage layer is optimised for the task, not only in terms of energy proportionality but also in terms of embodied carbon. 18 | 19 | Two storage units running at low utilization rates will consume more energy than one running at a high utilization rate. In addition, the unused capacity on the underutilised storage unit could be more efficiently used for another task or process. 20 | 21 | ## Solution 22 | Move storage resources away from underutilised storage resources. 23 | 24 | ## SCI Impact 25 | 26 | `SCI = (E * I) + M per R` 27 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | 29 | Moving storage resources will impact SCI as follows: 30 | 31 | - `E`: Moving storage resources away from underutilised storage will *increase* the total storage utilisation. The more storage that is utilised, the more efficient it becomes at turning energy into useful operations. Therefore rightsizing storage volumes should reduce the energy consumption of processes. 32 | - `M`: By reducing the total number of storage volumes required, the total embodied carbon is lower. 33 | 34 | ## Assumptions 35 | If we choose oversized storage resources *occasionally* because there may be a burst of workload, then undersizing them will reduce the margin available to handle the peak load. A better solution would be to consider an auto-scaling architecture that automatically scales the number of storage resources. 36 | 37 | 38 | ## Considerations 39 | - It may reduce cloud bills, as using less storage volumes will cost less. 40 | - If auto-scaling architecture is absent, there is more overhead for handling spikes in load. 41 | 42 | ## References 43 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency) 44 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency) 45 | -------------------------------------------------------------------------------- /docs/catalog/cloud/optimize-avg-cpu-utilization.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: dubrie 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: CPU usage and utilization varies throughout the day, sometimes wildly for different computational requirements. The larger the variance between the average and peak CPU utilization values, the more resources need to be provisioned in stand-by mode to absorb those spikes in traffic. 7 | tags: 8 | - compute 9 | - monitoring 10 | - role:cloud-engineer 11 | - role:software-engineer 12 | - role:reliability-engineer 13 | - size:medium 14 | --- 15 | 16 | # Optimize average CPU utilization 17 | 18 | ## Description 19 | 20 | CPU usage and utilization varies throughout the day, sometimes wildly for different computational requirements. The larger the variance between the average and peak CPU utilization values, the more resources need to be provisioned in stand-by mode to absorb those spikes in traffic. 21 | 22 | ## Solution 23 | 24 | Optimizing average CPU utilization means driving the average utilization value to an optimal level. To find that optimal level, you must understand how your system reacts to traffic and scale issues. If you system can scale quickly, a higher average CPU is ideal. If you system cannot scale quickly, lower average CPU values are generally better to provide additional buffer to support the longer scale times. 25 | 26 | From an energy efficiency perspective, optimizing and reducing the average CPU utilization values for your system reduces the overall energy required to support traffic and can make your system hardware requirements more predictable overall. 27 | 28 | From a hardware efficiency perspective, optimizing and reducing the average CPU utilization values for your system reduces the amount of resources needed to support traffic. If the traffic in your system spikes quickly, that typically requires resources to be on stand-by and under utilized. This pattern would reduce the amount of resources required to support traffic. 29 | 30 | ## SCI Impact 31 | 32 | `SCI = (E * I) + M per R` 33 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 34 | 35 | Optimizing average CPU utilization will impact SCI as follows: 36 | 37 | - `E`: Optimized average CPU utilization can reduce the amount of energy needed to support the systems traffic from the reduced CPU requirements. 38 | - `M`: Optimized average CPU utilization can reduce the amount of resources needed which will decrease the amount of embodied carbon required to support the system. 39 | 40 | ## Assumptions 41 | - There is an assumption that traffic is expected to fluctuate during normal production usage because of external natural changes in how users consume. Monitoring the average CPU utilization helps to normalize these fluctuations and give a better overall sense of the system CPU utilization. 42 | 43 | ## Considerations 44 | - There is no optimal CPU utilization value provided in this pattern, that should be determined from the system and its specific requirements. 45 | - Reducing average CPU utilization could be achieved by adding more hardware to better load balance. The software practioner should try to find efficiencies within the system that don't involve introducing more hardware and therefore additional embodied carbon. 46 | 47 | ## References 48 | -------------------------------------------------------------------------------- /docs/catalog/cloud/optimize-impact-on-customer-equipment.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2022-11-09 5 | category: cloud 6 | tags: 7 | - cloud 8 | - role:cloud-engineer 9 | - size:small 10 | --- 11 | 12 | # Optimize impact on customer devices and equipment 13 | 14 | ## Description 15 | 16 | Applications run on customer hardware or are displayed on it. The hardware used by the customer has a carbon footprint embodied through the production and electricity required while running. Optimising your software design and architecture to extend the life of the customer devices reduces the carbon intensity of the application. 17 | Ideally the customer can use the hardware until it's failure or until it becomes obsolete. 18 | 19 | 20 | ## Solution 21 | 22 | Understand the devices and equipment your customers use to consume your services. Implement software patterns and architectures to minimize the need for customers to replace devices and upgrade equipment. 23 | A few examples on how this could be achieved: 24 | * Implement new features using code that is backwards compatible with older hardware and operating system versions or disable them on older hardware only so the application can still be used 25 | * Support older browser versions and optimize the UX for an older tier of CPUs 26 | * Optimize network bandwidth for older devices or customers that have limited connectivity 27 | 28 | ## SCI Impact 29 | 30 | `SCI = (E * I) + M per R` 31 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 32 | 33 | Concerning the SCI equation, optimize impact on customer devices will impact two parts: 34 | 35 | - `I`: Optimizing for older hardware might reduce the carbon intensity if it also runs more efficiently in general 36 | - `M`: Using older devices allows hardware to be used longer and therefore reduces the embodied carbon impact 37 | 38 | ## Assumptions 39 | 40 | - This pattern assumes that the team does have sufficient time and resources to implement backwards compatibility and optimize the application 41 | 42 | ## Considerations 43 | 44 | - Consider the other cloud patterns to optimize the application itself inside the cloud environment 45 | 46 | ## References 47 | 48 | - [AWS Sustainability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_software_a6.html) 49 | -------------------------------------------------------------------------------- /docs/catalog/cloud/optimize-peak-cpu-utilization.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: dubrie 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: CPU usage and utilization varies throughout the day, sometimes wildly for different computational requirements. The larger the variance between the average and peak CPU utilization values, the more resources need to be provisioned in stand-by mode to absorb those spikes in traffic. 7 | tags: 8 | - compute 9 | - monitoring 10 | - role:cloud-engineer 11 | - role:software-engineer 12 | - role:reliability-engineer 13 | - size:medium 14 | --- 15 | 16 | # Optimize peak CPU utilization 17 | 18 | ## Description 19 | 20 | CPU usage and utilization varies throughout the day, sometimes wildly for different computational requirements. The larger the variance between the average and peak CPU utilization values, the more resources need to be provisioned in stand-by mode to absorb those spikes in traffic. 21 | 22 | ## Solution 23 | 24 | Optimizing peak CPU utilization can take many different forms but the key is to understand the processes utilizing your CPU and what actions drive increases and decreases. For example, loading a user's full profile could potentially require dozens of database queries, data processing threads and UI rendering that can drive CPU usage up. Adding caching layers, reducing the amount of data being transmitted and rendered, or queuing non-urgent requests up for later processing are good examples of ways to optimize CPU utilization and flatten out some of the spikes your system may see. 25 | 26 | From an energy efficiency perspective, optimizing and reducing the peak CPU utilization values for your system reduces the overall energy required to support traffic and can make your system hardware requirements more predictable overall. 27 | 28 | From a hardware efficiency perspective, optimizing and reducing the peak CPU utilization values for your system reduces the amount of resources needed to support traffic. If the traffic in your system spikes quickly, that typically requires resources to be on stand-by and under utilized. This pattern would reduce the amount of resources required to support traffic. 29 | 30 | ## SCI Impact 31 | 32 | `SCI = (E * I) + M per R` 33 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 34 | 35 | Optimizing peak CPU utilization impacts SCI as follows: 36 | 37 | - `E`: Reduced peak CPU utilization will reduce the amount of energy needed to support the systems traffic from the reduced CPU requirements. 38 | - `M`: Reduced peak CPU utilization will reduce the amount of resources needed which will decrease the amount of embodied carbon required to support the system. 39 | 40 | ## Assumptions 41 | - There is an assumption that traffic is expected to fluctuate during normal production usage because of external natural changes in how users consume. If there are other reasons for the CPU utilization spikes caused by the system itself, these should be addressed separately. 42 | 43 | ## Considerations 44 | - There is no optimal CPU utilization value provided in this pattern, that should be determined from the system and its specific requirements. 45 | - Reducing spikes in CPU utilization could be achieved by adding more hardware to better load balance. The software practioner should try to find efficiencies within the system that don't involve introducing more hardware and therefore additional embodied carbon. 46 | 47 | ## References 48 | -------------------------------------------------------------------------------- /docs/catalog/cloud/queue-non-urgent-requests.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: greenhsu123 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: All systems have periods of peak and low load. From a hardware-efficiency perspective, we are more efficient with hardware if we minimise the impact of request spikes with an implementation that allows an even utilization of components. From an energy-efficiency perspective, we are more efficient with energy if we ensure that idle resources are kept to a minimum. 7 | tags: 8 | - cloud 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Queue non-urgent processing requests 14 | 15 | ## Description 16 | 17 | All systems have periods of peak and low load. From a hardware-efficiency perspective, we are more efficient with hardware if we minimise the impact of request spikes with an implementation that allows an even utilization of components. From an energy-efficiency perspective, we are more efficient with energy if we ensure that idle resources are kept to a minimum. 18 | 19 | ## Solution 20 | 21 | Utilize a message queue so requests that do not require immediate processing are queued. 22 | 23 | ## SCI Impact 24 | 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | Queuing non-urgent requests will impact SCI as follows: 29 | 30 | - `E`: By reducing the total number of idle resources, less total electricity is required. 31 | - `M`: By reducing the total number of computing equipment required, the total embodied carbon is lower. 32 | 33 | ## Assumptions 34 | There is an assumption that the components in your system can communicate with a message queue asynchronously. If your component is the producer, it can add requests to the queue without waiting for the previous sent to be processed. If your component is the consumer, it will only process requests when they are available. We assume that no components in the system ever stalled while waiting for another. 35 | 36 | 37 | ## Considerations 38 | Decoupling components of your system can introduce unnecessary complexity and managing a message queue might mean additional overheads. As such, you should give careful consideration as to whether a message queue is appropriate. 39 | 40 | 41 | ## References 42 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency) 43 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency/) 44 | - [Message Queue](https://aws.amazon.com/message-queue/) 45 | - [Optimise software and architecture for asynchronous and scheduled jobs](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/optimize-software-and-architecture-for-asynchronous-and-scheduled-jobs.html) 46 | -------------------------------------------------------------------------------- /docs/catalog/cloud/reduce-network-traversal-between-VMs.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2024-07-30 5 | category: cloud 6 | tags: 7 | - cloud 8 | - network 9 | - compute 10 | - kubernetes 11 | - role:cloud-engineer 12 | - size:medium 13 | --- 14 | 15 | # Reduce network traversal between VMs 16 | 17 | ## Description 18 | Placing VMs in a single region or a single availability zone reduces the physical distance between the instances. 19 | 20 | ## Solution 21 | Choose the VM placement that is best for your workload. 22 | 23 | Most cloud providers provide various options, like 24 | - https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html 25 | - https://cloud.google.com/compute/docs/instances/define-instance-placement 26 | - https://learn.microsoft.com/en-us/azure-stack/hci/manage/vm-affinity 27 | 28 | ## SCI Impact 29 | `SCI = (E * I) + M per R` 30 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 31 | 32 | Regarding the SCI equation, reducing network traversal between VMs will impact: 33 | 34 | - `E`: By reducing network travel distance, we reduce the amount of energy consumed. 35 | 36 | ## Assumptions 37 | - VM placement options provided by cloud providers are adequate for this workload, 38 | 39 | ## Considerations 40 | - For business critical workloads, you need to ensure your workload is spread across multiple availability-zones, which may result in more network traversal and increase in your carbon footprint. 41 | -------------------------------------------------------------------------------- /docs/catalog/cloud/reduce-transmitted-data.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: greenhsu123 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: From an energy-efficiency perspective, it's better to minimize the size of the data transmitted so that less energy is required because the network traffic is reduced. 7 | tags: 8 | - networking 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Reduce transmitted data 14 | 15 | ## Description 16 | From an energy-efficiency perspective, it's better to minimize the size of the data transmitted so that less energy is required because the network traffic is reduced. 17 | 18 | ## Solution 19 | Minimize the size of data transmitted by only sending properties or values deemed necessary. 20 | 21 | ## SCI Impact 22 | 23 | `SCI = (E * I) + M per R` 24 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 25 | 26 | Reducing the size of data will impact SCI as follows: 27 | 28 | - `E`: We reduce the total electricity required by reducing network traffic. 29 | - `M`: By reducing the total size of data stored, the total embodied carbon is lower. 30 | 31 | ## Assumptions 32 | - Suppose we choose to transfer data (e.g. payloads) to the client side as it is because some properties or values may be needed later. A better solution would be to consider curating the data set, ensuring only necessary properties are sent across the network so the overall network traffic is reduced. In many use cases, certain properties or values can be correlated later. 33 | 34 | - Another consideration is that different data formats will affect the overall network traffic depending on their size. For example, Protobuf is much more compact than XML. 35 | 36 | ## Considerations 37 | - It may reduce cloud bills because minimising the size of the data transmitted will cost less. 38 | - If we minimize the data set by taking away properties or values, there may be overhead to corelate the missing properties or values. 39 | 40 | ## References 41 | - [Energy Efficiency Principle](https://learn.greensoftware.foundation/practitioner/energy-efficiency) 42 | -------------------------------------------------------------------------------- /docs/catalog/cloud/remove-unused-assets.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2022-11-22 5 | category: cloud 6 | tags: 7 | - cloud 8 | - role:cloud-engineer 9 | - size:small 10 | --- 11 | 12 | # Remove unused assets 13 | 14 | ## Description 15 | 16 | Monitor and analyze the application and the cloud bill to identify resources that are no longer used or can be reduced. 17 | 18 | ## Solution 19 | 20 | Decommission unused assets to free consumed resources. Consolidate resources, for example different database instances with a only a few tables could be moved into one instance. Review generated assets if they contain redundant content and handle them accordingly. 21 | Inspect storage buckets if unused assets can be removed. 22 | 23 | ## SCI Impact 24 | 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | With respect to the SCI equation, remove unused assets will impact one part: 29 | 30 | - `E`: Reduces the electricity by not using resources 31 | - `M`: Removing unused resources also reduces the embodied emissions, for example by reducing the storage or CPUs needed 32 | 33 | ## Assumptions 34 | 35 | - Assumes that resources can be decommissioned 36 | 37 | ## Considerations 38 | 39 | - Consider creating monitoring to more easily identify resources that are no longer needed 40 | 41 | ## References 42 | 43 | - [AWS Sustainability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a4.html) 44 | -------------------------------------------------------------------------------- /docs/catalog/cloud/scale-down-kubernetes-workloads.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: In order to reduce carbon emissions and costs, Dev&Test Kubernetes clusters can turn off nodes out of office hours. Thereby, optimization is implemented at the cluster level. For production clusters, where nodes need to stay up and running, optimization needs to be implemented at the application level. 7 | tags: 8 | - kubernetes 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Scale down kubernetes applications when not in use 14 | 15 | ## Description 16 | In order to reduce carbon emissions and costs, Dev&Test Kubernetes clusters can turn off nodes (VMs) out of office hours (e.g at night & during weekends). => thereby, optimization is implemented at the cluster level. 17 | 18 | For production clusters, where nodes need to stay up and running: optimization needs to be implemented at the application level (Deployment, StatefulSet). 19 | 20 | ## Solution 21 | Scale down Kubernetes applications (Deployments, StatefulSets) based on time (out of office hours). Turning off an application means scaling its pods to zero. 22 | 23 | The scaled down Kubernetes resources can be selected using Labels or Annotations. 24 | 25 | ## SCI Impact 26 | `SCI = (E * I) + M per R` 27 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | 29 | Regarding the SCI equation. scaling down the pods to zero will impact: 30 | 31 | - `E`: The goal is to "reduce demand", aka the number of pods running out of office hours, which reduces overall consumed power by the application. 32 | 33 | 34 | ## Assumptions 35 | The Business Application has predictible traffic (usage), which allows to scale up & down based on Time. 36 | 37 | ## Considerations 38 | - This pattern does not require application code changes. 39 | - This pattern requires an understanding of the application usage patterns including technical governance and inventory management. 40 | 41 | -------------------------------------------------------------------------------- /docs/catalog/cloud/scale-down-unused-applications.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali, markus-ntt-seidl 4 | published_date: 2023-12-14 5 | category: cloud 6 | description: Applications consume CPU even when they are not actively in use. For example, background timers, garbage collection, health checks, etc. Even when the application is shut down, the underlying hardware is consuming idle power. 7 | tags: 8 | - cloud 9 | - size:small 10 | --- 11 | 12 | # Scale down applications when not in use 13 | 14 | ## Description 15 | 16 | Applications consume CPU even when they are not actively in use. For example, background timers, garbage collection, health checks, etc. Even when the application is shut down, the underlying hardware is consuming idle power. 17 | This can also happen with development and test applications or hardware in out-of-office hours. 18 | 19 | 20 | ## Solution 21 | 22 | The best way to mitigate this is to scale down applications and hardware that are not in use on a schedule. Cloud vendors and software solutions (e.g. Kubernetes) provide various efficient ways of achieving this. 23 | 24 | ## SCI Impact 25 | 26 | `SCI = (E * I) + M per R` 27 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | 29 | Scaling down the pods to zero will impact SCI as follows: 30 | 31 | - `E`: Energy consumption is reduced in the hours when the application and hardware are shut down or switched off. 32 | 33 | ## Assumptions 34 | 35 | - Assumes that the application has predictable traffic or usage patterns, which should be known in advance. 36 | 37 | ## Considerations 38 | 39 | - Consider moving to a serverless architecture 40 | 41 | ## References 42 | 43 | - [Azure Well-Architected Framework Sustainability Pillar](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-application-design) 44 | -------------------------------------------------------------------------------- /docs/catalog/cloud/scale-infrastructure-with-user-load.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: franziska-nttdata-hesselfeld 4 | published_date: 2023-12-14 5 | category: cloud 6 | description: Demand for resources depends on user load at any given time. However, most applications run without taking this into consideration. As a result,resources are underused and inefficient. 7 | 8 | tags: 9 | - compute 10 | - cloud 11 | - role:cloud-engineer 12 | - size:medium 13 | --- 14 | 15 | # Scale infrastructure with user load 16 | 17 | ## Description 18 | 19 | Demand for resources depends on user load at any given time. However, most applications run without taking this into consideration. As a result,resources are underused and inefficient. 20 | 21 | ## Solution 22 | 23 | The solution involves reviewing workloads for predictable patterns and identifying periods of low or no activity where resources can be scaled back. Scaling back resources during periods of low utilisation eliminates excess capacity and improves efficiency. In addition, reducing the total number of resources used also reduces the amount of embodied carbon. Underutilized Virtual Machines, for example, can be easily identified by inspecting the CPU load over time. These resources can be consolidated, shut down on a schedule and/or removed. 24 | 25 | ## SCI Impact 26 | 27 | `SCI = (E * I) + M per R` 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Scaling infrastructure with user load impacts the SCI as follows: 31 | 32 | - `E`: Optimizing the application will lead to less electricity consumed over time 33 | - `M`: Can reduce the embodied emissions of the application since the optimization uses less hardware overall 34 | 35 | ## Considerations 36 | 37 | - Consider starting with the easiest optimizations first 38 | 39 | ## References 40 | 41 | - [AWS Sustainability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a2.html) 42 | -------------------------------------------------------------------------------- /docs/catalog/cloud/scale-kubernetes-workloads-based-on-events.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: By default, Kubernetes scales workloads based on CPU and RAM utilization. In practice, however, it's difficult to correlate your application's demand drivers with CPU and RAM utilization. Scaling your workload based on relevant demand metrics that drive scaling of your applications, such as HTTP requests, queue length, and cloud alerting events can help reduce resource utilization, and therefore also your carbon emissions. 7 | tags: 8 | - cloud 9 | - serverless 10 | - kubernetes 11 | - role:software-engineer 12 | - role:cloud-engineer 13 | - size:medium 14 | --- 15 | 16 | # Scale Kubernetes workloads based on relevant demand metrics 17 | 18 | ## Description 19 | By default, Kubernetes scales workloads based on CPU and RAM utilization. In practice, however, it's difficult to correlate your application's demand drivers with CPU and RAM utilization. 20 | 21 | Scaling your workload based on relevant demand metrics that drive scaling of your applications, such as HTTP requests, queue length, and cloud alerting events can help reduce resource utilization, and therefore also your carbon emissions. 22 | 23 | ## Solution 24 | 25 | Implement a custom scaler for your application, or use [KEDA](https://keda.sh) to help you build event-driven Kubernetes applications, to allow scaling down to zero when there is no demand. 26 | 27 | In addition to scaling Kubernetes applications based on relevent scaling metrics (or events), cluster auto-scaling and bursting capabilities are also used to scale infrastructure based on demand. 28 | 29 | ## SCI Impact 30 | `SCI = (E * I) + M per R` 31 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 32 | 33 | Scaling based on events will impact SCI as follows: 34 | 35 | - `M`: By scaling the workloads based on demand and reducing resource utilization, the total embodied carbon emissions by the Kubernetes cluster is lower. 36 | 37 | ## Assumptions 38 | 39 | The metrics that drive application demand and scaling needs are known. 40 | 41 | ## Considerations 42 | If your workloads have predictable usage patterns, you could implement scaling based on time as an alternative to optimize utilization and reduce carbon emissions. 43 | -------------------------------------------------------------------------------- /docs/catalog/cloud/scale-logical-components-independently.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2024-03-14 5 | category: cloud 6 | tags: 7 | - compute 8 | - cloud 9 | - kubernetes 10 | - role:software-engineer 11 | - role:cloud-engineer 12 | - size:medium 13 | --- 14 | 15 | # Scale logical components independently 16 | 17 | ## Description 18 | A microservice architecture may reduce the amount of compute resources required as it allows each independent component to be scaled according to its own demand. 19 | 20 | ## Solution 21 | 22 | Using cloud native projects can help you separate your application functionality into different microservices. This kind of microservice architecture allows for independent scaling of the application's logical components. 23 | 24 | ## SCI Impact 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | Scaling logical components independently will impact SCI as follows: 29 | 30 | - `E`: By optimizing the scaling of the most consuming application components, we reduce the amount of energy consumed by the application globally. 31 | - `M`: By scaling each component independently, we can right-size its resources to maximize their utilization, thereby reducing the application's total embodied carbon emissions. 32 | 33 | ## Assumptions 34 | 35 | - The application's logical components are deployed on platforms with auto-scaling capabilities, such as Kubernetes. 36 | 37 | ## Considerations 38 | - Microservice frameworks use additional components or resources in order to provide additional capabilities (messaging, secure traffic, tracing, etc.). This may result in an increase in carbon emissions. As such, only the necessary framework capabilities should be used. 39 | - Communication incurs overheads, which also have a carbon impact. As such, microservices should not be made too small. Alternatively, communication tools other than http/s should be considered, such as GPRC. 40 | -------------------------------------------------------------------------------- /docs/catalog/cloud/scan-for-vulnerabilities.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: Many attacks on cloud infrastructure seek to misuse deployed resources, which leads to an unnecessary spike in usage and cost. 7 | tags: 8 | - cloud 9 | - security 10 | - compute 11 | - kubernetes 12 | - role:cloud-engineer 13 | - size:medium 14 | --- 15 | 16 | # Scan for vulnerabilities 17 | 18 | ## Description 19 | Many attacks on cloud infrastructure seek to misuse deployed resources, which leads to an unnecessary spike in usage and cost. 20 | 21 | [Vulnerability scanning](https://en.wikipedia.org/wiki/Vulnerability_scanner) and [endpoint detection and response](https://en.wikipedia.org/wiki/Endpoint_detection_and_response) (EDR) tools help minimize the window of opportunity for attackers and mitigate any potential malicious usage of resources. 22 | 23 | ## Solution 24 | The EDR capabilities provide advanced attack detections and are able to take response actions to remediate those threats. The unnecessary resource usage created by these common attacks can quickly be discovered and remediated, often without the intervention of a security analyst. 25 | 26 | ## SCI Impact 27 | `SCI = (E * I) + M per R` 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Scanning for vulnerabilities will impact SCI as follows: 31 | 32 | - `M`: By preventing heavy misusage of resources, unnecesseary embodied carbon emissions are avoided. 33 | 34 | ## Assumptions 35 | A zero trust security policy is implemented, which covers security controls for infrastructure, applications, data, networking, [role-based access control](https://en.wikipedia.org/wiki/Role-based_access_control) (RBAC), and devices. 36 | 37 | ## Considerations 38 | Leverage cloud native EDR and scanning services, which scale based on demand, to maintain awareness of the carbon impact of the security tooling. 39 | 40 | ## References 41 | [Microsoft Azure well architected framework sustainability patterns](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-security) 42 | 43 | -------------------------------------------------------------------------------- /docs/catalog/cloud/set-retention-policy-on-storage-resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: greenhsu123 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: From an embodied carbon perspective, it's better to have an automated mechanism to delete unused storage resources so we are efficient with hardware and so that the storage layer is optimised for the task. 7 | tags: 8 | - storage 9 | - role:cloud-engineer 10 | - size:small 11 | --- 12 | 13 | # Set storage retention policies 14 | 15 | ## Description 16 | From an embodied carbon perspective, it's better to have an automated mechanism to delete unused storage resources so we are efficient with hardware and so that the storage layer is optimised for the task. 17 | 18 | ## Solution 19 | Set a retention policy on storage resources to automate the deletion of unused storage resources. 20 | 21 | ## SCI Impact 22 | 23 | `SCI = (E * I) + M per R` 24 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 25 | 26 | Setting a retention policy will impact SCI as follows: 27 | 28 | - `M`: By reducing the total number of storage volumes required, we reduce the total embodied carbon. 29 | 30 | ## Assumptions 31 | - If we choose not to delete *all* storage resources because they might be needed in the future, then storing them permanently will take up a lot of unnecessary storage resources. A better solution would be to set a retention policy that automatically deletes and keeps storage resources based on business needs. 32 | 33 | ## Considerations 34 | - It may reduce cloud bills, as reducing idle storage resources will cost less. 35 | - If a retention policy on the storage resources is undefined, there is more overhead for manually deleting idle resources. 36 | 37 | ## References 38 | - [Hardware Efficiency Principle](https://learn.greensoftware.foundation/practitioner/hardware-efficiency) 39 | -------------------------------------------------------------------------------- /docs/catalog/cloud/shed-lower-priority-traffic.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: dubrie 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: When resources are constrained during high-traffic events or when carbon intensity is high, more carbon emissions will be generated from your system. Adding more resources to support increased traffic requirements introduces more embodied carbon and more demand for electricity. Continuing to handle all requests during high carbon intensity will increase overall emissions for your system. Shedding traffic that is lower priority during these scenarios will save on resources and carbon emissions. This approach requires an understanding of your traffic, including which call requests are critical and which can best withstand retry attempts and failures. 7 | tags: 8 | - compute 9 | - monitoring 10 | - reliability-availability 11 | - role:cloud-engineer 12 | - role:software-engineer 13 | - role:reliability-engineer 14 | - size:large 15 | --- 16 | 17 | # Shed lower priority traffic 18 | 19 | ## Description 20 | 21 | When resources are constrained during high-traffic events or when carbon intensity is high, more carbon emissions will be generated from your system. Adding more resources to support increased traffic requirements introduces more embodied carbon and more demand for electricity. Continuing to handle all requests during high carbon intensity will increase overall emissions for your system. Shedding traffic that is lower priority during these scenarios will save on resources and carbon emissions. This approach requires an understanding of your traffic, including which call requests are critical and which can best withstand retry attempts and failures. 22 | 23 | 24 | ## Solution 25 | 26 | From an energy efficiency perspective, shedding lower priority traffic during high traffic and high carbon intensity periods will reduce the overall energy required to support traffic. 27 | 28 | From a hardware efficiency perspective, shedding lower priority traffic during high traffic and high carbon intensity periods will reduce the total number of hardware resources needed to support traffic. 29 | 30 | ## SCI Impact 31 | 32 | `SCI = (E * I) + M per R` 33 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 34 | 35 | Optimizing peak CPU utilization will impact SCI as follows: 36 | 37 | - `E`: Shedding traffic means your system is handling fewer requests, resulting in lower energy requirements. 38 | - `M`: Shedding traffic means fewer hardware resources are needed to handle it, resulting in lower embodied carbon requirements to support the system. 39 | 40 | ## Assumptions 41 | Your traffic must be prioritized and identified so that you can programmatically determine which can be shed and which is critical for system functionality. 42 | 43 | ## Considerations 44 | Consider having an exponential shedding policy that increases shedding exponentially as traffic climbs. This will help reduce the impact of traffic with high variance "spikes". 45 | 46 | 47 | ## References 48 | - [https://github.com/Green-Software-Foundation/green-software-patterns/issues/43](https://github.com/Green-Software-Foundation/green-software-patterns/issues/43) 49 | - [Using load shedding to avoid overload](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/) 50 | -------------------------------------------------------------------------------- /docs/catalog/cloud/time-shift-kubernetes-cron-jobs.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: The carbon emissions of a software system depends on the power consumed by that software, but also on the Carbon intensity of the electricity it is powered on. For this reason, running energy-efficient software on carbon intensive electricity grid, might be inefficient to reduce its global carbon emissions. Carbon aware time scheduling, is about scheduling workloads to execute, when electricity carbon intensity is low. 7 | tags: 8 | - kubernetes 9 | - role:cloud-engineer 10 | - size:medium 11 | --- 12 | 13 | # Time-shift Kubernetes cron jobs 14 | 15 | ## Description 16 | The carbon emissions of a software system depends on the power consumed by that software, but also on the Carbon intensity of the electricity it is powered on. For this reason, running energy-efficient software on carbon intensive electricity grid, might be inefficient to reduce its global carbon emissions. 17 | 18 | Carbon aware time scheduling, is about scheduling workloads to execute, when electricity carbon intensity is low. 19 | 20 | ## Solution 21 | Kubernetes recurrent Jobs (such as ML Training Jobs, Batchs, etc.) are implemented [as CronJobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/). They can be time shifted by using **carbon intensity Forecast data** (24h usually, depdening on the Electricity data provider), to calculate the best time in the future to execute the job. 22 | 23 | To capture the impact of time shifting, the following image shows variation of electricity carbon intensity during a day, from one the electricity data providers, [Electricity Maps](https://app.electricitymaps.com/map). 24 | 25 | ![zez](../../../src/images/time-shift.png) 26 | 27 | 28 | ## SCI Impact 29 | `SCI = (E * I) + M per R` 30 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 31 | 32 | Regarding the SCI equation, Time shifting will impact: 33 | 34 | - `I`: The goal is to reduce SCI by reducing carbon intensity. 35 | 36 | 37 | 38 | ## Assumptions 39 | In order to estimate the best time to schedule the CronJob: 40 | - The execution duration of the Job is assumed to be known. 41 | - The Job should ideally have a flexible deadline which allows a wider time window for scheduling. 42 | 43 | ## Considerations 44 | - This pattern does not require an application code change and can be handled at the platform operating level. 45 | - When cron jobs have scheduling constraints or dependencies, it can be difficult to change their timing. 46 | 47 | -------------------------------------------------------------------------------- /docs/catalog/cloud/use-async-instead-of-sync.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: srini1978, markus-ntt-seidl 4 | published_date: 2023-10-25 5 | category: cloud 6 | description: When making calls across process boundaries to either databases or file systems or REST APIs, relying on synchronous calls can cause the calling thread to become blocked, putting additional load on the CPU 7 | tags: 8 | - cloud 9 | - size:medium 10 | --- 11 | 12 | # Use Asynchronous network calls instead of synchronous 13 | 14 | ## Description 15 | 16 | When making calls across process boundaries to either databases or file systems or REST APIs, relying on synchronous calls can cause the calling thread to become blocked, putting additional load on the CPU. 17 | 18 | ## Solution 19 | 20 | Using asynchronous patterns frees the calling thread from being blocked on the response and, as such, additional work can be achieved without CPU cycles being consumed. 21 | 22 | ## SCI Impact 23 | 24 | `SCI = (E * I) + M per R` 25 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 26 | 27 | Using asyncronous calling patterns impacts SCI as follows: 28 | 29 | - `E`: Optimal utilization of the CPU leads to reduced energy consumption 30 | - `M`: Optimized average CPU utilization can reduce the amount of resources needed which will decrease the amount of embodied carbon required to support them 31 | 32 | ## Assumptions 33 | 34 | - The specific library for making asynchronous calls is available in the language being used for web development e.g. Task parallel library in C#. 35 | 36 | ## Considerations 37 | 38 | - Consider higher level patterns for asynchronous communication as well e.g. Queues, Topics and Streams 39 | 40 | ## References 41 | 42 | - Async/Await (https://en.wikipedia.org/wiki/Async/await) 43 | - [Azure Well-Architected Framework Sustainability Pillar](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-application-design) 44 | -------------------------------------------------------------------------------- /docs/catalog/cloud/use-circuit-breaker.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2023-09-28 5 | category: cloud 6 | description: Modern applications need to communicate with other applications on a regular basis. Since these other applications have their own deployment schedule, downtimes and availability, the network connection to these application might have problems. If the other application is not reachable, all network requests against this other application will fail and future network requests are futile. 7 | tags: 8 | - compute 9 | - size:medium 10 | --- 11 | 12 | # Use circuit breaker patterns 13 | 14 | ## Description 15 | 16 | Modern applications need to communicate with other applications on a regular basis. Since these other applications have their own deployment schedule, downtimes and availability, the network connection to these application might have problems. 17 | If the other application is not reachable, all network requests against this other application will fail and future network requests are futile. 18 | 19 | ## Solution 20 | 21 | Circuit breaker patterns reject the request to the other application if health checks against the other application have failed to complete successfully. In this case a lot of network requests, and energy, can be saved. 22 | The circuit breaker will reset itself automatically, if health checks against the other application are successful again. 23 | 24 | ## SCI Impact 25 | 26 | `SCI = (E * I) + M per R` 27 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | 29 | The circuit breaker pattern reduces the following aspect: 30 | 31 | - `E`: Reduces the energy consumed, as requests are not executed if the other system is known to be not available 32 | 33 | ## Assumptions 34 | 35 | - Assumes that the communication target can be checked for availability 36 | 37 | ## Considerations 38 | 39 | - Consider implementing an back-off strategy to automatically re-enable the requests if the resource becomes available again 40 | - Consider handling different errors of the called application differently. For example exceptions that indicate that the called application will not be available for a longer time should be handled differently than exceptions that indicate only a short time in-availability. 41 | 42 | ## References 43 | 44 | - [Azure Well-Architected Framework Sustainability Pillar](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-application-design) 45 | - [Azure Circuit Breaker Pattern Description](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker) 46 | -------------------------------------------------------------------------------- /docs/catalog/cloud/use-cloud-native-network-security-tools-and-controls.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2022-11-10 5 | category: cloud 6 | description: Network and web application firewalls provide protection against most common attacks and load shedding bad bots. These tools help to remove unnecessary data transmission and reduce the burden on the cloud infrastructure, while also using lower bandwidth and less infrastructure. 7 | tags: 8 | - cloud 9 | - security 10 | - networking 11 | - compute 12 | - kubernetes 13 | - role:software-engineer 14 | - size:medium 15 | --- 16 | 17 | # Use cloud native network security tools and controls 18 | 19 | ## Description 20 | Network & web application firewalls provide protection against [most common attacks](https://owasp.org/Top10/) and load shedding bad bots. These tools help to remove unnecessary data transmission and reduce the burden on the cloud infrastructure, while also using lower bandwidth and less infrastructure. 21 | 22 | ## Solution 23 | Filter ingress and egress traffic at the source to block any unauthorized data transmissions. 24 | 25 | Use cloud native security tools, as they scale based on demand, and only the necessary infrastructure resources. 26 | 27 | 28 | ## SCI Impact 29 | `SCI = (E * I) + M per R` 30 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 31 | 32 | Using cloud native security controls and tools will impact SCI as follows: 33 | 34 | - `E`: By filtering transmitted data, less energy is consumed by the networking resources. 35 | - `M`: By scaling the tools based on demand and maximizing resource utilization, the total embodied carbon emissions are lower. 36 | 37 | ## Assumptions 38 | Deployment and configuration of the security tools is automated. 39 | 40 | ## Considerations 41 | Consider implementing a zero trust model, where security controls are layered. 42 | 43 | ## References 44 | [Microsoft Azure well architected framework sustainability patterns](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-security) 45 | -------------------------------------------------------------------------------- /docs/catalog/cloud/use-compiled-languages.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2024-07-30 5 | category: cloud 6 | tags: 7 | - cloud 8 | - role:cloud-engineer 9 | - size:small 10 | - programming-language 11 | 12 | --- 13 | 14 | # Use compiled languages 15 | 16 | ## Description 17 | 18 | Interpreted languages need to be parsed, compiled and executed when the application starts or a workload arrives. This tends to be more energy heavy then when a compiled language is used. The compilation is then only done once, saving on resources. 19 | 20 | ## Solution 21 | 22 | Use compiled languages (like Go, Rust, Java or others) whenever possible or compile interpreted languages. 23 | 24 | 25 | ## SCI Impact 26 | 27 | `SCI = (E * I) + M per R` 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Concerning the SCI equation, use compiled languages will impact as follows: 31 | 32 | - `E`: Running compiled binaries is more energy efficient and uses less energy which outweighs the energy consumed in compiling it to binary upfront 33 | - `M`: The embodied carbon emissions will be reduced, as compiled binaries tend to be smaller then the sources they are compiled from 34 | 35 | ## Assumptions 36 | 37 | - There is the assumption that the execution environment allows usage of compiled languages, this is not always the case (for example web browsers) 38 | - Use benchmarks to determine if the application use case benefits from using a compiled language. 39 | 40 | ## Considerations 41 | 42 | - Some interpreted languages provide ways to be compiled into binary (for example GraalVM for Java, Python and more) 43 | - Consider factoring in compile time when doing benchmarks 44 | 45 | ## References 46 | 47 | - [One Carbon intensity benchmark](https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf) 48 | 49 | -------------------------------------------------------------------------------- /docs/catalog/cloud/use-ddos-protection.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2024-03-14 5 | category: cloud 6 | description: Distributed denial of service (DDoS) attacks are used to increase the server load so that it is unable to respond to any legitimate requests. This is usually done to harm the owner of the service or hardware. 7 | tags: 8 | - cloud 9 | - size:small 10 | --- 11 | 12 | # Use DDoS protection 13 | 14 | ## Description 15 | 16 | Distributed denial of service (DDoS) attacks are used to increase the server load so that it is unable to respond to any legitimate requests. This is usually done to harm the owner of the service or hardware. 17 | Due to the nature of attack, a lot of environmental resources are used up by nonsensical requests. 18 | 19 | ## Solution 20 | 21 | All cloud providers have some form of DDoS protection (AWS Shield, Azure DDoS Protection, GCP DDoS Protection, CloudFlare, etc.) that can prevent those attacks. 22 | 23 | ## SCI Impact 24 | 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | DDoS protection impacts the SCI as follows: 29 | 30 | - `R`: The functional unit is impacted because the amount of requests will be reduced. 31 | 32 | ## Assumptions 33 | 34 | - There is budget for the DDoS protection service. 35 | 36 | ## Considerations 37 | 38 | - Consider purchasing advanced protection to be fully protected against other attack patterns similar to DDoS attacks. 39 | 40 | ## References 41 | 42 | - [Azure Well-Architected Framework Sustainability Pillar](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-application-design) 43 | 44 | -------------------------------------------------------------------------------- /docs/catalog/cloud/use-energy-efficient-hardware.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: yelghali 4 | published_date: 2024-03-14 5 | category: cloud 6 | tags: 7 | - cloud 8 | - compute 9 | - kubernetes 10 | - role:software-engineer 11 | - role:cloud-engineer 12 | - size:medium 13 | --- 14 | 15 | # Use cloud native processor VMs 16 | 17 | ## Description 18 | 19 | Cloud virtual machines come with different capabilities based on different hardware processors. As such, using virtual machines based on the efficiency of their processors would impact hardware efficiency and reduce carbon emissions. 20 | 21 | 22 | ## Solution 23 | 24 | Using new cloud virtual machines that have been engineered with [cloud native processors](https://www.forbes.com/sites/davealtavilla/2022/10/13/amperes-efficient-128-core-cloud-native-processor-builds-momentum-in-sustainable-data-centers/) allows you to efficiently run scale-out, cloud-native workloads and consume energy efficiently. 25 | 26 | 27 | ## SCI Impact 28 | `SCI = (E * I) + M per R` 29 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 30 | 31 | Using energy efficient hardware impacts SCI as follows: 32 | 33 | - `E`: By using energy efficient hardware, we reduce the total embodied carbon emissions. 34 | - `M`: By using energy efficient hardware, we also reduce the embodied emissions. 35 | 36 | ## Assumptions 37 | 38 | The cloud provider offers VM SKUs based on efficient hardware. 39 | 40 | 41 | ## Considerations 42 | 43 | Energy efficient VMs tend to be cost effective as well. However, you should consider SKU availability in the region you choose for deployment: 44 | 45 | - Azure: https://azure.microsoft.com/en-us/blog/azure-virtual-machines-with-ampere-altra-arm-based-processors-generally-available/ 46 | - Google: https://cloud.google.com/blog/products/compute/tau-t2a-is-first-compute-engine-vm-on-an-arm-chip 47 | 48 | -------------------------------------------------------------------------------- /docs/catalog/cloud/use-serverless.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2023-01-17 5 | category: cloud 6 | tags: 7 | - cloud 8 | - role:cloud-engineer 9 | - size:small 10 | - serverless 11 | --- 12 | 13 | # Use serverless cloud services 14 | 15 | ## Description 16 | 17 | Serverless cloud services are services that the cloud provider manages for the application. These scale dynamically with the workload needed to fulfill the service task and apply best practices to keep resource usage minimal. 18 | 19 | ## Solution 20 | 21 | Evaluate serverless based on your application requirements. 22 | 23 | ## SCI Impact 24 | 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | Regarding the SCI equation. using serverless cloud services will impact: 29 | 30 | - `I`: Resources are only running when in use and shared over many applications, the carbon intensity will decrease. There is a slight increase in provisioning serverless structures (for example AWS Lambda cold starts), overall the carbon intensity still decreases. 31 | - `M`: Serverless architectures share resources and only use resources when needed, this reduces the embodied carbon. 32 | 33 | ## Assumptions 34 | 35 | - The cloud provider provides serverless services for the technologies the application uses 36 | - There is an assumption that the application can benefit from serverless architectures 37 | 38 | ## Considerations 39 | 40 | - Evaluate and consider what workloads can be moved to serverless. Using serverless patterns can involve a complete redesign of the application architecture. 41 | - Consider if your application can afford a cold start during serverless resource initialization. 42 | 43 | ## References 44 | 45 | - [Azure Dev Blog](https://devblogs.microsoft.com/sustainable-software/adopting-azure-serverless-architectures-to-help-reduce-co2-emissions-part-1/) 46 | -------------------------------------------------------------------------------- /docs/catalog/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 3 3 | --- 4 | 5 | # Catalog -------------------------------------------------------------------------------- /docs/catalog/web/.keep: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /docs/catalog/web/avoid-chaining-critical-requests.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: dubrie 4 | published_date: 2022-11-10 5 | category: web 6 | description: Most web experiences require a lot of work from the user's browser. The greater the length of the chains and the larger the download sizes, the more significant the impact on page load performance and the energy required to render a page. 7 | tags: 8 | - web 9 | - role:web-developer 10 | - size:medium 11 | --- 12 | 13 | # Avoid chaining critical requests 14 | 15 | ## Description 16 | 17 | Most web experiences require a lot of work from the user's browser. The intermediate steps between receiving the HTML, CSS, and JavaScript bytes and the request processing to turn them into rendered pixels is known as the critical rendering path. [Critical request chains](https://web.dev/critical-rendering-path/) are a series of dependent network requests that block page rendering until they complete. The greater the length of the chains and the larger the download sizes, the more significant the impact on page load performance and the energy required to render a page. 18 | 19 | ## Solution 20 | 21 | From an energy efficiency perspective, avoiding critical request chains reduces the overall energy required to render a page by using loading time more efficiently without a serialized set of requests and allowing the user to begin interacting with the content earlier, potentially negating the need for any further rendering and energy consumption. 22 | 23 | ## SCI Impact 24 | 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | Avoiding chaining critical requests will impact SCI as follows: 29 | 30 | - `E`: Improved page rendering times will reduce the amount of energy needed to render the page 31 | 32 | ## Assumptions 33 | - There is an assumption that users are on modern web browsers that can support these types of requests. 34 | 35 | 36 | ## Considerations 37 | - Some critical request chains may be necessary, the focus here is on avoidance and only using them when absolutely critical 38 | 39 | ## References 40 | - [Critical Rendering Path](https://web.dev/critical-rendering-path/) 41 | - [Critical Request Chains](https://web.dev/critical-request-chains/) 42 | - [Proposed Pattern in Issue 54](https://github.com/Green-Software-Foundation/green-software-patterns/issues/54) 43 | -------------------------------------------------------------------------------- /docs/catalog/web/avoid-excessive-dom-size.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2022-11-10 5 | category: web 6 | description: The greater the amount of nodes that are defined in HTML, the greater the time spent processing and rendering each element. 7 | tags: 8 | - size:medium 9 | - role:web-developer 10 | - web 11 | --- 12 | 13 | # Avoid an excessive DOM size 14 | 15 | ## Description 16 | 17 | Web browsers convert the HTML from the server into a Document Object Model (DOM) to further process the web page. Each HTML element, for example, one div, is then one node in the DOM. The amount of nodes defines the memory requirements in the browser and the needed time to display and update the page. 18 | The greater the amount of nodes that are defined in HTML, the greater the time spent processing and rendering each element. Additionally, each interaction with the DOM from Javascript needs more processing time and more memory to traverse the DOM elements. 19 | 20 | 21 | ## Solution 22 | 23 | Keep the necessary HTML as small as possible and strip unneeded elements from it. Use advanced strategies of the frontend framework used to reduce the DOM size additionally. When rendering large lists, for example, use these techniques: 24 | * Angular: Use [virtual scrolling](https://material.angular.io/cdk/scrolling/overview#virtual-scrolling) with the component dev kit 25 | * React: Use "windowing" libraries like [react-window](https://react-window.vercel.app/#/examples/list/fixed-size) 26 | 27 | 28 | ## SCI Impact 29 | 30 | `SCI = (E * I) + M per R` 31 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 32 | 33 | Optimizing the DOM size will impact SCI as follows: 34 | 35 | - `E`: Reduces the processing and memory requirements to display the page and therefore the energy requirements. 36 | 37 | ## Assumptions 38 | 39 | - There is an assumption that the framework and/or the environment allows for changing the HTML structure or rendering path. 40 | 41 | ## Considerations 42 | 43 | 44 | ## References 45 | 46 | - [Reference](https://web.dev/dom-size/) 47 | -------------------------------------------------------------------------------- /docs/catalog/web/avoid-tracking-unnecessary-data.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: dubrie, holanita 4 | published_date: 2022-11-10 5 | category: web 6 | description: User tracking, user data collection and targeting in things like advertisements are responsible for significant energy use in many digital products, and services. 7 | tags: 8 | - storage 9 | - role:web-developer 10 | - role:software-engineer 11 | - size:small 12 | --- 13 | 14 | # Avoid tracking unnecessary data 15 | 16 | ## Description 17 | 18 | User tracking, user data collection and targeting in things like advertisements are responsible for significant energy use in many digital products, and services. This is primarily due to the large size of tracking and advertising scripts, the energy required to process and track user behavior, and databases collecting vast amounts of user data. Furthermore, this can present a significant violation of user privacy and tangibly degrade user experience. 19 | 20 | 21 | ## Solution 22 | 23 | From an energy efficiency perspective, avoiding tracking unnecessary user data will reduce the overall workload for page loads and decrease overall page weight of the site. 24 | 25 | ## SCI Impact 26 | 27 | `SCI = (E * I) + M per R` 28 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 29 | 30 | Avoiding tracking unnecessary data will impact SCI as follows: 31 | 32 | `E`: Avoiding the tracking of unnecessary data will reduce time spent on transfering and processing web pages. 33 | `I`: Avoiding the tracking of unnecessary data will reduce the amount of energy consumed by the users browser, reducing the intensity of carbon emissions. 34 | 35 | ## Assumptions 36 | - The term `unnecessary` here is assumed to mean data that is not required for the functionality of the site. Things like advertisements, user location, or click patterns are considered not-critical functionality for a site. 37 | 38 | ## Considerations 39 | - Consider what data is absolutely critical to your site functionality and what data can be deferred, sampled, or aggregated from other more energy efficient sources. 40 | 41 | 42 | ## References 43 | - [https://github.com/Green-Software-Foundation/green-software-patterns/issues/52](https://github.com/Green-Software-Foundation/green-software-patterns/issues/52) 44 | - [Does the website avoid tracking user behavior and collecting data unnecessarily?](https://sustainablewebdesign.org/does-the-website-avoid-tracking-user-behaviour-and-collecting-data-unnecessarily/) 45 | -------------------------------------------------------------------------------- /docs/catalog/web/defer-offscreen-images.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2022-11-10 5 | category: web 6 | description: Web pages offer a lot of images that aren't displayed on the first loaded screen and can thus be loaded dynamically. 7 | tags: 8 | - web 9 | - role:web-developer 10 | - size:small 11 | 12 | --- 13 | 14 | # Defer offscreen images 15 | 16 | 17 | ## Description 18 | 19 | Web pages offer a lot of images that aren't displayed on the first loaded screen. They can also hide these images behind other interactions, like tabs and accordions. This content is dynamically displayed and therefore doesn't need to be loaded when it isn't displayed. 20 | 21 | The fact that images are loaded on-demand, only when they are about to be displayed, is often called "lazy-loading". 22 | 23 | 24 | ## Solution 25 | 26 | Use on demand loading for images which are unlikely to be displayed on first page load. This can be done via the newer browser attribute `loading="lazy"` on the image tag and can also be [polyfilled](https://github.com/mfranzke/loading-attribute-polyfill) for older browsers. 27 | 28 | ## SCI Impact 29 | 30 | `SCI = (E * I) + M per R` 31 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 32 | 33 | Using lazy loading of images will impact SCI as follows: 34 | 35 | - `E`: Images are only loaded when needed, saving bandwidth and processing power on the client and server, therefore reducing the energy required. 36 | 37 | ## Assumptions 38 | 39 | - This assumes that the HTML for the image tags can be modified in the application 40 | 41 | ## Considerations 42 | 43 | None 44 | 45 | ## References 46 | 47 | - [Detailed description](https://web.dev/offscreen-images/) 48 | -------------------------------------------------------------------------------- /docs/catalog/web/deprecate-gifs.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2022-11-10 5 | category: web 6 | description: One direct replacement of the GIF is the MP4 video format which provides much smaller file sizes and higher quality at the same time. 7 | tags: 8 | - size:small 9 | - role:web-developer 10 | - web 11 | --- 12 | 13 | # Deprecate GIFs for animated content 14 | 15 | ## Description 16 | 17 | GIFs were invented in the early 80s and this popular format was used to deliver animated content in web browsers. 18 | 19 | Newer technologies have made GIFs technically obsolete, but they are still widely known as animated picture format. One direct replacement of the GIF is the MP4 video format. MP4 provides much smaller file sizes and higher quality at the same time. 20 | 21 | ## Solution 22 | 23 | Convert the source material of the GIF to MP4 to receive a higher quality at lower file size. If that is not possible, the GIF can also be directly converted to reduce the file size while maintaining the quality of the GIF. 24 | 25 | Even higher compression ratios can be achieved by inspecting the content of the GIF. Depending on the content other techniques may provide even better solutions, such as CSS animations, SVG animations and image formats that also support animations. 26 | 27 | ## SCI Impact 28 | 29 | `SCI = (E * I) + M per R` 30 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 31 | 32 | Converting GIFs will impact the SCI as follows: 33 | 34 | - `E`: Reduced energy consumption by reducing download size and increased page performance. 35 | 36 | ## Assumptions 37 | - The web browser must support the new format. 38 | 39 | 40 | ## Considerations 41 | None 42 | 43 | ## References 44 | 45 | - [Alternatives to GIF](https://en.wikipedia.org/wiki/GIF#Alternatives) 46 | - [Real life improvement reports for replacing GIF with MP4](https://en.wikipedia.org/wiki/GIF#Uses) 47 | -------------------------------------------------------------------------------- /docs/catalog/web/enable-text-compression.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2023-10-25 5 | category: web 6 | description: Web browsers often communicate with web servers in a human readable format. These can be HTML, JavaScript and/or CSS files and REST requests which can return a response in JSON. This human readable communication is redundant and, as such, can be compressed to save bandwidth. 7 | tags: 8 | - web 9 | - size:small 10 | - role:web-developer 11 | --- 12 | 13 | # Enable text compression 14 | 15 | ## Description 16 | 17 | Web browsers often communicate with web servers in a human readable format. These can be HTML, JavaScript and/or CSS files and REST requests which can return a response in JSON. This human readable communication is redundant and, as such, can be compressed to save bandwidth. 18 | 19 | Web browsers and servers can communicate the compression format dynamically via the "Accept-Encoding"/"Content-Encoding" HTTP Headers. This allows the communication to dynamically switch to compression formats both sides support. 20 | 21 | 22 | ## Solution 23 | 24 | Enable all supported compression formats on the server, allowing clients to use the best available format. 25 | 26 | 27 | ## SCI Impact 28 | 29 | `SCI = (E * I) + M per R` 30 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 31 | 32 | Enabling text compression will impact SCI as follows: 33 | 34 | - `E`: Reducing emissions by reducing the amount of electricity needed while transferring and processing text files 35 | - `M`: Reducing the size of the files can also reduce the storage requirements of the web page on the server 36 | 37 | ## Assumptions 38 | 39 | - The use of web servers that allow compression formats 40 | 41 | ## Considerations 42 | 43 | 44 | 45 | ## References 46 | - [HTTP compression](https://en.wikipedia.org/wiki/HTTP_compression) 47 | - [Information about Brotli, a common web compression algorithm](https://en.wikipedia.org/wiki/Brotli) 48 | - [Compression Format WebBrowser Implementation Status](https://caniuse.com/?search=content-encoding) 49 | 50 | -------------------------------------------------------------------------------- /docs/catalog/web/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 5 3 | --- 4 | 5 | import TeamMember, { TeamMembers } from "@site/src/components/TeamMember"; 6 | import Image from "@theme/IdealImage"; 7 | 8 | # Web 9 | 10 | ## Subject Matter Experts 11 | 12 | 13 | Markus Seidl 14 | Bill Johnson 15 | Navveen Balani 16 | 17 | -------------------------------------------------------------------------------- /docs/catalog/web/keep-request-counts-low.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2023-10-25 5 | category: web 6 | description: Accessing a web page usually retrieves a HTML file from the web server. The HTML may then reference additional resources that the browser has to download. 7 | tags: 8 | - size:medium 9 | - role:web-developer 10 | - web 11 | --- 12 | 13 | # Keep request counts low 14 | 15 | ## Description 16 | 17 | Accessing a web page usually retrieves a HTML file from the web server. The HTML may then reference additional resources that the browser has to download. More requests means more energy consumed. As such, reducing the amount of files needed to display a page in the browser also reduces the environmental impact. 18 | 19 | ## Solution 20 | 21 | Reduce the amount of files needed and requests made by the loaded JavaScript in order to display the final page. 22 | 23 | ## SCI Impact 24 | 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | Keeping request counts low will impact SCI as follows: 29 | 30 | - `E`: Reducing the amount of requests reduces the energy needed to display the page 31 | - `M`: Reducing the amount of requests can also reduce the amount of files and therefore the storage requirements of the web page on the server 32 | 33 | 34 | ## Assumptions 35 | 36 | 37 | ## Considerations 38 | 39 | - Consider setting up request count budgets that are measured when the application is tested via test automation 40 | 41 | 42 | ## References 43 | 44 | - [Detailed description](https://web.dev/resource-summary/) 45 | -------------------------------------------------------------------------------- /docs/catalog/web/minify-web-assets.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: navveenb 4 | published_date: 2022-11-10 5 | category: web 6 | description: Minification removes unnecessary or redundant data without affecting how the resource is processed by the web browser. 7 | tags: 8 | - web 9 | - role:web-developer 10 | - size:small 11 | --- 12 | 13 | # Minify web assets 14 | 15 | ## Description 16 | A web page comprises various assets, such as HTML, CSS, JavaScript, and third-party libraries like jQuery, Bootstrap etc. Minification removes unnecessary or redundant data without affecting how the resource is processed by the web browser. 17 | 18 | ## Solution 19 | Minify web assets to reduce page size and network bandwidth while delivering the content. At scale, even a small reduction in size can have a significant impact. 20 | 21 | ## SCI Impact 22 | `SCI = (E * I) + M per R` 23 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 24 | 25 | Minifying web assets will impact the SCI as follows: 26 | 27 | - `E`: Minifying web assets can reduce the size of the web page and lead to a reduction in network bytes during the transfer of content. The browser/device would take less energy to render the content. This should reduce the energy consumption of your web page. 28 | 29 | ## Assumptions 30 | None 31 | 32 | ## Considerations 33 | None 34 | 35 | ## References 36 | - [Minify CSS](https://web.dev/unminified-css/) 37 | - [Minify JavaScript](https://web.dev/unminified-javascript/) 38 | -------------------------------------------------------------------------------- /docs/catalog/web/minimize-main-thread-work.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2022-11-22 5 | category: web 6 | tags: 7 | - web 8 | - compute 9 | - role:web-developer 10 | - size:small 11 | --- 12 | 13 | # Minimize main thread work 14 | 15 | ## Description 16 | 17 | Web browsers traditionally consist of a main rendering thread that handles most of the updates on the web page and the execution of JavaScript. JavaScript is executed on the main thread to simplify JavaScript implementations so the JavaScript programmer doesn't have to deal with any multi-threading programming patterns. 18 | When doing long running JavaScript computations it is running single threaded. In contrast all CPUs nowadays have multiple cores which have to be powered on while being underutilized. 19 | 20 | ## Solution 21 | 22 | For long running JavaScript computations (e.g. computations that run longer than a few 100 ms) try to use WebWorkers and run them in another thread while keeping the main rendering thread free. Consider moving the JavaScript computation to efficient server implementations that use optimized algorithms. 23 | 24 | ## SCI Impact 25 | 26 | `SCI = (E * I) + M per R` 27 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | 29 | Concerning the SCI equation, minimize main thread work will impact as follows: 30 | 31 | - `E`: CPU resources can be used more efficiently which reduces the electricity required and reduces the carbon intensity 32 | 33 | ## Assumptions 34 | 35 | - An assumption is made that the code in question can be moved of the main rendering thread 36 | 37 | ## Considerations 38 | 39 | - Consider moving the workload to a efficient server implementation 40 | 41 | ## References 42 | 43 | - [Main thread work breakdown](https://web.dev/mainthread-work-breakdown/) 44 | - [What is a good Total Blocking Time](https://www.debugbear.com/docs/metrics/total-blocking-time#whats-a-good-total-blocking-time) 45 | -------------------------------------------------------------------------------- /docs/catalog/web/properly-sized-images.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2022-11-10 5 | category: web 6 | description: Ideally, the stored pixel dimensions are exactly the same, or smaller, as the display size in pixels so that no bandwidth or storage space is wasted. 7 | tags: 8 | - web 9 | - size:medium 10 | - role:web-developer 11 | --- 12 | 13 | # Optimize image size 14 | 15 | ## Description 16 | 17 | Images are stored with fixed pixel dimensions on disk. This determines the file size and the quality that can be achieved when displaying the image on screen. Web pages let us dynamically resize the images from the stored size to a specific display size. 18 | 19 | Ideally, the stored pixel dimensions are exactly the same, or smaller, as the display size in pixels so that no bandwidth or storage space is wasted. 20 | The display size of images varies from device to device and can even change when the window is esized. For this use case, web browsers provide the functionality to have "responsive images". In practice, the web server stores multiple versions of the same image, then decides which image size to load depending on the screen and window size. 21 | 22 | ## Solution 23 | 24 | The ideal scenario is for the web browser to download the image in a size that is nearest to the display size, in order to save bandwidth and processing cost in the web browser. The generation can be done in multiple ways, for example inside the CI/CD pipeline or via a third party service (for example via Image-CDNs). 25 | 26 | ## SCI Impact 27 | 28 | `SCI = (E * I) + M per R` 29 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 30 | 31 | Optimizing the image sizes will impact SCI as follows: 32 | 33 | - `E`: Reduces the processing and memory requirements to display the page, which also reduces the energy requirements. However, there is also an increase in the processing time for every image to convert it into the required size. 34 | - `M`: Increases the storage requirements to cache or store all needed image sizes. 35 | 36 | ## Assumptions 37 | 38 | None 39 | 40 | ## Considerations 41 | 42 | - Consider using vector image formats like SVG to provide dynamically scalable images. 43 | 44 | ## References 45 | 46 | - [Further explanation](https://web.dev/uses-responsive-images/) 47 | - [Image CDNs](https://web.dev/image-cdns/) 48 | -------------------------------------------------------------------------------- /docs/catalog/web/remove-unused-css.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2022-11-10 5 | category: web 6 | description: CSS files are very complex and need energy intensive parsing and processing. Each added CSS definition increases the amount of time and processing power needed in this process. 7 | tags: 8 | - size:small 9 | - role:web-developer 10 | - web 11 | --- 12 | 13 | # Remove unused CSS definitions 14 | 15 | ## Description 16 | 17 | Cascading Style Sheets (CSS) allow HTML content to be styled in a very exact way. In order to have this flexibility, the CSS files are very complex and need energy intensive parsing and processing. The browser needs to download all specified CSS files, process all definitions inside these files, apply it to the DOM and calculate the layout for rendering. Each added CSS definition increases the amount of time and processing power needed in this process. 18 | 19 | ## Solution 20 | 21 | Remove all unused CSS definitions if they aren't used on the website at all. Also consider combining multiple CSS files into one file to reduce the amount of requests, and therefore time, the browser needs to retrieve all CSS definitions at once. 22 | 23 | ## SCI Impact 24 | 25 | `SCI = (E * I) + M per R` 26 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 27 | 28 | Removing unused CSS definitions will impact SCI as follows: 29 | 30 | - `E`: Reduces the processing, memory and bandwidth requirements to display the page and therefore the energy requirements. 31 | 32 | ## Assumptions 33 | 34 | None 35 | 36 | ## Considerations 37 | 38 | - Depending on the web page, consider crafting specialized CSS files for landing pages or highly frequented web pages. This also makes sense if a landing page has a completely different layout as the rest of the web page. 39 | 40 | ## References 41 | 42 | - [Unused CSS Rules reference](https://web.dev/unused-css-rules/) 43 | -------------------------------------------------------------------------------- /docs/catalog/web/serve-images-in-modern-formats.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl, navveenb 4 | published_date: 2022-11-10 5 | category: web 6 | description: Modern image formats can help to reduce bandwidth, storage and computing requirements on the displaying device. 7 | tags: 8 | - web 9 | - size:small 10 | - role:web-developer 11 | --- 12 | 13 | # Serve images in modern formats 14 | 15 | ## Description 16 | 17 | Images are a key element in modern websites and are widely used. Modern image formats can help to reduce bandwidth, storage and computing requirements on the displaying device. 18 | 19 | There are several new image formats to choose from, for example WebP and AVIF. All new formats provide better compression ratio, increased quality and more features than traditional formats. For example, WebP offers around 30% smaller files sizes than JPEG, with no drop in quality. 20 | 21 | 22 | ## Solution 23 | 24 | Test which image format give the best compression ratio, visual quality and device coverage for the website use cases. Use the best image format to serve the images on the website. 25 | 26 | 27 | ## SCI Impact 28 | 29 | `SCI = (E * I) + M per R` 30 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 31 | 32 | Concerning the SCI equation, the new image formats will impact SCI as follows: 33 | 34 | - `E`: Reducing the amount of emissions by reducing time spent on transfering and processing images 35 | 36 | ## Assumptions 37 | - The ability to use modern web browsers which support modern image formats. 38 | 39 | ## Considerations 40 | - Consider minification to reduce emissions on other resources. 41 | 42 | 43 | ## References 44 | - [More Information about WebP](https://en.wikipedia.org/wiki/WebP) 45 | - [More Information about AVIF](https://en.wikipedia.org/wiki/AVIF) 46 | - [Image Format WebBrowser Implementation Status](https://caniuse.com/?search=image%20format) 47 | -------------------------------------------------------------------------------- /docs/catalog/web/use-server-side-rendering.md: -------------------------------------------------------------------------------- 1 | --- 2 | version: 1.0 3 | submitted_by: markus-ntt-seidl 4 | published_date: 2023-10-25 5 | category: web 6 | description: Use server-side rendering for high-traffic pages 7 | tags: 8 | - web 9 | --- 10 | 11 | # Use server-side rendering for high-traffic pages 12 | 13 | ## Description 14 | 15 | Modern web applications feature a lot of interface elements that are stored in templates on the server. The template is downloaded with the application code and then rendered with requested data from the server. 16 | This can dramatically increase the SCI in different scenarios: When the client device doesn't have access to green energy, when the page usage is short (e.g. accidental clicks, pages with short dwell time like landing pages) or if a lot of server round-trips are needed to gather data. 17 | 18 | 19 | ## Solution 20 | 21 | Consider using server-side rendering as a method to reduce energy consumption on the client side. Frameworks like Angular or React already provide solutions on how to implement this efficiently. 22 | Server side rendering can improve site loading times (including rendering time on slower hardware), reduce network requirements (less round trips needed), and utilize caching (pre-rendered pages can be stored on the client device). 23 | 24 | ## SCI Impact 25 | 26 | `SCI = (E * I) + M per R` 27 | [Software Carbon Intensity Spec](https://grnsft.org/sci) 28 | 29 | Server side rendering will impact SCI as follows: 30 | 31 | - `E`: Pre-rendering once can dramatically reduce energy consumption; pre-rendering on every request can reduce energy consumption if the server is more energy efficient and has access to green energy 32 | 33 | ## Assumptions 34 | 35 | - Assumes that the frontend technology being used allows for pre-rendered content 36 | - Assumes that the web page is visited in high enough volumes so as to affect the overall SCI 37 | 38 | ## Considerations 39 | 40 | - Consider using a caching mechanism to store rendered pages if they change frequently but are still met with a high load. This can significantly reduce the server load by serving pre-rendered content for frequent requests. 41 | - Consider the other patterns in the web category 42 | 43 | ## References 44 | 45 | - [Azure Well-Architected Framework Sustainability Pillar](https://learn.microsoft.com/en-us/azure/architecture/framework/sustainability/sustainability-application-design) 46 | -------------------------------------------------------------------------------- /docs/guide/.keep: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /docs/guide/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 2 3 | --- 4 | 5 | # Guide 6 | 7 | ## What is a green software pattern? 8 | 9 | A green software pattern if applied correctly will reduce the emissions of your software. Every pattern in the database contains these sections: 10 | 11 | **Metadata** 12 | * **Version**: Designation of iteration on the pattern. This will initially be assigned by the patterns working group and defaults to 1.0 13 | * **Submitted By**: The name of the person(s) submitting the pattern 14 | * **Published Date**: The date this version of the pattern is published. This will be provided by the patterns working group upon approval 15 | * **Tag Category**: Select the most appropriate category from: Artificial Intelligence, Cloud, or Web which might apply to this pattern 16 | * **Tags**: A [pre-defined list of additional tags](/guide/suggested-tags) which might apply to the pattern (e.g. Machine Learning, Gaming, Mobile). 17 | 18 | **Pattern Content** 19 | * **Title**: Title of the pattern. Please follow the naming convention of an `Action` taken on a `Resource`. Example: "Reduce compute requirements" 20 | * **Description**: A full description of what problem this pattern is solving 21 | * **Solution**: How will this patter solve the problem 22 | * **SCI Impact**: How will this pattern affect an SCI score of an application and why 23 | * **Assumptions**: What are the assumptions being made 24 | * **Considerations**: Discussion section anything that should be taken into consideration when implementing this pattern 25 | * **References**: Use this section to provide relevant links for your pattern content from other web sites 26 | 27 | ## How to **propose** a new pattern or a change to a pattern? 28 | 29 | Whether you are proposing a new pattern or a change to an existing pattern. The first step is to discuss the change with others. 30 | 31 | Open a [GitHub issue](https://github.com/Green-Software-Foundation/green-software-patterns/issues) to discuss your changes. 32 | 33 | Use the appropriate GitHub issue template for the change you would like to make. 34 | 35 | ## How to **submit** a new pattern or a change to a pattern? 36 | 37 | You will need experience with GitHub and Pull Requests in order to submit a change. 38 | 39 | All changes follow a series of approval stages that starts with a PULL REQUEST made to the `dev` branch. 40 | 41 | Fork the repository 42 | Checkout the `dev` branch make the changes that you see fit. You can edit an existing pattern or creating a new markdown file for a new pattern. For any new patterns, please follow the Pattern Template provided in root of the [GitHub repository](https://github.com/Green-Software-Foundation/green-software-patterns) 43 | Create a PULL REQUEST to merge your changes in with the official repository, remember it should be against the `dev` branch. 44 | 45 | This starts an approval process. 46 | 47 | ## What are the stages if a Green Software Pattern? 48 | 49 | ### Discussion 50 | Anyone (member or non-members) can discuss patterns via the GitHub Issues tab of the repository. There will be an issue template to suggest new patterns or suggest changes to existing patterns. Once they are ready then can go ahead and create a PR to add a pattern to the database. 51 | 52 | ### Draft 53 | Anyone (member or non-members) can create a PR matching the template for Green Software Patterns to be merged into the dev branch. This starts an internal process of review. 54 | 55 | ### Initial Review 56 | An initial review by one member of the patterns project. The goal of this stage is just to make sure the pattern meets core requirements for what a pattern should contain, is it the right format, syntax etc…? 57 | 58 | The initial reviewer will also decide what subject matter experts are required to review this pattern. 59 | 60 | This needs an explicit approval from the initial reviewer before the pattern can move to the next stage. 61 | 62 | ### SME Review 63 | One or more subject matter experts in the GSF are asked to review the pattern and give their feedback. E.g. If the pattern is in the machine-learning catalog we ask a machine learning expert to review. 64 | 65 | This needs an explicit approval from the SME reviewer before the pattern can move to the next stage. 66 | 67 | ### Team Consensus 68 | Once the pattern has been approved by the SME it starts the team review phase. The principles and patterns team has 2 weeks to comment/object to the pattern. It needs consensus before the PR can be approved and merged into dev. 69 | 70 | At the end of this stage the pattern is merged into `dev` but is **not published on our official catalog**. 71 | 72 | ### Consistency Review 73 | Every quarter the `dev` branch is merged to the `main` branch and this triggers a consistency review where anyone in the Foundation has 2 weeks to comment or object. We need GSF wide consensus for the patterns to be published. 74 | 75 | This is done in batches every quarter to reduce the noise to the rest of the Foundation. 76 | 77 | ## What are the timelines for each stage? 78 | 79 | The working group will regularly review submitted patterns along the following timeline: 80 | 81 | * Initial Review: 1 week 82 | * SME Review: 2 weeks (plus additional iteration time based on feedback) 83 | * Team Consensus: 2 weeks 84 | 85 | ## Roles and Responsibilities 86 | 87 | ### What are the expectations for an Internal Reviewer? 88 | - Determine the if the submitted pattern aligns to green software and is clearly written 89 | - Ensure the submitted pattern provides enough detail for the Subject Matter Expert to effectively evaluate 90 | - Ensure the submitted pattern follows the defined pattern template 91 | - Provide clear feedback to the submitter if any of these areas are missing or not up to the defined standard 92 | - Assign the pattern to a relevant Subject Matter Expert for further review 93 | 94 | ### What are the expectations for a Subject Matter Experts review? 95 | - Determine if this pattern already exists in the catalog 96 | - Ensure there is appropriate level of detail for this pattern to be implemented 97 | - Determine the efficacy and accuracy of the submitted pattern 98 | - Explore splitting or combining patterns as necessary to meet the defined level of depth for a pattern 99 | - Provide clear feedback to the submitter if any of these areas are missing or not up to the defined standard 100 | 101 | ### What are the expectations on the Team to reach consensus? 102 | TODO 103 | 104 | ### What are the expectations on the broader GSF members in a consistency review? 105 | TODO 106 | 107 | ## How granular should my pattern be? 108 | 109 | We prefer smaller atomic patterns to larger patterns. A helpful way to approach a pattern is defining a specific `Action` to take on a specific `Resource`. For example, `Write efficient code` would be rejected as too generic since there is no specific action to take on a specific resource. Whereas `Cache Static Data` provides a specific action of Caching to a specific resource of Static Data. 110 | 111 | ### Least number of solutions per pattern 112 | 113 | If your pattern has multiple solutions in the solutions section, that's a good hint that the pattern can be decomposed into smaller patterns, try one per solution. 114 | 115 | ### Touching on two or more SCI components is a sign it can be decomposed further 116 | 117 | If your pattern touches on multiple components of the SCI equation simultaneously then thats a hint that your pattern can be decomposed further into multiple smaller patterns. 118 | 119 | ### Smallest SCI Impact 120 | 121 | If decomposing your pattern allows the sub patterns to impact smaller areas of the SCI equation then that's a good signal to break down your pattern into smaller patterns. 122 | 123 | For instance if your pattern affects, `E`, `I` and `M` but it could be broken down further into two smaller patterns one that impacts only `E` and the other that impacts `M` and `I`. Then break down the pattern until breaking it down further doesn't create any more changes to the SCI impact section. 124 | 125 | ## Available Guides 126 | - [Initial Reviewer Guide](initial-reviewer-guide.md) 127 | - [Subject Matter Expert Reviewer Guide](sme-reviewer-guide.md) 128 | -------------------------------------------------------------------------------- /docs/guide/initial-reviewer-guide.md: -------------------------------------------------------------------------------- 1 | # Initial Review Guide 2 | 3 | This is the guide that our Initial Reviewers will follow to determine if a submitted Green Software Pattern meets the requirements to move the Subject Matter Expert review or not. If any issues arise, the reviewer will provide feedback directly in the pull request that the submitter should update before moving forward. Once the pattern passes the initial review guidelines, the reviewer will assign it to an appropriate Subject Matter Expert (SME) for a deeper technical review. This process is expected to take no more than 1 week barring any lengthy feedback cycles. 4 | 5 | ## What To Look For In Your Review 6 | Here are the things you should look for in the initial review. If any of these areas are not met, provide feedback and any recommended changes in the pull request and assign back to the submitter. If all of these areas are met, you may assign the pattern to an appropriate Subject Matter Expert (SME) for the next phase of review. 7 | 8 | ### Alignment to Green Software Foundation 9 | Does this pattern align to the mission of the Green Software Foundation of reducing emissions that software is responsible for? Is the content clearly written and able to be understood by a subject matter expert? You don't need to evaluate jargon or acronyms from a specific domain, focus more on the content and how it relates to emission reduction and the SCI. 10 | 11 | ### Alignment to Green Software Pattern Template 12 | Does this pattern align to the [Pattern Template](https://github.com/Green-Software-Foundation/green-software-patterns/blob/dev/TEMPLATE.md) for Green Software Patterns? This includes all sections being present, tags supported on our [Tags list](https://patterns.greensoftware.foundation/tags/), valid author and github alias, clearly defined assumptions and considerations, relevance to SCI has been called out. The Pattern Title should follow the form of a specific `Action` on a specific `Resource`. For example, "Write efficient code" is not a good title since there is no specific action to take on a specific resource. A title of "Cache Static Data" provides a specific action of Caching to a specific resource of Static Data. 13 | 14 | ### Proper Green Software Pattern Formatting 15 | Our documentation system uses "front matter" which requires a specific format for metadata and this section should be included at the top of each submitted pattern. The front matter content and structure can be seen on the [Pattern Template](https://github.com/Green-Software-Foundation/green-software-patterns/blob/dev/TEMPLATE.md) and should include all fields listed there. 16 | 17 | Additionally, we look for patterns to align to the following formatting rules: 18 | - Titles should be in sentence casing. Ex: `Title of a pattern` and not `Title Of A Pattern`. 19 | - Each section should end with the appropriate punctuation. 20 | - The SCI Impact section entries should follow the same order of the equation. `E` should be first (if applicable), then `I` (if applicable), then `M` (if applicable), then `R` (if applicable). 21 | 22 | ### Pull Request Set To Merge In Dev Branch 23 | We require that all new patterns are submitted against the `dev` branch in the repository. If the pull request is set to merge to any other branch of the repository, the submitter should update it to merge to `dev`. 24 | 25 | ### Content Validation 26 | Is there enough information and detail provided in the pattern for a subject matter expert to reasonably evaluate it? You may or may not have specific knowledge for the submitted pattern so this is a cursory check to make sure there is enough information present for the subject matter expert and does not need to be perfect. 27 | 28 | ### Provide Clear Feedback 29 | If any of these areas are missing or incomplete, you must provide clear and constructive feedback and guidance as comments in the pull request so that the submitter can make the necessary changes to move to the next phase. Initial Reviewers are one of the first interactions many people will have with Green Software leaders so we want to ensure we are creating an open and inclusive environment by being constructive and clear with the feedback. 30 | 31 | 32 | ## Assigning to SME for Further Review 33 | If all of these conditions have been met and the pattern is ready for a subject matter expert, you should remove the `Initial Review` label and add the `SME Review` label on the pull request. You also should assign the pull request to an appropriate SME Reviewer based on the tags and content of the pattern. A list of available SMEs is available on each [Tag Page](https://patterns.greensoftware.foundation/tags/). Where possible, spread the SME reviews out across the available experts on a tag so that we do not overload one single person with reviews. 34 | 35 | -------------------------------------------------------------------------------- /docs/guide/sme-reviewer-guide.md: -------------------------------------------------------------------------------- 1 | # Subject Matter Expert (SME) Review Guide 2 | 3 | This is the guide that our Subject Matter Experts (SMEs) will follow to determine if a submitted Green Software Pattern meets the requirements to move the Team Consensus Review or not. If any issues arise, the reviewer will provide feedback in the pull request that the submitter should update before moving forward. Once the pattern passes the SME Review guidelines, the reviewer add the appropriate label for the next stage of Team Consensus review. This process is expected to take no more than 2 weeks barring any lengthy feedback cycles. 4 | 5 | ## What To Look For In Your Review 6 | Here are the things you should look for in the subject matter expert review. If any of these areas are not met, provide feedback and any recommended changes in the pull request and assign back to the submitter. If all of these areas are met, you may approve the pull request and move it to the Team Consensus phase. 7 | 8 | ### Check For Dupliate Patterns 9 | The first thing to check is if this pattern exists already in our defined catalog or in a pending pull request. If you feel that any other pattern matches this submission, reference the potential duplicate in the pull request comments and seek feedback from the submitter on this possible duplication. It may be a new or more specific scenario that what is previously defined so we want to provide the submitter the opportunity to provide more clarity. 10 | 11 | ### Content Validation 12 | Determine if there is an appropriate level of details for someone in the industry to implement it based solely on this content. We aren't looking for step-by-step instructions at this level, but the guidance of taking a specific action on a specific resource or system component should be clearly stated and able to be replicated by another person. 13 | 14 | ### Efficacy & Accuracy Review 15 | Determine if the proposed pattern would effectively reduce software emissions based on your experitise and best judgement. This is where we look to you as the subject matter expert to provide guidance and make judgement calls. If you are unsure or would like more detail or data, make clear requests or comments in the pull request to gain that clarity from the submitter. The value of Green Software Patterns is largely driven from this step in the review so please be critical of submissions where the efficacy and/or the accuracy is not stated or evident to you. 16 | 17 | ### Validate Pattern Level of Depth 18 | One of the trickiest parts of defining new Green Software Patterns is determining the appropriate "level" a pattern should exist. Patterns that are too broad or vague are not useful and difficult to apply. Patterns that are too specific risk losing touch with the system emissions impact in a system and are not as relatable to the industry. We prefer smaller atomic patterns to larger patterns. A helpful way to approach a pattern is defining a specific `Action` to take on a specific `Resource`. For example, `Write efficient code` is too vague and high-level since there is no specific action to take on a specific resource. Whereas `Cache Static Data` provides a specific action of Caching to a specific resource of Static Data. 19 | 20 | Some common signs that patterns should be broken down into multiple patterns include: 21 | - Multiple solutions in solution section 22 | - Touching on two or more SCI components simultaneously 23 | 24 | If the pattern is too specific as defined, the reviewer should look to combine it with other existing patterns or provide guidance to meet the appropriate level of depth. 25 | 26 | ### Provide Clear Feedback 27 | If any of these areas are missing or incomplete, you must provide clear and constructive feedback and guidance as comments in the pull request so that the submitter can make the necessary changes to move to the next phase. Subject Matter Experts are one of the first interactions many people will have with Green Software leaders so we want to ensure we are creating an open and inclusive environment by being constructive and clear with the feedback. 28 | 29 | ## Approving and Moving To Team Consensus Phase 30 | If all of these conditions have been met and the pattern is ready for the Team Consensus phase, you should remove the `SME Review` label and add the `Team Consensus` label on the pull request. You also should assign the pull request back to the Initial Reviewer of the pattern. This will start a new 2-week phase where the Principles and Patterns Working Group has 2 weeks to comment/object to the pattern. It needs team consensus before the PR can be approved and merged into the `dev` branch of the repository. 31 | 32 | 33 | -------------------------------------------------------------------------------- /docs/guide/suggested-tags.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 3 3 | --- 4 | 5 | # Suggested Tags 6 | 7 | Please use the tags within this section for your proposed pattern. New tags must be proposed through the defined proposal process and be approved by the working group. 8 | 9 | ## Technology 10 | Which technology does this pattern align to? 11 | 12 | * Alerting 13 | * [Artificial Intelligence](/tags/ai) 14 | * Augmented Reality 15 | * [Cloud](/tags/cloud) 16 | * [Compute](/tags/compute) 17 | * Content Delivery/CDN 18 | * Database 19 | * [Deployment](/tags/deployment) 20 | * DevOps 21 | * Gaming 22 | * Internet of Things 23 | * [Kubernetes](/tags/kubernetes) 24 | * Logging 25 | * [Machine Learning](/tags/machine-learning) 26 | * Mobile 27 | * [Monitoring](/tags/monitoring) 28 | * [Networking](/tags/networking) 29 | * Operating Systems 30 | * Programming Language 31 | * [Reliability/Availability](/tags/reliability-availability/) 32 | * [Security](/tags/security) 33 | * [Serverless](/tags/serverless) 34 | * [Storage](/tags/storage) 35 | * User Experience 36 | * User Interface 37 | * Virtual Reality 38 | * [Web](/tags/web) 39 | 40 | 41 | ## Role 42 | Which traditional role would implement this pattern? 43 | 44 | * [Cloud Engineer](/tags/role-cloud-engineer) 45 | * [Data Scientist](/tags/role-data-scientist) 46 | * Database Administrator 47 | * UX/Graphic Designer 48 | * Hardware Engineer 49 | * Mobile Engineer 50 | * Project Manager 51 | * Program Manager 52 | * [Reliability Engineer](/tags/role-reliability-engineer) 53 | * [Software Engineer](/tags/role-software-engineer) 54 | * [Web Developer](/tags/role-web-developer) 55 | 56 | 57 | 58 | ## Complexity 59 | How complex is this pattern to implement? 60 | 61 | * [Small](/tags/size-small) 62 | * [Medium](/tags/size-medium) 63 | * [Large](/tags/size-large) 64 | * Undetermined 65 | -------------------------------------------------------------------------------- /docs/index.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 1 3 | description: "An online open-source database of green software patterns reviewed and curated by the Green Software Foundation" 4 | --- 5 | 6 | import TeamMember, { TeamMembers } from "@site/src/components/TeamMember"; 7 | 8 | # Green Software Patterns 9 | 10 | ## Summary 11 | 12 | An online open-source database of software patterns reviewed and curated by the Green Software Foundation across a wide range of categories. You can be confident that applying any of our published and live patterns will reduce your software emissions. 13 | 14 | Any software practitioner can find the patterns related to their field, technology, or domain. Anyone can submit a pattern that triggers a detailed review process by the Foundation. 15 | 16 | ## Getting Started 17 | 18 | - Learn what constitutes a pattern and how to [contribute](/guide) a new one or edit an existing one. 19 | - View the [catalog](/catalog/) of patterns. 20 | 21 | ## Quick Links 22 | 23 | - [Press Release FAQ](https://github.com/Green-Software-Foundation/pr-faqs/blob/main/live/green-software-patterns.pr-faq.md) 24 | - [Main Website](https://patterns.greensoftware.foundation) 25 | - [Main GitHub Repository](https://github.com/Green-Software-Foundation/green-software-patterns) 26 | 27 | ## Principles, Patterns, and Practices 28 | 29 | The [**principles**](https://learn.greensoftware.foundation/practitioner/introduction) of green software outline a core set of competencies needed to define, run and build green software. 30 | 31 | A green software **pattern** is a specific example of how to apply one or more principles in a real-world example. Whereas principles describe the theory that underpins green software, patterns are the practical advice software practitioners can use in their software applications today. Patterns are vendor-neutral. 32 | 33 | A green software **practice** is a pattern applied to a specific vendor's product and informs practitioners about how to use that product in a more sustainable way. 34 | 35 | Practices should refer to patterns that should refer to principles. 36 | 37 | ![Green Software Principles, Patterns, and Practices](../src/images/GSF_Principles_Patterns_Practices_v2.png "Green Software Principles, Patterns, and Practices") 38 | 39 | --- 40 | 41 | ### Appointments 42 | 43 | 44 | 50 | Franziska Warncke 51 | 52 | 58 | Liya Mathew 59 | 60 | 61 | -------------------------------------------------------------------------------- /docs/tags/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 4 3 | --- 4 | 5 | # Tags 6 | 7 | -------------------------------------------------------------------------------- /docusaurus.config.js: -------------------------------------------------------------------------------- 1 | // @ts-check 2 | // Note: type annotations allow type checking and IDEs autocompletion 3 | 4 | const lightCodeTheme = require("prism-react-renderer/themes/github"); 5 | 6 | /** @type {import('@docusaurus/types').Config} */ 7 | const config = { 8 | // Change to Site title 9 | title: "Green Software Patterns", 10 | // Change to site description 11 | tagline: 12 | "An online open-source database of green software patterns reviewed and curated by the Green Software Foundation", 13 | // Change to site url 14 | url: "https://patterns.greensoftware.foundation/", 15 | baseUrl: "/", 16 | onBrokenLinks: "throw", 17 | onBrokenMarkdownLinks: "warn", 18 | favicon: "img/favicon.ico", 19 | organizationName: "Green-Software-Foundation", 20 | // Change to GitHub repo name. 21 | projectName: "green-software-patterns", 22 | deploymentBranch: "gh-pages", 23 | i18n: { 24 | defaultLocale: "en", 25 | locales: ["en"], 26 | }, 27 | 28 | presets: [ 29 | [ 30 | "classic", 31 | /** @type {import('@docusaurus/preset-classic').Options} */ 32 | ({ 33 | docs: { 34 | sidebarPath: require.resolve("./sidebars.js"), 35 | routeBasePath: "/", 36 | // Change this to your repo. 37 | editUrl: 38 | "https://github.com/Green-Software-Foundation/patterns/edit/main/", 39 | }, 40 | blog: false, 41 | theme: { 42 | customCss: require.resolve("./src/css/custom.css"), 43 | }, 44 | gtag: { 45 | trackingID: "G-G3P4S2WSTC", 46 | }, 47 | sitemap: { 48 | changefreq: "weekly", 49 | priority: 0.5, 50 | ignorePatterns: ["/tags/**"], 51 | filename: "sitemap.xml", 52 | }, 53 | }), 54 | ], 55 | ], 56 | 57 | themeConfig: 58 | /** @type {import('@docusaurus/preset-classic').ThemeConfig} */ 59 | ({ 60 | navbar: { 61 | // Change to project name 62 | title: "Green Software Patterns", 63 | logo: { 64 | alt: "Green Software Patterns Logo", 65 | src: "img/logo.svg", 66 | }, 67 | items: [ 68 | { 69 | href: "https://patterns.greensoftware.foundation/guide/#how-to-propose-a-new-pattern-or-a-change-to-a-pattern", 70 | position: "right", 71 | label: "Add/Edit a pattern", 72 | }, 73 | { 74 | href: "https://greensoftware.foundation/", 75 | position: "right", 76 | label: "a Green Software Foundation project", 77 | }, 78 | ], 79 | }, 80 | footer: { 81 | style: "dark", 82 | links: [ 83 | { 84 | title: "Links", 85 | items: [ 86 | { 87 | label: "Github", 88 | href: "https://github.com/Green-Software-Foundation/green-software-patterns/", 89 | }, 90 | { 91 | label: "Website", 92 | href: "https://patterns.greensoftware.foundation", 93 | }, 94 | ], 95 | }, 96 | { 97 | title: "LEGAL", 98 | items: [ 99 | { 100 | label: "Trademark Policy", 101 | href: "https://greensoftware.foundation/policy/trademark", 102 | }, 103 | { 104 | label: "Terms and Privacy Policy", 105 | href: "https://greensoftware.foundation/policy/terms", 106 | }, 107 | ], 108 | }, 109 | { 110 | title: "GSF Info", 111 | items: [ 112 | { 113 | label: "Green Software Foundation", 114 | href: "https://greensoftware.foundation", 115 | }, 116 | { 117 | label: "Twitter", 118 | href: "https://twitter.com/gsfcommunity", 119 | }, 120 | { 121 | label: "Linkedin", 122 | href: "https://www.linkedin.com/company/green-software-foundation/", 123 | }, 124 | ], 125 | }, 126 | ], 127 | copyright: `Copyright © ${new Date().getFullYear()} Joint Development Foundation Projects, LLC, Green Software Foundation Series`, 128 | }, 129 | prism: { 130 | theme: lightCodeTheme, 131 | }, 132 | colorMode: { 133 | disableSwitch: true, 134 | defaultMode: "light", 135 | }, 136 | metadata: [{ 137 | name: "twitter:card", 138 | content: "summary", 139 | }, 140 | { 141 | name: "twitter:site", 142 | content: "@gsfcommunity", 143 | }, 144 | { 145 | name: "twitter:title", 146 | content: "Green Software Patterns", 147 | }, 148 | { 149 | name: "twitter:description", 150 | content: "An online open-source database of green software patterns reviewed and curated by the Green Software Foundation", 151 | }, 152 | { 153 | name: "twitter:image", 154 | content: "https://patterns.greensoftware.foundation/img/og-image.png", 155 | }, 156 | { 157 | name: "twitter:creator", 158 | content: "@gsfcommunity", 159 | }, 160 | { 161 | name: "og:title", 162 | content: "Green Software Patterns", 163 | }, 164 | { 165 | name: "og:description", 166 | content: "An online open-source database of green software patterns reviewed and curated by the Green Software Foundation", 167 | }, 168 | { 169 | name: "og:image", 170 | content: "https://patterns.greensoftware.foundation/img/og-image.png", 171 | }, 172 | { 173 | name: "og:url", 174 | content: "https://patterns.greensoftware.foundation/", 175 | }, 176 | { 177 | name: "og:site_name", 178 | content: "Green Software Patterns", 179 | }, 180 | { 181 | name: "og:type", 182 | content: "website", 183 | }, 184 | 185 | ] 186 | }), 187 | 188 | plugins: [ 189 | [ 190 | "@docusaurus/plugin-ideal-image", 191 | { 192 | quality: 90, 193 | max: 1030, // max resized image's size. 194 | min: 640, // min resized image's size. if original is lower, use that size. 195 | steps: 2, // the max number of images generated between min and max (inclusive) 196 | disableInDev: false, 197 | }, 198 | ], 199 | ], 200 | }; 201 | 202 | module.exports = config; 203 | -------------------------------------------------------------------------------- /license.md: -------------------------------------------------------------------------------- 1 | Materials in this repository other than source code are provided as follows: 2 | 3 | Copyright (c) 2022 Joint Development Foundation Projects, LLC, GSF Series and 4 | its contributors. All rights reserved. THESE MATERIALS ARE PROVIDED "AS IS." The 5 | parties expressly disclaim any warranties (express, implied, or otherwise), 6 | including implied warranties of merchantability, non-infringement, fitness for a 7 | particular purpose, or title, related to the materials. The entire risk as to 8 | implementing or otherwise using the materials is assumed by the implementer and 9 | user. IN NO EVENT WILL THE PARTIES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS 10 | OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY 11 | CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE 12 | OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING 13 | NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED 14 | OF THE POSSIBILITY OF SUCH DAMAGE. 15 | 16 | No patent licenses are granted for the Draft Deliverables or Approved Deliverables 17 | developed by this Working Group. 18 | 19 | Source code in this repository is provided under the MIT License, as follows: 20 | 21 | Copyright (c) 2022 Joint Development Foundation Projects, LLC, GSF Series and 22 | its contributors. 23 | 24 | Permission is hereby granted, free of charge, to any person obtaining a copy of 25 | this software and associated documentation files (the "Software"), to deal in 26 | the Software without restriction, including without limitation the rights to 27 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of 28 | the Software, and to permit persons to whom the Software is furnished to do so, 29 | subject to the following conditions: 30 | 31 | The above copyright notice and this permission notice shall be included in all 32 | copies or substantial portions of the Software. 33 | 34 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 35 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 36 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 37 | COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 38 | IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 39 | CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 40 | -------------------------------------------------------------------------------- /package.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "gsf-docusaurus-template", 3 | "version": "0.0.0", 4 | "private": true, 5 | "scripts": { 6 | "docusaurus": "docusaurus", 7 | "start": "docusaurus start", 8 | "build": "docusaurus build", 9 | "swizzle": "docusaurus swizzle", 10 | "deploy": "docusaurus deploy", 11 | "clear": "docusaurus clear", 12 | "serve": "docusaurus serve", 13 | "write-translations": "docusaurus write-translations", 14 | "write-heading-ids": "docusaurus write-heading-ids", 15 | "typecheck": "tsc" 16 | }, 17 | "dependencies": { 18 | "@docusaurus/core": "^2.0.1", 19 | "@docusaurus/plugin-ideal-image": "^2.0.1", 20 | "@docusaurus/preset-classic": "^2.0.1", 21 | "@mdx-js/react": "^1.6.22", 22 | "clsx": "^1.2.0", 23 | "prism-react-renderer": "^1.3.5", 24 | "react": "^17.0.2", 25 | "react-dom": "^17.0.2" 26 | }, 27 | "devDependencies": { 28 | "@docusaurus/module-type-aliases": "^2.0.1", 29 | "@tsconfig/docusaurus": "^1.0.5", 30 | "typescript": "^4.7.4" 31 | }, 32 | "browserslist": { 33 | "production": [ 34 | ">0.5%", 35 | "not dead", 36 | "not op_mini all" 37 | ], 38 | "development": [ 39 | "last 1 chrome version", 40 | "last 1 firefox version", 41 | "last 1 safari version" 42 | ] 43 | }, 44 | "engines": { 45 | "node": ">=16.14" 46 | } 47 | } 48 | -------------------------------------------------------------------------------- /sidebars.js: -------------------------------------------------------------------------------- 1 | /** 2 | * Creating a sidebar enables you to: 3 | - create an ordered group of docs 4 | - render a sidebar for each doc of that group 5 | - provide next/previous navigation 6 | 7 | The sidebars can be generated from the filesystem, or explicitly defined here. 8 | 9 | Create as many sidebars as you want. 10 | */ 11 | 12 | // @ts-check 13 | 14 | /** @type {import('@docusaurus/plugin-content-docs').SidebarsConfig} */ 15 | const sidebars = { 16 | // By default, Docusaurus generates a sidebar from the docs folder structure 17 | tutorialSidebar: [{type: 'autogenerated', dirName: '.'}], 18 | 19 | // But you can create a sidebar manually 20 | /* 21 | tutorialSidebar: [ 22 | { 23 | type: 'category', 24 | label: 'Tutorial', 25 | items: ['hello'], 26 | }, 27 | ], 28 | */ 29 | }; 30 | 31 | module.exports = sidebars; 32 | -------------------------------------------------------------------------------- /src/components/HomepageFeatures/index.tsx: -------------------------------------------------------------------------------- 1 | import React from 'react'; 2 | import clsx from 'clsx'; 3 | import styles from './styles.module.css'; 4 | 5 | type FeatureItem = { 6 | title: string; 7 | Svg: React.ComponentType>; 8 | description: JSX.Element; 9 | }; 10 | 11 | const FeatureList: FeatureItem[] = [ 12 | { 13 | title: 'Easy to Use', 14 | Svg: require('@site/static/img/undraw_docusaurus_mountain.svg').default, 15 | description: ( 16 | <> 17 | Docusaurus was designed from the ground up to be easily installed and 18 | used to get your website up and running quickly. 19 | 20 | ), 21 | }, 22 | { 23 | title: 'Focus on What Matters', 24 | Svg: require('@site/static/img/undraw_docusaurus_tree.svg').default, 25 | description: ( 26 | <> 27 | Docusaurus lets you focus on your docs, and we'll do the chores. Go 28 | ahead and move your docs into the docs directory. 29 | 30 | ), 31 | }, 32 | { 33 | title: 'Powered by React', 34 | Svg: require('@site/static/img/undraw_docusaurus_react.svg').default, 35 | description: ( 36 | <> 37 | Extend or customize your website layout by reusing React. Docusaurus can 38 | be extended while reusing the same header and footer. 39 | 40 | ), 41 | }, 42 | ]; 43 | 44 | function Feature({title, Svg, description}: FeatureItem) { 45 | return ( 46 |
47 |
48 | 49 |
50 |
51 |

{title}

52 |

{description}

53 |
54 |
55 | ); 56 | } 57 | 58 | export default function HomepageFeatures(): JSX.Element { 59 | return ( 60 |
61 |
62 |
63 | {FeatureList.map((props, idx) => ( 64 | 65 | ))} 66 |
67 |
68 |
69 | ); 70 | } 71 | -------------------------------------------------------------------------------- /src/components/HomepageFeatures/styles.module.css: -------------------------------------------------------------------------------- 1 | .features { 2 | display: flex; 3 | align-items: center; 4 | padding: 2rem 0; 5 | width: 100%; 6 | } 7 | 8 | .featureSvg { 9 | height: 200px; 10 | width: 200px; 11 | } 12 | -------------------------------------------------------------------------------- /src/components/TeamMember/index.tsx: -------------------------------------------------------------------------------- 1 | import React from "react"; 2 | import styles from "./styles.module.css"; 3 | 4 | type TeamMemberType = { 5 | children: string; 6 | role: string; 7 | company: string; 8 | github: string; 9 | twitter?: string; 10 | linkedin?: string; 11 | }; 12 | 13 | export function TeamMembers({ children }: { children: React.ReactNode }) { 14 | return
{children}
; 15 | } 16 | 17 | export default function TeamMember({ 18 | children, 19 | role, 20 | company, 21 | github, 22 | twitter, 23 | linkedin, 24 | }: TeamMemberType): JSX.Element { 25 | return ( 26 |
27 |
28 | avatar 29 |
30 |
31 | {children} 32 | {role} 33 | @{company} 34 |
35 | {github && ( 36 | 37 | 50 | 51 | )} 52 | {twitter && ( 53 | 54 | 67 | 68 | )} 69 | {linkedin && ( 70 | 71 | 84 | 85 | )} 86 |
87 |
88 |
89 | ); 90 | } 91 | -------------------------------------------------------------------------------- /src/components/TeamMember/styles.module.css: -------------------------------------------------------------------------------- 1 | .container { 2 | display: grid; 3 | grid-template-columns: repeat(2, 1fr); 4 | gap: 44px; 5 | } 6 | .teamMember { 7 | display: flex; 8 | gap: 32px; 9 | } 10 | .avatar { 11 | flex-shrink: 0; 12 | } 13 | .avatar img { 14 | border-radius: 50%; 15 | width: 100px; 16 | height: 100px; 17 | } 18 | .name { 19 | font-size: 20px; 20 | font-weight: bold; 21 | color: var(--ifm-color-primary); 22 | display: block; 23 | } 24 | .role { 25 | font-size: 16px; 26 | color: var(--ifm-color-content); 27 | display: block; 28 | } 29 | .company { 30 | font-size: 14px; 31 | color: var(--ifm-color-emphasis-700); 32 | display: block; 33 | } 34 | .social { 35 | display: flex; 36 | gap: 8px; 37 | margin-top: 8px; 38 | } 39 | -------------------------------------------------------------------------------- /src/css/custom.css: -------------------------------------------------------------------------------- 1 | /** 2 | * Any CSS included here will be global. The classic template 3 | * bundles Infima by default. Infima is a CSS framework designed to 4 | * work well for content-centric websites. 5 | */ 6 | 7 | /* You can override the default Infima variables here. */ 8 | :root { 9 | --ifm-color-primary: #006d69; 10 | --ifm-color-primary-dark: #00524f; 11 | --ifm-color-primary-darker: #003734; 12 | --ifm-color-primary-darkest: #002c2a; 13 | --ifm-color-primary-light: #80b6b4; 14 | --ifm-color-primary-lighter: #bfdbd9; 15 | --ifm-color-primary-lightest: #e5f0f0; 16 | --ifm-color-content: #3c3c3c; 17 | --ifm-heading-color: var(--ifm-color-primary); 18 | --ifm-footer-background-color: var(--ifm-color-primary-darkest) 19 | --ifm-code-font-size: 95%; 20 | --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.1); 21 | } 22 | 23 | /* For readability concerns, you should choose a lighter palette in dark mode. */ 24 | [data-theme="dark"] { 25 | --ifm-color-primary: #25c2a0; 26 | --ifm-color-primary-dark: #21af90; 27 | --ifm-color-primary-darker: #1fa588; 28 | --ifm-color-primary-darkest: #1a8870; 29 | --ifm-color-primary-light: #29d5b0; 30 | --ifm-color-primary-lighter: #32d8b4; 31 | --ifm-color-primary-lightest: #4fddbf; 32 | --background-color: #fbfcf6; 33 | --ifm-navbar-background-color: var(--background-color); 34 | --docusaurus-highlighted-code-line-bg: rgba(0, 0, 0, 0.3); 35 | } 36 | 37 | body{ 38 | background-color: var(--background-color); 39 | } 40 | .navbar__brand { 41 | color: var(--ifm-color-primary); 42 | } 43 | .footer--dark { 44 | --ifm-footer-background-color: #032629; 45 | --ifm-footer-title-color: #aecc53; 46 | --ifm-footer-link-color:hsla(0,0%,100%,0.5); 47 | --ifm-footer-link-hover-color: hsla(0,0%,100%,1); 48 | } 49 | .intro-logo{ 50 | width: 96px; 51 | margin-bottom: -44px; 52 | margin-top: 32px; 53 | } -------------------------------------------------------------------------------- /src/images/GSF_Principles_Patterns_Practices_v2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Green-Software-Foundation/patterns/fd7495df4925530e2dc61a99188e6aae7149d7aa/src/images/GSF_Principles_Patterns_Practices_v2.png -------------------------------------------------------------------------------- /src/images/test.txt: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /src/images/time-shift.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Green-Software-Foundation/patterns/fd7495df4925530e2dc61a99188e6aae7149d7aa/src/images/time-shift.png -------------------------------------------------------------------------------- /static/.nojekyll: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Green-Software-Foundation/patterns/fd7495df4925530e2dc61a99188e6aae7149d7aa/static/.nojekyll -------------------------------------------------------------------------------- /static/CNAME: -------------------------------------------------------------------------------- 1 | patterns.greensoftware.foundation -------------------------------------------------------------------------------- /static/img/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Green-Software-Foundation/patterns/fd7495df4925530e2dc61a99188e6aae7149d7aa/static/img/favicon.ico -------------------------------------------------------------------------------- /static/img/logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Green-Software-Foundation/patterns/fd7495df4925530e2dc61a99188e6aae7149d7aa/static/img/logo.png -------------------------------------------------------------------------------- /static/img/logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /static/img/og-image.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Green-Software-Foundation/patterns/fd7495df4925530e2dc61a99188e6aae7149d7aa/static/img/og-image.png -------------------------------------------------------------------------------- /tsconfig.json: -------------------------------------------------------------------------------- 1 | { 2 | // This file is not used in compilation. It is here just for a nice editor experience. 3 | "extends": "@tsconfig/docusaurus/tsconfig.json", 4 | "compilerOptions": { 5 | "baseUrl": "." 6 | } 7 | } 8 | --------------------------------------------------------------------------------