<p>I'll give you my perspective. Developers should care about docker as there are other developers who are willing to use docker and have already built an expertise in it. They are willing to take up the roles of a DevOps engineer along with being a developer. So the Ops part of DevOps is what they are now building expertise on. </p>

<p>These days, you'll find more and more guys who can develop, orchestrate, automate tests, automate jobs and build tools to monitor and take this complete package into production single-handedly. These are the guys who are pushing docker and other tools among the developer community. </p>

<p>Also, the tide of market is towards virtualization, auto-scaling, automation, machine learning and docker fits in all of these. It has become very imperative to use docker. The businesses are willing to pay 2x for a single guy who takes all these responsibilities and when there is demand for such guys, the supply will also begin. This is from point of view of an employee-employer.</p>

<p>Technically, in the organisations I have worked, there are separate development and DevOps teams, although they work very closely for deliveries.
The DevOps engineers and developers share a vast majority of skill-sets here and hence there is a negotiation of duties sometimes. </p>

<p>The bare minimum a developer can do is to share his binaries, but he needs to understand that the binaries will be used to run inside a docker container and for that he needs to understand how docker works. For kubes, swarms, mesos etc, the developer may not even care what's being used, but basics of docker should be very well understood by the developer and a mindset should be there from the beginning to build the application loosely coupled for re-use as micro-services. If the application is built from that mindset (which requires basics of docker), then the DevOps engineers can take it up from there to auto-scale, orchestrate, test, deploy and monitor. </p>

<p>Also, most of the times there is no one size fits all kind of thing. A developer does not know clearly how to build a docker friendly app and a DevOps engineer quite rightly does not know the internals of the app building process. Hence, most of the times, organisations prefer to give both these tasks to the same guy to speed things up. If there are separate things, then a continuous feedback mechanism is required from the DevOps team to the dev team for making the apps more futuristic and docker/cloud/scaling ready.</p>

CC BY-SA 3.0
2017-08-16T05:00:42.747Z
2018-01-09T12:51:06.297Z
2018-01-09T12:51:06.297Z
lakshayk
<p>It is not about Docker or any other containerisation technologies out there.</p>

<p>Containers like Docker, rkt, etc. are just way of delivering your application in similar fashion to static binary. You are building your deployment that it contains everything it need inside and end user doesn't need anything more than runtime.</p>

<p>These solutions are similar to fat JARs in Java, where everything you (in theory) need is just runtime (JRE) preinstalled and everything Just Works™.</p>

<hr>

<p>The reason why developers need to understand (they do not need to learn how to operate such tool, only why this is needed) orchestration tools is that this allows you to have some advantages over "traditional" deployment.</p>

<h2>Cattle, not pets</h2>

<p><a href="https://blog.engineyard.com/2014/pets-vs-cattle" rel="noreferrer">EngineYard have written good article about that.</a> Whole point of that is that when your server dies, then you shrug and wait as new will appear. You treat them as cattle, you have tens, hundreds, thousands of them running and when one goes down neither you or your clients should be ever aware of that.</p>

<p>Orchestration tools achieve that by monitoring status of all applications (pods/jobs, whatever) in cluster, and when it sees that one of the servers stops responding (goes down) then it automatically moves all applications that were running on that server somewhere else.</p>

<h2>Better resource utilisation</h2>

<p>Thanks to orchestration you can run multiple applications on one server and orchestrator will track resources for you. It will rearrange applications when required.</p>

<h2>Immutable infrastructure</h2>

<p>Thanks to the automatic failover handling in orchestrators you can ran your custom images in the cloud as is. When you will be needing update, you just build new image, set your Launch Configuration to use that one now and just roll. Everything will be handled for you:</p>

<ol>
<li>Create new server with new configuration.</li>
<li>Kill one running server.</li>
<li>Your orchestrator will move everything to other machines (including new one).</li>
<li>If there are any old servers left then go to 1.</li>
</ol>

<h2>Simpler operations</h2>

<ul>
<li>Not enough resources? Add new machine to cluster.  </li>
<li>Need more application instances? Increase number and go on.  </li>
<li>Monitoring? Done.  </li>
<li>Log management? Done.  </li>
<li>Secrets? Guess what.</li>
</ul>

<hr>

<p><strong>TL;DR</strong> Whole point isn't about Docker but about orchestration. Docker is just a extended version of tarball/fat JARs that is required for proper orchestration.</p>

