Shift your Java applications into containers with Jelastic PaaS


Hardware virtualization was a great step forward in application hosting compared to the days of bare metal. Hypervisors allowed us to isolate multiple applications within one hardware platform, freeing us to use hardware resources more efficiently by hosting heterogeneous workloads on the same infrastructure. Still, virtual machines have massive overhead in terms of resource consumption, because each VM runs a fully dedicated operating system.

Containerization advances the benefits of virtualization much further by allowing containers to share the OS kernel, networking stack, file system, and other system resources of the host machine, all while using less memory and CPU overhead.

If your organization is wary about making the transition from VMs to containers, consider the following advantages of containers:

  • Far more efficient resource utilization than with VMs.
  • Easier scaling—resizing container limits can be achieved on the fly, without a reboot.
  • Faster provisioning and start times for containers compared to VMs.
  • More granular resource provisioning, and the ability to share resources among containers on the same host.
  • Publicly available container templates based on the Docker packaging standard make it is easy to create new images for specific projects.

Jelastic is a PaaS provider that offers managed containerized application environments for a wide variety of programming languages including Java, PHP, Ruby, Node.js, Python, and .Net. The platform was initially built on Virtuozzo containers, so when Docker’s container technology arrived, we already had strong expertise in containerization and quickly added support for the Docker standard. Because we support multi-cloud options (allowing the Jelastic PaaS to be used on various IaaS platforms), our clients can maximize container portability benefits by mixing and matching different cloud services and managing them through the same UI and API.

, monolithic application topology needs first to be decomposed into small logical pieces distributed among a set of interconnected containers. Each application component should be placed inside an isolated container. This approach can simplify the application topology in general, as some specific parts of the project may become unnecessary within a future architecture.

vm decompositionJelastic

There are two types of containers that can be chosen for running the project: application and system containers. An application container (such as Docker) typically runs little more than a single process. It is more appropriate for building new projects, as it is relatively easy to create the required images using publicly available Docker templates and meet the requirements of the cloud-native approach from the very beginning.

A system container (LXD, Virtuozzo) behaves more like a full OS. It can run full-featured init systems like Systemd, SysVinit, and OpenRC that allow processes to spawn other processes like OpenSSH, Crond, or Syslogd together inside a single container. This is more preferable for monolithic and legacy applications, as it lets you reuse architectures and configurations implemented in the original design for running in VMs.

application container vs system containerJelastic

System containers offer multiple benefits when migrating an existing legacy application. IP addresses, hostnames, and locally stored data can survive container downtimes, there’s no need for port mapping, and you gain a far better isolation and virtualization of resources. Plus you get compatibility with SSH-based config tools and even hibernation and live migration of the memory state. The only perceptible disadvantage compared to application containers might be a slower start-up time as system containers are a bit heavier due to the additional services required for running multiple processes.

In Jelastic, it is possible to run both application and system containers. In contrast to other PaaS vendors that use the so-called Twelve-Factor App methodology, Jelastic does not force customers to use any specific approach or application design in order to deploy cloud-native microservices and legacy monoliths. Nor must developers modify their code to a proprietary API in order to deploy applications to the cloud. The projects can be up and running in just minutes using an application archive (for example) or just the link to the project in GitHub. This makes the entry point easier and more seamless, reducing go-to-market time and eliminating vendor lock-in.

Destination: GlassFish Server in a container

The components of a GlassFish cluster are the same in a container as in a VM, but they are distributed across separate isolated containers.

glassfish containersJelastic

Worker nodes can be added or removed automatically, as well as attached to a DAS node using a container orchestration platform and a set of natively integrated automation scripts.

glassfish container clusterJelastic

Jelastic hides much of the complexity of migration and automates scaling and clustering. Once the application is running in a containerized environment, the PaaS handles all the steps of the application lifecycle and providing easy creation of dev, test, and production environments and vertical and horizontal scaling out of the box. For example, there is already a pre-configured highly available with automatic provisioning of replicated instances. So developers do not need to write custom scripts to implement the required logic and can concentrate on coding.

, provider of a cloud platform that simplifies application hosting inside containers. An expert in large-scale distributed applications and enterprise platforms, Ruslan has led engineering and software architecture teams at Jelastic, Inntelligenz, and SolovatSoft. He was one of the key engineering leads at the National Space Agency of Ukraine.

New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to .