Mirantis Container Cloud Reviews

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.

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

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.

The solution's stability could be improved. 

I have been using Mirantis Container Cloud for two years.

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.

The solution is scalable.

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.

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. 

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.

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.

Did not use Mirantis Container Cloud in the organization.

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.

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.

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

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.

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. 

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.

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.

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.

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.

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.

The solution containerizes software. 

Mirantis Container Cloud needs to improve its documentation. 

I have been using the solution for half a year. 

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

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

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

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

I rate the solution an eight out of ten. 

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.

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. 

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.

An improvement would be automated testing.

I've been using this solution for three months.

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.

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

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.

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.

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.

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.

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.

I have been using this solution for approximately two years.

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.

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.

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.

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.

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.

The solution is open-source and free to try.

I rate Mirantis Container Cloud a nine out of ten.

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

The solution is simple and faster.

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.

I have been using Mirantis Container Cloud for six months.

There were no issues with the solution.

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

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

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

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

We use the product for deployment purposes.

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.

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

We have been using Docker Enterprise for a year.

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

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.

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.

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.

We use Docker for the construction of container-based QA environments and the development environments as well.

On Selenium containers, we had about 550 test cases that we ran across 17 browsers and OS combinations. We could have run this on any of the third party products, but what we're able to do is done using Docker containers.

We were able to run a different operating system and browser combination on a single machine of 8 GB. We were able to run all the 550 test cases simultaneously on 16 OS and browser combinations just in the testing.

The required time was around five days for five test cases. With Docker, we were able to reduce it to two days.

The main Docker feature is the repository where you can store images.T he image is available and you can read parts of those images. You can use it for your local development and QAs. That's the most basic Docker basic feature. 

Secondly, we like the footprint that Docker requires to construct an environment. 

The third most important aspect is maintenance. You won't have to rely on third-party support. If you have the full environment control, you will be able to maintain Docker containers on your own. Or you can just destroy them and construct a new container, i.e. add them when you want to, ephemeral and mutable objects.

You need to be aware of the complete networking aspects of Docker across walled communications. That is something that you can simplify. For a developer, it is easy to understand if you have networking knowledge. 

If you are just a developer without networking knowledge, it's very difficult to understand how to communicate across walls using containers. Especially if you're in a call data center. That's the one aspect which I find very difficult.

I'm a coder. I've wanted to see an easy way to integrate seamlessly with other systems. For example, Jenkins has a Docker plugin. If you were to write an integration, you need to explicitly write code, especially for customizations. It's not easy to integrate unless you are a coder. 

If Docker can create some kind of workflow in generic fields, i.e. things that we can integrate with other out of the box tools, that would be great. OpenShift is an alternative to Kubernetes. 

I find Docker easier to use, but I gave it to an inexperienced developer and it took him a lot of time to understand.

Scalability with Docker is another aspect of adoption. Although we are using OpenShift and Kubernetes sparingly, I think we're able to achieve more with Docker. The developers can scale.

Beyond that, Docker requires a lot of discipline and also pushing cultural change. It is technical in that you need to educate people about it. In terms of scale, I find the scalability more of a culture and discipline issue in our environment, rather than a technical issue. 

There are three types of people who are using Docker:

• The developers (those include QA as well), i.e. scrum teams.
• The business analysts.
• The product owners.

We have product roles: an implementation team and the architects. Those are the types of people who are using the Docker solution.

For every 30 people, we have around three people supporting the pipeline. This makes sure that the Docker files are up to date. They're the gold standard. If we are using Docker Compose, Docker Compose will supply it. 

We use Docker a lot. With any required file, they just need to make sure that the changes are up to date and there are no conflicts. 

We started with one team. Now able to scale it. In the current project, we started eight months back. We started with a six-member team. Now, there are eight plus 64 members using this platform. 

We have plans to increase usage to 3000 developers.

It's tough. We're not there yet for the Docker technical support. Docker's technical support is a struggling area. We're still not able to progress in that area.

We were not using a different solution. We were using the VM-based solution from VMware in the data center for pipelines and Jenkins pipelines without container-based environments. 

Those are VM-based and the footprint is high. They're not maintainable. We need to rely on somebody else to maintain those environments. 

They are not self-contained or self-sufficient environments. That's the reason why we switched out to container-based solutions.

The setup of Docker was very straightforward. Maybe for a beginner, it may be difficult. If you are in a Windows 7 environment, it's very difficult. Some of our systems are in Windows 7. As soon as we ran Windows 10, it was easy. If Docker was run on Linux, Mac, or any Unix product, it was pretty straightforward.

The entire pipeline is for eight teams. If you're pushing all the way through, it takes about four and a half hours including the test execution. There are around 100 test cases, including the unit tests, that need to be done for a simple change. That was taking about three days.

We were able to push through in four and a half hours by including NetWare. For our implementation strategy, we used a Docker-based continuous integration/continuous delivery pipeline.

What is demonstrated on the laptop with Docker, we have full control of in the data center. When you translate to implementation, half the things don't work. 

In spite of the expertise, that's the problem with SIs, i.e. the promises versus what is delivered. That's one aspect that we're still struggling.

Docker is fairly stable because you just carry the artifacts, but in DEV it is highly unstable. There's a lot of discipline that we need to enforce on the developers. 

On the deployment front, we saved about six developers worth of effort for every 64 people. Six developers worth of effort for two months in a six-month project of 64 people. That's the ROI that we easily got once we stabilized.

We did not evaluate other options because the only one that we knew was Docker.

I recommend using Docker. The most important thing is that you review your internal capability building before using this product. 

• Look at what kind of skill sets are currently in the organization. 
• Make sure that everybody understands what Docker means before implementing. 
• Up-skill them and make sure that everybody understands why Docker is important in the scheme of things. 

Some organizations may think that Docker doesn't fit their culture. In general, I think that Docker is a good fit for 80% of the organizations that I've seen.

Internal capability building is the other thing that is very important in the setup. You need to make an architectural runway before actually starting to implement Docker Compose, especially in a distributed environment. 

For security aspects, we need to make sure that the security and monitoring for Docker are always in operation. 

I would rate this product a 7.5 out of ten because it solved many of my problems. If you're a developer, it's easy to understand. It is the way a developer should develop and deploy in the current environment, especially in a container-driven world.