Pattern Development: Accelerate and Achieve Enterprise DevOps at Scale

In our last article we discussed the role of pattern identification in the overall process of achieving DevOps at scale. Today we’ll share how to best develop patterns based on the needs of your organization. Pattern development is the fifth step in the enterprise DevOps at scale process, following the development of a DevOps platform.

Pattern Development

Once your applications are categorized by identifiable patterns and the DevOps platform is developed, the CoE should work together with operations, security and business unit teams to develop patterns that meet organizational requirements. These patterns should go through a process, helmed by the CoE, of pattern certification.

As you embark on your pattern development, it’s important to keep in mind that each pattern you develop needs to be managed by the CoE; the CoE is responsible for pattern lifecycle management. Specifically they shall be tasked with cataloging patterns, making sure they are up-to-date with current best practices, incorporating any new GRC requirements, and retiring them when appropriate. Too many patterns and the job of keeping them maintained quickly becomes unwieldy. Conversely, too few patterns means that each pattern will likely have many options. Too many options and the CoE risks being flooded by queries from engineers who need help navigating pattern complexities.

When developing patterns, it is definitely an exercise in appropriately balancing the CoE’s workload between pattern maintenance and fielding questions. When building this balance, we recommend you keep the experience of the team in mind.

The Right Size Remote

We like to use the analogy of a remote control here. While some people might be more 

The work of pattern use is easier if there is a manageable number with the right amount of control — or buttons. If there are too few buttons, or too few options, you’ll find yourself in a position of rewriting too many patterns to fit use cases of a subset of the apps identified for the pattern. comfortable with the remote on the right, many would be overwhelmed with the complexity of choice. And so it is with patterns.

Too many buttons, on the other hand, can simply make it difficult to know what to do. And this is where the expertise of your team comes in. If you work with a development team that is expert at and willing to go deeper, then they can certainly handle more buttons and may in fact be comfortable with many options.

On the other hand, if your teams are not full stack developers, they may be more comfortable with patterns that look like the remote on the left, with more of the options hidden behind the scenes. Said another way, if your patterns give the team more options than they are comfortable with, your CoE may very well end up reworking patterns to achieve an affect like this:

A last consideration is the number of development teams who will be working with your patterns. The more teams you have, the greater the ability to take on the overhead of more patterns. For example, if you have 250 development teams, it’s much easier for the CoE to increase the number of patterns as compared to an enterprise with 20 teams who will need fewer patterns to work.

Pattern Development in Action: Enterprise Media

Flux7 had the opportunity to work with an enterprise media group on its IT modernization plan in which it had determined an AWS cloud migration was the ideal path. This firm had over 400 applications that were assessed by the CoE, of which over 200 were flagged for application replatforming. For these apps, the CoE — working with operations, security and business units — developed five patterns to use to move these apps to a modern, DevOps infrastructure.

For example, the first pattern was for a set of applications whose architecture will run Java/Tomcat in Docker containers on top of a Kubernetes platform. The CoE developed a “Kubernetes pipeline” to deploy Kubernetes on AWS, that is clusters as self-service on top of AWS, allowing for apps that may or may not use session state as well as apps with and without the need for shared storage (NFS). For a deeper dive on this organization’s story, read their story at, Developing an AWS Cloud Migration Path and Developing a Tomcat Cloud Migration.

Enterprise Communications DevOps at Scale

The second organization is a global communications company who had identified 120 Tomcat applications for replatforming. For these business critical apps, the CoE developed four patterns:

• External-facing Web applications
• Internal Java Tomcat applications that had specific security and compliance requirements
• Internal Java Tomcat applications without any dependencies
• Batch apps with database dependencies

Once the patterns were developed, the firm created an application factory that allowed it to streamline the process of deploying the applications to AWS. It creates a templated Docker file, makes a tweak, and allows developers to push the code, all without the involvement of the IT team. Its patterns were created with the flexibility to accomodate the needs of each app identified as belonging to the pattern. While the applications are not identical, they are similar enough that the pattern successfully works for each.

DevOps Consulting Expert

Just as with pattern identification, pattern development can be difficult. Questions like, how many parameters do you put into each pattern, how many patterns are appropriate for the number of teams you have, and more are all important considerations. And while the two examples we provided today focus on companies that created four and five patterns, there is no rule of thumb to guide you here. As a result, we recommend bringing in a DevOps consulting expert for this step in the process as they can help teach your team how to develop the right number of patterns with the right amount of control, effectively balancing pattern maintenance, and developer questions and control to ensure an optimal outcome that will help accelerate your enterprise DevOps adoption.

In the next blog in our DevOps at scale series, we will take a look at the next steps in the process, exploring the topic of continuous improvement as it applies to DevOps in the enterprise. Don’t miss it. Subscribe to our blog below.