CC BY-SA 3.0
2017-08-22T04:39:49.257Z
Now that's what I am asking and that's what the whole question is about. Should developers care about better resource utilisation, Immutable infrastructure and Simpler operations ?... What I believe is that they should focus on delivering business requirements and code optimisation that would lead to better resource utilisation. Even docker won't help in better utilisation if it is a badly/average written code. Let's accept the fact that business requirements make devs deliver things faster. And by doing this they don't have time to optimise the code. Why add docker's responsibility on them ?
Abhay Pai
CC BY-SA 3.0
2018-01-09T18:18:17.340Z
The thing is that having an overview of the entire stack, from tests through implementation and finally to deployment will allow you to see how your software is used, what the edge cases are, what is crashing. It will slow you down in the LOC you write, but greatly improve their quality. In the long run saving time
Moritz
CC BY-SA 3.0
2017-08-19T16:27:50.883Z
2017-08-19T16:27:50.883Z
Hauleth
<p>Here are for example some arguments from a blog post published back 2014 and titled in way quite matching your answer:</p>

<blockquote>
  <ul>
  <li>Much more flexible injection of new technologies into the environment</li>
  <li>there is still a massive pain point between committing the final tested code and then getting it running on the final production servers. Docker vastly simplifies this final step</li>
  <li>Docker makes it trivial to keep legacy OS, no matter what flavor of Linux you are running</li>
  </ul>
</blockquote>

<p>From: <a href="https://thenewstack.io/why-you-should-care-about-docker/" rel="nofollow noreferrer">https://thenewstack.io/why-you-should-care-about-docker/</a></p>

CC BY-SA 3.0
2017-08-14T06:08:16.683Z
I agree to injection of new technologies. But there are some issues with it too. Like using docker for databases (https://www.percona.com/blog/2016/11/16/is-docker-for-your-database/). They're not stable at the moment and probably would be stable in future. Let's hope for the best.   

We can achieve pushing the tested code to producing by using CI / CD anyway. Then why docker ?  

Developers don't care about what OS we are running on. Why should they even bother on learning docker in first place ? To make devops life easier ?
Abhay Pai
CC BY-SA 3.0
2017-08-14T06:22:43.743Z
in first place I just think about the following "MVP" scenario: dev tries out some new configuration/tool for the environment as infrastructure component, say imagemagick. Without Docker this information can get lost or forgotten, or needs communication along with many other tiny things. Sharing a Dockerfile is a machine-provable setup of a working thing which even being used to handcraft the setup to a Docker-free infrastructure is more valuable than just a documentation. Sure you might go for Puppet as well; nice thing about Docker is IMHO how it allows self-contained scenarios.
Ta Mu
CC BY-SA 3.0
2017-08-14T12:19:54.787Z
Agreed. But the problem arises during the orchestration. The developer needs to have an expertise in docker orchestration in order to adhere by the best practices and deliver business requirement. Consider your scenario where developer needs imagemagick as a service. Now while building a dockerfile, he / she gets complete control on the packages he / she can install in the docker image. What if they install sshd to ssh into the docker instead using docker logs ? What if they install tools that has nothing to do with business logic but compromises security ? Do devs need docker expertise ?
Abhay Pai
CC BY-SA 3.0
2017-08-14T12:50:38.440Z
hm but what if they implement a socket based backdoor? docker does not replace enteprise firewall I think
Ta Mu
CC BY-SA 3.0
2017-08-14T15:19:38.057Z
True. But that would be a malicious intention of the developer in any case. Be it docker or no docker. But when docker is introduced to devs, they can cause mishaps just because they lack the appropriate knowledge. Why should they even bother to learn docker (considering the orchestrator will also add in the complexity) when it might cause mishaps and complications ?

Please don't mind my questions. Even I love docker. But I am trying to understand a developer's perspective. I have been a developer myself for past 3 years and now I am a DevOps engineer.
Abhay Pai
CC BY-SA 3.0
2017-08-14T16:56:01.157Z
well.. in a project with many components, there have been an integration quality gate stated like that: to get your code accepted, please deliver a Dockerfile and a bashscript with curl commands to demonstrate the API is working against the container. There was a signoff with PO and PM for this gate. This setup was not even used for operations, but components without these two tiny pieces just did not qualify their delivery milestone with following business escalation.
Ta Mu
CC BY-SA 3.0
2017-08-14T19:07:11.560Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/63814/discussion-between-j-doe-and-abhay-pai).
Ta Mu
CC BY-SA 3.0
2017-08-14T05:59:28.360Z
2017-08-14T05:59:28.360Z
Ta Mu
<p>If you are running your production in docker container it's crucial that those container are being made by the same developers that have build the app running on them.
Who else is better place to know what external dependency are needed and so on ... ? </p>

