Docker Reviews

My main use case for Docker is building and testing Docker materials built by other people and also other systems. I do a lot of voluntary GitHub work and development, so some of that runs on Docker. I have been building browsers and other applications which also rely on Docker, so databases running on Docker and containers running on Docker are part of my workflow. Regarding my main use case for Docker, I mention reliability and local building.

In the best possible scenario, Docker allows me to run a really complex Docker container locally and then be able to test it and quickly get fixes in. When I send the information to the senior developers for them to fix the issues that the Docker containers or those operating systems or software have, I am able to quickly get to the GitHub repo, get the newest version, and try again with Docker.

Docker impacts my organization positively because we all use it and we haven't moved away from it. Docker is pretty much mandatory and required and needs to be there. People use it, set it up, and then they're happy with it, and then we use it.

Using Docker has allowed me to test faster, and software development has moved faster.

The main thing that really frustrates me about Docker is how much battery power it consumes on a Macintosh. I really am not a fan of that, which leads me to not want to run Docker 24/7 because I do not want my laptop battery to be exhausted by Docker instances running or even the Docker CLI or UI being booted up. I tend to not have it running until I need it, and then I run it and close it. It would be really nice if it did not consume as much battery as it does currently.

Docker can definitely be improved by reducing the battery and CPU load that it impacts on a Macintosh. If it were possible for me to run Docker without panicking about the battery running out, that would be excellent. I believe battery is the biggest issue with Docker. The other issue is memory. It seems to consume a lot of memory, and I am not a fan of that. This means that I need to have a really powerful, high-specification Macintosh with a lot of battery and a lot of memory for it to work reliably. I do not always have access to that. If Docker could consume less battery and less memory, that would be magnificent.

I have been using Docker for nine years.

Docker feels like it is stable, but it also feels like it consumes a lot of battery.

Docker's scalability is such that the more I use it, the more battery it uses, and that is the only metric that matters to me. I want my laptop to be usable and not to choke up and run out of battery.

I did not previously use a different solution.

I was not the person who chose Docker and I did not evaluate any other options. We went with Docker because that was the one.

I have been using Docker for nine years. I believe Docker makes the process of being able to run complex containers locally and quickly test and fix things the smoothest it can be. I have never had any annoyances after the Docker environments have been set up. Sometimes I have had to help with the documentation and setting the Docker environments up, but most of the time, it is really good and really useful. It is just better.

The development speed and velocity have increased by me being able to test on Docker.

My advice for others looking into using Docker is to get multiple battery laptop chargers. Get multiple and keep them around at all times. Stock up the office with battery chargers and laptop chargers. Give people two for home, two for a backpack, and two for travel. Make sure that they constantly have laptop chargers available to them and that they are of the fastest possible quality and the highest quality and reliability.

The main issue is the battery usage, which keeps Docker from being rated higher.

My overall review rating for Docker is 7 out of 10.

I used Docker to Dockerize Java code. We had a code base, and I needed to create a Docker image from it so that it could be deployed. At the time, we used Docker Compose, which is somewhat similar to Kubernetes.

Docker allows virtualization at a higher level without the need for a host machine. You can have a few libraries in the image, and it will run on any machine, making deployment easier. This approach reduces the number of headaches compared to traditional methods.

Docker provides another level of virtualization where you don't need the host machine. The ability to use an image with the software built into it, rather than just the software, is beneficial. It allows the software to run on various machines without compatibility issues, saving a lot of time.

Docker is a time-tested, proven solution with industry-wide applications. There can be challenges with port mapping, however, that's not related to Docker itself.

I started using Docker when I began my career in cloud computing. It has been approximately five or six years since I last created a Docker image.

Docker is fairly old, and there are existing GitHub repositories for any issues that arise. We can often resolve these issues ourselves through online resources.

Docker is highly scalable. Without the need for physical hardware, you can run multiple images on your server. Previously, only one or two applications could run on a server, but now it can handle hundreds of applications, scaling up or down as needed.

