Pattern Identification: Simplify, Expedite Enterprise DevOps at Scale
Last week we introduced the idea of enterprise DevOps at scale, and the seven step process that has emerged to effectively achieve this goal, helping organizations effectively reap economies of scale and address the complexities inherent to a large enterprise. While our last blog series on DevOps adoption focused heavily on the first two steps — plan and assess, and pilot — today’s article will dive more deeply into the third step of the process: pattern identification.
What is a Pattern?
Imagine you are planning a move. You want your friends to help and you explain that you’d like them to choose one thing in the house to pick up and drive to the new house, and so on until the entire move is complete. Not only would you quickly be out of help, they would never offer to help again. Of course you’d pack boxes full of like items that go to the same spot in the new house and your friends would graciously help.
Similarly, patterns help us much more easily and successfully move to an enterprise DevOps at scale model by identifying applications that share common infrastructure and deployment pipelines. At Flux7 we call these patterns, or a common method for integrating and delivering applications. To achieve DevOps at scale, identifying patterns across your applications helps expedite the process and makes it much more efficient.
Application Replatforming: Identify Apps
Organizations that successfully spread DevOps go through the process of assessing their application portfolio and identifying those applications that share common patterns. The first step of the analysis process — as we outline in more detail in this blog, The Best Cloud Migration Path: Lift and Shift, Replatform or Refactor — is to place your applications in one of several categories. As not all applications should be moved or simply lifted and shifted, it’s important to identify apps for:
Of these, we’ll look at those applications that have been identified for replatforming to determine which applications share patterns.
Now that we have winnowed down the list of applications to just those that will be replatformed, the next step is to look more deeply into application patterns. The infrastructure template of a given application, the server configuration as code, and deployment process as code of each application. While patterns are technology agnostic, common patterns we see would consist of: An infrastructure DSL (e.g., AWS CloudFormation or HashiCorp Terraform), a software provisoining tool (e.g., Ansible, PowerShell, Chef), and a process DSL (e..g, a Jenkins file outline deployment process for apps that follow this pattern).
That said, the pattern definition should be a complete embodiment — including all the dependencies and the app itself — of what you need to deploy an application. The overarching intent should be to identify those applications that can be deployed using the same pattern. In our experience, as many as 50 apps can use a single pattern.
Not Too Broad, Nor too Narrow
The key to success here is the Goldilocks Principle, neither identifying patterns that are too broad nor too narrow as either will cause headaches and unnecessary delays in process. For, if the pattern is defined too narrowly, then every application could theoretically have its own pattern. Hearkening to our moving analogy, defining patterns too narrowly would be like moving your house with shoe boxes.
Conversely, patterns that are too broad create extra work as configurations become quite difficult to manage — like moving your house on pallets. Just as you’d still need to sort and manage the details on the back-end, engineers will need to know a lot about the configuration of each application. The goal, therefore, is to set the pattern granularity just right.
For example, if you were to have a Java Tomcat pattern, the goal would be to identify all Java Tomcat apps that can use the same pattern. Identify parameters that inclusively define these apps, such as the run-time database, required properties, session stickiness, etc. You may as you explore these patterns decide that two Tomcat patterns might be advisable, e.g. one for EC2 deployments and one for Kubernetes deployments. But, in either case, it’s important to ask yourself if you are slicing the bologna too thinly.
Expert DevOps Services
At the end of the day, it can be truly difficult to get the dial just right on your patterns without some experience with the task. Having participated in dozens of DevOps at scale projects, we’ve seen first hand how challenging it can be to know ‘just right’ when you see it. That’s why we often recommend bringing in a DevOps expert for this step in the process as they can help teach your team how to define and develop ‘just right’ patterns for your specific application set.
In the next blog in our DevOps at scale series, we will dive into just this — how to best develop patterns based on the needs of your organization. We’ll also delve into the story of two different companies and how they went about the process of pattern identification, development and lifecycle management.
In the meantime, if you haven’t already read our DevOps adoption series that discusses steps one and two, you can enjoy them here:
- Survey: What Motivates Enterprises to DevOps Adoption
- DevOps Adoption: 7 Lessons for a Successful DevOps Pilot
- DevOps Adoption: Why Every DevOps Pilot Needs a Landing Zone
- Hospitality Combats Competitive Pressure with DevOps Adoption
- AWS Cloud Migration Strategy: Replatform vs Refactor
- DevOps Metrics to Ensure Your Pilot Measures Up