I wanted to write about this because it seems to be a trend I'm seeing with a lot of companies who discuss their methodology of approaching automation.

In the most diligent of companies where I have seen some killer automation there is a pattern across the board that strikes semblance with other companies:  Active patterns, lack of anti-patterns, and an adoption of tools that make sense.  If a tool is to be adopted, does it replace another?  Does it serve a similar function of another?  

These are all things considered in that process.  In my opinion, these are fantastic things to consider.  One observation I've made time and time again with many new companies who are in the process of trying to get to their first level of automation is "ADOPT ALL THE THINGS!"  Hey, get kubernetes, get ansible, get terraform, use cloudformation, use chef, use puppet too!  Code pipeline? HELL YEAH.  You know, I read about making your own tools too!  Let's use them all!  Before you know it, you've got virtually every team in the company using DIFFERENT tools, there is no cohesion among pipelines and all the projects are now silo'd per team.  

This leads to a new problem, how to you optimize that?  How do you migrate it?  If one team comes in to help another, they now have to learn brand new technology.  This of course presents a problem with velocity, which is an anti-pattern but you didn't even realize you were making one.

Let's say for example, one team decides to use a very old technology that's no longer supported.  They build some modules in Terraform, another makes their architecture in Cloudformation.  Both of these are great to use, but now we have divergence.  Instead of being able to tie the architecture build in terraform with cloudformation, or vice versa, we're now at a weird standstill of having to make the call: "Which do we want to use?  Do we re-write one of these?  Do we keep these projects separate now?  Do both teams need to learn both?"

Instead, automation should be seen from the perspective of an adopted pattern or technology that serves a purpose for teams.  If Terraform suits your needs, and your teams like it, and you can create infrastructure as code that is repeatable with modules, then adopt it.  However, if you decide 3 months down the road to have a team go off on a tangent and start using cloudformation and diverge, if these projects decide to be moved in together at some point, or work together within architecture, well, now you're in a weird place.  Divergence is often times, the beginning of anti-patterns.

There's also the poison of letting teams simply just adopt whatever tools they want that deal with automation.  This type of divergence can be pretty dangerous in the automation world because there's little to no cohesion.  I have seen many cases where a company can't even agree on a communication platform.  What if you're using 5 or 6 platforms to communicate?  How do you know where to talk to someone?  How do you know what's "okay" to discuss outages, or expect a PM from someone on?  What about email?  Is there set expectations?

Automation is the same way.  There are many, many benefits of so many tools, and it can be important to keep on top of the newest tools, setup a lab or a sandbox environment and yes, TRY THEM OUT!  At the end of the day, however, the sandbox shouldn't be your production environment for those.  Keep it in the sandbox and remember:  Patterns, not anti-patterns.

Infrastructure as code should always be thought of as: "How does it scale?  How will this scale later?  Is there a better way to scale that fits our needs in the long run?  Am I using this in a way that's a good pattern and not an anti-pattern, and what cohesion can this drive between teams?"