<p>Also pipeline can fail at any step during a CD, particularly when it's the docker image build step, sometimes it's a file who is missing or a lib that's needed.</p>

<p>At work we've introduce all devs to docker explaining them the basics to build the dockerfile in order to serve their app, also we made the pipeline easy so one can only add a name and a dockerfile and its app will automatically be build on the next push regardless of the tech running it.</p>

<p>Docker quickstart is really a great introduction to do so, after what the devOps team guide the dev in their choice of distro (a lot of them don't know things like <code>alpine</code>). </p>

<p>Our job is to provide them an easy access to the tools, they do the rest so they can fix it when something is wrong. Docker is really a part of the development process and the devOps team provide them docker images that match our needs and that are easy enough so it take only a couple minute to create a new app and deploying it without assistance.</p>

CC BY-SA 3.0
2017-08-14T12:28:07.370Z
So according to a dev, the use of docker in a project should only be taken up if the project demands external dependency ? I think docker has become part of our development process because we have enforced it on the devs or because we think its cool. Also the problem arises during orchestration. Do they have to learn orchestrator like swarm, kubernetes or mesos ? The implementation of all of these orchestration is different. What if the orchestration crash due to bad implementation ? Who is to be blamed ?

PS : Don't mind my questions. I am just playing devli's advocate. I too love docker :)
Abhay Pai
CC BY-SA 3.0
2017-08-14T09:46:37.297Z
2017-08-14T09:46:37.297Z
Juub
<p>Docker gets lots of press and blog mentions which leads to developers getting interested in using it.  For some people it is the interest in playing with a new technology or understanding how things work.  For others it is a desire to add keywords to their resume.  Either way, the more developers know about how things work and how they get deployed the less surprised they will be later.  From what I've seen there's a decent amount of pre-existing interest in this so it shouldn't be that hard to encourage it further.</p>

CC BY-SA 3.0
2017-10-13T00:24:24.353Z
2017-10-13T00:24:24.353Z
chicks
<p>Well, if you ever used VMs for testing you may want try to use containers and docker is actually a great stuff for testing and it's much more simpler to use instead of LXC :)</p>

CC BY-SA 3.0
2017-08-22T04:47:27.080Z
Agreed. I am not against the use of docker or it's various orchestration tools. I love them too. What I am trying to understand is simple. Who owns the containerisation of the application. Devs ? Or DevOps ? Or Both ? If both then how much each of them should contribute ? When things fail either due to docker or docker orchestration who should be held responsible ? Code efficiency vs helping devops to make their life easy. My question is inclined towards the role of an individual rather than the technology itself.
Abhay Pai
CC BY-SA 3.0
2017-08-20T20:30:35.527Z
2017-08-20T20:30:35.527Z
Y V
<p>Probably not the answer that you're looking for, but an answer nonetheless :) </p>

<p>Learning about docker and its deployment methods could actually be included in the business requirements by making it part of the project or team development environment, just like the code language(s), version control system, compilers, test infrastructure, etc - to work in that team or on that project one needs to know about and use all of these, can't "bring your own" (in most cases).</p>

<p>Things get a bit more complicated if by "a developer" you actually mean the majority of or even entire development team. Pushing a tool in the development environment without actually having any of the developers supporting it will be really tough. Spend the time to create one such supporter first from the team's technical leadership.</p>

<p>Side note: it <em>might</em> also not be necessary for each and every developer in the team to become a docker expert. Pre-established usage recipes wrapped in simple, cheatsheet-ready commands often allow developers to use docker-based solutions without actually knowing too much about their inner workings, which could be fairly acceptable, especially in large teams. Just like being able to contribute code without knowing all the details about how the end-product is being built.</p>

