Usman-Malik - PeerSpot reviewer
Cloud Native Architect | Edge | Kubernetes | Security | DevOps | SRE | Consultant | Public Speaker at a tech company with self employed
Real User
Top 5Leaderboard
A stable solution with valuable volume binding features, but room for improvement in scalability and integration
Pros and Cons
  • "I think the volume binding is a really interesting feature."
  • "With the Mirantis runtime being removed from Kubernetes, which is the industry-wide standard for orchestration of containers, I think it's going in a direction that is not super scalable."

What is our primary use case?

We use Mirantis for nearly everything, starting with development. The developers use Mirantis to basically package the application. We use Kubernetes, and both Mirantis and Kubernetes are used locally by developers. The container runtime is done by Mirantis.

We use Mirantis for our CICD pipelines as well. For very runner in GitLab, a Mirantis container is spawned and then an application is built and some tests are run, and all of that is done in Mirantis containers.

The same goes for production. An image is promoted and tagged and published to a Mirantis registry, and then later pulled in by another agent that's running in Kubernetes.

How has it helped my organization?

Did not use Mirantis Container Cloud in the organization.

What is most valuable?

I think the volume binding is a really interesting feature. For example, if you're running a Mirantis container on your host machine, you can bind a directory of files by the container and use the overlay file system. 

Swarm is quite okay for smaller cases. You don't need Kubernetes and all the other orchestration tools for everything. It works for that use case pretty well.

What needs improvement?

I think the build time can be better. There's a lot of work done by Mirantis for BuildKit, for example, or Buildx, and I think there is a lot of stuff that can be done over there. 

Some improvements can be made on the Docker Compose level with some dependencies. For example, if you have a service that's dependent on another service, you can't do that today with Docker Compose.

Also, if Mirantis can leverage open source Kubernetes as part of its own offering, I think it would be a huge hit because every developer uses Mirantis. People know Containers because of Docker, and I feel that if they collaborate or incorporate Kubernetes into the Mirantis runtime it would be a big thing because everybody needs local environments and everybody needs to assemble environments for testing, A/B deployments, or production, and have as much of a reproducible environment as possible. I think that would be a huge success.

I would love to see the QUIC protocol support apart from TCP and UDP in Mirantis. I think that they would be the first one to do it because it's not really there at the moment with any other container runtimes that I know of.

Buyer's Guide
Mirantis Container Cloud
April 2024
Learn what your peers think about Mirantis Container Cloud. Get advice and tips from experienced pros sharing their opinions. Updated: April 2024.
768,857 professionals have used our research since 2012.

For how long have I used the solution?

I have been using this solution for about six years now. 

What do I think about the stability of the solution?

I think it's really stable. There were problems in the past, like you have with every software, but I think it's pretty stable now. I have seen very few crashes of the Docker daemon itself, but I'm not talking about the containers because that's not Docker' s job. The stability of those depends what you have learning in your container. As far as the runtime is concerned, I think it's decently stable.

What do I think about the scalability of the solution?

The solution is definitely scalable, but only to some degree. For example, Mirantis did make an effort to get into the orchestration world by having Docker Swarm, but I don't think a lot of people use it because of the other orchestration tools available. I think that's where the scalability problem comes in.

But now with the Mirantis runtime being removed from Kubernetes, which is the industry-wide standard for orchestration of containers, I think it's going in a direction that is not super scalable. Also, with the recent licensing changing with Docker Desktop, a lot of companies are opting to stop using that and switching to another solution like Rancher Desktop, which gives you a UI. If you want to use Docker Desktop in a commercial environment, you have to pay a per user fee. It might be okay for conglomerates and enterprises, but it's not okay for midsize or small companies, because they're tight on budget.

I think there are some scalability issues from my point of view, from the business model and the tech model, and I think stepping out of Kubernetes is a huge setback.

There are currently 200+ people using this solution in my company. 

How are customer service and support?

