Are Containers the Next Best Thing for Development?

Recently, Containers (Kubernetes and Dockers), have become a buzzword in the IT world. It’s success and tremendous adoption is due to how it makes easy to solve one of the biggest DevOps problems today: The Deployment.

This problem arises from the fact that you need to accommodate a lot of different technologies (software and hardware) in a lot of different environments from the development until the production stages, and the configurations for all these environments are complex and error prone leading to situations were the software runs in one environment, but not in the other. With containers, this is not an issue.

If it works in one container correctly it will run in every container, no matter the hardware or the OS where the containers are running.

In short, containers allow you to package up an application with all the parts needed, such as libraries and dependencies, and deploy it as single package which is OS agnostic, like if it was a Mobile App, with its own sandbox, but better because you’d be able to install the exact same app in both Android and iOS. Containers gained popularity when Docker was released in 2013, making containers easy to use, not only in Linux but also in Windows and OS X.

The biggest advantages of containers when compared with Virtual Machines (VM) are the speed and the lower resource usage. Per host machine, you can have more containers than VMs, with a performance increase in both boot speed and container size than you would have with VMs. This not only brings down infrastructure costs (both Cloud and on premises) but also the operational costs, since maintenance of all environments are pretty much the same.

Although there are clear advantages to work with Containers, as described in the huge number of articles that we can find online (stating how awesome containers can be used for software development) there are also some drawbacks: development using containers require the setup of a complex container environments and will require a controlled release management (which can be eased up with automation development support tools (such as Maven, Jenkins, SonarQube). It also brings a risk of development slowness (as the project grows the slowness and complexity would grow with it). This slowness is compensated with the main major advantage of Containers: How easy it is to perform a deployment.

Containers deployment is easy and fast because you no longer need to worry about complex, and error prone, specific configurations for each environment. Now, if it works as it should in one container it will work, for sure, on every container in any environment. No longer we will have the episodes of “It was working on my machine…”!

Besides the obvious advantage of this kind of setup, a quicker onboarding for new team members, there is other like the need to setup a single environment either for development and to deployment.

Conclusion

Bottom line is yes, for most of our client projects it makes sense to setup development environments on top of a container-based environments, even considering the price that you have to pay to setup a complex development environment and loose some of the speed of developing in a native environment.

Docker is an open source implementation of Linux containers. Containers are based in a Linux feature called cgourps, that limits and isolates the use of resources (CPU, RAM, OI, network, …) to a collection of processes. This feature is a part of the Linux kernel since version 2.6.24, release in January 2008.

Kubernetes are an open-source container-orchestration system. It works with a range of container tools, including Docker.

Example of a docker file:

1FROM ubuntu:18.04
2COPY . /app
3RUN make /app
4CMD python /app/app.py