CC BY-SA 3.0
2017-08-16T11:11:53.417Z
In addition, you can build on whatever technology you want, giving you less restrictions, and less of a headache for sysadmins to support all different technologies. And since the "dev" decides the technology, it should be up to him to configure the docker environment.
DarkMukke
CC BY-SA 3.0
2017-08-19T17:28:44.137Z
@DarkMukke The "dev" doesn't always decide the technology... Quite the opposite is often true in larger dev teams - the "dev" just uses whatever technology the team uses. Exceptions *might* be tolerated if they don't interfere with or negatively impact the team's activities.
Dan Cornilescu
CC BY-SA 3.0
2017-08-20T00:11:43.897Z
I partly agree, but I have seen large (200+) dev companies work with docker in the way i described. I think it is a matter of personal choises of not just the dev teams but also the managing staff above them. If there is decent devops, the amount of docker a dev needs is usually trivial.
DarkMukke
CC BY-SA 3.0
2017-08-14T15:53:42.790Z
2017-08-14T15:53:42.790Z
Dan Cornilescu
<p>Generally a developer cares about satisfying business requirements. He / she might have the expertise in a particular stack or a framework. But should he / she make an effort to learn docker and it's various deployment methods (swarm, kube, mesos, etc) ?  </p>

<p>Simply put why should a developer care about docker ?</p>

<p>PS : The parent question to this post is <a href="https://devops.stackexchange.com/questions/1737/implications-of-introducing-docker-to-the-development-team">Implication of introducing docker to the development team</a></p>

<docker><project-management><orchestration>
Why should a developer care about Docker?
Abhay Pai
# Why should a developer care about Docker?

(Asked by: username_0 on 2017-08-14)

Generally a developer cares about satisfying business requirements. He / she might have the expertise in a particular stack or a framework. But should he / she make an effort to learn docker and it's various deployment methods (swarm, kube, mesos, etc) ?

Simply put why should a developer care about docker ?

