...a big server (aka vertical scaling)...
.. a cluster of servers (aka horizontal scaling)...
.. or even a compute grid (horizontal scaling on steroids).
For resiliency we can have active-passive...
... or active-active...
... or replication in a cluster or grid...
...each with their own connectivity, load-balancing and routing concerns.
From a logical perspective we could have a simple client-server setup...
...a two tier architecture...
...an n-tier architecture...
...a service oriented (micro- or ESB) architecture...
...and so on.
And in each environment we can have different physical topologies depending on the environmental needs with logical nodes mapped to each environments servers...
With our functional components deployed on our logical infrastructure using a myriad of other deployment topologies..
... or ...
... and on and on and on...
And this functional perspective can be implemented using dozens of design patterns and a plethora of integration patterns.
With each component implemented using whichever products and packages we choose to be responsible for supporting one or more requirements and capabilities...
So the infrastructure we rely on, the products we select, the components we build or buy; the patterns we adopt and use... all exist for nothing but the underlying requirement.
We should therefore be able to trace from requirement through the design all the way to the tin on the floor.
And if we can do that we can answer lots of interesting questions such as "what happens if I turn this box off?", "what's impacted if I change this requirement?" or even "which requirements are driving costs?". Which in turn can help improve supportability, maintainability and availability and reduce costs. You may even find your product sponsor questioning if they really need this or that feature...
No comments:
Post a Comment