What is a validated pattern?

• Nothing—you can start here

Red Hat’s validated patterns are codified use cases based on real-world customer and partner example deployments. They are focused on solving a business problem and tested as a complete use case deployment.

Validated patterns are maintained across three different tiers:

• Sandbox tier: These patterns are operational models that are developed and tested in the upstream community using GitOps principles. They are maintained by their creators, or are still in process of being developed. As they are not included in an automated continuous integration (CI), their code should be used with discretion, but might be helpful in developing your own pattern.
• Tested tier: These validated patterns are tested on at least a quarterly basis. There are additional artifacts developed like demo videos, documentation and presentations. Testing is done on major cloud providers and is on the last two extended life Red Hat OpenShift versions at a minimum.
• Maintained tier: These patterns are deemed essential to multiple customers, so they are tested further for wider use. They must be deployed at a customer site, are maintained over time and have their own lifecycle, include a demo of the use case that uses the API connections between products, are designed as modular, and are tested on the three major clouds supported in the validated patterns initiative (AWS, Google Cloud, and Microsoft Azure), as well as bare metal testing. From there, the pattern is included in Red Hat’s CI, and testing is done on both currently available versions as well as pre-general availability bits.

Unlike a reference architecture, validated patterns are based on actual customer deployments and are actively maintained over time. They are also validated not only through continuous integration (CI), but via the support of product teams and solutions architects. By using GitOps to deliver configuration as code, validated patterns leverage upstream repositories for open collaboration. 

In other words, validated patterns are reliable and less risky because they are maintained and deployed in the real world. They provide a quick proof of concept (PoC) for deploying complex workloads and can be quickly implemented into your streamlined GitOps framework. They have many opportunities for customization and innovation, and also include a demo to show an example workload use case.

At a high level, a validated pattern uses Helm charts to create templates of the code architecture for a given use case. This template is a well-defined workflow that contains values and secrets files that manage overrides, making the deployment specific to your use case. Sub-patterns are then applied to multiple layers of the architecture, helping to deploy the components reliably and according to best practices.

Deploying the pattern will follow these general steps:

1. Find a pattern for a use case that fits your needs and fork the pattern repository.
2. Change secrets and/or values files in the local clone to specify overrides for your use case.
3. Deploy the pattern workflow, which will first deploy Red Hat OpenShift® GitOps. OpenShift GitOps will deploy the application(s) and make sure all the components of the pattern are working correctly, including operators and application code.
4. Most patterns will also have a Red Hat Advanced Cluster Management operator deployed so that multi-cluster deployments can be managed.

If you’re still wanting to learn more about validated patterns, here are a few additional resources:

• What are validated patterns?
• Available patterns and documentation
• Portfolio architectures for hybrid multi-cloud management with GitOps

• Troubleshoot with Red Hat support*
• OpenShift Commons validated patterns Slack channel
• GitHub repositories for validated patterns

*Red Hat supports subscribed Red Hat products used in validated patterns. The codified patterns are distributed as community projects and no additional support beyond subscribed Red Hat products is implied.