I have never had to use tech support because I use the documentation, which is pretty decent from my point of view. Also, the community is huge, so there's QAs and forums and discussions going on.

Which solution did I use previously and why did I switch?

I don't think there's strong reasoning behind why my company decided to go with Mirantis because it used to be, and still is to some degree, the standard for containers. When it comes to containers, what comes to your mind is basically Docker. 

In my organization, we have a lot of developers that are developing applications on top of Kubernetes. Just to keep in sync with the newer version, they decided to switch from Mirantis to Containerd to run their containers, so I think it's changing. In my company, a lot of people are not even using Docker Desktop. Some people are using it because they're used to it and the company had a license for them, but a lot of people switched to an open source alternative to have some DUI for managing their containers.

How was the initial setup?

The initial setup is pretty easy. I think it's super easy with the universal builds offered by Docker for ARM64, Linux, Windows, etc. Even for people who are not familiar with terminal and text files, you can use the Docker Desktop UI to manage all your running containers, images, and modify your Docker daemon JSON file. I think it's really easy as a starting point.

What's my experience with pricing, setup cost, and licensing?

With open source, you can use Mirantis completely free. If you're using Docker Desktop in a commercial environment, you do have to pay a fee, but if you're using the Mirantis runtime, just the daemon and the runtime, you don't have to pay anything. It's all open source. The code is there for BuildKit on GitHub. There's a community, the MOBI project, and you don't have to pay anything.

What other advice do I have?

If you were to use Mirantis for the first time, I would really advise you just to look into the basics of understanding containers in general, anc realize that Mirantis is an abstraction or a way or runtime to run your containers. It is an industry-wide standard now, when it comes to distributing the images, but that's also shifting now to OCI images. I would advise looking into other container runtimes as well, and keep your vision broad and try to make conscious decisions rather than being biased and just following the herd.

I would rate this solution as a seven out of ten because it has really educated users. It created a lot of shift in the industry for using containers. I feel it's stable because it hasn't crashed very much in my experience. The reason I gave this a little bit of a lower number while saying good things about it, is because I don't like how the community' is responding nowadays, especially collaborating with other bigger communities. One of the examples is Kubernetes, for example. There was a backlash and they couldn't agree to stuff. It's really a big thing at the moment, and it will be for the next couple of years.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
Software Architect at AIOPS group
Real User
Top 5Leaderboard
Provides a comprehensive platform for deploying and managing containerized applications across cloud environments
Pros and Cons
  • "Mirantis Container Cloud operates similarly to how we interact with databases. It provides a comprehensive platform for deploying and managing containerized applications across cloud environments."
  • "The solution's stability could be improved."

What is our primary use case?

We use Mirantis Container Cloud to package and configure our microservices. Whether it's a simple standalone service or a service with a PostgreSQL or MongoDB connection, we handle it all in a Docker file.

How has it helped my organization?

We don't use Mirantis Container Cloud straightforwardly. We use it through GCP and Google's managed Kubernetes environment.

What is most valuable?

Mirantis Container Cloud operates similarly to how we interact with databases. It provides a comprehensive platform for deploying and managing containerized applications across cloud environments.

The solution makes it easy to reconfigure your microservices. Each microservice has its configuration stored in one file. If you need to scale or perform any other action, you can access these configuration files and scale the specific part of your system. This approach divides the system into manageable pieces while keeping them interconnected. The configurations are centralized, preventing scattered configurations across random places.

What needs improvement?

The solution's stability could be improved. 

For how long have I used the solution?

I have been using Mirantis Container Cloud for two years.

What do I think about the stability of the solution?

Mirantis Container Cloud is designed to facilitate easy setup and reconfiguration of microservices. Each microservice has its configuration stored in a single file. Scaling or adjusting components can be achieved by modifying these Docker files. This approach breaks down the system into manageable pieces while ensuring coherence and centralized configuration management. Overall, it offers stability and ease of management.

I rate the solution’s stability a nine out of ten.

