Software Qualities
Software Architecture lives in quality, the hidden part which delights the customer
- TL;DR;
- It works for my service
- Quality is not an island
- Pause, lets look at some quality
- Rewind to the islands
- Lean on the platform? (a possible way forward)
- links
Functional features are things we discuss all the time while developing software, but what about its reliability or performance?
Software Qualities can be the difference of a great user experience or a product that breaks under pressure, leaks information. These things are important lets see how.
TL;DR;
- Services can impact one another, consider the big picture too
- What main qualties a service should consider.
- Qualities are getting easier to implement, i.e. serverless, can take care of some out of the box.
- you can leverage a common platform, in order to satisfy/improve a number of Software Qualities.
It works for my service
Lets setup a context, and we will use this to discuss.
We work on developing the Basket Service
Our Product owner says, we need to be
- up and running 24hours a day
- and we will have upto 300 request per second (this was a discussion, and we estimated it, but to be on the safe side we design to handle 400)
Finally we expose an API, using JSON, for a number of clients to call
At we are looking at a few Software Qualities: Reliability, Performance, and Compatibility.
This yeilds this picture:
WOOO HOO….. and we nailed it…. well no
Software is not an island.
Quality is not an island
Lets revisit the Basket service, once a customer has basket this will need to be turned into an actual order, update Next best buy, reserve stock (and maybe more)
We can observe that
- the other services also have Software Qualities.
- Software Qualties can be applied over a number of services as well as at the single service.
….
Pause, lets look at some quality
Software Quality, is also referred to as Non-Functional, or Ilities.
If we look at wikipedia, there are over 50, its daunting,
Lets be smart, and select a smaller subset, we can take the ISO 25010 as a sensible starting point, and look at qualites which we find valuable to our software
The above is based on the ISO, and we have missed out Functional, as that is a given in this context (for now).
Also we can see the
- there is a small higharchy, with 7 main areas, which group the qualities we are interested in
- in the basket example, we can see
Reliability,Performance, andCompatibility.
Rewind to the islands
In the simple example we put forward, our basket service and its peer services, we can see an interesting picture now form.
we can see a number of issues arise, to the point where can fail to meet our own measures as the peer to peer connected servcies may be down (either not running, or our service has overwhelmed them)
Lean on the platform? (a possible way forward)
Given an assumption that the down stream services will process at the same speeds (there may be some constraints)
Lets look at using a Event Broker (which could be delivered as part of the platform), to decople the services
The broker would be an extra concern, however the payoff allows the downstream services to process the messages at their own pace
by doing this change we have considered and improved
Reliability- basket can continue to work, even if the downstream services are downPreformance- baskest is not limited by down streamMaintainability- we have decoupled the services, making it more modularCompatability- all services use the same interchange (JSON)
overall our service will appear to have more Quality.
