At the time of his death in 1985 the ceaselessly inventive Italo Calvino was working on a series of lectures -- to be presented at Harvard University -- devoted to certain characteristics specific to literature that most resonated with his sensibilities, the characteristics he had hoped would continue to inspire and shape the literature of future. The five completed lecture notes -- titled "Lightness", "Quickness", "Exactitude", "Visibility", "Multiplicity" -- were published posthumously as "Six Memos for the Next Millennium" ("Consistency" being the unwritten one). These accessible yet irreducible pieces retain their freshness today: encyclopaedic knowledge of literature and startlingly original approaches to works iconic and unknown alike, elucidated in that inimitably limpid prose style.
Lightness. Quickness. Exactitude. Visibility. Multiplicity.
Any reasonably successful Software Architecture shares some of these qualities with great literature (especially the Novel which is deeply architectural in structure).
Lightness: agility, flexibility, extensibility, ease of installation and upgrade.
Quickness: optimized performance, responsiveness, fault-tolerance, rapid self-healing capabilities.
Exactitude: accuracy of information being presented, precise monitoring and optimized scaling.
Visibility: high availability, transparency into the current state of the system, repeatability and predictability, user persona driven usability experience.
Multiplicity is a more elusive quality. In Software Architecture as it is in literature. Calvino approaches multiplicity relatively more obliquely, letting the works he cites and passages he quotes speak for themselves. His references are drawn from a widely disparate set whose members are dissimilar in most aspects: Thomas Mann to Alfred Jarry, Borges to Georges Perec. From this dense orchestra of texts two prominent melodic voices distinguish themselves as easily recognizable: the multiplicity of relationships, in effect and in potential; and the multiplicity of representation and encoded knowledge.
An effective example of multiplicity of relationship in Software is the problem of optimized hosting in a Cloud environment. We choose AWS IaaS Cloud for this example but this pattern applies to other hosting environments as well, public cloud as well as on-premise cloud. Let us say there are N different VPCs -- each potentially with their unique Network topology, a special case being the topologies are isomorphic to each other -- and M different multi-tier applications (with their design time representation originally being encoded as CloudFormation Templates, leading to runtime Stacks, and for the sake of simplicity we assume that these Templates, of an arbitrary category EC2-Only, themselves do not create VPCs, but only provisions EC2 instances and manage corresponding Security Group, ELB entries etc.) are to be deployed and managed for optimal performance. M is a dynamically changing number dependent on usage demand, but typically a few orders of magnitude higher that N. N obviously has a strict upper bound: there can only be so many VPCs. Also the Set of potential CloudFormation Templates are not a closed one either -- based on use cases for newer types of Services and new Compute-Network-Storage requirements newer Templates would be written. Hence, to find an optimal deployment strategy no a priori determinations can be made about the affinity of a CloudFormation Stack to the VPC. Such a strategy must be willing to redeploy -- i.e., migrate -- a Stack from one VPC to another to optimize the cluster of VPCs holistically.
The actual algorithmic aspects of the solution are well-known and well-understood. However the better instances of Architecture and Design would accommodate a multiplicity in relationship between the VPC and the Stack which is often merely reduced to a "Hosting"/"Hosted" characterization: i.e., a VPC is the host for the Stack and hence is merely a container.
However, the effective capacity -- IP Address Pools, DNS entries, number of Security Groups and ELB entries etc. -- of a VPC is also dynamically impacted by the running Stacks that are being hosted. One might even say that this previous statement is a tautology given that "hosting" does imply the "host" sharing his finite resources with the "guest". May that it be, this inverse relation of impacting the capacity of the VPC in a multidimensional manner can be easily overlooked while modeling the system. Multidimensional because the impact is not only a quantitative factor by which the capacity decreases but the topological affinity of a VPC to a particular CloudFormation Template (i.e., the likelihood of that VPC being a good candidate, network usage and requirements wise, for a Stack that is spun off from the Template) also gets modified.
An effective architecture hence would not only encode the "VPC hosts Stack" relationship in the model of the system, but also the "Stack performs transformation X to VPC" relationship. Here, the X again would be a function of the CloudFormation Template from which the VPC is created, but also a template-ized idealization of the VPC itself.
An example: consider a CloudFormation Template T (of the type EC2-Only mentioned above ), a Stack S being spun off from it, and is being hosted on a VPC V. These are relationship modalities:
The multiplicity of representation and encoded knowledge finds well-known examples in Literature: Mann's "Magic Mountain" presents deep scientific knowledge of the world, a sure understanding of Eros and the power of mortality, a lyricism that is ironic and compassionate at the same time. Or Borges through his incisive (and effervescently entertaining) meditations on time, universe, imagination, knowledge continuously creates and subverts self-contained universes using the formal structures of a detective story.
The public facing model(s) -- APIs are the preeminent examples -- of a complex system bears the signature of a good architecture when the different modalities of "consumption" are all equally facilitated and represented.
The diagram below demonstrates such a semantic equivalence across API consumption paradigms: REST, pure HTTP, Remote Object API, Relational (RDBMS etc.) management, Command Line Interfaces.
Lightness. Quickness. Exactitude. Visibility. Multiplicity.
Any reasonably successful Software Architecture shares some of these qualities with great literature (especially the Novel which is deeply architectural in structure).
Lightness: agility, flexibility, extensibility, ease of installation and upgrade.
Quickness: optimized performance, responsiveness, fault-tolerance, rapid self-healing capabilities.
Exactitude: accuracy of information being presented, precise monitoring and optimized scaling.
Visibility: high availability, transparency into the current state of the system, repeatability and predictability, user persona driven usability experience.
Multiplicity is a more elusive quality. In Software Architecture as it is in literature. Calvino approaches multiplicity relatively more obliquely, letting the works he cites and passages he quotes speak for themselves. His references are drawn from a widely disparate set whose members are dissimilar in most aspects: Thomas Mann to Alfred Jarry, Borges to Georges Perec. From this dense orchestra of texts two prominent melodic voices distinguish themselves as easily recognizable: the multiplicity of relationships, in effect and in potential; and the multiplicity of representation and encoded knowledge.
An effective example of multiplicity of relationship in Software is the problem of optimized hosting in a Cloud environment. We choose AWS IaaS Cloud for this example but this pattern applies to other hosting environments as well, public cloud as well as on-premise cloud. Let us say there are N different VPCs -- each potentially with their unique Network topology, a special case being the topologies are isomorphic to each other -- and M different multi-tier applications (with their design time representation originally being encoded as CloudFormation Templates, leading to runtime Stacks, and for the sake of simplicity we assume that these Templates, of an arbitrary category EC2-Only, themselves do not create VPCs, but only provisions EC2 instances and manage corresponding Security Group, ELB entries etc.) are to be deployed and managed for optimal performance. M is a dynamically changing number dependent on usage demand, but typically a few orders of magnitude higher that N. N obviously has a strict upper bound: there can only be so many VPCs. Also the Set of potential CloudFormation Templates are not a closed one either -- based on use cases for newer types of Services and new Compute-Network-Storage requirements newer Templates would be written. Hence, to find an optimal deployment strategy no a priori determinations can be made about the affinity of a CloudFormation Stack to the VPC. Such a strategy must be willing to redeploy -- i.e., migrate -- a Stack from one VPC to another to optimize the cluster of VPCs holistically.
The actual algorithmic aspects of the solution are well-known and well-understood. However the better instances of Architecture and Design would accommodate a multiplicity in relationship between the VPC and the Stack which is often merely reduced to a "Hosting"/"Hosted" characterization: i.e., a VPC is the host for the Stack and hence is merely a container.
However, the effective capacity -- IP Address Pools, DNS entries, number of Security Groups and ELB entries etc. -- of a VPC is also dynamically impacted by the running Stacks that are being hosted. One might even say that this previous statement is a tautology given that "hosting" does imply the "host" sharing his finite resources with the "guest". May that it be, this inverse relation of impacting the capacity of the VPC in a multidimensional manner can be easily overlooked while modeling the system. Multidimensional because the impact is not only a quantitative factor by which the capacity decreases but the topological affinity of a VPC to a particular CloudFormation Template (i.e., the likelihood of that VPC being a good candidate, network usage and requirements wise, for a Stack that is spun off from the Template) also gets modified.
An effective architecture hence would not only encode the "VPC hosts Stack" relationship in the model of the system, but also the "Stack performs transformation X to VPC" relationship. Here, the X again would be a function of the CloudFormation Template from which the VPC is created, but also a template-ized idealization of the VPC itself.
An example: consider a CloudFormation Template T (of the type EC2-Only mentioned above ), a Stack S being spun off from it, and is being hosted on a VPC V. These are relationship modalities:
- V hosts S
- S performs transformation X on V
- X = f( topology(T), idealized(V))
The multiplicity of representation and encoded knowledge finds well-known examples in Literature: Mann's "Magic Mountain" presents deep scientific knowledge of the world, a sure understanding of Eros and the power of mortality, a lyricism that is ironic and compassionate at the same time. Or Borges through his incisive (and effervescently entertaining) meditations on time, universe, imagination, knowledge continuously creates and subverts self-contained universes using the formal structures of a detective story.
The public facing model(s) -- APIs are the preeminent examples -- of a complex system bears the signature of a good architecture when the different modalities of "consumption" are all equally facilitated and represented.
The diagram below demonstrates such a semantic equivalence across API consumption paradigms: REST, pure HTTP, Remote Object API, Relational (RDBMS etc.) management, Command Line Interfaces.
No comments:
Post a Comment