What do I think about the scalability of the solution?

The solution is scalable.

How are customer service and support?

We have a dedicated team that handles all requests. They can contact support for issues like Postgres or anything else. In the past few years, we've encountered some problems with containers around five times, but our team has managed to address them effectively.

Which solution did I use previously and why did I switch?


How was the initial setup?

The initial setup is straightforward but requires some knowledge and research to be executed properly. Once you understand the process, it becomes simple, involving configuration in one file. It is easy to reconfigure

Google provides us with GKE, a managed global cloud Kubernetes engine. We've deployed our application there. It's familiar territory for us, and scaling up or down is incredibly simple. Our workflow revolves around GitHub actions and a specific set of configurations. 

What other advice do I have?

You have support for multiple configurations. Let's say you need a service that uses a SQL database; perhaps you require another well-known SQL database. With Mirantis Container Cloud, you can configure all these in one place. Additionally, these services can connect seamlessly. You can specify the ports on which they connect in a single configuration file, consolidating all settings in one central location.

All these cloud platforms—Google, Amazon, Microsoft Azure, and others—offer a managed Docker environment.

We are also using Mirantis Container Cloud for development. It simplifies the setup needed for your project. Instead of installing various components individually on your Windows or IOS, such as a SQL database, a NoSQL database, DocIQ, with Docker, you can install everything within Docker containers. This keeps your project setup separate from your computer's environment. It's really convenient, if you need to transition to a different project with different requirements. You can simply discard the Docker images associated with the previous project and install the new ones for the new project. This process doesn't affect your computer, whether it's running Windows, Mac, Linux, or any other operating system.

It's a great solution. It's designed to handle complex, demanding, and scalable applications. Occasionally, these issues can be challenging to investigate, necessitating support intervention. I recommend this solution.

If you would like to scale your application to get millions of end users. It offers the biggest scalability.

Mirantis is simplifying their setup, stability and the easy use of configuration.

Overall, I rate the solution a nine out of ten.

Which deployment model are you using for this solution?

Hybrid Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
Buyer's Guide
Mirantis Container Cloud
April 2024
Learn what your peers think about Mirantis Container Cloud. Get advice and tips from experienced pros sharing their opinions. Updated: April 2024.
768,857 professionals have used our research since 2012.
Miguel Angel Cuesta Bravo - PeerSpot reviewer
System Administrator at Vermont Solutions
Real User
Top 5Leaderboard
A simple and fast solution for containerization with easy usage

What is our primary use case?

We use the solution for containerization and link Kubernetes to the Container.

What is most valuable?

The solution is simple and faster.

What needs improvement?

The solution is easy to use and difficult to understand. There are many courses available since it is difficult and has many things. Only experts can use it.

For how long have I used the solution?

I have been using Mirantis Container Cloud for six months.

What do I think about the stability of the solution?

There were no issues with the solution.

I rate the solution’s stability a nine out of ten.

What do I think about the scalability of the solution?

We use the application to monitor and orchestrate any applications and workloads.

I rate the solution’s scalability a ten out of ten.

What other advice do I have?

Overall, I rate the solution a nine out of ten.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
Ulf Dellbrügge - PeerSpot reviewer
Web Developer at Qanuk GMBH
Real User
Top 5Leaderboard
Containerizes the software but needs improvement in documentation
Pros and Cons
  • "The solution containerizes software."
  • "Mirantis Container Cloud needs to improve its documentation."

What is most valuable?

The solution containerizes software. 

What needs improvement?

Mirantis Container Cloud needs to improve its documentation. 

For how long have I used the solution?

I have been using the solution for half a year. 

What do I think about the stability of the solution?

I rate the solution's stability an eight out of ten. 

What do I think about the scalability of the solution?

I rate Mirantis Container Cloud's scalability a ten on ten. I am the only one using it. 

How was the initial setup?

Mirantis Container Cloud's installation is straightforward and is completed in half an hour. 

