What are validated patterns?

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.

A validated pattern is a trusted, automated blueprint for deploying complete, ready-to-run software in a hybrid cloud. It goes beyond your typical reference architecture and is instead a rigorously tested, pre-integrated stack that combines the application with all required configurations and infrastructure. The pattern is a full solution to a specific problem like implementing a GitOps approach to multi-cloud or zero trust security. It supplies all the needed components for the platform via GitOps, including workload identity management, secret management, and identity and access management.

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.

Validated patterns are used by partners, architects, advanced developers and consulting services to bring together products for  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® Container Platform (OCP), or using Ansible without OCP. Most patterns can also deploy an Advanced Cluster Management operator for managing multi-cluster deployments.

The diagram below outlines the general deployment flow of an example use case, a datacenter application.

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.

As a note, Kustomize is also supported in the validated patterns deployment framework, but as Helm is built for consistency, it is recommended.