I have never had to contact Docker's support team.

Positive

The initial setup is not difficult, especially with Docker Desktop. It allows you to manage images easily without having to run commands if you prefer not to.

Docker is well-established in the market. Most people in DevOps or IT are familiar with Docker or creating Docker images. It is easy to use.

I'd rate the solution ten out of ten.

We are a service provider and we have various use cases. However, the most prominent one is that instead of virtualizing the application workloads, we use Docker. Docker allows you to create small applications and containerize them. You can create multiple such application containers that can run simultaneously on the Linux operating system.

We use Docker because if we want to create an application using Node.js, an environment for backend and frontend technologies, we can deploy this single application in a container. This container will run independently of its underlying OS. 

If you want to migrate this application to a different server, migrate the container image to the new server and start using the application there. This makes developers' jobs much easier because they don't have to copy everything the application needs. They just copy the container image, send it to a different server, and start using it there. All the required libraries, packages, and dependencies are encapsulated within that container. The container contains everything it needs to run. In a DevOps environment where multiple teams are creating applications, developing new versions, and deploying applications frequently, Docker is very helpful.

The greatest benefit of the solution is that you can create applications and multiple versions of the same application, distributing them across various Linux platforms. Setting up Docker is very quick; whereas setting up a Linux operating system can take five to ten minutes, you can set up a Docker-based Linux OS container within minutes. Docker also has a small footprint on memory and resources because it uses the system's resources efficiently. It operates within its environment, independent of the underlying operating system, running in its namespace. This isolation prevents negative impacts on the system.

For developers who frequently create and deploy applications, Docker makes it easy to quickly develop, deploy, and run the latest versions. You don't need to manage the operating system, applications, dependencies, or data separately; everything is encapsulated within the Docker container itself.

Moreover, AI is another application you can use through Docker. AI can help you set up more efficient Docker-based workloads. The role of AI is to guide you and provide the necessary knowledge for various tasks, whether it’s related to Docker or anything else. Additionally, AI itself can run as a container using Docker.

There's always room for improvement. Sometimes there's a bug or defect in the solution. However, the Docker team works on fixing it.

The solution’s stability is great. I rate it a nine out of ten.

Regarding scalability, Docker doesn't require any separate configuration for multiple users. Suppose you create a container and expose it to the public via an IP address and port. The ability to serve the number of users depends on the system's resources, like RAM, CPU, and storage. You can create or scale the number of containers based on these resources, and manage the number of users accordingly.

For example, if I have a small server, I can create containers and share them with the outside world according to the available resources. The server's ability to handle the number of users depends on its resources. Docker doesn't restrict you to a certain number of users; hundreds or even thousands of users can access the containers. Most of our customers are using the product.

The initial setup hardly takes minutes. All the container images are available on Docker Hub when you create a container. Docker Hub is a repository, like an App Store for containers. If you use Windows or Mac, you have an App Store where you can download and start using any application you want. Similarly, Docker Hub is the application store for containers. It's a cloud-based solution. In Docker Hub, you can find all kinds of container images. If you want to install an Apache server, a Postgres database server, or any other server—even Linux and Windows servers—they are all available in containers. Anyone who wants to use these can immediately download and start using the container image.

Our customers buy the software and the prices are available on Docker Hub. The subscription is typically yearly, and customers will need to buy the subscription directly. They can purchase it themselves.

The product is similar to GitHub.

If you are trying to create an application quickly for testing or development purposes, Docker is the best tool available. Docker can also be used on Mac and Windows with a tool called Docker Desktop. You can start using Docker there by installing Docker Desktop on a Windows or Mac system.

Whenever a new Docker image is created by the OEMs, like MySQL for instance, they name the new image with the version number. If you want to check the latest version, you can go to Docker Hub and search for it. There are multiple versions available, and Docker also allows you to create your own version. So let's say your company has specific requirements for MySQL. You can download the original MySQL image from Docker Hub, install a couple of additional applications within the Docker container, and share this customized Docker image via your own repository on Docker Hub.