What's my experience with pricing, setup cost, and licensing?

Mirantis Container Cloud is free. However, there are features for which you need to pay. 

What other advice do I have?

I rate the solution an eight out of ten. 

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Google
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
Software Engineer at a computer software company with 1,001-5,000 employees
Real User
Top 20
Allows us to look at all the remote repositories of the images, volumes, and containers
Pros and Cons
  • "The UI is very useful."
  • "An improvement would be automated testing."

What is our primary use case?

I'm working for cybersecurity, so there are some thread data pipelines where we have data processing and then the pipelines are built and being containerized and then exported to the pipelines.

We're using version 20.10.11. It's deployed on a private cloud.

There are more than 20 people using this solution in my organization. We are all data engineers, and our managers are also from the same background. There are also machine learning engineers using this solution.

How has it helped my organization?

Before using this solution, we didn't have any kind of platform. This solution allows us to run anything and then post it like a single file. 

What is most valuable?

The solution as a whole serves a very good purpose.

The UI is very useful. We can look at all the remote repositories of the images and the volumes and containers. It shows all the images along with the total size. There is a huge difference by looking into the terminal and the UI.

What needs improvement?

An improvement would be automated testing.

For how long have I used the solution?

I've been using this solution for three months.

What do I think about the stability of the solution?

The stability is good. We had a few issues before in terms of just running an application and explaining to the other teams and stuff. Because of this application, it's easier for the DevOps engineer. 

We don't need to dig around to know what is happening. We just run the container and put it in the pipeline and then it runs.

How are customer service and support?

We haven't raised any tickets yet. We have a particular infrastructure team, and that team helps us.

How was the initial setup?

It's pretty straightforward. It was easy to install on Windows rather than on a MacBook. On the MacBook, it was a little difficult, probably because of the version that my company is using. We had a little bit of confusion with that.

Everything was done onsite.

I would rate setup 4 out of 5.

What other advice do I have?

I would rate this solution 9 out of 10.

It's a very good application. You don't need to do anything. Just deploy it, run it, and then it does all the work by itself. It's a piece of cake for someone new. If I'm a DevOps engineer, I don't need to worry about anything. I just have to run a command and it shows the errors. Then, I pass it to the other team and they look into it.

It's easy and straightforward to do the deployments. Before, we had to do the manual container when it comes to deployment. Now, you just make an image and then run it by using the commands.

Which deployment model are you using for this solution?

Private Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Erick  Karanja - PeerSpot reviewer
Technical Lead at Cellulant Kenya
Real User
Top 5Leaderboard
Stable product with an easy setup process
Pros and Cons
  • "The product's most valuable feature is cloud simulation to predict application behavior on the cloud."
  • "There could be an automation feature included in the product. It will speed up application processes and will not require scripting codes."

What is our primary use case?

We use the product for deployment purposes.

What is most valuable?

The product's most valuable feature is cloud simulation to predict application behavior on the cloud. It helps us with setting images and deploying them without a need to certify applications in the Kubernetes environment. We can work in a cloud-managed environment. It allows us to focus on testing properly.

What needs improvement?

There could be an automation feature included in the product. It will speed up application processes and will not require scripting codes.

For how long have I used the solution?

We have been using Docker Enterprise for a year.

What do I think about the stability of the solution?

I rate the product's stability an eight out of ten. I have never had any stability issues.

What do I think about the scalability of the solution?

The platform's scalability depends on the availability of resources. It is highly scalable if there is enough memory or storage space. A team of four to five executives from the CACD team uses Mirantis Container Cloud in our organization. They support all the deployments conducted by the rest of our engineers.

How was the initial setup?

The initial setup is easy and takes a day to complete. The process involves downloading an executable profile, which is available online, and then executing it on the machine. It requires following guidelines from the CACD team for setting up applications.

What other advice do I have?

