5 Key Features to Make Containers Reliable for Production Applications

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Previously we have already covered two features that make containers production-ready solution – high availability and live migration. Default Docker® containers do not implement such important features at these days, so we did a lot of work to merge the mentioned technologies with application packaging standard. In the near future the same features will be available for App Container standard.

And now, we are ready to proceed with uncovering the next five important features to ensure that your application is secured and that resources are consumed efficiently.

So today we’ll talk about security and isolation, smart distribution of containers among physical servers, high density and maximum utilization of server resources, hibernation and memory de-duplication technology that you gain within our system.


Full Security and Isolation

The biggest myths about containers are that all of them aren’t secure enough. And this can be the case if containers are configured incorrectly, or are not using the needed kernel security and isolation capabilities like namespaces and cgroups to the full extent. For example, there are several important issues that are not solved by default Docker® containers implementation:

  • Inability to limit RAM usage for containers in a correct way to give applications, that are running inside the container, information about amount of RAM which is allowed to be used. For now applications can “see” the whole amount of RAM that is available on the host machine, and if an application will try to allocate more RAM than it’s allowed then the application will crash.
  • Poor CPU isolation does not provide the needed level of isolation flexibility. All you can do is just to specify the priority for your container among all others, you cannot set the limit to an absolute value. This priority is a relative weight and has nothing to do with the actual processor speed. There is no way to specify that a container should have access only to 1GHz, for example.
  • Network isolation is also a kind of pain. Today, linux kernel namespaces allow to create absolutely independent network devices that are fully isolated from the network adapters on the host machine. Containers can use their own dedicated external IP address and can work as a separate network adapter just located in the same collision domain. If you are not using these capabilities you have to apply different workarounds all the time like port exposing, DNAT from adapter on host machine and other tricks.
  • There are much more issues – limiting of the network bandwidth, limiting of the disk space and I/O performance, swap limitations, issues related to user namespace, not user friendly workarounds for applying the limit changes on the fly without containers restart and others. We will cover all of them in the next articles.

There is a workaround which is partially solving the mentioned security and isolation issues. This workaround is actively used by many companies due to the lack of a better solution available by default. The workaround suggests to run containerized applications on top of a virtual machine (VM). However, due to the extra hypervisor virtualization layer you lose the advantage of running a lightweight multi-container environment with high elasticity and performance because of additional spare overhead caused by hardware emulation required to run a VM in hypervisor.

In Jelastic we do it differently, because the container virtualization we use was developed and polished during the last 15 years and all such kind of security and isolation problems were eliminated. As the result it provides the ability to host containers directly on top of bare metal hardware.

In other words, each container with a Docker® template gets complete privacy and needed level of isolation. The data inside the container becomes unavailable to other containers and users due to the advanced isolation of RAM, CPU, IO, filesystem and network. It prevents neighboring containers from stealing resources belonging to another, greatly improving the performance of applications operating within the container and ensuring a high-quality, consistent end-user experience.


Smart Distribution of Containers

The Jelastic platform provides high availability by evenly distributing containers installed in one environment on different hardware nodes (physical servers). This is done with the help of anti-affinity groups configured to specify that certain virtual containers should never run on the same physical server. As a result, it eliminates the risk of application downtime if one of the physical servers has any issues with performance.


High Density and Maximum Utilization of Server Resources

Container-based virtualization guarantees the highest application density and maximum utilization of server resources compared to virtual machines, resulting in the best ROI (return-on-investment). Since containers are optimized for high density environments, the customer can place more applications on the same infrastructure and that leads to a reduction of TCO (total cost of ownership).

A virtual machine includes a full operating system with all associated virtualized device drivers, memory management, etc., while containers use the shared OS and device drivers of the host. As a result, containers are considerably smaller than VMs, with much faster startup and better performance.

VM (1)

The ability to run containerized applications directly on top of bare metal hardware eliminates the need to use an extra hypervisor virtualization layer and delivers on one of the original promises of the containers idea.


Hibernation of Applications

Jelastic’s hibernation feature delivers even better density and utilization of cluster resources. Optimal use of resources is achieved by CRIU (Checkpoint/Restore In Userspace). This technology can freeze a running container and checkpoint it to a hard drive as a collection of files. Then these files are used to restore and run the container from the point it was frozen at.

When the containers are in sleep mode, the hibernated apps do not consume resources (only disk space). The released resources are returned back to the cluster. This prevents unnecessary consumption of resources and extra charges to customers.


There are many ways to use this checkpoint/restore technology on an infrastructure level: live migration of containers, accelerating the start of large applications, update of the kernel without rebooting, load balancing, saving the task status in case of system failure. There are also several scenarios for the application level, including network load balancing, behavior analysis of applications on another machine, duplication of processes, etc.

For enterprises and cloud hosting service providers, Jelastic has implemented specific automated hibernation rules that save a great deal of resources by putting the containers of inactive users, demo and trial accounts into sleep mode.


Memory De-Duplication Technology

The memory de-duplication technology collects file-usage statistics to determine which files are most frequently accessed by containers, and puts commonly used files in cache. As a result, if a container needs to access a frequently used file, it goes straight to the cache instead of the disk.


This improves performance by reducing the number of I/O operations and memory bottlenecks. It significantly increases the number of running containers per server.



All these technical aspects directly affect the performance of containerized applications, making them reliable and highly available, as well as driving benefits for infrastructure owners due to smart resource distribution, high density and utilization.

Next time we’ll describe the way your containerized application can be managed within the Jelastic platform, with all of the required tools and settings for full orchestration of your containers.

Feel free to try out the described features of the application containers in the Jelastic Cloud and leave your comments about your experience.

Disclaimer: Jelastic has used production-ready containers virtualization starting from 2011 and is not in any way affiliated with Docker® activities, products and services. This trademark is mentioned in the article only for clarification of Jelastic containers implementation and for highlighting the added value to the application packaging standard.  

Related Articles:

Smart Container Orchestration within the Cloud Platform. Part 1: Installation

Multi-Containers Orchestration with Live Migration and High-Availability for Microservices in Jelastic

Containers for Business. How to Make Money on Containers?

Webinar Roundup – Multi-Containers Orchestration with Live Migration and HA for Microservices

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone

Leave a Reply

Subscribe to get the latest updates