Mirantis Kubernetes Engine

Formerly Docker Enterprise

Mirantis Cloud Native Suite (Docker Enterprise) is well suited for extracting docker images of large applications and test the application for various operating systems and all. It is well suited for business applications, customer applications etc. and not suited for financial applications because there may be security concerns so use it wisely

Mirantis solution is really helpful when your critical application is containerised and if you are facing any kind of problems related to containers. You don't have to rely on the community for your issue, you can raise a ticket with the vendor and the resolution is quite fast.
It [is] quite expensive when it comes to pricing and almost all the features can be utilized using the community edition which is free.

[Mirantis Cloud Native Suite (Docker Enterprise)] is the most advanced tool till now, which works as a VMs and separates any single application from the dependencies. Also, this tool is helping me in the agile development of the processes. It is strongly recommended to almost all major organizations.

I would definitely recommend Docker to my colleagues if they are planning to build a microservice. The containers not only saves space but also time. The ease of portability helps to pass it among the team and helps them to get the setup ready in no time. It is a great way to save some developers repetitive task.

Swarm is well suited to deploy in an infrastructure of distributed micro-services and orchestrating them from a central platform. It does this job very well, and if you're looking for this functionality, I highly recommend Swarm. However, if you're simply looking for a load balancing and horizontal scaling, I think there are far better and even simpler tools available more suited to that task.

For CI/CD it is the best tool to use. If you want to manage an infra where there are millions of machines needed you need to start using Docker if you are not.

Docker is the best widely-used solution for isolated development environments and predictable deployments. However, for teams that work with only one specific technology stack, using Docker for local development can introduce more complexity. It shines when teams have to move between many different types of projects, but is "overkill" for a single application with minimal dependencies.

It would really all depend on what they are looking to do. We are planning on using it as a monitoring tool for our locations. There are tons of different ways Docker can be used so as it said, it depends on the use case. Not only do I use Docker for my company but I use it at home as well and there it is a beautiful and amazing tool for HTPC users, I just wish I had found it sooner.

Docker gives developers flexibility and repeatable outcomes. It is very useful for developing with confidence and knowing that all environments will behave the same. Not all developers like to use Linux for developing, so being able to run a Linux instance on Windows allows team members to develop on their OS of choice.

It's excellent when you need to run several simultaneous containers and has much better performance than Vagrant or VirtualBox based solutions. It's easier to configure than VMWare. It doesn't seem appropriate if you need GUI access inside the container, I'm not sure that's even possible. SSH access is possible, but a little cumbersome.

Docker is great for when you would want to use a VM for any given application, but don't need the overhead of the whole OS. Docker containers use very little computing resources, boot up very quickly, and are very easy to set up. An instance where Docker may not be appropriate would be for an application that requires good security. If in this situation, a true VM would probably be your best bet.

Docker is great for staging and quickly deploying small to medium projects. With larger projects, it can become a significant challenge to manage all of the containers used for multiple microservices, keeping them up to date, secure and portable to other platforms. One of the goals of Docker is to allow the macro service to be platform agnostic and this can sometimes be more of a challenge than its long-term benefit.

My use case is different from the "main" use case, but for me, Docker is great if you want to test different apps easily in local environments. I have never pushed an app to a server, but testing, creating, and deleting servers with different configurations with 2 commands is DEFINITELY easier than how I did it before. Creating environment variables and many configurations that can be shared across a simple file definitely makes things easier.

If you, like me, know something about developing but very little about Linux and distributions, be ready to test a lot of things and have a hard time achieving what you want. That's not Docker's fault, it's because it's meant for other users who are more "experts" in that field.

It is best managed with cloud providers and setting up your CI pipeline. You probably would set up your images with access to file system,volume, environment variable.

Docker is well suited for providing a simple, standardized deployment of our systems that can be reliably reproduced in both development and production environments. Since using Docker, we have been able to decentralize the deployment reducing the load on our dev ops team and making continuous integration processes easier to establish and more flexible to use.

Docker is great for deploying headless applications like web applications, databases, etc., because it gives you a container environment that can be easily managed with a shell client. If you need to use a UI, it might make sense to use a VM instead.

Great for light frontends and (REST) microservices that don't depend on hardware/drivers and just do DB/file IO. Not so great for dev virtual machines and testing complex network configurations.

If you have an architecture that requires the use of multiple languages or many different microservices, docker is a great tool for managing the development and deployment of these services. It is also excellent for designing fault-tolerant production environments because 3rd-party orchestrators can be used to automatically replace failing applications with minimal server configuration. It may not be the best choice if you have a single monolithic application and a well-defined deployment pipeline.

Docker is well suited if you want to test new technologies or just having a consistent test environment across different machines. Docker also allows you to easily share your current local environment with anyone else regardless of their system. One drawback of Docker is the need to learn some of the quirks such as learning how to map ports and IPs to be accessible from your local machine. In the case where you don't need a strict environment control and only need to do some quick tests, docker can be overkill.

Docker is best suited for deploying Linux based apps. Eventually, it should (or will) be suited for Windows based apps as well.

I most certainly would encourage everyone to try it. It might not be a good fit for their needs, but knowing about it definitely helps. For me it's very useful because of the way we can set up Selenium Grid with it. As official images are released for it, setting up a working Selenium Grid can be done in 1-2 single commands. If you use Docker Compose it's even easier to spin it up, just create a YML file describing the browsers you want to use, and with one single line you can spin up a grid with X number of different browsers and browser instances.

Each Docker container’s purpose is to run a single application. As such, the scope for a Docker container is built towards a particular application, as opposed to an entire operating system. The file system inside a Docker container is isolated to provide an environment similar to a VM. Docker further incorporates container management solution that allows for easy scripting and automation. There is a strong focus on execution time for containerized applications and the ease of scripting. For developers looking for a performance breakdown between a Docker container and virtual machines, a container will win every time. That being said, some applications don't respond well to running in a container, such as containers that have high IO and need high performance persisted data mounted across multiple nodes.

One of the coolest things about Docker that people tend to overlook, I think, is the way it has made public repositories the go-to way to distribute and install software. I’m referring to Docker Hub, which hosts thousands of container images that anyone can grab in just a single command.

Docker is incredibly useful if you're deploying and hosting your own application infrastructure. It leads to reusable components that can be linked together in order to build a fully-functional, reusable system.

However, if your application is simpler and hosted on something like Elastic Beanstalk or AWS Lambda or RedShift, Docker might be overkill for the application development team.

Well suited for:

• Small scale persistent databases.
• Replicating the runtime environment.
• It's also well suited for use with micro-services, where multiple small size databases need to spin up easily and consistently across environments.

It's less appropriate for database instances where backing up instances is not always scalable. It also does not fit well where monitoring instances is important, it requires a lot of additional code to manage instances.