Architecture & Backend

Description

MACH architecture is a composable architectural approach comprising the concepts of Microservices, API-first, Cloud Native and Headless.

What's the impact?

Similar to the benefits of Jamstack, MACH architecture allows for the selection of individual best-of-breed components, which can be prioritized based on their sustainability impact. This approach can enable a separation of concerns in an architecture and can be advantageous when attempting to optimize the energy footprint of a system. For example, building in a cloud-native way enables the use of state-of-the-art scaling techniques.

Description

Superfluous requests consume both server and client compute, often with minimal benefit for the end-user experience. When possible, determine a request delay which accomplishes the end-user expectation of reactivity, bulks requests into a larger but less frequent payload, and ensure that caching reflects the frequency in which data is expected to be updated.

What's the impact?

Limiting the frequency of network requests is a well-known, but sometimes forgotten, technique that can significantly reduce network traffic and compute usage on both the server and client. As bandwidth and processing time are a modest to non-existent cost, request frequency and caching are often a lower priority during development. However, reducing server-side compute naturally leads to a reduction of infrastructure costs — as well as the energy consumption. Similarly, client devices can accommodate heavy or frequent requests, but with the trade-off of higher energy usage.

Description

Optimizing databases, queries and API responses helps ensure requests for data are efficient and inexpensive—while avoiding returning extraneous data from APIs.

What's the impact?

Other than being a best-practice in database design, the small accumulation of inefficient requests can have a real impact to the carbon footprint of an app or service. Performance optimization has the added benefit of reducing this footprint.

Description

Architectural patterns, such as Jamstack, separate the data and business logic from website presentation technologies. The Jam in Jamstack is from the initials of JavaScript, APIs and Markup. The strategy uses these technologies to create a standalone web layer decoupled from data and business logic. Together with other techniques, such as 'Using pre-compilation for improved performance and less processing time,' this pattern becomes very energy efficient.

What's the impact?

Decoupling of these concerns allows for lower energy consumption hosting and distribution. It also means you can scale resources based on demand and respond to client requests with minimal data, therefore reducing the energy overhead of data transfer. In addition there can be other benefits to this architectural strategy, including performance improvements and reduced cloud infrastructure costs. We are adopting a Jamstack architecture wherever the technique is appropriate.

Learn more

https://jamstack.org/

Description

Event-driven architecture uses system events to trigger and communicate between decoupled services and APIs. This pattern is efficient in that it only invokes the services/code that are required when they are needed.

What's the impact?

Event-driven architecture is estimated to be more energy efficient when compared with command-driven approaches (which stay available or 'on' waiting for a command). The technique should be used whenever appropriate.

Description

For certain use cases (i.e., documentation or infrequently updated sites), static site generators (SSGs) can be an effective and efficient alternative to CMS products.

What's the impact?

An important component of both Jamstack and MACH architecture, SSGs provide the benefit of pre-compilation for reducing your processing and hosting footprints—serving the same content with considerably less compute. Tooling in this area is particularly mature and widely supported by cloud platforms.

Learn more

Jamstack.org maintains an extensive list of static site generators across a wide range of development and templating languages.

Description

Adopting an appropriate level of abstraction helps limit network congestion, latency and overall complexity.

What's the impact?

Abstracting microservices can help minimize the overall footprint of the architecture—including aspects like network congestion and latency. Approaches for abstracting microservices are sometimes not apparent from the onset of development and are likely to evolve over time. Exploring this technique whenever possible in the Software Development Lifecycle will likely be beneficial to the energy footprint of the architecture.

Description

Offsetting worker processes results in an architecture that defines a 'web' portion that handles HTTP requests and a 'worker' portion that handles time or processing-intensive operations.

What's the impact?

Offsetting worker processes can improve resource utilization efficiency. Decoupling the frontend and resource-intensive backend processes allows for independent scaling, and enables efficient use of managed services. This is an architecture technique that isn't commonly adopted and may be a second level optimization in some cases that are worthy of exploration.

Learn more

• Web-Queue-Worker architecture style on Azure

Description

Strategies such as Demand Shaping and Demand Shifting dynamically run computation in hosting regions and at times when carbon-intensity is best. In 'carbon-aware applications' configuration can be made so that when carbon intensity is particularly high, applications 'do less.'

What's the impact?

These techniques are not always applicable to all applications and other considerations—such as regulations on data flows and the need to address demand when it arises—can influence when this can be applied. However, when applied correctly, it can be a great strategy for reducing or managing resource consumption.

Learn more

• Read about Demand Shaping on Green Software Practitioner

Description

Monolithic applications are self-contained applications where all logic and functions are compiled together and delivered from single source. Usually such applications bundle a number of features and attempt to provide for to solve a wide variety of user needs.

What's the impact?

Monolithic applications tend to increase in size exponentially and lead to slower development as the code base grows. Larger monoliths are difficult to optimize for efficiency and tend to use a large amount of resources. As monolithic applications bundle inter-operable features, they often require a large cloud or resource footprint when compared to applications that are architected to separate concerns and logic. For instance, the administration of a CMS and serving of the CMS's content require different resources and usage patterns, but when amalgamated, require an always-on, high-powered service.