6 Reasons why I started using containers
I’ve been using containers for nearly 3 years, initially working in the Technical Support team helping customers solve problems in their applications and giving advice about best practices to run containers. Today I work on a team where we develop containers to use in our OpenShift environment, and because of my Technical Support background, my troubleshooting skills helped me in this task. I run containers for most of my tasks and it makes my life easier. I can run any software on containers, whether for evaluation or even use in my websites. Let’s face the fact: containers are becoming more common across the companies. Google can spin up thousands of containers a day in their data centers without downtime, Netflix launches more than 1 million containers a week and many other companies, whether small or large, use containers in production to achieve a new level of scalability. Having this in mind, I’d like to list 6 main reasons why I started to use containers.
Containers are simple
There’s nothing better than using the KISS principle in my work, so why not use simple tools to make my job better? I say containers are simple because I can have an Operating System and an entire Software Stack running on my machine with just 2 or 3 commands. Because of that simplicity, I can save a lot of time and effort running containers than creating Virtual Machines, installing the OS and installing the software and really focus on what matter.
Everything you need to grow your career.
With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.SIGN UP
Containers are lightweight
The good thing about containers is the way it operates directly on top of the OS (Linux) layer, without the hypervisor layer in the middle. This makes containers use fewer resources than Virtual Machines and I can spin up more containers in the same hardware than VMs. Containers also use less storage than VMs, which is more attractive to run. Just as an example, the RHEL 7 image size is 193MB and there is an alternative RHEL version (which we call RHEL Atomic) with less than 80MB. Because of the image size, the bootstrap time is less than any traditional way to run an Operating System. Although the boot time of an RHEL installation either in VMs or in Bare Metal machines is about 1 minute, running inside containers can take no more than 15 seconds.
With containers, I can avoid the “works on my machine” effect
Containers are immutable, period. What makes this feature important to me? It guarantees that a container running in my laptop will run in the same way on any machine. No more excuses like: “it works on my machine” anymore. Now with containers, it’s possible to avoid that. You can even run on Cloud Providers like Amazon AWS, IBM Bluemix, Google Cloud Platform or even Azure and get the same behavior.
There is a large community about containers
Think about the software you’d like to run with containers. I’m sure that if you can’t find an image with the software you want there is someone creating and will be available soon in any repository. Most companies are creating images of their software to run in containers, and you can use them to create your own configuration. Besides that, there are lots of books (both paid and free) about Containers and how to develop, run, and make them more secure.
Containers are extensible
You found an image to run but there is a missing specific configuration or a missing piece of the software that is required in your environment. With containers, it’s possible to extend an existing image and add things you need in your container, and thus making your image fit better in your requirements. That way, the time spent in preparing the OS to run your software is much less than any other method. Even using DevOps tools like Puppet, Chef, and others, the time to prepare an environment to run software is even more than spin up a new container.
Containers are Cloud-ready
Cloud Computing is the next-generation of computing, where you can add resources on-demand in your environment, using them as you need and collect usage metrics about them. Containers bring all these requirements and more to Cloud Computing in their design, because they are simple to replace in case of any problem. You don’t need to worry if you lose a container because the most advanced Cloud Computing architectures already manage for you and spin up a new container to replace the one that became unresponsive.
Whether you are new to Containers or have experience, downloading this cheat sheet can assist you when encountering tasks you haven’t done lately.
To learn more, visit our Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets (e.g. containers), books (e.g. microservices), and product downloads that can help you with your microservices and/or container application development.