I highly recommend Mirantis Container Cloud and rate it an eight out of ten. It is a good starting point for organizations adopting containerization and Kubernetes.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Flag as inappropriate
PeerSpot user
Solution Architect at KIAN company
Real User
Reliable, scalable, and easy installation
Pros and Cons
  • "The solution is scalable and we have plans to increase usage in the future."
  • "This solution is open-source and they need to focus on improving the Linux Operating Systems' GUI. It does not have a GUI making it not user-friendly. Additionally, the containers need to improve security and compliance."

What is our primary use case?

In our team, we need to develop virtualization infrastructure and provide a specific environment for the developer and software engineers to migrate microservices and new applications in an environment based on containers. Therefore, we need to build and create a new platform. We established a container engine called Docker and a distributed open-source orchestrators, such as Kubernetes, to manage lots of containers in the environment.

How has it helped my organization?

The organization has a lot of microservices for websites and mobile applications that need to scale easily horizontally and vertically. I am directly responsible for building a Docker environment for the organization for their applications and microservices. Our developers have provided the organization with the benefit of the scalability and availability of the applications. By using Docker Engine and the environment, they can easily run their application in different containers and schedule different hosts. It is simple to scale the applications, check the health and availability.

The most benefits of the containers are resolving the portability of the applications from the developer environment to the production, as well as the ability to scale easily.

What needs improvement?

This solution is open-source and they need to focus on improving the Linux Operating Systems' GUI. It does not have a GUI making it not user-friendly. Additionally, the containers need to improve security and compliance.

For how long have I used the solution?

I have been using this solution for approximately two years.

What do I think about the stability of the solution?

Docker is not stable itself because it is an engine to run containers, and whenever a container is shut down, your data is lost, and you need to restart the containers. However, if you want to receive more stability, you need to use container orchestrators, such as Docker Swarm, or Kubernetes along with Docker. Docker is not perfect itself, you need to use additional software or another orchestration system to make it more stable.

What do I think about the scalability of the solution?

In my company, approximately 10 software engineers and developers are working directly on Docker Engine. In the infrastructure environment, we have two members, myself and another colleague. We build and manage the Docker environment and infrastructure. My main responsibility in my company is providing and developing container solutions, establish and supporting their Docker environment and orchestration systems.

The solution is scalable and we have plans to increase usage in the future.

How are customer service and technical support?

I learned Docker and Kubernetes myself based on online files, such as educational materials published on the websites and at the Dockers website.

Unfortunately, due to sanctions in my country, we cannot access the official support by searching Google for Kubernetes or the Mirantis company that provided and support Docker. Therefore, we need to solve many problems based on online materials available on the internet. For specific more complex and critical problems, we communicate and negotiate with one of our partners in Europe.

It would be better to provide an online lab for providing Docker environments on the Docker website. This would allow any engineers who are looking to work on a Docker environment access to the environments on the website where they can easily work and manage Docker containers freely on the internet. Additionally, Docker should publish some presentations about new features. For example, they could provide a specific channel for interaction between engineers who are working on the Docker to share their knowledge. The Docker community is not great in comparison with VMware or Microsoft community.

How was the initial setup?

Docker installation is very straightforward because you can easily install Docker Engine based on the instruction provided on the Docker website. It is an easy four or five steps process. 

If you have good knowledge about the installation process, it can be installed in five minutes. However, if you do not have any information about the prerequisites of the installation, it can be difficult. You need to provide lots of prerequisites, such as install services. Without previous knowledge, it could take four or five hours.

What about the implementation team?

I did the implementation of the solution myself. My main responsibility is conducting proof of concept, as well as implementing and helping to develop new solutions for Docker and Kubernetes.

What's my experience with pricing, setup cost, and licensing?

The solution is open-source and free to try.

What other advice do I have?

I rate Mirantis Container Cloud a nine out of ten.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Shibu Babuchandran - PeerSpot reviewer
Shibu BabuchandranRegional Manager/ Service Delivery Manager at a tech services company with 201-500 employees
ExpertModeratorReal User

Very informative

