Compute Resource Consolidation Pattern

Introduction

Homer et al. (2014, 34) suggest the use of the Compute Resource Consolidation Pattern to reduce costs when multiple computational units are charged uniformly in spite of low usage.

Problem

According to Homer et al. (2014, 34), some applications that follow the design principle of separation of concerns result in an architecture in which various pieces of discrete computational units are hosted and deployed individually. This strategy “can increase runtime hosting costs and make management of the system more complex”. Furthermore, Homer et al. (2014) add: “Each computational unit consumes chargeable resources, even when it is idle or lightly used. Therefore, this approach may not always be the most cost-effective solution”.

Solution

The solution proposed by Homer et al. (2014, 35) is simply to “consolidate multiple tasks or operations into a single computational unit”. In terms of implementation, the recommendation is to identify tasks that have a similar profile in terms of scalability, lifetime, and processing requirements.

As an example of identifying tasks that can be grouped together, Homer et al. (2014) suggest to look at the difference between tasks that require high-scalability in reaction to high-volume bursts of network traffic and those that poll for infrequent, time-insensitive messages sent to a queue.

Considerations

Given the sheer number of caveats and assumptions mentioned by Homer et al. (2014, 35–36), the author’s opinion is that, in most cases, this is an anti-pattern except in the concrete scenario of traditional IaaS-based cloud computing service in which the deployable (and chargeable) units of computation are of relatively coarse granularity. For example, it is hard to see why a pattern like this would be applied when using micro-virtualisation technology such as Docker.¹

• Scalability Property: Since scalability and elasticity normally apply to a given deployable computational unit, this property is what needs to be taken into account when identifying consolidation opportunities.

• Recycling of the Virtual Environment: In the case of a consolidated unit that runs multiple tasks, a mechanism must be in place to prevent the virtualisation or cloud infrastructure from recycling the environment until all the tasks have completed.

• Deployable Artefact Boundary: All tasks consolidated into a single computational unit are bound to the same life cycle when performing actions such as stop, redeploy and restart.

• Security Boundary: The security context that applies to the consolidated computational unit may apply indiscriminately to all tasks.

• Fault Isolation Boundary: A fault in one task within a consolidated computational unit may affect other tasks as well.

• Contention: Tasks within a consolidated computation unit should consume resources and behave from a time and space perspective in a similar manner. This criteria should have been used to consolidate the tasks in the first place.

• Increased Complexity: Consolidating tasks into a single computational unit may make them harder to test, debug, and maintain.

References

Homer, Alex, John Sharp, Larry Brader, Masashi Narumoto, and Trent Swanson. 2014. Cloud Design Patterns: Prescriptive Architecture Guidance for Cloud Applications. Microsoft. https://msdn.microsoft.com/en-us/library/dn568099.aspx?f=255.

Before You Leave