There are two kinds of updates: one within the Docker technology itself, where the creators of Docker keep updating the Docker engine, and another for the Docker images. The Docker engine is the software tool that runs on your system, and the global team working on it keeps it updated. You can always check for the latest version of the Docker engine and upgrade as needed.

Moreover, container orchestration is a different technology. You need Kubernetes to orchestrate the containers in the solution. A single container is independent, but Kubernetes is an orchestration tool that manages these containers using its control and data planes. For example, if you have hundreds of containers, it takes work to manage each one independently. You need some orchestrator to control these containers' life cycles, maintain high availability, and more. Kubernetes handles this container orchestration.

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

I work with startups and companies looking to build products from scratch to production. I handle deployments from various teams and use AWS. My experience includes deploying applications, setting up APIs, adding load balancers, and managing traffic. Docker is essential for this work, allowing me to create sandbox environments to run applications. Essentially, Docker helps manage clusters of applications and maintain the cloud environment.

The tool's most valuable feature is its sandbox environment. It makes it very easy to run and test applications without needing configurations, which is the core advantage of containerization. Kubernetes and Helm are helpful as they provide high-level metrics, making tracking the status of all the containers and applications running easier.

One of the challenges I face with Docker is debugging containers within the infrastructure. It can be tricky to debug applications inside containers, which is a common issue among developers. If easier tools or methods were available to debug applications within Docker containers, it would be very beneficial.

I have been working with the product for two to three years. 

I have never contacted support since documentation is available on the issues. The community is huge, and the documentation is pretty good. Additionally, there is information online that I can refer to.

Overall, setting up the Docker environment is quite easy. Many methods exist, such as using Docker Compose and Docker networks to communicate between containers. The main challenge lies in designing the architecture and integrating different frameworks and microservices.

I would rate the ease of setting up the tool at around nine out of ten. The time it takes to deploy depends on the scale of the system. For the early-stage startup I'm currently working with, it doesn't take much time. It's just me handling the deployment. In our early-stage startup, we have a couple of teams with around four to five backend APIs and two front-end services. Deploying these doesn't take much time. My focus is more on minimizing costs due to our lean startup structure.

Using the solution containers saves a lot of time compared to deploying on EC2 instances. It simplifies deployment and greatly reduces the deployment time. So, the internal ROI is quite good, making Docker a very valuable tool for us.

Regarding pricing, we primarily use AWS for our deployments since we have funding for it. We don't spend much on Docker-specific services, just the containerization product. Docker Hub isn't particularly expensive either, so overall, the pricing is pretty reasonable.

I'm a backend engineer and handle major deployments—I'm the only one on the team who does this. I help deploy and configure the product and expose endpoints for other teams. If a service stops working, they contact me to address the issue. I also maintain the deployed environments, including building, testing, and development.

I rate the overall product a ten out of ten. 

In our company, I mostly design 5G networks and my work revolves around virtualization of the 5G core, which is known as backhaul. In our organization, we use many containerization technologies to obtain a proper ROI.

No-code servers and other servers are used in a combination predominantly as part of our company operations, which is the most relevant approach in the service provider or enterprise end. For small-scale customers of our organization, we use a combination of Kubernetes and Docker to drive adoption. 

One of the main use cases of Docker is resource utilization. Like traditional VMs, there is no need to depend upon reserving resources and it's much easier to spin up required instances for consumption using Docker. 

The capability of the solution to convert an application into a Docker image is a vital functionality. 

The learning curve with Docker is huge and extensive. Adopting Docker is a bit difficult because it requires a lot of expertise and background, including an understanding of networking and security concepts. Many professionals are facing issues with the different architectures that interact with each other in Docker.

Whenever in our company, we are working with the production environment, professionals are hesitant to adopt Docker due to the extensive learning curve, and most of the team members in our company are more accustomed to an environment like VMware instead of Docker. 

