Why dockerize a service or application when you could install it? [closed]

Question

We have around 12 services and other applications such as presto.

We are thinking about building Docker containers for each service and application. Is it right to dockerize all of them?

When would a Docker container not be the ideal solution?

Answer 1

Docker is a recipe for consistency and reproducibility.

To make a nice cup of tea, you need boiling water, put some tea bag in it and let it brew for three minutes. How you achieve boiling water is absolutely irrelevant.

Now let's imagine that you need to serve up 12 cups of tea. Does your staff know how to make a proper brew? Does your staff know how to use a kettle or a pan? What guarantee do you have that each cup of tea will be the same?

You could spend a lot of time training people and make you sure you have all the appliances you need. Or you can invest in a machine that will produce the same cup of tea over and over again.

The analogy may seem stupid but my point is that relatively common problems already have well-known solutions.

Unless it's a one-off scenario or you have additional constraints we don't know about, what reasons do you have to not consider Docker?

Answer 2

You should containerize all Linux-based services that are stateless and require frequent upgrades/changes/patches. These include all types of front-end and application servers.

Databases/datastores, on the other hand, are a more complex case, since there are issues of performance and data persistence/integrity. Also, databases are not upgraded/patched as frequently as front-end applications.

*Windows containers will only run in Windows.

Answer 3

PROS:

1. Quick local environment set up for your team - if you have all your services containerized. It will be a quick environment set up for your development team.
2. Helps Avoid the "It works on mine, but doesn't work on yours problem" - a lot of our development issue usually stems from development environment setup. If you have your services containerized, a big chunk of this gets offloaded somewhere else.
3. Easier deployments - while we all have different processes for deploying code, it goes to tell that having them containerized makes thing a hell lot easier.
4. Better Version Control - as you already know, can be tagged, which helps in VERSION CONTROL.
5. Easier Rollbacks - since you have things version controlled, it goes to say that it is easier to rollback your code. Sometimes, by just simply pointing to your previously working version.
6. Easy Multi-environment Setup - as most development teams do, we set up a local, integration, staging and production environment. This is done easier when services are containerized, and, most of the times, with just a switch of ENVIRONMENT VARIABLES.
7. Community Support - we have a strong community of software engineers who continuously contribute great images that can be reused for developing great software. You can leverage that support. Why re-invent the wheel, right?
8. Many more.. but there's a lot of great blogs out there you can read that from. =)

CONS: I don't really see much cons with it but here's one I can think of.

1. Learning Curve - yes, it does have some learning curve. But from what I have seen from my junior engineers, it doesn't take too much time to learn how to set it up. It usually takes you longer when you are figuring out how to containerized.

SOME CONCERNS:

1. Data Persistence - some engineers are having concerns with data persistence. You can simply fix this by mounting a volume to your container. If you want to use your own database installation, you can simply switch your HOST, DB_NAME, USERNAME and PASSWORD with the one you have in your localhost:5432 and all should be fine.

I hope this helps!