According to Docker, the differences between containerization and virtualization can be thought of as a person looking for a new house. If you live by yourself, do you need the ten bedrooms and the garage? Even when you find the smallest home on the market, you’ll have at least one bedroom. Containerization is the studio apartment to a virtual machine’s mega-house. Why use all of that extra space when all you need is a single room?
Don’t get us wrong – virtual machines still have their purpose and can even be combined with containers. But they use a lot of resources, and maintaining the cloud is an expensive business. Depending on your needs, there are many reasons why you should (or shouldn’t) be using containerization. But for the time being let’s focus on why you should.
Docker is a shipping container for your code, which provides a sandboxed environment where a fully described app can be configured and run. While this isn’t new technology (think BSD Jails and Solaris Zones), it has gained more support than its predecessors. Unlike a VM that isolates at the OS level, Docker has the benefit of being separated at the process level. By removing the need for a hypervisor layer, it can have direct access to a host’s CPU. Each container is restricted to running a single application, enabling you to free up memory and disk space with the added benefit of scalability and speed. Containers can function independently of one another but can also pull from the same bins/libraries, and share an OS where appropriate.
Build your app once, and it works on any Docker-compatible OS despite variations in hardware. This means better stability when testing, quicker configurations, increased overall productivity, and more flexibility by allowing you to keep resources (and time) free.
Interested in the Cloud? Join us for our quarterly Meetup!