Docker runs on scripts, so if AI can automate most of the scripting process in Docker, it would be a great advantage in the future version of Docker. As of now, we can create scripts utilizing most of the functions within Docker, but that initial planning phase wherein to understand exactly how you will plan for the resources, how you will convert applications into a Docker-based image, and similar tasks needs to be simplified so that more professionals can adopt Docker.  

I have been working with Docker for almost four years. 

I would rate the stability an eight out of ten. Docker provides a highly stable environment to work with. 

I would rate scalability a five out of ten. In Docker, it's very difficult to predict how scaling works and this is where automation should be implemented. I would recommend Docker for small and medium-sized businesses as it provides a practical environment that can facilitate cost-savings. Docker also doesn't have critical workloads.

The applications used in critical workloads consume a high proportion of traditional server and physical infrastructure; by using Docker, the efficiency can be enhanced ten times. Docker is definitely a great option for small businesses that are trying to deploy applications on the cloud. Whether primarily deployed on-prem or cloud, with Docker the application can be moved in between them. 

I personally depend on the Docker community to resolve my issues with the product and avail support. 

The setup process of Docker is extremely simple. Docker is compatible with multiple operating systems, including macOS, Windows, and Ubuntu. 

I would rate the pricing of Docker as ten out of ten.  

OpenShift is gaining more popularity than Docker because it is used in enterprises that follow the traditional model. OpenShift is from Red Hat, and many enterprises are already running Red Hat-based systems at the back end, so it becomes much easier for them to move to OpenShift than to migrate to Docker.

For Docker based adoption, the entire existing infrastructure needs to be changed to migrate into the Docker environment but for OpenShift the older architecture just needs to be brought into the latest architecture. 

For container management, Kubernetes is our primary tool of choice in our organization, and we recommend the same for most of our customer's enterprise environments, but now we are witnessing a high adoption rate for OpenShift which has all the features of Kubernetes.

At our company, we are also noticing the rise of another competitor tool for Docker, which is called Amazon EKS, which runs on the cloud with a Kubernetes background. I can easily manage my public and private cloud using the same containerized environment and one single orchestrator. 

There are complexities in integrating Docker with other CI/CD tools because the available documentation is not straightforward. An expert is required with hands-on project experience to integrate Docker with other solutions. 

The solution should provide better deployment documentation with added project examples that can be used like a workbook by professionals. The vendor should develop and provide some explainer videos around Docker with a major focus on how AI has came to the picture and how Docker will provide integrations with automation and a Generative AI context. I have had two or three instances where I had used ChatGPT to deploy a code on behalf of me, but it took three of my colleagues to understand the AI-generated code. 

In recent days, I have noticed that enterprises are not adopting Docker, and they are choosing a solution like Proxmox. Other competitor solutions to Docker are easier to use, so the usability factor is causing the adoption of products other than Docker. But I would say Docker has a more mature environment than the competitors. 

The product is still at an early stage in terms of security. The basic aspects of security are covered, but there is a lot of room for improving the solution's security. Our organization works on container security and Docker should improve on container security. 

If you are working on Docker, you need to have expertise in the product, it's security, architecture and resource planning. I would choose OpenShift over Docker. I would overall rate Docker an eight out of ten. 

I'll definitely recommend Docker to users, especially to professionals who are working with a cloud-based environment, server-less architecture, or developers who are trying to build efficient applications. Docker is an excellent learning platform to initially get accustomed to basic architectures before shifting to more complex architectures like OpenShift. 

Instead of building images for underwriting systems, we pull pre-existing standard images. This allows us to quickly set up the necessary environment for development. For example, if I need a database instance, I simply pull the Docker image and create it, rather than going through a full installation and build process. We also leverage these images to create small, stackable components for building solutions. This streamlines our workflow and enhances our ability to upgrade and adapt quickly.

Docker setup itself is a useful thing because Docker itself is running your environment in a separate isolated box. So, it's not that things will be deployed or installed on your local system. Things (as in the development environment) will be separate. 

