Ansible Responds To Report That It Must Work To Maintain Its Importance In The Face Of Containers (Part One)

Some folks at Ansible read recently that enterprises like it must strive to retain significance given the popularity of containers and microservices. In a message to ContainerJournal, an external PR agency responded on behalf of Ansible. Ansible’s VP of Community, Greg DeKonigsberg spoke with ContainerJournal to provide a more complete response, rendered here in Q&A format, publishing in two parts. We based our questions on the communication from the PR representative.

ContainerJournal: You say you need a solution that not only works with the promise that containers bring, but that also maintains the flexibility required to work with the many environments that are not amenable to containerization. Why is that?

Greg DeKonigsberg: The question behind that is, does anyone have an environment in which they can just start everything from scratch, and the answer is not very many folks do. Containers are great from a greenfield perspective, certainly. But any company that has any legacy has to figure out how to deal with that legacy.

Whenever you have any container strategy, whether it’s at the application level or the OS level, you’re going to have to figure out what things in your organization you can containerize: what applications you can put in containers, what you need to leave alone, and what is just legacy technology. Anything Oracle on the backend, your CRM systems, and things like that that your applications need to interact with are going to have a very high cost to touch them at all, let alone the question of containerizing those things.

Then there’s just legacy. Legacy is a real thing that people have to deal with and there are going to be some things that you just don’t want to touch, even if you’re doing some things with containers.

Sponsorships Available

Sponsorships Available

Sponsorships Available

CJ: You say containers can’t work in isolation. What prevents containers from working in isolation?

GD: Containers run on physical hardware that you still need to configure and connect to other machines. If you’re going to run containers, are you going to run them on an OS that’s running on bare metal, or are you going to run containers inside of some virtual environment? The environment around the containers still matters and you can’t just explain it away.

When you deploy containers, you need to know which host you’re going to be deploying them to and what the configurations of those hosts are relative to one another, and relative to the non-containerized bits that you’re running.

CJ: How and why does container software need complimentary solutions like Ansible to work at full efficiency? What about their efficiency is lacking without Ansible or solutions like it?

GD: People who are most excited about containers are excited about containers because they provide a way of creating microservices that you can mix and easily swap out as units. When a container that is running a particular microservice is no longer up to date, we throw it out and replace it with a new container and in this way, it allows you, ideally, to build a more modular infrastructure with the container-based microservice as the key central component of that architecture.

So the challenge is that people who are doing this are generally coming from a more monolithic background where they’re simply deploying all of these things on particular systems at the OS level. So when you move from that sort of monolithic approach to a more containerized approach, what you end up doing is creating a lot more containers that then need to be coordinated with one another somehow, right, and that challenge is at its heart a configuration and orchestration challenge.

That’s one of the reasons why we’re seeing so many people in the Docker universe turn to Ansible in particular. Ansible is one of the simplest tools to understand how to do that, how to deploy what may be many different Docker containers on many different pieces of physical hardware in development, QA, and production.

So a container is an individual thing, and what the container descriptor, which is usually the Dockerfile describes is what’s going on in that particular container, but what is not described in any Dockerfile is the relationships between the containers. You have to define those relationships somehow, and people are increasingly turning to Ansible as the mechanism to describe that relationship, not only between containers, but also between containers and the things that they’re interacting with.

Stay tuned to this ‘ContainerJournal channel’ for the rest of Ansible’s defense.