Is HyperContainer the Answer for Cloud Native Applications?

Since the early days of the Cloud, developers have been seeking the promised land of PaaS, where they can focus on building applications, instead of being distracted by managing servers. With the rise of Cloud Native Applications, this dream could be just around the bend.

One way to run a cloud native application is to setup a container platform. For developers and institutions that live on the public IaaS, that means:

• creating a VM cluster (plus the capacity planning beforehand, instance type, cluster size)
• configuring the VM instances (software dependency, security patches, etc.)
• preparing the VM storage (again, capacity planning and volume management)
• setting up the VM network (firewall, ACL, NAT, Route Table, etc.)
• deploying the container orchestration engine (COE) in the VM (scheduling policy, service discovery, traffic proxy, etc.)
• deploying the container storage system in the VM (mount, replica, data sync, failover, etc)
• setting up the container network
• Once you’ve gone through all of these steps, the container platform is ready to launch the first container, though you have to continuously monitor and manage all these moving parts to make sure nothing falls apart when you are on air. This process is heavy, tedious, fragile, and most importantly, it has nothing to do with applications. Although, we are no longer hindered by physical boxes, our hands are still tied with IaaS. How do we change this and alleviate the management difficulties?

Enter HyperContainer

HyperContainer is an open-source virtualized container technology. It does not use Linux containers, but hypervisors (like Xen) to launch container images. Why? To explain the reasoning behind this, it’s best to understand how Linux containers work. When you launch a Linux container, the application’s processes are isolated from the host OS by a cgroup and several namespaces. However, this process is not entirely isolated from the outside. It still runs atop the host kernel. Therefore, from the process' point of view, a Linux container is:

Linux Container = Cgroup (resource limit) + Namespace (access isolation) + Host Kernel + Data (image)

As the host kernel is shared by all (Linux) containers running on the same host, the lack of necessary kernel isolation makes it insecure to deploy applications using Linux containers in a multi-tenant environment (where the VM cluster is employed as the security boundary between tenants).

HyperContainer addresses the isolation problem by changing some ingredients in the recipe:

• Resource Limit and Access Isolation: Cgroup + Namespace ---> Hypervisor (KVM/QEMU, Xen, etc)
• Host Kernel ---> Guest Kernel

The updated formula is:

HyperContainer = Hypervisor + Guest Kernel + Data (image)

In a HyperContainer, the application process is still able to access what it needs: kernel and data. The difference is that the container does not run on the host kernel. Instead, every container gets its own, independent, guest kernel. By doing this, the application running inside is perfectly isolated from both other containers and the host.

Performance wise, with the assistance of the super tiny guest kernel, a HyperContainer is able to finish booting in milliseconds (100-150ms), which is dramatically faster than a VM. Some may argue that this speed still lags behind a Linux container, but consider that an application usually takes longer to get started anyway meaning that, in practice, there is simply no difference.

The Infinite Laptop

Thanks to the built-in isolation, a HyperContainer doesn’t need to reside inside a VM. On the contrary, it replaces VMs as the cloud's building block.

Without the VM hosts, the need for a cluster is gone, along with things like VM capacity planning, VM configuration, COE, cluster utilization rate, etc. The whole cloud works like one single host, and containers are managed in the same way as on local laptop:

• hyper pull the image from (private) registries to the cloud;
• hyper run to launch container directly without VM;
• hyper link different containers as they appear to run on the same host;
• hyper commit to create new images;
• hyper push the image from the cloud to (private) registries;
• hyper associate floating public IPs to enable Internet access;
• hyper exec to access containers;

What remains different is that this "cloud laptop" has infinite capacity. Developers can launch any number of containers at any time, without worrying about how much memory is left for example.

Hyper Elastic

One defining characteristic of cloud native application is Elasticity. Developers want their system to autonomously adapt its capacity to workload over time. Traditionally this scale-out/in function is implemented with VM-based autoscaling, which is notoriously slow and heavy. Linux containers makes things better, because of their layered images and the trivial cost to provision new ones. However, with the existence of VM clusters, some heavy legacy is kept. Consider the case when a VM pool runs out of capacity, to add extra resources a lengthy procedure of several steps must be taken:

• Provision new VM instances;
• VMs complete bootstrapping and join the fleet;
• COE deploy more containers on new nodes;
• Application rebalances the traffic to the new containers;