it_user185772 - PeerSpot reviewer
Senior Software Architect with 5,001-10,000 employees
Vendor
Docker v. CFEngine v. Puppet Data Center Automation v. Chef v. Ansible

Originally posted at http://technologyconversations.com/2015/08/26/configuration-management-in-the-docker-world/

Anyone managing more than a few servers can confirm that doing such a task manually is a waste of time and risky. Configuration management (CM) exists for a long time and there is no single reason I can think of why one would not use one of the tools. The question is not whether to adopt one of them but which one to choose. Those that already embraced one or the other and invested a lot of time and money will probably argue that the best tool is the one they chose. As things usually go, the choices change over time and the reasons for one over the other might not be the same today as they were yesterday. In most cases, choices are not based on available options but by the architecture of the legacy system we are sworn to maintain. If such systems are to be ignored or someone with enough courage and deep pockets would be willing to modernize them, today’s reality would be dominated by containers and microservices. In such a situation, the choices we made yesterday are definitely different from choices we could make today.

CFEngine

CFEngine can be considered father of configuration management. It was created in 1993 and revolutionized the way we approach server setups and configurations. It started as an open source project and become commercialized in 2008 when the first enterprise version was released.

CFEngine is written in C, has only few dependencies and is lightning fast. Actually, as to my knowledge, no other tool managed to overcome CFEngine’s speed. That was, and still is its main strength. However, it had its weaknesses with requirement for coding skills being probably the main one. In many cases, an average operator was not able to utilize CFEngine. It requires a C developer to manage it. That did not prevent it from becoming widely adopted in some of the biggest enterprises. However, as youth usually wins over age, new tools were created and today rarely anyone chooses CFEngine without being “forced” to do so due to the investment the company made into it.

Puppet

Later on Puppet came into being. It also started as an open source project followed by the enterprise version. It was considered more “operations friendly” thanks to its model driven approach and small learning curve when compared to CFEngine. Finally there was a configuration management tool that operations department could leverage. Unlike C utilized by CFEngine, Ruby proved to be easier to reason with and more accepted by ops. CFEngine’s learning curve was probably the main reason Puppet got its footing into the configuration management market and slowly sent CFEngine into history. That does not mean that CFEngine is not used any more. It is and it doesn’t seem it will disappear any time soon in the same way as Cobol is still present in many banks and other finance related businesses. However, it lost its reputation for being the weapon of choice.

Chef

Then came Chef promising to solve some of the nuances of Puppet. And it did, for a while. Later, as popularity of both Puppet and Chef continued increasing, they entered the “zero sum game”. As soon as one of them came up with something new or some improvement, the other one adopted it. Both feature an ever increasing number of tools which tend to increase their learning curves and complexity. Chef is a bit more “developer friendly” while Puppet could be considered more oriented towards operations and sysadmin type of tasks. Neither has a clear enough advantage over the other and the choice is often made based on personal experience than anything else. Both Puppet and Chef are mature, widely adopted (especially in enterprise environments) and have a huge number of open source contributions. The only problem is that they are too complicated for what we are trying to accomplish. Neither of them was designed with containers in mind. Neither of them could know that the “game” would change with Docker since it didn’t exist at the time they were designed.

All of the configuration management tools we mentioned thus far are trying to solve problems that we should not have the moment we adopt containers and immutable deployments. The server mess that we had before is no more. Instead of hundreds or even thousands of packages, configuration files, users, logs, and so on, we are now trying to deal with a lot of containers and very limited amount of anything else. That does not mean that we do not need configuration management. We do! However, the scope of what the tool of choice should do is much smaller. In most cases, we need a user or two, Docker service up and running and a few more things. All the rest are containers. Deployment is becoming a subject of a different set of tools and redefining the scope of what CM should do. Docker Compose and Kubernetes are only a few of a rapidly increasing number of deployment tools we might use today. In such a setting, our configuration management choice should value simplicity and immutability over other things. Syntax should be simple and easy to read even to those who never used the tool. Immutability can be accomplished by enforcing a push model that does not require anything to be installed on the destination server.