PS : The parent question to this post is [Implication of introducing docker to the development team](https://devops.stackexchange.com/questions/1737/implications-of-introducing-docker-to-the-development-team)

**Tags:** docker, project-management, orchestration


---

## 7 answers

### Answer by username_8 on 2017-08-14. Score: 8 | Accepted answer

Probably not the answer that you're looking for, but an answer nonetheless :)

Learning about docker and its deployment methods could actually be included in the business requirements by making it part of the project or team development environment, just like the code language(s), version control system, compilers, test infrastructure, etc - to work in that team or on that project one needs to know about and use all of these, can't "bring your own" (in most cases).

Things get a bit more complicated if by "a developer" you actually mean the majority of or even entire development team. Pushing a tool in the development environment without actually having any of the developers supporting it will be really tough. Spend the time to create one such supporter first from the team's technical leadership.

Side note: it *might* also not be necessary for each and every developer in the team to become a docker expert. Pre-established usage recipes wrapped in simple, cheatsheet-ready commands often allow developers to use docker-based solutions without actually knowing too much about their inner workings, which could be fairly acceptable, especially in large teams. Just like being able to contribute code without knowing all the details about how the end-product is being built.

> **Comments:**
> **username_9**: In addition, you can build on whatever technology you want, giving you less restrictions, and less of a headache for sysadmins to support all different technologies. And since the "dev" decides the technology, it should be up to him to configure the docker environment.  
> **username_8**: @username_9 The "dev" doesn't always decide the technology... Quite the opposite is often true in larger dev teams - the "dev" just uses whatever technology the team uses. Exceptions *might* be tolerated if they don't interfere with or negatively impact the team's activities.  
> **username_9**: I partly agree, but I have seen large (200+) dev companies work with docker in the way i described. I think it is a matter of personal choises of not just the dev teams but also the managing staff above them. If there is decent devops, the amount of docker a dev needs is usually trivial.  

---

### Answer by username_1 on 2017-08-16. Score: 7

I'll give you my perspective. Developers should care about docker as there are other developers who are willing to use docker and have already built an expertise in it. They are willing to take up the roles of a DevOps engineer along with being a developer. So the Ops part of DevOps is what they are now building expertise on.

These days, you'll find more and more guys who can develop, orchestrate, automate tests, automate jobs and build tools to monitor and take this complete package into production single-handedly. These are the guys who are pushing docker and other tools among the developer community.

Also, the tide of market is towards virtualization, auto-scaling, automation, machine learning and docker fits in all of these. It has become very imperative to use docker. The businesses are willing to pay 2x for a single guy who takes all these responsibilities and when there is demand for such guys, the supply will also begin. This is from point of view of an employee-employer.

Technically, in the organisations I have worked, there are separate development and DevOps teams, although they work very closely for deliveries.
The DevOps engineers and developers share a vast majority of skill-sets here and hence there is a negotiation of duties sometimes.

The bare minimum a developer can do is to share his binaries, but he needs to understand that the binaries will be used to run inside a docker container and for that he needs to understand how docker works. For kubes, swarms, mesos etc, the developer may not even care what's being used, but basics of docker should be very well understood by the developer and a mindset should be there from the beginning to build the application loosely coupled for re-use as micro-services. If the application is built from that mindset (which requires basics of docker), then the DevOps engineers can take it up from there to auto-scale, orchestrate, test, deploy and monitor.

Also, most of the times there is no one size fits all kind of thing. A developer does not know clearly how to build a docker friendly app and a DevOps engineer quite rightly does not know the internals of the app building process. Hence, most of the times, organisations prefer to give both these tasks to the same guy to speed things up. If there are separate things, then a continuous feedback mechanism is required from the DevOps team to the dev team for making the apps more futuristic and docker/cloud/scaling ready.


---

### Answer by username_2 on 2017-08-19. Score: 7

It is not about Docker or any other containerisation technologies out there.

Containers like Docker, rkt, etc. are just way of delivering your application in similar fashion to static binary. You are building your deployment that it contains everything it need inside and end user doesn't need anything more than runtime.

These solutions are similar to fat JARs in Java, where everything you (in theory) need is just runtime (JRE) preinstalled and everything Just Works™.

---

The reason why developers need to understand (they do not need to learn how to operate such tool, only why this is needed) orchestration tools is that this allows you to have some advantages over "traditional" deployment.

## Cattle, not pets

[EngineYard have written good article about that.](https://blog.engineyard.com/2014/pets-vs-cattle) Whole point of that is that when your server dies, then you shrug and wait as new will appear. You treat them as cattle, you have tens, hundreds, thousands of them running and when one goes down neither you or your clients should be ever aware of that.

Orchestration tools achieve that by monitoring status of all applications (pods/jobs, whatever) in cluster, and when it sees that one of the servers stops responding (goes down) then it automatically moves all applications that were running on that server somewhere else.

## Better resource utilisation

Thanks to orchestration you can run multiple applications on one server and orchestrator will track resources for you. It will rearrange applications when required.

## Immutable infrastructure

Thanks to the automatic failover handling in orchestrators you can ran your custom images in the cloud as is. When you will be needing update, you just build new image, set your Launch Configuration to use that one now and just roll. Everything will be handled for you:

1. Create new server with new configuration.
2. Kill one running server.
3. Your orchestrator will move everything to other machines (including new one).
4. If there are any old servers left then go to 1.

## Simpler operations

* Not enough resources? Add new machine to cluster.
* Need more application instances? Increase number and go on.
* Monitoring? Done.
* Log management? Done.
* Secrets? Guess what.

---

**TL;DR** Whole point isn't about Docker but about orchestration. Docker is just a extended version of tarball/fat JARs that is required for proper orchestration.

> **Comments:**
> **username_0**: Now that's what I am asking and that's what the whole question is about. Should developers care about better resource utilisation, Immutable infrastructure and Simpler operations ?... What I believe is that they should focus on delivering business requirements and code optimisation that would lead to better resource utilisation. Even docker won't help in better utilisation if it is a badly/average written code. Let's accept the fact that business requirements make devs deliver things faster. And by doing this they don't have time to optimise the code. Why add docker's responsibility on them ?  
> **username_3**: The thing is that having an overview of the entire stack, from tests through implementation and finally to deployment will allow you to see how your software is used, what the edge cases are, what is crashing. It will slow you down in the LOC you write, but greatly improve their quality. In the long run saving time  

---

### Answer by username_4 on 2017-08-14. Score: 4

Here are for example some arguments from a blog post published back 2014 and titled in way quite matching your answer:

> * Much more flexible injection of new technologies into the environment
> * there is still a massive pain point between committing the final tested code and then getting it running on the final production servers. Docker vastly simplifies this final step
> * Docker makes it trivial to keep legacy OS, no matter what flavor of Linux you are running

From: <https://thenewstack.io/why-you-should-care-about-docker/>

> **Comments:**
> **username_0**: I agree to injection of new technologies. But there are some issues with it too. Like using docker for databases (https://www.percona.com/blog/2016/11/16/is-docker-for-your-database/). They're not stable at the moment and probably would be stable in future. Let's hope for the best.     We can achieve pushing the tested code to producing by using CI / CD anyway. Then why docker ?    Developers don't care about what OS we are running on. Why should they even bother on learning docker in first place ? To make devops life easier ?  
> **username_4**: in first place I just think about the following "MVP" scenario: dev tries out some new configuration/tool for the environment as infrastructure component, say imagemagick. Without Docker this information can get lost or forgotten, or needs communication along with many other tiny things. Sharing a Dockerfile is a machine-provable setup of a working thing which even being used to handcraft the setup to a Docker-free infrastructure is more valuable than just a documentation. Sure you might go for Puppet as well; nice thing about Docker is IMHO how it allows self-contained scenarios.  
> **username_0**: Agreed. But the problem arises during the orchestration. The developer needs to have an expertise in docker orchestration in order to adhere by the best practices and deliver business requirement. Consider your scenario where developer needs imagemagick as a service. Now while building a dockerfile, he / she gets complete control on the packages he / she can install in the docker image. What if they install sshd to ssh into the docker instead using docker logs ? What if they install tools that has nothing to do with business logic but compromises security ? Do devs need docker expertise ?  
> **username_4**: hm but what if they implement a socket based backdoor? docker does not replace enteprise firewall I think  
> **username_0**: True. But that would be a malicious intention of the developer in any case. Be it docker or no docker. But when docker is introduced to devs, they can cause mishaps just because they lack the appropriate knowledge. Why should they even bother to learn docker (considering the orchestrator will also add in the complexity) when it might cause mishaps and complications ?  Please don't mind my questions. Even I love docker. But I am trying to understand a developer's perspective. I have been a developer myself for past 3 years and now I am a DevOps engineer.  
> **username_4**: well.. in a project with many components, there have been an integration quality gate stated like that: to get your code accepted, please deliver a Dockerfile and a bashscript with curl commands to demonstrate the API is working against the container. There was a signoff with PO and PM for this gate. This setup was not even used for operations, but components without these two tiny pieces just did not qualify their delivery milestone with following business escalation.  
> **username_4**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/63814/discussion-between-j-doe-and-abhay-pai).  

---

### Answer by username_5 on 2017-08-14. Score: 4

If you are running your production in docker container it's crucial that those container are being made by the same developers that have build the app running on them.
Who else is better place to know what external dependency are needed and so on ... ?

Also pipeline can fail at any step during a CD, particularly when it's the docker image build step, sometimes it's a file who is missing or a lib that's needed.

At work we've introduce all devs to docker explaining them the basics to build the dockerfile in order to serve their app, also we made the pipeline easy so one can only add a name and a dockerfile and its app will automatically be build on the next push regardless of the tech running it.

Docker quickstart is really a great introduction to do so, after what the devOps team guide the dev in their choice of distro (a lot of them don't know things like `alpine`).

Our job is to provide them an easy access to the tools, they do the rest so they can fix it when something is wrong. Docker is really a part of the development process and the devOps team provide them docker images that match our needs and that are easy enough so it take only a couple minute to create a new app and deploying it without assistance.

> **Comments:**
> **username_0**: So according to a dev, the use of docker in a project should only be taken up if the project demands external dependency ? I think docker has become part of our development process because we have enforced it on the devs or because we think its cool. Also the problem arises during orchestration. Do they have to learn orchestrator like swarm, kubernetes or mesos ? The implementation of all of these orchestration is different. What if the orchestration crash due to bad implementation ? Who is to be blamed ?  PS : Don't mind my questions. I am just playing devli's advocate. I too love docker :)  

---

### Answer by username_6 on 2017-10-13. Score: 2

Docker gets lots of press and blog mentions which leads to developers getting interested in using it. For some people it is the interest in playing with a new technology or understanding how things work. For others it is a desire to add keywords to their resume. Either way, the more developers know about how things work and how they get deployed the less surprised they will be later. From what I've seen there's a decent amount of pre-existing interest in this so it shouldn't be that hard to encourage it further.


---

### Answer by username_7 on 2017-08-20. Score: 0

Well, if you ever used VMs for testing you may want try to use containers and docker is actually a great stuff for testing and it's much more simpler to use instead of LXC :)

> **Comments:**
> **username_0**: Agreed. I am not against the use of docker or it's various orchestration tools. I love them too. What I am trying to understand is simple. Who owns the containerisation of the application. Devs ? Or DevOps ? Or Both ? If both then how much each of them should contribute ? When things fail either due to docker or docker orchestration who should be held responsible ? Code efficiency vs helping devops to make their life easy. My question is inclined towards the role of an individual rather than the technology itself.  

---