Then, the development environment can be segregated from the local underlying hardware. Your instances can be separate, or whatever you build, the application itself can be covered in one single Docker image at the end of it. All these things can be done. It saves part of the configuration and installation time of the initial local setup of the development team. 

So whenever I'm developing something, the time required to set up the local environment and the time required to set up other developers' environments will be radically reduced. So that is a great thing that we have.

TL;DR, Docker helps to reduce the time to set up the environment.

Important features for CI/CD workflows:

For CI/CD pipelines, instead of building separate deployable files, we package our solutions as Docker images. This allows us to compose the entire solution using Docker, which improves our deployment process. 

We create Docker images for each build and push them to a registry. These images are then pulled and deployed in our environments, streamlining the entire process.

Docker volumes. When I integrated volumes, I faced challenges. I have not essentially used add volumes to the existing instances. Maybe, I am not familiar with adding volumes to the existing Docker images. That might be a challenge, but it should be fairly straightforward. I'm just not aware of it. So just for me personally, it is a challenge.

Docker has all the major support already. They should publish all the build images of Docker on an open-source resource like Github. They should support all the stuff.

For example, now Docker supplies all these standard images, like database images or whatever image that the standard application is related to. Whenever there is Docker Compose information available on an open-source community project, that image should also be maintained and supported by Docker itself instead of the dev team doing it. Docker should take an interest in building those images and maintaining them for the public community projects that are hosted.

I have been using it for more than four years now. 

There were some issues with Docker images. In the Alpine image, I downloaded the one. There were some packages that you are not able to deploy on specific Docker-based images.

It is not directly a problem with Docker itself, but with the base image that it is starting. Like the Alpine image, the Linux image being used as a base for Docker. That was not compatible and had some package issues, which prevented us from deploying our solution on top of it. All the libraries we had were not going clean on it.

There needs to be a support matrix to identify which Docker base image can support which packages. The package team should tag these things to those base images, indicating which base images are supported. Once they have this matrix, both the package and the Docker base machine should have it.

It is difficult for a developer to understand and see a problem at the end once you develop and deploy. You stumble upon these problems, then you fix them. It takes a lot of time. You need to upgrade, rebuild, and rearrange. That is the only issue I want to clarify.

There should be a mechanism to identify which images should be supported.

Docker is quite stable. I don't see an issue there. I never saw a Docker image going down.

I don't see any issues. At least from my experience, I don't see anything going wrong with an image that I have used.

For stability, I mean it is up and running for a long time without any issues on the Docker side.

Overall, I would rate it a nine out of ten. 

Docker is very good at scaling up applications. There is no problem with scaling. I'd rate it a nine out of ten. It's good. 

In my earlier company, almost the entire team used Docker. The last team I had a year ago had eight members, and we all used Docker images for our development.

There is a good amount of documentation that quite helps. Every question that I had is addressed in the documentation or on the forum. I've got all the answers I needed. 

I didn't have a chance to raise a specific issue or interact with support directly. Everything is documented, and there's a lot of information available, so I didn't need to raise a support ticket.

The initial setup is quite easy. I don't find it difficult. 

For Windows, it can be a bit confusing, but for Linux, it is quite easy. Both Linux and Mac can do it very easily. However, for Windows, I did face some challenges, it doesn't work as smoothly on Windows.

For Linux and Mac, I would rate my experience with the initial setup as a nine out of ten, with ten being easy. For Windows, I'd give it around six to seven.

• Deployment model: Mostly, everything is on-premises only. We have not used anything on the public cloud.

• Deployment time: That depends upon the application setup and the dependencies. Generally, Docker itself does not take much time. It’s purely based on the application and its dependencies. So, it should not take more than a few minutes. Two minutes, maybe a maximum of sixty seconds. It's quite fast.

ROI is there in terms of efficiency. Adding the development time setup or the build time required is quite easy, and we always eliminate the environmental differences between one environment and another. 

For example, the underlying machine can have anything, and the developer can have anything, but still be able to run the application or whatever is being developed. It eliminates issues with the underlying hardware or operating system.

