ˈpætɚns
Image source https://vecteezy.com/
Recap
In the first article, we discussed the need for patterns as an architectural paradigm, in order to achieve re-usability across complex environments such as Hybrid Cloud scenarios. We identified the benefits of a pattern based approach. We talked about automation, Hybrid Cloud, and about organizational aspects
We’ve learned that patterns are what you need beyond just using technology. And that patterns help you for doing a quick-start, without the need for re-inventing the wheel. Patterns are relevant for keeping control in complex automations, and now we will see what role automation can play when implementing patterns for the Hybrid Cloud.
Today, we will talk about how patterns help to get productive in the Hybrid Cloud, how patterns should look like, who is providing them, and whether there are Open Source patterns. And, last but not leased, are there patterns ready for production.
Challenges
Creating patterns is not always an easy task. On one side, they should match 100% on the individual requirements scenario. On the other hand, they shall be re-usable and applicable for as many use cases as possible. As a consequence, you need to find the right balance between perfect fit and general use.
Also, patterns are needed in different stages of a solution. They should not put too much restriction within a creative process (preferably during the design phase), but should on the other hand provide rock-solid, proven blueprints for the final system (i.e. the implementation of the solution).
Last but not least – as every asset – patterns have a life cycle, and have to address certain aspects such as applicability, maintainability, transparency, stability, resilience, or security. As a consequence, someone has to take care of them, ideally as part of a community process.
Community
As requirements and environments change, the pattern needs to be adapted and to be part of a feedback process. If this won’t happen, the pattern will decay over time and, finally, will become useless.
As already mentioned above, the common development and maintenance processes of Open Source communities are a good option for also creating, discussing, evaluating and maintaining patterns. In fact, patterns are (implicitly or explicitly) already a substantial part of every Open Source community project.
So why not transfer the whole pattern life cycle into a community process? Well, it depends. Patterns can be public, but sometimes patterns are not. Examples are things that need to be kept confidential, be it for business reasons, or security reasons, or because of regulations.
So there are situations, where patterns will probably not be public. But if they are, Open Source processes are the perfect choice for leveraging the converging knowledge and power of Open also for patterns.
Scope and levels of abstraction
As already mentioned in the first article on patterns, when dealing with patterns, you need to define the scope for the pattern. Outside the scope, the pattern probably won’t work. The scope or use case, can be a certain task, such as instantiating a Hybrid Cloud setup, but also a business case, such as using AI for the recognition of certain diseases, just from the existing diagnostic visual material.
The scope does not necessarily have to be a perfect match, the basic idea is that the pattern covers general aspects of a certain use case, but can be customized to your individual needs. Implementation on the basis of a pattern means, we will create something that is proven to work, but it probably will not be the full solution, although as much as possible will be covered.
Another aspect of patterns is that they may apply in different stages of an implementation process.
At the beginning of a solution design, it might be desirable to use a pattern with a high level of abstraction, describing the key business benefits, the logical architecture, and the flow and the dependencies within that system. The primary use for such patterns is to start describing the scenario and the solution on a high level, without going too much into implementation details. If you are dealing with multiple solution scenarios, these patterns may represent a solution portfolio, and as such, can be called Portfolio Architectures.
The next stage in general is to reify that Portfolio Architecture by identifying the suitable technology and components for the solution, so that you can build the whole solution, whether for proof of concept, for development setups, or for production. Again patterns can support in this step, which then are called Solution Patterns.
Portfolio Architectures and Solution Patterns can be created and paired for the same scenario or use case, covering different stages in the creation of the final solution.
Validation
When looking for existing patterns, either for the high level design phase with Portfolio Architectures, or for the implementation phase with Solution Patterns, you will have to find a choice among existing patterns. Naturally, you will ask whether the pattern is proven to work, whether it has been tested and documented, and whether the pattern is supported in a way that if something goes wrong, or simply needs guidance, help will be available.
If all this is the case for a Solution Pattern, we are talking about so-called Validated Patterns. Validated Patterns have a sponsor, a maintainer, who takes care of proving the patterns are suitable for what they have been designed, and who controls the life cycle of the pattern, including of all components which are part of the pattern.
Obviously Validated Patterns need a special framework, describing the intention, the scope and the life cycle of the pattern. Also, Validated Patterns require a set of rules and policies, or governance, in order to establish efficiency and control. Validated Patterns require a development and maintenance system, which ensures that all pattern rules are always applied, so that Validated Patterns can be used out-of-the box with a minimum level of stability and maturity. All this can be handled within a proper framework.
Examples for patterns
Examples for patterns can be found for many use cases or business scenarios. Starting with Portfolio Architectures, continuing with Solution Patterns, and finally looking at already proven Validated Patterns, which are embedded into a maintenance system.
Just to show how it can work, have a look at the pattern collection which is available at Red Hat. As a vendor for industry grade Open Source solutions, Red Hat recognized that only utilizing products from a portfolio is just one half of the solution. Technology and even products need to be adapted to individual scenarios. Components need to be identified, integrated, and configured according to the requirements of the solution. What could be better to sum up similar solutions as patterns, so that there is a starting point for every use case where a pattern already exists.
In accordance with the pattern types above, the patterns are divided into Portfolio Architectures, Solution Patterns and Validated Patterns.
The focus of Red Hat patterns for the Portfolio Architectures is mainly on industry solutions, but also includes general use cases such as creating hybrid multi-cloud platforms. Solutions Patterns concentrate primarily on the life cycle of cloud-native applications, whereas Validated Patterns are proven by Red Hat’s engineering team, and are dedicated to GitOps based automation in order to make them easy and safe to use.
Applications for patterns in general can be found in many areas, and are not restricted to certain industries. Examples can be found e.g. in the industrial edge, for medical diagnostics, for implementing multi-cloud with GitOps and for edge scenarios with Ansible.
One of the most interesting future applications, though, is (beyond AI) hybrid multi-cloud. The scenario in principle: you have to provide a cloud solution, which guarantees full application lifecycle management across multiple clouds, which of course includes public clouds (which again include the hyperscalers), and private clouds. Typically, you are starting with a Portfolio Architecture, which includes the definition of the business benefits, and a logical architecture (here on a very high level).
As you can see from the above diagram, important areas are identified, such as the management hub, which is responsible for creating, securing and managing the multi-cloud environment, as well as the managed cluster landscape, distributed among different infrastructure providers, public as well as on-prem.
If this scenario is similar to what you want to build, the matching Portfolio Architecture can be applied and customized as needed. The Portfolio Architecture for hybrid multi-cloud scenarios also includes a blueprint for a logical architecture, identifying what you basically need to create the solution:
Once you are done with the Portfolio Architecture, you may think about create the full solution, which as a matching Validated Pattern looks (again high level) like this:
Technically, the matching Validated Pattern is based on Red Hat’s Validated Pattern Framework, which again is based on a GitOps approach for both creating and updating the platform, utilizing Helm Charts for configuration and customization, and Red Hat Advanced Cluster Management for Kubernetes (ACM) for deploying managed cluster pieces.
The framework has been designed to be used for managing the whole pattern life cycle and for providing the proper technology and governance for a community process, where patterns are proposed upstream to the community, further developed by the community, and processed downstream for validation and support.
And, of course, the framework itself is Open Source.
Outlook
The first two parts of the series on patterns have their focus primarily on the theoretical background – what are patterns, what is their benefit, and how can they look like.
The next part of the series will be about how to use them in terms of implementation and adoption. So stay tuned.