What is our primary use case?
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.
What is most valuable?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using it for more than four years now.
What do I think about the stability of the solution?
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.
What do I think about the scalability of the solution?
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.
How are customer service and support?
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.
How was the initial setup?
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.
What was our ROI?
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.
What's my experience with pricing, setup cost, and licensing?
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.
Which other solutions did I evaluate?
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.
What other advice do I have?
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.
*Disclosure: My company does not have a business relationship with this vendor other than being a customer.