The offering and service are quite free. We have used only the free instance, and we are also on-premises only. So there's nothing that we have had to pay for.

Docker is the most prominent one. I didn't see any other choice there. But after Docker, Kubernetes started kicking in, and we are using some Kubernetes as well. However, we still use Docker images. 

Docker and Kubernetes are not parallel but complementary. We are ramping up with Kubernetes and understand how we can orchestrate it. 

It is a quite mature technology. People can simply use the existing features available, which will really help their development and make it much easier. Definitely, it will have all these benefits built along with it.

Overall, I would rate it a ten out of ten. 

In our company, I have used Docker to launch an application publicly. The aforementioned application becomes available to end users via CloudFront. Docker is also used to cache the optimized performance.  

Docker hasn't been directly able to improve our organization's deployment processes. 

Docker offers a resilient system with minimal failure chances and optimized performance. For example, if an EC2 is utilized, the software container can be customized to allow only the specific benchmark of resources to be used. I found the solution to be easily customizable. 

The vendor should release a monitoring tool or include monitoring capabilities in Docker that can be used to monitor container performance and other Docker-based solutions. 

I have been using Docker for two years. 

I would rate the stability a nine out of ten. As containers are isolated and not dependent on each other, stability is satisfying in Docker. With the solution, when one service is down at the production end, it won't affect the functionality of other services running in parallel. The solution can be considered stable 99% of the time. 

I would rate the scalability an eight out of ten. Docker offers satisfying scalability features, and it depends upon the correct configuration being run within the virtual machines. Scalability in Docker is easier to manage than in legacy-based documents.

Presently, Docker is used by only me in our organization. Docker is an open-source solution. In our organization, we work with Docker on average once a week. At our company, we are not planning to increase the usage of Docker. 

Previously, applications were directly deployed in the server in our company instead of packaging the applications and running them on isolated environments. For instance, if any application experiences outage, it affects the other services as well, but with Docker this issue doesn't arise. 

I would rate the initial setup a ten out of ten. Docker offers an effortless setup process. As part of the setup, I have faced some configuration failure issues in Docker compose utility, but I was able to resolve it on my own with some changes in configuration. A feature of Docker can be made live in 20 to 30 seconds but the total deployment of the solution took me around one and a half days. 

As part of the deployment process, I inputted the code in the local environment and tested it on my personal computer using the Docker desktop utility. Following the aforementioned step, I pushed the code to the cloud and cloned it in EC2. Then, I developed a few necessary configuration files for Docker deployment and building.

As the last step of the deployment, the commands are run successfully to make the solution go live. Only one professional is enough to deploy Docker. To implement maintenance for a production-based cluster, a team of three professionals, one lead and two other team members, is needed. 

It's an open-source solution, so it doesn't cost anything. 

Docker is a trending tool and is being used for numerous production based applications, so instead of evaluating multiple tools, our company adopted Docker. 

I find Docker to be a user-friendly product. Docker acts as a stand-alone application without any dependency on other hardwares, so it can be used in an isolated environment. The tool can be easily customized. 

In our company, the product is running on EC2. I have restored all the required packages and need to compile the code within a container using the Docker tool. After the aforementioned step, Docker is used to run a few specific images where images are not dependent on each other. If one of the running images on Docker malfunctions, there won't be any cases of outage because the environment remains isolated. There is no interdependency between containers in Docker. 

Docker's container orchestration capabilities support our organization's projects with minimal downtime and low failure chances and offer a robust system. Our company has a Docker compose utility to customize the workflow and make it operate smoothly. Overall, I would rate the solution a nine out of ten. 

We use Docker for validation mechanisms and have built Docker images for our applications.

For container orchestration, we haven't used Kubernetes instances extensively. Docker works well for us.

It's flexible and easy to use. My team also finds it comfortable to work with.

Sometimes, it can become heavy and cause performance issues.

The stability is pretty good. 

We use horizontal scaling, and it works well. Considering its container architecture, I'd rate the scalability a nine out of ten. 