Ansible

Ansible tries to solve the same problems as other configuration management tools but in a very different way. One important difference is that it performs all its operations over SSH. CFEngine and Puppet require clients to be installed on all servers they are supposed to manage. While Chef claims that it doesn’t, its support for agent-less running has limited features. That in itself is a huge difference when compared to Ansible that does not require servers to have anything special since SSH is (almost) always present. It leverages well defined and widely used protocol to run whatever commands need to be run in order to make sure that the destination servers comply with our specifications. The only requirement is Python that is already pre-installed on most Linux distributions. In other words, unlike competitors that are trying to force you to setup servers in a certain way, Ansible leverages existing realities and does not require anything. Due to its architecture, all you need is a single instance running on a Linux or MacOS computer. We can, for example, manage all our servers from a laptop. While that is not advisable and Ansible should probably run on a “real” server (preferably the same one where other continuous integration and deployment tools are installed), laptop example illustrates its simplicity. In my experience, push based systems like Ansible are much easier to reason with than pull based tools we discussed earlier.

Learning Ansible takes a fraction of the time when compared to all the intricacies required to master the other tools. Its syntax is based on YAML (Yet Another Markup Language) and with a single glimpse over a playbook, even a person who never used a tool would understand what’s going on. Unlike Chef, Puppet and, especially CFEngine that are written by developers for developers, Ansible is written by developers for people who have better things to do than learn yet another language and/or DSL.

Some would point out that the major downside is Ansible’s limited support for Windows. The client does not even run on Windows and the number of modules that can be used in playbooks and run on it is very limited. This downside, assuming that we are using containers is, in my opinion, an advantage. Ansible developers did not waste time trying to create an all around tool and concentrated on what works best (commands over SSH on Linux). In any case, Docker is not yet ready to run containers in Windows. It might be in the future but at this moment (or at least the moment I was writing this text), this is on the road map and with questionable results. Even if we ignore containers and their questionable future on Windows, other tools are also performing much worst on Windows than Linux. Simply put, Windows architecture is not as friendly to the CM objectives than Linux is.

I probably went to far and should not be too harsh on Windows and question your choices. If you do prefer Windows servers over some Linux distribution, all my praise of Ansible is in vain. You should choose Chef or Puppet and, unless you already use it, ignore CFEngine.

Personal choice

If someone asked me few years ago which tool should we use I would have a hard time answering. Today, if one has the option to switch to containers (be it Docker or some other type) and immutable deployments, the choice is clear (at least among tools I mentioned). Ansible (when combined with Docker and Docker deployment tools) wins any time of the day. We might even argue whether CM tools are needed at all. There are examples when people rely completely on, let’s say, CoreOS, containers, and deployment tools like Docker Swarm or Kubernetes. I do not have such a radical opinion (yet) and think that CM continues being a valuable tool in the arsenal but. Due to the scope of the tasks CM tools needs to perform, Ansible is just the tool we need. Anything more complex or harder to learn would be an overkill. I am yet to find a person who had trouble maintaining Ansible playbooks. As a result, configuration management can easily become responsibility of the whole team.I’m not trying to say that infrastructure should be taken lightly (it definitely shouldn’t). However, having contributions from the whole team working on a project is a big advantage for any type of tasks and CM should not be an exception. CFEngine, Chef and Puppet are an overkill with their complex architecture and their steep learning curve. At least when compared with Ansible.

The four tools we briefly went through are by no means the only ones we can choose from. You might easily argue that neither of those is the best and vote for something else. Fair enough. It all depends on preferences and objectives we are trying to archive. However, unlike the others, Ansible can hardly be a waste of time. It is so easy to learn that, even if you choose not to adopt it, you won’t be able to say that a lot of valuable time was wasted. Besides, everything we learn brings something new and makes us better professionals.

Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user