[null, null, {"document_url": "https://www.sourcelair.com/blog/articles/113/why-still-docker", "unformatted_src": "https://e003241e1ca22fe3a801-e6bf09af38ee59e24e7cffd16c43a1d9.ssl.cf2.rackcdn.com/113-why-still-docker.png", "src": "https://e003241e1ca22fe3a801-e6bf09af38ee59e24e7cffd16c43a1d9.ssl.cf2.rackcdn.com/113-why-still-docker.png", "formatted_filename": "why still docker"}, null]
Why we still use Docker 
TLDR; Docker has dramatically helped deployment and most staging practices, why don't we solve our development practices too?

There's no one who would argue against Docker images being the ideal deployable unit today - even more so now that Docker 1.11 has broken down the binaries, uses runC and is fully OCI compliant. Why would you still code in a VM?

Deployment has become so, so sexy 👓

Lately, we've lived great times in the deployment world. You have so many awesome processes and platforms that you can use in order to safely deploy your code. Starting off with Heroku and AppEngine - both pioneers in the managed container solutions space - you can now deploy using Deis or Empire if you prefer hosted solutions, or even using Kubernetes and Mesos for tailor-made solutions.

Also, the progress in the CI/CD tools is great: you can now provision your own containers and either use plain image builders like Docker Hub or Quay as CI/CD pipelines, or tools like CodeShip, Jenkins or Cloud Bees which would help you in creating your workflow.

The current state of development

Currently, every team - or if I may, every developer in a team - has her own development workflow. There are tons of tools, editors and ways to do the same things in your local development environment. We, developers, tend to start off with a certain tool and then keep up with it until eternity.

The question is: Why are we constantly trying to find better ways to deploy our code and keep it running safely, while we don't pay so much attention to our development workflow?

At the end of the day, most of our time is spent developing our application.

Why is development so 💩 after all then?

Development workflows are a thing that's considered "scary to play with". It's not easy to make a team use a specific development workflow, yet having an opinionated way for deploying services is a must. This has to be true for development workflows too. As important as it is deploying code safely, it's even more critical developing applications in a safe environment and having good development workflows to save time and make more reliable systems.

After all, standardizing the manufacturing process is what led us to the industrial revolution. Could you imagine a world where each line of assembly would work in a different way? Why would you allow that for your code pipeline?

It's this fragmentation that led us to a state when there is no code-nirvana when developing applications.

VMs are back

As if the current situation was not bad enough, we've noticed a lot of tools aimed at helping developers doing their job faster surrendering to this "do it as you wish" paradigm and switching to VMs where developers can customize their machine to their liking and do their work. Too much freedom is not always a good thing though.

The challenge is giving developers a framework to develop their applications faster without restricting one's creativity.

There must be a better way At SourceLair, we are devoted to removing any friction from a developer's workflow. Thus, we are committed to supporting the container movement and giving developers the ideal place to develop their services in a safe and robust way. There's a reason after all that dev-prod parity is in the 12-factor application manifesto.

At the end of the day, we spend more time developing our application than deploying it.

Would you like to be part of the container revolution? We're building the next container development environment and would love to hear your feedback on that.
