Should Docker be used in a non devops, not very agile environment? [closed]
Imagine yourself at the beginning of a new web app project. The usual infrastructure needs to be set up – databases, webservers, appservers. From the very start you know that this project is going to be very waterfally, with strict devision between dev team, deployment team, ops team, etc. No continuous deployments, no continuous anything.
Does it make any sense to advocate the use of docker for a project like this?
Are there any hidden advantages to using docker that I’m missing?
Edit: The point made by @VonC below is perfectly valid, what I’m looking for here however are arguments for or against embracing docker in the development/release process itself.
2 Solutions collect form web for “Should Docker be used in a non devops, not very agile environment? [closed]”
In that case, docker can be used for specifying a development environment, that is an image which includes:
- the right language pre-installed
- the right IDE with the right settings
- the right tools at the right version
That way, a developper only has to pull and run an image dedicated to dev, and can start working right away, without having anything to configure.
arguments for or against embracing docker in the development/release process itself
This is mainly about the ability to reproduce an execution environment.
That may not be for continuous integration/deployment in your case, but that remains useful for developing in an environment “like” (or “close to”) production, which can be easily rebuilt on the production machine at any time.
- Consistent Development/Production environments (no need for Vagrant or the like)
- Provisioning with Docker is much simpler
- If you want to employ a microservices pattern, then Docker makes a LOT of sense regardless of the lifecycle.
- Making full-use of Docker also forces you to build better apps in my opinion.
- It encourages you to create highly-decoupled/12-factor apps
- Everything is disposable – containers, servers, load balancers, etc. If you have a problem with a server, destroy/replace it.
- Using Service Discovery patterns makes scaling much simpler and much more dynamic
- Docker infrastructure – once setup, scales to multiple applications easily, saving time in the long-run.
- Server clusters
- Service Registration/Discovery mechanisms
- DNS handling & Dynamic Load Balancing
- …all these, once setup, will work for multiple applications