Making informed decisions on design pattern adoption

Let’s take a look at the usual software engineering cycle. Leaving out the initial stages like scope definition, the engineers usually decide on a set of requirements that dictate what the product should do (functional) and how well should it do that (non-functional). We are using the term “engineers” to encapsulate the whole team of people that analyze, design, implement, deploy and support a product. Then comes one of the two points in the cycle where a decision can radically influence the outcome of the product, and more importantly, make or break the product. The architectural design. This is where the notion of design patterns emerges.

While every engineer can and does base their design decisions on their experience and available technologies, the diligent use of design patterns can give structure and, more or less, predictable outcomes on the fine grain design decisions.

There are a few resources that provide descriptions of the various patterns that could be adopted depending on the engineer’s requirements. Those can be roughly distinguished into vendor neutral and vendor specific patterns. Below we can find a small collection of such resources. A big part of this collection deals with patterns that are specific for cloud applications and, as you will probably notice with a first glance, all of the vendor specific patterns come from cloud providers. The DECIDE project dealing with multi-cloud applications being the main factor for that kind of specialization. The list is by no means exhaustive but, after a good parsing, you will notice that patterns tend to repeat themselves with small variations.

Vendor Neutral pattern resources

• C. Fehling, F. Leymann, R. Ralph, W. Schupeck and P. Arbitter, Cloud Computing Patterns: Fundamentals to Design, Build, and Manage Cloud Applications, Springer, 2014. (the results are available at http://www.cloudcomputingpatterns.org/)
• ARTIST Consortium, “The Artist Project,” 2014. Available: https://cordis.europa.eu/project/rcn/105117_es.html. [Accessed November 2018].
• B. D. Martino, “Semantic Techniques for Multi-cloud Applications Portability and Interoperability”. 
• T.-F. Fortiş and N. Ferry, “Cloud Patterns,” in Model-Driven Development and Operation of Multi-Cloud Applications: The MODAClouds Approach, Springer International Publishing, 2017, pp. 107--112.
• P. Jamshidi, C. Pahl, S. Chinenyeze and X. Liu, “Cloud Migration Patterns: A Multi-Cloud Architectural Perspective,” 10th International Workshop on Engineering Service-Oriented Applications, 11 2014. 
• Arcitura Education Inc., “CloudPatterns.org,”. Available: http://www.cloudpatterns.org/.

Vendor specific pattern resources

• “AWS Cloud Design Patterns”. Available: http://en.clouddesignpattern.org.
• “Microsoft Azure Cloud Design Patterns” Available: https://docs.microsoft.com/en-us/azure/architecture/patterns/.

Smart utilization of the pattern resources is key to designing products that can fulfill the functional requirements in a consistent and manageable way. It is also always prudent to exploit past experience and knowledge before starting to experiment on ourselves.

On the other hand, design patterns do have an impact on the non-functional properties of the product which unfortunately cannot be measured in any kind of precision. Phrases like “Eventual consistency gives higher performance by reducing the number of replicas that need to accessed during r/w operations” and “Synchronized operating state via heartbeat signals can improve availability when no clustering technology is available” are correct but do not give precise measurement on the impact on each non-functional property.

In general, design patterns can and do impact the non-functional properties of the product BUT measuring the impact and, more importantly, choosing the correct combination based on the product’s non-functional requirements is not a trivial task and is usually done based on the engineer’s experience and knowledge.

One of the goals of the DECIDE project is to help with this decision via the tool called ARCHITECT.

The way that the tool fulfills its purpose is dual. First, it provides a repository of the more impactful design patterns for multi cloud applications for the engineer to choose and pick from. This repository has all the basic content that describes the design pattern and (since the majority of those patterns come from the aforementioned sources) links to the original source for further study.

One important addition to the repository is that each pattern has additional properties that describe the qualitative (and in some cases quantitative) impact of each pattern to a non-functional property. This gives to the human or the machine (the tool itself) a valuable piece of information so that he/she/it can reason which set of patterns is suitable for the product based on its non-functional requirements.

Additionally, the tool can suggest design patterns once the engineer adds the basic information about the product and its requirements. Of course, those are merely suggestions and the humans is the one that needs to select and implement their product based on those patterns. We believe that this step gives a solid foundation on the software engineering cycle while also allowing the rest of the DECIDE toolchain to work on the deployment part of the cycle (we will leave this part for a next blog post). In general…

ARCHITECT supports the engineers in making informed decisions on the architectural patterns that they should adopt based on their product’s non-functional requirements.