User:Zha Ewry/AWG: Desiderata for evaluating the proposed design

This page captures some of the criteria I think would help evaluate proposed architecture designs

This is a work in progress

The page captures, in outline form some of the criteria we might use to evaluate choices in the architecture process. They are probably not earth shattering, but they should provide a nice starting point for discussion on how we make sure that what is being proposed is viable and well structured.

Separation of concerns

This bucket includes looking at whether we have properly separated out the various parts of the system, and possibly, clustered them sensibly.

• Can we run a coherent system with as many services removed? In particular, can we pull services and only lose the functionality directly provided by the service?

• Can we run the service or of services as a standalone service, without the rest of the system to support it?

• Can we plug replace the service with a different version of the service?

• Can we run multiple copies of the service in the system?

• Are the services individually scalable, along each axis of scalability relevant to them as we want?Can we run any service which is belonged to our service clusters and has free time?

• Are the services coupled scalably, along each axis of scalability for the architecture as a whole?

Overall, all of these tests circle around making sure that we are keeping services, or small clusters of services as free from entanglement in other services as possible.

Is there an existing solution

This bucket asks the basic question, is there an existing, public, usable solution to the problem/use case being solved by a portion of the design.

• Is there a public standard

• Is there a public, open source implementation of the possible solition

• Does the solution (proposed in this design and/or in an existing specification/design) inter-operate well with the rest of the proposed design

Packaging in different collections / Variations in coarse structure

This bucket suggests that we look at whether the choices being made permit or preclude bundling the service into a broad range of possible packagings. This applies both to the client/Services split, but also the splits into domains as currently suggested by Linde Labs.

• Permit combined client/sim build of the system
  • Host biased with a very lightweight client
  • Client biased, with locally simulated regions embedded
• Permit services and utilities to run within a single box buld

Plug and proxy models

This bucket asks questions about how the proposed api/contract/service/utility can be set up with a proxy/pluggable solution. It aims to drive the design towards services which can have multiple implementations behind a single programmatic facade, or proxied to a delegated service. (Can we fold this in with separation of concerns?)

• Can the service/api be proxied?

• Can I plug in multiple implementations behind the public contract of the service