From 3014de95d22b311510c79e0b0609a68612ba11cd Mon Sep 17 00:00:00 2001 From: dkrees Date: Wed, 12 Jun 2024 16:04:49 +0100 Subject: [PATCH] Formatting and corrections --- pages/information/paas.md | 115 +++++++--------- pages/information/saas.md | 145 ++++++--------------- pages/views/roles/architecture.md | 2 +- pages/views/roles/architecture_nfrs.md | 119 +++++++---------- pages/views/roles/architecture_strategy.md | 40 +++--- 5 files changed, 160 insertions(+), 261 deletions(-) diff --git a/pages/information/paas.md b/pages/information/paas.md index 6f5d2d9..613cc32 100644 --- a/pages/information/paas.md +++ b/pages/information/paas.md @@ -9,45 +9,43 @@ published: false Platform as a Service is a special case of cloud that lets the customer run applications without having to manage infrastructure (VM or Physical). The user of the PaaS service is still responsible for the writing of application code and its deployment but they don't have to worry about OS updates, low level networking, securing virtual machines and other infrastructure concerns. -The diagram below shows just a few of the many the PaaS offerings on the market: +The diagram below shows just a few of the many PaaS offerings on the market: Some options are relatively simple and opinionated like Heroku and Salesforce whereas others are more complex but flexible like those from the main cloud providers offering a variety of options including: +* Short-running function executors, e.g. AWS Lambda, Google Cloud Run and Azure Functions +* Longer running app executors, e.g. Google App Engine and AWS Elastic Beanstalk + * Also managed Kubernetes, e.g. GKE, AKS +* Databases, e.g. Dynamo DB, Cosmos DB - * Short running function executors, e.g. AWS Lambda, Google Cloud Run and Azure Functions - * Longer running app executors, e.g. Google App Engine and AWS Elastic Beanstalk - * Also managed Kubernetes, e.g. GKE, AKS - * Databases, e.g. Dynamo DB, Cosmos DB - -Cloud vendor PaaS options often straddle the IaaS divide and allow the mixing and matching of high and low level components. Salesforce on the other hand also offers SaaS products that run on it's platform. -There's also a pattern of CDN providers now offering short lived compute and sometimes storage services alongside tradtional cacheing use cases. +Cloud vendor PaaS options often straddle the IaaS divide and allow the mixing and matching of high and low-level components. Salesforce on the other hand also offers SaaS products that run on its platform. +There's also a pattern of CDN providers now offering short-lived compute and sometimes storage services alongside traditional caching use cases. {% include linkedHeading.html heading="Benefits of PaaS for emissions" level=2 %} The advantages and disadvantages of cloud from an emissions perspective are discussed in Cloud Emissions including the use of green electricity (if offsetting is counted) and having a low PUE. -Where PaaS can have an advantage over IaaS is in maximising utilisation. Where an organisation has lifted and shifted virtual machines from on-prem those machines may be doing very little work but taking a percentrage of a physical machine's resources meaning energy use from CPU and memory usage and also resulting in embodied carbon. e.g. if some large cloud VM instances are required to be continually running in case of high traffic once a day or week. +Where PaaS can have an advantage over IaaS is in maximising utilisation. Where an organisation has lifted and shifted virtual machines from on-prem those machines may be doing very little work but taking a percentage of a physical machine's resources meaning energy use from CPU and memory usage and also resulting in embodied carbon. e.g. if some large cloud VM instances are required to be continually running in case of high traffic once a day or week. -On the other hand PaaS products are generally multi-tenant and so maximise resource with everything being shared. The headroom of each physical machine (i.e. unused utilsation) can be much lower as the scale of the PaaS provider means that when a given tenant needs to scale up, more resources can easily be accomodated. Even where an organisation uses compute resources quite efficiently, e.g. via a custom Kubernetes cluster, it is common for services like databases to be managed externally using VMs and so may be underutilised. +On the other hand, PaaS products are generally multi-tenant and so maximise resources with everything being shared. The headroom of each physical machine (i.e. unused utilisation) can be much lower as the scale of the PaaS provider means that when a given tenant needs to scale up, more resources can easily be accommodated. Even where an organisation uses compute resources quite efficiently, e.g. via a custom Kubernetes cluster, it is common for services like databases to be managed externally using VMs and so may be underutilised. -From a purely sustainability viewpoint there are few downsides to using PaaS but be aware that: - * for some providers there may be less control over location and carbon intensity than a full IaaS solution with the option to pick from numerous regions over the world. - * this would also reduce the ability to dynamically switch regions over time according the lowest carbon electricity -* the above only applies for multi-tenant providers. Where dedicated hardware is employed for security and regulatory reasons then the advantage no longer applies -* not all providers report on the emissions of their PaaS offerings +From a purely sustainability viewpoint there are a few downsides to using PaaS but be aware that: +* For some providers, there may be less control over location and carbon intensity than a full IaaS solution with the option to pick from numerous regions over the world. + * This would also reduce the ability to dynamically switch regions over time according to the lowest carbon electricity. +* The above only applies to multi-tenant providers. Where dedicated hardware is employed for security and regulatory reasons then the advantage no longer applies. +* Not all providers report on the emissions of their PaaS offerings. {% include linkedHeading.html heading="PaaS Capabilities and their emissions" level=2 %} A PaaS will provide all or some of the following functionality: - * Configurable API layers - i.e. access and entrypoints to the installed functions - * Function runner - will execute functions in response to API requests - * Additional supporting services +* Configurable API layers - i.e. access and entrypoints to the installed functions +* Function runner - will execute functions in response to API requests +* Additional supporting services * Object storage * DBs * Queues * Hosting/webserver, sometimes including CDN layer for caching -The diagram below shows how a PaaS service fits into the end to end service and what must be measured or estimated. Th -A typical web service includes a browser front end app or pages, a backend API layer and some persistance and it may also have some external services as dependencies. The next sections explain how these are provided by PaaS products. +The diagram below shows how a PaaS service fits into the end-to-end service and what must be measured or estimated. A typical web service includes a browser front-end app or pages, a backend API layer and some persistence and it may also have some external services as dependencies. The next sections explain how these are provided by PaaS products. @@ -55,74 +53,61 @@ A typical web service includes a browser front end app or pages, a backend API l Various flavours of this are possible but the aim is to be able to do processing server side without having to manage any servers. Solutions tend to be based around either Docker containers or something slightly more prescriptive known as serverless functions whereby only certain languages are permitted and all the application writer has to do is ensure their app, e.g. a set of Javascript files, conforms to some prescribed interface such that the runtime can launch it, report logs and metrics etc. {% include linkedHeading.html heading="Serverless functions" level=4 %} -These can be the most efficient way to execute code from a carbon point of view. Docker containers or very lightweight virtual machines (see AWS Firecracker) are spun up when requests come in and after a period of in-activity wind down. They'll scale as needed dependent on the number of requests. The underlying hardware running those machines is by default multi-tenant and shared. This ensures that hardware is maximally utilised within the constraint of needing headroom for busy periods. +These can be the most efficient way to execute code from a carbon point of view. Docker containers or very lightweight virtual machines (see AWS Firecracker) are spun up when requests come in and after a period of inactivity wind down. They'll scale as needed depending on the number of requests. The underlying hardware running those machines is by default multi-tenant and shared. This ensures that hardware is maximally utilised within the constraint of needing headroom for busy periods. -It is especially beneficial for infrequently used applications that would be idling most of the time, waiting for the occasional request. e.g. some internal workflow tool used by a small number of internal users when cases to process come in. Even if a container or a virtual machine is used these will consume memory and some CPU cycles when nothing is happening whereas serverless functions can scale to 0. +It is especially beneficial for infrequently used applications that would be idling most of the time, waiting for the occasional request. e.g. some internal workflow tools used by a small number of internal users when cases to process come in. Even if a container or a virtual machine is used these will consume memory and some CPU cycles when nothing is happening whereas serverless functions can scale to zero. -There's 2 scenarios where the benefits can be reduced: - * high traffic sites, e.g. hundreds of requests per second - * To take an example AWS Lambdas only handle one request at a time per virtual machine which may make them inefficient if there's any external dependencies and the function is waiting on a DB or storage for a significant proportion of request time - * where dedicated resources are being used to host the lambdas +There are 2 scenarios where the benefits can be reduced: +* High-traffic sites, e.g. hundreds of requests per second + * To take an example; AWS Lambdas only handles one request at a time per virtual machine which may make them inefficient if there are any external dependencies and the function is waiting on a DB or storage for a significant proportion of request time. +* Where dedicated resources are being used to host the lambdas. -On the second point the worst case is where something like Azure App Service Environment is being used to provide an isolated single tenant environment for hosting the "serverless". This could be quite wasteful if not being used for a heavily utilised service. In between this and the default scenario are options for provisioned instances that mean virtual machines to handle requests are always running so as to avoid cold starts, e.g where a JVM initialises for the first time. There are low carbon ways to mitigate this such as AWS SnapStart which avoids the need to reserve instances. +On the second point, the worst case is where something like Azure App Service Environment is being used to provide an isolated single-tenant environment for hosting the "serverless". This could be quite wasteful if not used for a heavily utilised service. In between this and the default scenario are options for provisioned instances that mean virtual machines to handle requests are always running to avoid cold starts, e.g. where a JVM initialises for the first time. There are low-carbon ways to mitigate this such as AWS SnapStart which avoids the need to reserve instances. Therefore from a carbon emissions point of view, all else being equal it is preferable to avoid dedicated hardware and to minimise reserved instances. {% include linkedHeading.html heading="General app hosting" level=4 %} -Whereas serverless functions generally do a small amount of work then end there are also services for running more traditional longer lived apps which can be based around docker images or code performing to a standard directory structure and entry point in a set of supported languages and frameworks. Examples include Google App Engine and AWS Elastic Beanstalk and at a slightly lower level the various managed Kubernetes solutions on the market and tooling build aorund them like Open Shift. +Whereas serverless functions generally do a small amount of work then end there are also services for running more traditional longer lived apps which can be based around docker images or code performing to a standard directory structure and entry point in a set of supported languages and frameworks. Examples include Google App Engine and AWS Elastic Beanstalk and at a slightly lower level the various managed Kubernetes solutions on the market and tooling built around them like Open Shift. -These typically use standard VMs just as a user could spin up themselves but with the benefit that the providers manages the orchestration and maintenance of these resources. Nonetheless the infrasturcture isn't always hidden in the same way as the short lived serverless functions and this means that measurement can be done as per any IaaS component. +These typically use standard VMs just as a user could spin up themselves, but with the benefit that the providers manage the orchestration and maintenance of these resources. Nonetheless, the infrastructure isn't always hidden in the same way as the short-lived serverless functions and this means that measurement can be done as per any IaaS component. -In other cases, e.g. Salesforce there is a much more restricted platform where, as with cloud functions the runtime is hidden from the user of the service. +In other cases, e.g. Salesforce there is a much more restricted platform where, as with cloud functions, the runtime is hidden from the user of the service. {% include linkedHeading.html heading="Supporting services" level=4 %} -Some use cases are stateless but often there is a need to persist data and most PaaS vendors will provide options for this that may be tightly coupled to the platform or quite separate. As an example, in the Salesforce Platform this is a specific DB provided by the platform including APIs to communicate with it securely from an app running on the platform. On the other hand for GCP or AWS there are various database as a service offerings that can be used from an app on the platform but these are quite decoupled and can also be used from lots of other places. Heroku includes a single managed SQL, Redis and Kafka service to cover common use cases. +Some use cases are stateless, but often there is a need to persist data, and most PaaS vendors will provide options for this that may be tightly coupled to the platform or quite separate. As an example, in the Salesforce platform, this is a specific DB provided by the platform, including APIs to communicate with it securely from an app running on the platform. On the other hand, for GCP or AWS, various database-as-a-service offerings can be used from an app on the platform, but these are quite decoupled and can also be used from lots of other places. Heroku includes a single-managed SQL, Redis, and Kafka service to cover common use cases. -Ultimately an app running on a PaaS platform may make use of any number of SaaS products including authentication providers, databases and message queues and so long as HTTP or a standard protocol is used. +Ultimately, an app running on a PaaS platform may make use of any number of SaaS products, including authentication providers, databases, and message queues, so long as HTTP or a standard protocol is used. -As touched on earlier there is value in using database and queue solutions from a PaaS provider in that they are typically multi-tenant. As an example, with AWS Aurora Serverless, although the user gets their own DB instances these can be scaled automatically and dynamically and in fact the whole storage engine is distributed and multi-tenant as are many other types of storage include S3, Google Big Table, Azure Cosmos DB. This brings 2 benefits: - * high utilisation of resources whilst allowing room to scale a given tenant - * efficient storing of data - replication factor doesn't need to be high whilst still protecting from data loss +As touched on earlier, there is value in using database and queue solutions from a PaaS provider in that they are typically multi-tenant. As an example, with AWS Aurora Serverless, although the user gets their own DB instances, these can be scaled automatically and dynamically. The whole storage engine is distributed and multi-tenant, as are many other storage types, including S3, Google Big Table, Azure Cosmos DB. This brings two benefits: +* High utilisation of resources while allowing room to scale a given tenant. +* Efficient storing of data - replication factor doesn't need to be high while still protecting from data loss {% include linkedHeading.html heading="Measuring PaaS" level=2 %} -For AWS, Azure, GCP PaaS services can be measured as described in Cloud. In other words their built-in reporting can be used directly just as for lower level infrastructure. Additionally tools such as Cloud Carbon Footprint can be utilised in many cases as the PaaS solutions will still provision VMs that can be measured even though the user of the service doesn't have to manage them. +For AWS, Azure, GCP PaaS services can be measured as described in Cloud. In other words, their built-in reporting can be used directly just as for lower level infrastructure. Additionally, tools such as Cloud Carbon Footprint can be utilised in many cases as the PaaS solutions will still provision VMs that can be measured even though the user of the service doesn't have to manage them. -This is not possible for most of the other solutions except where they provision resources in the cloud account of the organisation using the PaaS product. As already discussed PaaS solutions offer the most benefits from a sustainability perspective when multi-tenant but this also makes reporting very challenging as the attribution of carbon emissions is not easy where many users share one set of servers and virtual servers. +This is not possible for most of the other solutions except where they provision resources in the cloud account of the organisation using the PaaS product. As already discussed, PaaS solutions offer the most benefits from a sustainability perspective when multi-tenant. However, this also makes reporting very challenging as the attribution of carbon emissions is not easy, as many users share one set of servers and virtual servers. -Where the underlying infrastructure is opaque there's 2 options: -1. Follow the same approach as for SaaS - * i.e. Sustainable Web Design, or Shift 1 or a custom request time based method where the data or request time in combination with number of users is used to aid estimation. +Where the underlying infrastructure is opaque, there are two options: +1. Follow the [same approach as for SaaS](/information/saas#measurement-estimation-methods) + * i.e. Sustainable Web Design, or Shift 1, or a custom request time-based method where the data or request time in combination with the number of users is used to aid estimation. 2. Run locally or in some other environment periodically. -The second option wasn't possible for SaaS because the implementation is totally hidden but for PaaS the user is responsible for the application code and so it may be possible to run this in an alternative environment in order to get an approximate value. This could be local, cloud or in something like Green Metrics Tool's SaaS offering) where a predictable environment is needed for measurements over time. +The second option wasn't possible for SaaS because the implementation is totally hidden, but for PaaS, the user is responsible for the application code, so it may be possible to run this in an alternative environment in order to get an approximate value. This could be local, cloud, or in something like Green Metrics Tool's SaaS offering where a predictable environment is needed for measurements over time. {% include linkedHeading.html heading="Measuring databases and other add-on services" level=3 %} -Where the application on the PaaS platform makes use of additional services such as a managed DB or queue then measurement becomes further complicated. - -One option is to use the aforementioned SaaS methods and don't break out the DB as a separate estimate. In other words, just consider the end-to-end request time or data sent. This is likely to be less accurate but is simpler as a first approximation. Where there is a preference to actually measure the end-to-end request handling including both app server and data services then there's a few possible scenarios: - - - - - - - - - - - - - - - - - - -
ScenarioOptions
Bespoke DB provided by cloud service provider like GCP that provides carbon reportingUse the vendor carbon reporting or a tool like Cloud Carbon Footprint
Bespoke DB with no carbon reporting, e.g. Salesforce Platform's data layerCould run with a similar DB, e.g. Postgres for a very approximate measurement as a Docker image alonside the application code that calls it. But would need changes to the application where there's no API compatible option so not always practical
Standard DB provided as a managed serviceRun a dockerised version or a cloud provided version to run with the app code.
- -Note that when running something like a database in Docker to estimate the energy usage of a request the set is much simpler with a single local DB instance vs a cluster across multiple sites and machines for the PaaS one and so the real DB may differ significantly. The value is better for observing change over time than getting an accurate number for reporting but in the absence of other options it is better than nothing. +Where the application on the PaaS platform makes use of additional services such as a managed DB or queue, then measurement becomes further complicated. + +One option is to use the aforementioned SaaS methods and don't break out the DB as a separate estimate. In other words, just consider the end-to-end request time or data sent. This is likely to be less accurate but is simpler as a first approximation. Where there is a preference to actually measure the end-to-end request handling, including both app server and data services, then there are a few possible scenarios: + +| **Scenario** | **Options** | +| ------------ | ----------- | +| Bespoke DB provided by cloud service providers like GCP that provides carbon reporting | Use the vendor carbon reporting or a tool like Cloud Carbon Footprint | +| Bespoke DB with no carbon reporting, e.g., Salesforce Platform's data layer | Could run with a similar DB, e.g., Postgres, for a very approximate measurement as a Docker image alongside the application code that calls it. But it would need changes to the application where there's no API-compatible option, so not always practical | +| Standard DB provided as a managed service | Run a dockerised or a cloud-provided version to run with the app code. | + +Note that when running something like a database in Docker to estimate the energy usage of a request, the set is much simpler with a single local DB instance vs a cluster across multiple sites and machines for the PaaS one, and so the real DB may differ significantly. The value is better for observing change over time than getting an accurate number for reporting, but in the absence of other options, it is better than nothing. \ No newline at end of file diff --git a/pages/information/saas.md b/pages/information/saas.md index 82063df..0dcd76e 100644 --- a/pages/information/saas.md +++ b/pages/information/saas.md @@ -8,137 +8,78 @@ published: false # Software as a Service (SaaS) SaaS is application software that is provided as a remote service by a vendor, usually including a web interface but can also include mobile and/or other UIs or be an API-only service. -The differentiating factor compared to Cloud IaaS is that there's no physical or virtual infrastructure to be managed so dev-ops concerns such as OS updates, server provisioning and scaling are all managed by the service provider. Further, unlike PaaS there is no app development/deployment/testing to be managed. - -There's tens of thousands of examples of SaaS products but a few well known ones include: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AreaExamples
Authentication providersAuth0, Okta
CRM ProvidersSalesforce, Microsoft Dynamics
Data Warehousing solutionsSnowflake, Databricks
ProductivityOffice 365, Google Docs
Development supportGithub, Gitlab, JIRA Cloud
AccountingQuickBooks, Sage
PaymentsStripe, Adyen
- -This page focuses specifically on SaaS but be aware that some providers such as Salesforce also span the Platform as a Service (PaaS) space where they provide a platform to run apps as well as providing SaaS apps running on that platform such as the core Salesforce CRM app. Similarly cloud platforms such as AWS, Azure and GCP mainly provide cloud Infrastructure as a Service in the form of VMs and networks and storage but also provide many SaaS products that run on that infra. +The differentiating factor compared to Cloud IaaS is that there is no physical or virtual infrastructure to be managed so dev-ops concerns such as OS updates, server provisioning and scaling are all managed by the service provider. Further, unlike PaaS there is no app development/deployment/testing to be managed. + +There are tens of thousands of examples of SaaS products but a few well known ones include: + +| **Area** | **Examples** | +| - | - | +| Authentication providers | Auth0, Okta | +| CRM Providers | Salesforce, Microsoft Dynamics | +| Data Warehousing solutions | Snowflake, Databricks | +| Productivity | Office 365, Google Docs | +| Development support | Github, Gitlab, JIRA Cloud | +| Accounting | QuickBooks, Sage | +| Payments | Stripe, Adyen | + + +This page focuses specifically on SaaS but be aware that some providers such as Salesforce also span the Platform as a Service (PaaS) space where they provide a platform to run apps as well as providing SaaS apps running on that platform such as the core Salesforce CRM app. Similarly, cloud platforms such as AWS, Azure and GCP mainly provide cloud Infrastructure as a Service in the form of VMs and networks and storage but also provide many SaaS products that run on that infrastructure. {% include linkedHeading.html heading="SaaS Categories" level=2 %} On the main TCS graphic SaaS appears under Category C as operational emissions from an organisation delivering a service, albeit indirect ones where a third party has been employed to deliver part of the service. In additional to this there may be Category D and Category O emissions associated with SaaS. -**Category O** Where a SaaS product has a front end component that is used by members or employees of an organisation then the use of the front end on a laptop or mobile device will incur operational emissions - typically Scope 2 from the organisation electricity but can also be Scope 3 where the user is working remotely. +**Category O** Where a SaaS product has a front-end component that is used by members or employees of an organisation, then the use of the front-end on a laptop or mobile device will incur operational emissions - typically Scope 2 from the organisation's energy use but can also be Scope 3 where the user is working remotely. -**Category D** Where a SaaS product has a front end component that is used by end users, e.g. public consumers, then the use of the front end on a laptop or a mobile device will incur downstream emissions. +**Category D** Where a SaaS product has a front end component that is used by the end-users, e.g. public consumers, then the use of the front-end on a laptop or a mobile device will incur downstream emissions. {% include linkedHeading.html heading="Why does SaaS matter" level=2 %} -The use of SaaS has been growing rapidly over the last decade1 and is expected to continue to do so. Statista has it as growing from 30Bn to 200Bn in just under ten years globally and this means it makes up an important part of technology emissions. +The use of SaaS has been growing rapidly over the last decade[^1] and is expected to continue to do so. Statista has it as growing from 30Bn to 200Bn in just under ten years globally and this means it makes up an important part of technology emissions. -Cloud Zero references a State of SaaS report that has companies with <500 employees using over 200 SaaS products whereas Dev Squad reports slightly different 130 products per company (no size specified so likely an average across all). They also state that "70% of software used by today's companies are SaaS". +Cloud Zero references a State of SaaS report that has companies with < 500 employees using over 200 SaaS products whereas Dev Squad reports slightly different 130 products per company (no size specified so likely an average across all). They also state that "70% of software used by todays companies are SaaS". -Whatever the precise numbers it is clear that companies use a lot of SaaS products and in fact they often make up a significant majority of all the tech products. This means that if one only looks at on-prem and cloud resources then it's likely a significant amount or even majority of tech emissions will be missed. +Whatever the precise number it is clear that companies use a lot of SaaS products and in fact they often make up a significant majority of all the tech products. This means that if one only looks at on-prem and cloud resources then it's likely a significant amount or even majority of tech emissions will be missed. {% include linkedHeading.html heading="The potential of SaaS for sustainability" level=2 %} -SaaS products have a couple of potential sustainability advantages over in-house created and operated software: multi-tenancy and no development+support duplication. This assumes all else being equal such as the SaaS vendor's data centre being of a similar carbon intensity or less than any data centres or cloud services that the purchasing org is using. +SaaS products have a couple of potential sustainability advantages over in-house created and operated software: multi-tenancy and no development + support duplication. This assumes all else being equal such as the SaaS vendor's data centre being of a similar carbon intensity or less than any data centres or cloud services that the purchasing organisation is using. ### Multi-tenancy SaaS products are typically multi-tenant where many users share the same servers and database. This means that infrasture will typically be heavily utilised and won't have periods of doing no work like a dedicated physical server or even dedicated cloud VM might. -How much of an advantage this is depends on how an org runs software. Where an organisation uses dedicated hardware for an application then there is likely a notable gain here. On the other hand where an application cluster like Kubernetes is used then the advantage is less because this also permits high utilisation. Even so, use of SaaS generally ensures all components including the DB are shared which isn't always the case for in-house cloud apps. +How much of an advantage this is depends on how an organisation runs software. Where an organisation uses dedicated hardware for an application then there is likely a notable gain here. On the other hand where an application cluster like Kubernetes is used then the advantage is less because this also permits high utilisation. Even so, the use of SaaS generally ensures all components including the DB are shared, which isn't always the case for in-house cloud apps. There are exceptions where this dosn't apply; somtimes for regulatory reasons an organisation may have their own instance of the SaaS stack or parts of it and so resources may be under utilised even for a SaaS product. ### No development duplication -By using a SaaS product rather than creating and/or running it's own software an organistion is avoiding duplicated effort that would include the writing of code, support of that code and build/deployment. In short this means less people (and so typically less offices), less supporting software, less laptops and other hardware like build machines. - -Put another way, the development, deployment and maintenance of software comes with an environmental cost as well as the running of software and so if many orgs make use of a single SaaS product then this is only incurred once rather than per org. +By using a SaaS product rather than creating and/or running it's own software, an organistion is avoiding duplicated effort that would include the writing of code, support of that code and build/deployment. In short this means less people (and so typically less offices), less supporting software, less laptops and other hardware like build machines. +Put another way, the development, deployment and maintenance of software comes with an environmental cost as well as the running of software and so if many organisations make use of a single SaaS product then this is only incurred once rather than per organisation. {% include linkedHeading.html heading="Measuring SaaS" level=2 %} -The nature of SaaS makes me problematic for working out the emissions related to a single org's activities; the very point of SaaS is that the implementation is hidden and not something that the user needs to know about. Further, as already mentioned, it is usually multi-tenant which means many organistions are sharing the same hardware. This wouldn't be a problem if the SaaS provider dealt with this and gave each organisation the emissions attributable to them, but unfortunately at the moment SaaS providers don't generally provide this attribution. A sample of ten well known SaaS providers including some of the examples mentioned above was looked at and although many had sustainability policies and reported on their own total emissions they don't break this down and provide each consumer with the individual consumer's proportion of the org's emissions. +The nature of SaaS makes measuring problematic for working out the emissions related to a single organisation's activities; the very point of SaaS is that the implementation is hidden and not something that the user needs to know about. Further, as already mentioned, it is usually multi-tenant which means many organistions are sharing the same hardware. This wouldn't be a problem if the SaaS provider dealt with this and gave each organisation the emissions attributable to them, but unfortunately at the moment SaaS providers don't generally provide this attribution. A sample of ten well known SaaS providers including some of the examples mentioned above were looked at and although many had sustainability policies and reported on their own total emissions they don't break this down and provide each consumer with the individual consumer's proportion of the org's emissions. -The reason for this is that it is challenging to do whether a SaaS vendor runs in the cloud or on-prem. Hundreds or thousands of consumers of a SaaS service may all be hitting the same application services and databases but physical hardware and cloud energy measurement can only be done at the machine level meaning it's very difficult for vendors to attribute. Proxy measures could be used such as number of API requests per consumer but thre's issues here such as not all requests being equal in energy usage. Therefore it is unlikely that SaaS vendors will start providing per consumer carbon reports until the tooling improves. +The reason for this is that it is challenging to do whether a SaaS vendor runs in the cloud or on-prem. Hundreds or thousands of consumers of a SaaS service may all be hitting the same application services and databases but physical hardware and cloud energy measurement can only be done at the machine level meaning it's very difficult for vendors to attribute. Proxy measures could be used such as number of API requests per consumer but there are issues here such as not all requests being equal in energy usage. Therefore it is unlikely that SaaS vendors will start providing per consumer carbon reports until the tooling improves. Given these challanges, for now it falls on the consumer of a SaaS service to to obtain carbon emissions to approximate the emissions associated with its use of the serice. There is no official government or GHG Protocol recommended way to do this but a few options are presented shortly. These are just suggestions and its important that whatever approach is taken there's transparency about the method. Before going into some of the possibilites it's useful to think about what information is available for use of SaaS. {% include linkedHeading.html heading="The data available" level=3 %} -If a SaaS product is effectively a black box then this raises the question of what data, if any is available tha could help in a CO2 emissions estimation. +If a SaaS product is effectively a black box then this raises the question of what data, if any is available tha could help in a CO2e emissions estimation. The following table lists the main data points that may be available: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
FactHow it's known
Data transferredBrowser stats or metrics on backend to backend call
Front end emissionsMeasurement
Num of requests and request timesBrowser stats or metrics on backend to backend call
LocationService location often published as has regulatory implications. Also can be reverse looked up via IP (but could be misleading if intermediary like a CDN is inbetween the client and servers)
DatabaseMay be published in tech documents
High level architectureMay be published in tech documents
+| **Fact** | **How it's known** | +| - | - | +| Data transferred | Browser stats or metrics on backend to backend call | +| Front-end emissions | Measurement | +| Number of requests and request times | Browser stats or metrics on backend to backend call | +| Location | Service location often published as has regulatory implications. Also can be reverse looked up via IP (but could be misleading if intermediary like a CDN is inbetween the client and servers) | +| Database | May be published in tech documents | +| High level architecture | May be published in tech documents | The first 3 are the most likely to be known as they are fully in the control of the organisation using the SaaS product. Be aware that request time is not necessarily processing time and will depend on the location of the end user - this is discussed more later. @@ -146,13 +87,12 @@ Be aware that request time is not necessarily processing time and will depend on The final two items around tech implementation can help decide on any scaling factors and/or can be used to see how closely the SaaS service resembles some other known systems for which data can be obtained. In other words they can make an estimate slightly less naive and more rooted in reality. {% include linkedHeading.html heading="Measurement/estimation methods" level=3 %} -Given the data above there's a few methods available for measuring and estimating SaaS emissions. These are summarised below including some links to resources where available. In some cases there is no industry standard mechanism and expert help may be beneficial where the organisation isn't experienced in these measurements and approximations. - +Given the data above there are a few methods available for measuring and estimating SaaS emissions. These are summarised below including some links to resources where available. In some cases there is no industry standard mechanism and expert help may be beneficial where the organisation isn't experienced in these measurements and approximations. **Sustainable Web Design method** -This is an approximation method promoted by Sustainable Web Design (SWD) Community Group and published on sustainablewebdesign.org. The method is specifically about websites but parts of it can be adapted for other uses. It covers all aspects of a service from the front end through to embodied carbon on the server and although it provides one number as an output this can be split if only part of the estimate is of interest. The input to this method is the number of GBs transferred. +This is an approximation method promoted by Sustainable Web Design (SWD) Community Group and published on sustainablewebdesign.org. The method is specifically about websites but parts of it can be adapted for other uses. It covers all aspects of a service from the front-end through to embodied carbon on the server and although it provides one number as an output this can be split if only part of the estimate is of interest. The input to this method is the number of GBs transferred. **Shift Project 1 Byte method** @@ -169,14 +109,14 @@ An alternative way to capture the server emissions component, at least for synch -There is no common methodology in the literature for this but by assuming request structures like the above (ideally aided with some high level knowledge of the SaaS architecture) it may be possible to derive some very approximate numbers for the SaaS emissions. +There is no common methodology in the literature for this, but by assuming request structures like the above (ideally aided with some high level knowledge of the SaaS architecture) it may be possible to derive some very approximate numbers for the SaaS emissions. **Front-end only emissions** Many SaaS products include web and mobile interfaces that may be targetted at admin users and general users of the service and this part of the SaaS emissions. Although this is accounted for in the SWD and 1-Byte methods it can also be measured more accurately separately in standard ways such as: - * browser energy measurements, e.g. via Firefox profiler functions - * device measurements via a power meter +* browser energy measurements, e.g. via Firefox Profiler functions +* device measurements via a power meter These measurements aren't practical to do on all user devices all the time and so representative use cases should be found in order to carry out the measurements. @@ -187,4 +127,5 @@ Sometimes the work involved in fulfilling a request will be quite different to b Another example would be the use of a machine learning tool or analytics service such as Snowflake where an API call results in a very expensive query across all the data. In such cases different bespoke methodologies may be needed - this is obviously not easy to estimate and so a judgement call should be made as to whether the analysis is worth it, i.e. is the particular operation expensive enough and used often enough to significantly move the needle on the total emissions. Workflows with lots of waits, e.g. on human intervention are the most complex thing to analyse because of their stop start nature. Other causes such running an expensive query may be estimated via time to complete, rather than the API response time if this is visible and can be captured, e.g. via time for an email or some other notification to arrive saying the work is done. {% include linkedHeading.html heading="References" level=3 %} -1. https://www.fortunebusinessinsights.com/software-as-a-service-saas-market-102222 +[^1]: [https://www.fortunebusinessinsights.com/software-as-a-service-saas-market-102222](https://www.fortunebusinessinsights.com/software-as-a-service-saas-market-102222) + diff --git a/pages/views/roles/architecture.md b/pages/views/roles/architecture.md index 9693dbd..f735f96 100644 --- a/pages/views/roles/architecture.md +++ b/pages/views/roles/architecture.md @@ -13,7 +13,7 @@ As an architect you can exert significant influence on a company's tech carbon e - Setting the tech strategy - e.g. cloud vs on-prem, build vs buy - Promoting best practice and setting tech principles - e.g. princples around resilience, data retention etc + - e.g. princples around resilience, data retention etc - Leading technical selection, e.g. of a cloud vendor or a SaaS product - Architecture Design (from enterprise to technical) - Setting non-functional requirements (NFRs) diff --git a/pages/views/roles/architecture_nfrs.md b/pages/views/roles/architecture_nfrs.md index a2010b9..6a7c216 100644 --- a/pages/views/roles/architecture_nfrs.md +++ b/pages/views/roles/architecture_nfrs.md @@ -24,12 +24,9 @@ The architect is at the center of vendor selection and so can promote green requ {% include categoryItem.html item="CatUSoftware" id="Software" noLink=true %} - +- **Prefer a higher user base:** Adding NFR around user base size means you'll be getting something well tested and more likely to be supported but can also influence carbon emissions. If you pay an organisation to create bespoke software for you or train a bespoke model for you the incurred emissions will only benefit your user base. On the other hand adopting open source software used by 100 companies and their users means there's a small attribution to you and there's less duplicated work. The same applies for internal build vs buy although in this case there's *Category O* emissions and other non tech ones like buildings in [GHGP Scope 3](/glossary#greenhouse-gas-ghg-protocols). ### Hardware Manufacture, Transport and Installation @@ -38,69 +35,56 @@ The architect is at the center of vendor selection and so can promote green requ {% include categoryItem.html item="CatUServerHardware" id="ServerHardware" noLink=true %} NFRs for hardware embodied carbon should fall out of the strategy and based on the suggestions above would include items like: +- **Hardware lifetime (inc. support) >= 5 years:** Clear requirement for procurement on how long servers must work and for how long they should be supportable. +- **Laptop/Switch/Server should have < X embodied kgCO2e per Y.** You can relate embodied carbon to a scale factor y like throughput or number of ports on network equipment. - - -A software implementation NFR may also drive reduce embodied carbon: - - +A software implementation NFR may also reduce embodied carbon: +- **New service should add no embodied emissions:** requiring a new service to use no additional embodied carbon means it must run on existing hardware making use of spare capacity. ## Operational Emissions For operational emissions you can directly target energy or emissions with your NFRs or proxy measures that will still promote reduced emissions. An obvious example of the latter is - +- **VM/machine utilisation should be > 50%** + +When targetting carbon or energy, NFRs could include: -When targetting carbon or energy NFRs could include: - -Such an NFR pushes development teams to optimise their apps. It says carbon OR energy because you may wish to target both. Energy is comparable from day to day whereas carbon will depend on the electricity mix and you might want to choose regions to boost this alongside efficient code to minimise electricity. +- **Energy or carbon per service should be < X gCO2e:** Can go more or less granualar as needed and dependent on measurement sophistication, e.g. per API REST endpoint call. + +Such an NFR pushes development teams to optimise their apps. It says carbon **or** energy because you may wish to target both. Energy is comparable from day to day whereas carbon will depend on the electricity mix. You might want to consider carbon or grid awareness to reduce carbon intensity of energy alongside developing efficient code to minimise electricity. ### Direct {% include categoryLabel.html label="CatO" %} -At the level of the data centre NFRs could include the following. - +At the level of the data centre, NFRs could include the following: +- **Data centre [PUE](/glossary#power-usage-effectiveness-pue) should be < 1.3:** When building out a new data centre you can set a maximum Power Usage Effectiveness. That said, be wary of over using PUE without considering factors like water usage. +- **[Carbon intensity](/glossary#carbon-intensity) should be < X kgCO2e/kWh:** Setting an NFR around the carbon intensity of the electricty influences choices on location or installation of wind turbines or solar. + {% include categoryItem.html item="CatOEmployeeDevices" id="EmployeeDevices" noLink=true %} In the strategy section there were suggestions around selecting laptops with low energy usage and ensuring they switch to low power, sleep etc. A target for average daily kWh energy usage could be set to help meet these requirements e.g. - +- **Average energy consumption per 24 hours < X gCO2e** + {% include categoryItem.html item="CatONetworkDevices" id="NetworkDevices" noLink=true %} Again utilisation or power/carbon usage targets can be set: - +- **Network switch utilisation should be > 40%** +- **Power per port should be < 2W:** Power per Gbps throughput or per port could be targeted just as an embodied carbon can be also. + Some application targetted NFRs may also reduce network traffic and so reduce the need to have more network hardware - this benfits operational and embodied carbon. e.g. - +- **Data compression of 50% vs raw text in API payloads:** promote zipping and/or efficient protocols like gRPC +- **Normalise async messages, no one-to-many entity to message mappings:** avoids one entity change causing a storm of messages {% include categoryItem.html item="CatOServers" id="Servers" noLink=true %} You can set utilisation targets for each server as per above but also go more granular. e.g. - +- **Hardware utilisation should be > 50%** +- **Servers must be energy observable via the network:** Really a function requirement but allows monitoring of progress in energy efficiency + {% include categoryLabel.html label="CatG" %} @@ -111,57 +95,46 @@ You can set utilisation targets for each server as per above but also go more gr {% include categoryLabel.html label="CatC" %} When vendors are used then you can set NFRs around their electricity e.g. - -You may also set NFRs for carbon per unit of compute or request as well see below. Exactly what you can do will be very much dependent on the amount of information provided. This may itself be a criteria, who gives the most transparent information about their emissions. +- 30% electricity from renewable sources. + +You may also set NFRs for carbon per unit of compute or request as well, see below. Exactly what you can do will be very much dependent on the amount of information provided. This may itself be a criteria, who gives the most transparent information about their emissions. {% include categoryItem.html item="CatCCloud" id="Cloud" noLink=true %} -Be careful when comparising vendors using their tools/info as reporting norms may vary. NFRs could include: - -Note: When targetting regions or times of day via NFRs be aware of the risks - if everyone does it then it'll result in dispatchable power like gas being used. +Be careful when comparing vendors using their tools/info as reporting norms may vary. NFRs could include: +- **Prefer compute with < gCO2e per core:** Pushes CPUs with lower power, e.g. ARM or CPUs powered by more renewable energy, e.g. in a different region. Be careful to weigh according to CPU power though - clock frequencies and processing capacity will vary. +- **Create no emissions when no requests are being handled:** Pushes the use of scale down or lambdas whilst not forcing an implementation. + +Note: When targeting regions or times of day via NFRs be aware of the risks - if everyone does it then it'll result in dispatchable power like gas being used. {% include categoryItem.html item="CatCSaas" id="Saas" noLink=true %} It's hard to set NFRs for SaaS because many orgs don't report emissions or when they do comparison is hard, e.g. if user bases are very different. Ideally you'd derive (or the vendor would provide) something like: - -but in reality the most you may be able to do is compare their strategies or where their data centres/cloud regions are. e.g. - +- carbon per user should be < X gCO2e + +But in reality the most you may be able to do is compare their strategies or where their data centres/cloud regions are. e.g. +- Service hosted in region with carbon intensity < X gCO2e/kWh The exception is where you're given dedicated resources in which case reporting may be possible. e.g. if they deploy some AWS instances for you and you can measure per request. {% include categoryItem.html item="CatCManaged" id="Managed" noLink=true %} -Consider NFRs like - +Consider NFRs like: +- **PUE < 1.3:** For when selecting a managed service. +- **Utilisation <= 50%:** Like cloud, at the level of VMs. {% include categoryLabel.html label="CatD" %} -End user devices like customer laptops are out of our control but there are NFRs that can be set around the apps running on them and for battery powered devices low carbon usage has the added benefit of aiding battery life. +End user devices like customer laptops, these are out of our control but there are NFRs that can be set around the apps running on them. For battery powered devices, low energy usage has the added benefit of aiding battery life. {% include categoryItem.html item="CatDEndUserDevices" id="EndUserDevices" noLink=true %} -NFRs for devices are one of the easier things to set and test because although you can obtain real representative hardware to do measurements. Possible NFRs are: - +NFRs for devices are one of the easier things to set and test because you can obtain real representative hardware to do measurements. Possible NFRs are: +- **Single page view uses < X kWh:** Promote pages that don't use unneccessary energy. +- **No energy usage when user not on page:** Ensure that no energy is used when the user is not on a webpage. Note: modern browsers will help enforce this anyway. {% include categoryItem.html item="CatDNetworkDataTransfer" id="NetworkTransfer" noLink=true %} You can't control the network but can affect the amount of data transferred over it. e.g. you could have - \ No newline at end of file +- **2nd API call uses 80% of 1st when data hasn’t changed:** Promotes caching \ No newline at end of file diff --git a/pages/views/roles/architecture_strategy.md b/pages/views/roles/architecture_strategy.md index 9541056..6116c54 100644 --- a/pages/views/roles/architecture_strategy.md +++ b/pages/views/roles/architecture_strategy.md @@ -24,53 +24,53 @@ The architect is at the center of vendor selection and so can promote green requ - Set strategy around COTS/OSS vs in-house - Set principle to prefer green vendors -All software creation comes with a cost and the first thing you might decide to do is to trade off open source and COTS software against in-house. Some of the in-house software carbon costs are out of the scope in this standard because they are non-technology items like buildings and transport for employees. Still they count in the overall picture of your org and if 1 company creates software that's less emissions than if 20 companies all create the same software. You may also wish to prefer vendors who report on their emissions and follow sustainability best practices in order to push software and machine learning model creators to be more sustainable. e.g. training models with renewable electricity. +All software creation comes with a cost and the first thing you might decide to do is to trade off open source and COTS software against in-house. Some of the in-house software carbon costs are out of the scope in this standard because they are non-technology items like buildings and transport for employees. Still, they count in the overall picture of your organisation and if one company creates software thats less emissions than if 20 companies all create the same software. You may also wish to prefer vendors who report on their emissions and follow sustainability best practices in order to push software and machine learning model creators to be more sustainable. e.g. training models with renewable electricity. ### Hardware Manufacture, Transport and Installation {% include categoryItem.html item="CatUEmployeeHardware" id="EmployeeHardware" noLink=true %} {% include categoryItem.html item="CatUNetworkHardware" id="NetworkHardware" noLink=true %} {% include categoryItem.html item="CatUServerHardware" id="ServerHardware" noLink=true %} -Any hardware you buy in or acquire from data centre servers to employee laptops required energy produced emissions in manufacture and transport. Not all architects will get involved in hardware selection - servers and network equipment may fall under data centre architects for example. Where you do though you can apply pressure to ensure there is a low carbon strategy for: +Any hardware you buy in or acquire; from data centre servers to employee laptops, required energy produced emissions in manufacture and transport. Not all architects will get involved in hardware selection - servers and network equipment may fall under data centre architects for example. Those that do though you can apply pressure to ensure there is a low carbon strategy for: - Renewal cycles: i.e. how often we should replace hardware. Less hardware bought per year is less emissions. -- Recycling. Check the criteria under which your current disposal partners were selected and if recycling and low energy usage were not considerations make sure they are next time the contrcats come around. -- Procurement. Do the procurement teams understand the emissions with each item they supply? If not kick-off an initiative to look at this and ensure equipment is bought with a known embodied carbon and ideally a target to keep it under. +- Recycling: Check the criteria under which your current disposal partners were selected and if recycling and low energy usage were not considerations make sure they are next time the contracts come around. +- Procurement: Do the procurement teams understand the emissions with each item they supply? If not kick-off an initiative to look at this and ensure equipment is bought with a known embodied carbon and ideally a target to keep it under. Consider refreshed hardware; reused, refurbished or remanufactured. ## Operational Emissions -Whether you are running in the cloud or on-prem architects can promote architectural patterns and ways of using resources to minimise day to day energy usage. This might include requiring use of efficient APIs such as gRPC, sharing resources as much as possible, carbon aware computing and having data dormancy strategies so data isn't held and stored later than needed. These may also have benefits on resilience, cost and compliance and the architect should take a holistic view. +Whether you are running in the cloud or on-prem, architects can promote architectural patterns and ways of using resources to minimise day to day energy usage. This might include requiring the use of efficient APIs such as gRPC, sharing resources as much as possible, carbon aware computing and having data dormancy strategies so that data is not held and stored longer than needed. These may also have benefits on resilience, cost and compliance and the architect should take a holistic view. -They will work with dev-ops or developers or date centre engineers on tech strategies and should ensure carbon emissions are parts of those strategies. +Architects will work with dev-ops, developers or data centre engineers on technology strategies and should ensure carbon emissions are part of those strategies. -Observability is a key part of technical strategy that requires a joined up approach between dev-ops, development and operations and architects should promote energy observability as part of this. +Observability is a key part of technical strategy that requires a joined up approach between dev-ops, development and operations, and architects should promote energy observability as part of this. ### Direct {% include categoryLabel.html label="CatO" %} -In the embodied section we talked about hardware selection maximising lifetime and having low manufacture emissions. Procurement strategy should also include observability and emissions in use. Accurate energy obserability (and thus carbon monitoring) is not possible without hardware support and so this must be a consideration when selecting hardware for the data centre. +In the embodied section we talked about hardware selection, maximising lifetime and having low manufacture emissions. Procurement strategy should also include observability and emissions in use. Accurate energy observability (and thus carbon monitoring) is not possible without hardware support and so this must be a consideration when selecting hardware for the data centre. {% include categoryItem.html item="CatOEmployeeDevices" id="EmployeeDevices" noLink=true %} -Where architects are involved in workforce IT like employee devices there's a few areas they can influence: +Where architects are involved in workforce IT, such as employee devices, there's a few areas they can influence: -- Like servers and other infra prefer devices with low operational power, e.g. an ARM chip device if an option. -- Put requirements on device power management. Ensure there is proper testing of device configuration such that laptops run in low power modes when with low activity and go to sleep quickly. -- Device a strategy for device power monitoring which would make carbon reporting much easier and allow improvements in devices or their configuration to be observed over time. +- Servers and other infrastructure; prefer devices with low operational power, e.g. an ARM chip device if an option. +- Put requirements on device power management; ensure there is proper testing of device configuration such that laptops run in low power modes with low activity and go to sleep quickly. +- Devise a strategy for device power monitoring which would make carbon reporting much easier and allow improvements in devices or their configuration to be observed over time. {% include categoryItem.html item="CatONetworkDevices" id="NetworkDevices" noLink=true %} -As with servers, architects can add usage emissions to the procurement evaluation criteria. Architects can help translate business growth requirements into expected data transfer needs and ensure the correct size of networking hardware is selected that is well utilised. Typically networking hardware doesn't scale down in power in the way standard servers do and so under utilised hardware will have a heavier cost. +As with servers, architects can add usage emissions to the procurement evaluation criteria. Architects can help translate business growth requirements into expected data transfer needs and ensure the correct size of networking hardware is selected that is well utilised. Typically networking hardware does not scale down in power in the way standard servers do and so under utilised hardware will have a heavier cost. -Where there's virtual networking functions running purely as software the same utilisation concerns apply as with any application - maximise software, albeit traded off against maximum latency and contention needs, i.e. promote the virtualisation (in software sense of the word) of the software networking appliances. +Where there is virtual networking functions running purely as software the same utilisation concerns apply as with any application - maximise software, albeit traded off against maximum latency and contention needs, i.e. promote the virtualisation (in software sense of the word) of the software networking appliances. Having application principles to minimise data transfer can reduce the amount of network traffic and even if this makes only a small reduction to the energy usage of switches and routers it may slow the need to add more hardware during growth. e.g. gRPC, persistent TCP connections. -Patterns like multi-cast for video can be pursued to reduce network capacity needs in the data centre (and ISP). Similarly large file transfers can be architected to take the most direct route without intermediary systems reducing network emissions and costs. A preference for larger more monolithic applications may also reduce network traffic - but can have other costs. +Patterns like multi-cast for video can be pursued to reduce network capacity needs in the data centre (and ISP). Similarly, large file transfers can be architected to take the most direct route without intermediary systems reducing network emissions and costs. A preference for larger more monolithic applications may also reduce network traffic - but can have other disadvantages. {% include categoryItem.html item="CatOServers" id="Servers" noLink=true %} -As well as the general application design patterns senior architects can drive virtualisation strategy for on-prem. For example they could create a plan for containerisation of workloads (e.g. to Kubernetes) and a migration plan in order to maximise the utilisation of on-prem hardware. +As well as the general application design patterns, senior architects can drive virtualisation strategy for on-prem. For example, they could create a plan for containerisation of workloads (e.g. to Kubernetes) and a migration plan in order to maximise the utilisation of on-prem hardware. {% include categoryLabel.html label="CatG" %} @@ -80,13 +80,13 @@ As well as the general application design patterns senior architects can drive v {% include categoryLabel.html label="CatC" %} -All the indirect solutions involve a vendor and so it is important that architects, where involved in vendor selection include carbon non functional requirements. This should include both how the vendor reports emissions but also the level of their emissions and how "green" their electricity is. +All the indirect solutions involve a vendor and so it is important that architects, where involved in vendor selection include carbon non-functional requirements. This should include both how the vendor reports emissions but also the level of their emissions and how "green" their electricity is. {% include categoryItem.html item="CatCCloud" id="Cloud" noLink=true %} -The architect can set principles and present patterns for sustainable application development as per on-prem. In addition they may require the use of cloud spefific patterns where applicable such as the use of serverless for infrequently used applications. +The architect can set principles and present patterns for sustainable application development as per on-prem. In addition they may require the use of cloud specific patterns where applicable such as the use of serverless for infrequently used applications. -The principle of observability remains the same and should be a key technical principle pushed down from architects. For cloud the architect must find different models to assess cloud energy usage in the absence of hardware monitoring and may recruit data science teams to support this. +The principle of observability remains the same and should be a key technical principle pushed down from architects. For cloud, the architect must find different models to assess cloud energy usage in the absence of hardware monitoring and may recruit data science teams to support this. {% include categoryItem.html item="CatCSaas" id="Saas" noLink=true %} @@ -96,7 +96,7 @@ Technical principles should also apply for the use of a vendor service as much a {% include categoryItem.html item="CatCManaged" id="Managed" noLink=true %} -As well as vendor selection and good software design patterns there may be options to improve utilisation as with on-prem, e.g. devising a containerisation strategy to better utilise vendor provided virtualisation. Where the service is data related principles around data retention can reduce emissions. +As well as vendor selection and good software design patterns there may be options to improve utilisation as with on-prem, e.g. devising a containerisation strategy to better utilise vendor provided virtualisation. Where the service is data related, principles around data retention can reduce emissions. {% include categoryLabel.html label="CatD" %}