Validated patterns are living code architectures for different edge computing and hybrid cloud use cases. They're created by using Helm Charts—a collection of files that describe a set of related Kubernetes resources—and play a critical role in bringing together the Red Hat® portfolio and technology ecosystem to help you build your edge architecture faster.
These predefined edge computing configurations contain all the code necessary to build a comprehensive edge or hybrid cloud stack. You can even create a reference architecture that goes beyond documentation by using automated processes in GitOps that simplify deployment and ensure consistency across multiple sites and clusters. Each use case’s git repository is open, and Red Hat regularly collaborates with customers to change use cases or add partner technologies to configurations.
Validated patterns are not only highly customizable, but are continuously tested against current product releases to ensure that deployments are kept up to date. Using a validated pattern gives the confidence of using a best practice, reduces the risk of falling behind a crucial release point, and makes your deployment operable at scale.
At Red Hat, we specialize in open source software. However, there are still challenges when it comes to proprietary cloud operations. To address this gap in the market, we have collaborated with an upstream community, Operate First, to extend upstream first1 principles of open development, including the needs of the target operational environment, from start to finish.
Operate First supports developers, operators, site reliability engineers (SREs), etc., by hosting their in-progress open source projects on a production cloud. There, they receive important feedback on their code and other artifacts, which can then become a relatively stable blueprint for other developers to use.2
You can think of these blueprints as a community pattern, or an operational model that is developed and tested in the upstream community using GitOps principles. Community patterns are use cases that bring together several technologies in a modular configuration to demonstrate a specific capability, but are maintained by their creators, not Red Hat.
Some patterns, however, are taken up in the downstream community at Red Hat to be tested further for wider use. These are called validated patterns, and they must achieve the following, based on GitOps principles:
- Deployed at a customer site
- Require three or more Red Hat technologies
- Maintained over time and have their own lifecycle, which allows for pattern versions to be tested based on new versions
- Include a demo of the use case that uses the API connections between products to ensure the pattern works across product versions
- Designed as modular so that individual functions can be replaced to apply to other solutions
Once these requirements have been met, the use case is included in Red Hat’s continuous integration (CI) for you to use and customize to fit your needs.
Read an example case of validated patterns in the form of Clair.
Validated patterns are used by architects and advanced developers to bring together products across the Red Hat portfolio in a specific use case that is tested and maintained across the product lifecycle. Current patterns are available as GitHub repositories that can be modified and deployed on Red Hat® OpenShift®, but in the future may deploy using Ansible alone. Most patterns will also have an Advanced Cluster Management operator for managing multi-cluster deployments.
Red Hat uses Helm Charts to create these replicable use cases in the form of templates. Much like how Red Hat® Ansible® Automation Platform uses variables to enforce policy and allow room for parameters and validation, Helm does the same for Kubernetes. Whereas Ansible addresses configuration problems in an OS instance by having a well-defined workflow structure and clear ways to inject variables and overrides, Helm defines the OpenShift workflow with a Chart and introduces overrides through secrets and values files.
By using Helm for templating, we’ve reduced the installation of the validated pattern down to two steps for the datacenter application above, and to one step for each factory. Developers and/or architects need only load their GitHub, Quay, and other credentials into a locally stored secrets file, and the validated patterns framework will do the rest.
That templated approach makes sure that OpenShift GitOps can drive the management and configuration of the architecture. The templates include sub-patterns that can be applied to the multiple layers. These sub-patterns help to deploy the components consistently and to apply best practices.
The end result is a bill of materials for each validated pattern, that clearly and centrally indicates the full list of namespaces, subscriptions, and configuration bundles needed for the solution.3
While Kubernetes and products like Red Hat OpenShift provide a scalable platform for deploying applications and services, customers can achieve that same scale for the entire architecture with validated patterns.
One of the primary benefits of using a validated pattern is that Red Hat maintains the configuration across product lifecycles. We ensure that these cloud native technologies continue to work together as they evolve, so you can trust that the use case is going to work as intended.
Validated patterns also contain all the code necessary to build your stack, and using GitOps principles means that developers can rely on automated processes to easily find where things might have gone wrong. A validated pattern makes the division of labor between various management pieces clear and easy to monitor and maintain.
Finally, patterns are developed using open source principles, so they remain open and customizable. With validated patterns, known workloads can be replicated anywhere, with easy ways to modify the pattern for different use cases. As the technologies you use continue to improve and your use cases change, validated patterns can be automated and updated to suit your needs.