Docker Review

Enables us to run a different operating system and browser combination on a single machine of 16 GB Redhat 7

What is our primary use case?

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

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

We have been using this solution for five years.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

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

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.

How was the initial setup?

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 about the implementation team?

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. 

What was our ROI?

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.

Which other solutions did I evaluate?

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

What other advice do I have?

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.

**Disclosure: I am a real user, and this review is based on my own experience and opinions.
More Docker reviews from users
Add a Comment