There are probably around 2,000 to 3,000 end users. It is extensively used. 

We have used Docker's technical support. I didn't have bad experience with the customer support. 

We used Kubernetes and other packaging techniques. 

Portability and accessibility were the main reasons we chose Docker. 

The initial setup is mostly straightforward. We used Ansible for deployment.

The ROI is high. Traditional deployments take more time and builds can be inconsistent across different environments. Docker solves these issues.

The value is there. Docker delivers high performance, leading to increased productivity. You can achieve more in less time, and your deployment cycle time is reduced.

I would rate the solution an eight out of ten.

AI with Docker is relatively new for us. But for traditional deployments like microservices and Spring Boot applications, Docker works very well.

I definitely recommend it. The landscape is changing, and Docker is transforming the way we approach deployments.

Currently, we are creating a JAR file and using microservices. There are around 178 services in a single project. We use Docker to manage and do load balancing for all the services together.

We are using Docker to host applications. We are using Docker Compose and sometimes Docker Screen.

We are facing multiple issues with the solution's stability.

We have been using Docker in the same project for five years, and we have recently deployed Docker into Kubernetes for four years.

We are facing multiple issues with the solution's stability. It is very difficult to analyze how much load a tool takes. Sometimes, our Docker images get crashed due to the unavailability of space.

I rate the solution a six or seven out of ten for stability.

Approximately, 400 users are using the solution in our organization.

I rate the solution a nine out of ten for scalability.

The solution’s initial setup is simple.

We implemented the solution through an in-house team. It took me around three to five hours to deploy the solution. Docker is easy to use and implement. For the deployment process, we used Docker in the CI/CD pipeline. Then, we pushed the Docker images to the Kubernetes as per the environment. We used Kubernetes to host and balance the load.

Since Docker is an open-source solution, it is free of cost.

Docker made it easy for us to monitor the microservices. Secondly, we were able to manage the key load balancer. Thirdly, we wanted to create a secure layer of protection for our organization. So, we started using the containers above the hypervisor.

It was like using a new operating system. We created our own network adapters. We created another isolated network inside the Docker containers to keep our organization and project safe and secure. We consider this very helpful in the secure software development life cycle.

We're implementing multiple stages in security. We are signing Docker images, Docker containers, Kubernetes containers, Kubernetes nodes, and clusters in cryptography. We are signing these so that no one tampers with the code or the docker images. We are doing this from a security point of view.

The solution's containerization helps us in providing integrity and availability. If you use a microservices architecture, I recommend implementing Docker and Kubernetes. I would recommend Docker and Kubernetes to manage multiple microservices running simultaneously.

We had to configure multiple services, like the utilization of the CPU and the utilization of the RAM for the service that we were building. Additionally, we had to mention the network adapters we will be using. We followed multiple benchmarks, like NIST Benchmarks and CIS benchmarks.

There were multiple advantages to using Docker. The most important advantage was scalability and availability. As I am working in the security team, I'm looking after the integrity of the Docker images.

Overall, I rate the solution an eight out of ten.

We set it up a lot of times to create environments for our students. 

When we teach our students, it's really important that everybody is on the same version of all their dependencies. So, Docker, we can set up the images on Docker, and it sets everybody up. 

So it's a much smoother process. Without Docker, without these containers, it would be a nightmare trying to get 20 to 30 students to set up their environments correctly. So this is just a really quick and easy way to use it.

Just the portability of Docker's containers and its ability to give everybody the exact same environment and experience is most valuable to me. 

It could be easier to create images and save them on reports.

Just improved development workflow, just quicker, like some better user experience creating the images for the Docker containers.

We have used it every day in my current company just to set up our environment for our build processes. We create a lot of labs.

We use the latest Docker version 4.22.

It is a very stable product.

It is extremely scalable. I would rate the scalability a ten out of ten.

The initial setup was very easy. I use it on-premises as well as in the cloud. So we use it in both places.

It's free, as far as I know. 

Docker is very reliable. It's easy to scale, and it's very stable.

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