When Ansible was first founded three years ago, the underlying premise was to simplify some of the complexity in the existing DevOps tools. The mere idea of needing a strong developer toolset to automate your IT infrastructure was an overwhelming concept for most. I believe this is one of the underlying reasons that the majority of the IT shops are still using home-crafted scripts to automate updates to their infrastructure and shying away from having to add more complexity to an already complex world.
The well known quote from, Dieter Rams, the famous industrial designer, saying: “Less but Better”, has become somewhat of a guiding principle for Ansible. Being able to achieve in few lines of YAML script, during lunch hour what you can’t do in days of writing code with others.
In fact, not only do we apply that principle to our products in general, but to other operational things we do at Ansible, Inc. - from our internal communication to the onboarding process of new employees to how we handle customer support tickets. We are building an organization and an enterprise product based on simplicity. In fact, I’ve become a strong believer in the notion that complex organizations tend to naturally drift towards creating complex products, while the opposite is also true.
Just as in Dieter’s principle of design around usefulness, aesthetic and minimal design, the Ansible mantra is about giving the user that first amazing experience of “this is so easy to use and it works”, similar to that experience of getting your first iPhone or iPad. The experience of minimal effort needed in achieving goals beyond what was expected.
The need for simplicity in an open source project has also played a key role for us. Allowing contributors to quickly ramp up their understanding of the baseline of the Ansible project, only to turn around and contribute back to the project is one of the reasons why Ansible is now among the top 10 open source projects and has a strong list of over a thousand contributors. Of course, the challenge lies in the fact that not all contributors are the same, and not every contribution builds on our story of simplicity. The weight then shifts in being careful in pulling random requests into the product while continuing to set standards and rebuilding frameworks that would make contributions easier to incorporate.
As we add higher-level enterprise extensions into the Ansible Tower product, it becomes more challenging to continue to maintain a level of simplicity. The downward pressure from enterprise companies incorporating new features that would potentially add complexity in the code base. As with most IT products, complexity only increases as integration with the necessary technology ecosystem, and support for large customers grow.
The Ansible engineering management team has to constantly check the boxes:
1) Is the new technology necessary and will it serve the many versus the few?
2) Will this technology create unnecessary complexity?
3) Is there an easier path to take?
Simple products that serve a real need will always have the upper hand. Maintaining the simplicity of a software product that has to serve complex IT environments at scale is a tall order for any company out there, no matter how big. Ansible today, after years in the open, has consistently maintained that simplicity aspect, although at times at a cost. This, I’m convinced of now, has been the leading factor in the amazing adoption trend we realized in the last two years and continue to see today.I’d love to hear from you - what are your thoughts about Ansible and how we can keep it as simple and accessible as possible?