In most cases, this process takes minutes to complete. In response to a customer traffic spike, that might be too late. In HyperContainer's context, the natural isolation helps us to get rid of this VM tax. Combined with the sub-second boot performance, it makes applications become hyperelastic. When a service gets overloaded, it simply calls for backup, and new containers will be up running quickly.

Consumed Per Second

Another interesting side effect of the sub-second performance is Per Second pricing. Due to the slow boot process, VMs typically employs a Per-Hour or Per-Minute plan. This model comes with the expense of lower agility and consequently higher costs for dynamic use case, like Dev/QA. With VM cluster, the cost structure is even worse, since some upfront investment (a.k.a CapEx) is required to reserve the pool, and a pool indicates that there is always some idle capacity wasted.

HyperContainer, however, allows you to spin up 100 containers in 2 seconds, crunch some data or run parallel builds on the latest commit for 10s, destroy all containers in 1s, and only pay for 2+10+1=13s. This Per Second model not only promises cost saving, its on-demand nature also eliminates the CapEx need, thus avoiding waste and enabling some new event-driven patterns in the style of AWS Lamda, Spark Streaming, CD/CI.

Cattle, cattle, cattle

A cloud native application is supposed to treat its components as cattle, instead of pets. When they look sick, instead of nursing them to health, we simply dispose of them and replace them with new clones. Though it is easy to reproduce Linux containers, the underlying VM is a nightmare - slow to provision, long-lived, and expensive to manage. In the case that a system (security) patch is required for the guest OS, we have to seek help from traditional system management tools to feed these pets!

By contrast, HyperContainer is completely free of any administration headaches. As only the guest kernel and the image reside in a HyperContainer, there is no more guest OS to take care of, no yum install, no cronjob, no /etc, no moving parts, and thus no server management at all. A HyperContainer is inherently immutable, demands zero attention, and costs much less over time. Combined with the sub-second boot feature, it fits perfectly into the cattle category for the inexpensive, disposable infrastructure.

DIY is not what they want

Stateful workloads, like databases, have haunted containers since the beginning. As Linux containers run on top of VMs, it is hard to integrate them with an IaaS storage service. Developers are left to operate a set of container-specific data solutions, which are often both complicated and immature.

HyperContainer provides a seamless way to pick up the same virtualization technologies widely employed in IaaS, for example distributed storage or SDNs. Developers no longer need to deploy their own LXC solutions, but simply enjoy the services managed by the cloud:

• hyper mount distributed block storage volumes onto containers;
• hyper snapshot generates persistent backup;

Run Anywhere

It’s a fact of life that IaaS customers suffer from vendor lock-in. Different hypervisors, plus incompatible VM image formats, present significant challenges to developers who desire greater flexibility and choice for application deployment. HyperContainer solves this problem by being technology agnostic. At the time of writing, HyperContainer supports several of the most popular hypervisors, including Xen, KVM and VirtualBox. On top of various heterogeneous technologies, HyperContainer provides the same set of interfaces as Docker including the API, image format and workflow. This brings the ultimate in workload portability: applications may be deployed in a private CaaS (Containers as a Service) powered by LXC, and seamlessly migrate (scale) to a HyperContainer-based public CaaS.

A Serverless Future

By repurposing the hypervisor from traditional full-blown VMs to the application-centric container, HyperContainer brings much-needed isolation to multi-tenancy, while keeping the signature tune of a Linux container: sub-second boot, with upgraded immutability and portability. It depicts a serverless future, in which

• Secure containers become the new building blocks
• VM clusters are automated away. The Cloud becomes as easy to use as a laptop
• Hyper-elastic applications are able to autoscale in seconds
• Consumed Per Second, enabling truly event-driven patterns

We believe that this is the nirvana for Cloud Native Applications. Developers can finally concentrate on the code, not being distracted by the server, because there is simply no such thing. Those interested can try Hyper_ now at https://hyper.sh

About the Author

Xu Wang is CTO and Cofounder of Hyper_. Prior to Hyper_, Xu served as the Chief Architect for China Mobile BigCloud, where he led the kernel, distributed storage, and big data product lines. Xu has over 10 years of experiences in Debian, Linux kernel, Virtualization, Distributed Filesystem and NoSQL databases. He holds a PhD degree from Beijing University of Posts and Telecom (BUPT).