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. 

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, Massachusetts Open Cloud (MOC), to extend upstream first principles of open development, including the needs of the target operational environment, from start to finish.

Validated patterns are developed in three tiers:

• Sandbox tier validated patterns are operational models that are developed and tested in the upstream community using GitOps principles. The sandbox validated patterns are use cases that bring together several technologies in a modular configuration to demonstrate a specific capability, but 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.
• After a validated pattern works consistently, it can graduate to the tested tier. At this phase, the validated patterns need to be tested on at least a quarterly basis. The testing should be automated, but that is not a firm requirement. There are additional artifacts developed that can include demo videos, documentation, and presentations. The testing is done on major cloud providers and is on the last two extended life Red Hat OpenShift versions at a minimum.
• Some patterns are deemed essential to multiple customers, so they are tested further for wider use at the maintained tier. 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
  • Testing is on the three major clouds supported in the validated patterns initiative (AWS, Google Cloud and Microsoft Azure).  Beyond the GA version testing from the tested tier, the maintained tier also introduces pre-GA testing to catch issues prior to GA.

Once these requirements have been met, the use case is included in Red Hat’s CI for you to use and customize to fit your needs.
 

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.

Validated patterns can work for a wide variety of use cases to fit your organization’s needs now and as they grow in the future.
See validated patterns here