May 03, 2018
Amr Abdelrazik
D2iQ
7 min read
In previous blogs, we covered how DC/OS helps you run traditional Java EE applications on any infrastructure with reduced cost, improved operations and security, and provides a self-service deployment environment. In this blog, we'll cover how DC/OS accomplishes that.
DC/OS includes 3 key components that make it easy to run traditional Java EE apps without packing them in a Docker container:
- Universal Container Runtime (UCR): Downloads and launches application binaries without having to package them in Docker containers
- Cluster Manager (Apache Mesos): Abstracts server nodes into a giant resource pool and manages resource allocations
- Application & Container Orchestrator (Marathon): Provides a single interface to deploy, run, and scale your Java EE app via UI, CLI, or GUI.
We'll provide plenty of detail on these three components lower in this post, but first let's start with some fundamentals.
A Primer: How Applications Run on an Physical server or a VM
Before we go into how DC/OS launches applications, let's do a quick review of how to launch an application on a traditional server or virtual machine.
After booting up your virtual machine and deploying your operating system, you need to copy the application and associated libraries/application server to that host, and then launch the application using a terminal such as Bash. The terminal launches the new application in a new process. The process inherits the privileges of the user who launched it as defined in the operating system, and the application has access to the entire user space memory, CPU, networking of the host operating system.
DC/OS Universal Container Runtime
DC/OS Universal Container Runtime (UCR), previously named Mesos containerizer, is installed when DC/OS is deployed on an agent node, and it is responsible for launching the application. UCR provides the following capabilities:
- Application file download: UCR automatically fetches and downloads application files, such as Jar files and application servers (i.e Tomcat) from any centralized repository such as an https server or artifact repository, eliminating the need to log in to each server and manually copy the files.
- Application launch using Standard Linux Commands: UCR launches applications in the same way they're launched by any Linux shell (like the previously mentioned Bash) using the same commands used on a physical machine. Applications don't need to be packaged in Docker containers or launched using Docker specific commands.
- Resource limitation (cgroup) and security isolation (namespaces). UCR allow multiple applications to share the operating system with complete isolation using cgroups and namespaces. cgroups guarantees that each application runs on a user defined subset of the host operating system resources such as memory, CPU and disk. Namespaces limit access and visibility to system resources.
- Application Health Check: UCR monitors the application process, and, if the process crashes, It reports the failure to DC/OS (Mesos) and then Mesos triggers it to restart the application. This is very handy, for example, if your Java EE applications that leak memory and ultimately crash. UCR also allows you to configure Health Checks. Developer can configure custom HTTP or CMD healthchecks with a specified number of retries, and, if the application continues to fail to respond, UCR automatically restarts it.
The above UCR capabilities are the core of what makes DC/OS capable of launching legacy Java EE applications. In addition, UCR provides additional capabilities such as:
- Integration with DC/OS networking so that your application can be launched with integrated load balancing, making it easy to scale your app when needed.
- Integration with DC/OS secrets management that stores application credentials such as usernames and passwords in an encrypted and access-controlled manner. Secrets are only loaded to the application and not the entire server or virtual machine to reduce risk of compromise.
How is UCR Different from Docker Engine?
Although UCR and Docker Engine use the same Linux primitives such as cgroups and namespaces, they have two main differences between them:
- UCR supports launching both Docker images and native application binaries unmodified, while Docker engine requires you to package your app in Docker images only.
- UCR is a mature, production proven technology, that has more than 8 years running in large scale production systems in such as Twitter and Airbnb on over tens of thousands of servers.
What's Wrong with Using Docker images
Actually, nothing is wrong with using Docker images to deploy your applications, however, packaging your app in a Docker container requires a learning curve and modifying your application development lifecycle. Organizations sometimes don't have the time or the resources to migrate all of their apps to Docker. In that case, DC/OS is an attractive platform for running traditional and dockerized application.
Cluster Manager (Apache Mesos)
So now that you understand the first component that enables you to run Java EE apps on DC/OS, it's time to get to the next component, Apache Mesos.
Apache Mesos is the core technology powering DC/OS. Mesos is a cluster manager originally developed at University of California Berkeley. Mesos employs a modular two-level scheduler architecture that allows it to run many technologies such as containers, data services, and analytics on a single platform while maintaining isolation. For Java EE, Mesos provides three key roles, Resource Pooling & Allocation, Cloud Portability/Hybrid Cloud, and server failure detection and recovery.
Resource pooling: Mesos aggregates all of the resources across all nodes into one pool of MEM, CPU and disk. Applications then request resources from the available pool. Once resources are allocated, Mesos then triggers UCR to launch the application with those resources, and guarantees that they are always reserved for this application and isolated from other workload.
Pooling enables IT organizations to get maximum utilization of the infrastructure and easily scale and consume available capacity anywhere on the cluster.
Cloud Portability/Hybrid Cloud: The same way virtualization abstracted the hardware, Mesos abstracts the underlying infrastructure across physical/virtual/cloud resources to provide seamless application portability across private and public infrastructure, and unlocks other hybrid capabilities such as cloud bursting and cross-cloud BC/DR.
Server Failure Detection and Recovery: While UCR restarts the application in case it crashes, Mesos detects if the entire server node crashes and automatically relaunches the application instances on another server node, increasing uptime and reducing manual intervention.
Application/Container Orchestrator (Marathon)
This brings us to the third key piece of the solution, Marathon. Marathon is the main application deployment and orchestration component that is built into DC/OS. Marathon provides self-service GUI, CLI and API interfaces to to deploy and manage your application as well as integration with CI/CD tools.
Streamlined Configuration and Deployment
In DC/OS, applications are defined in a single JSON configuration file that captures runtime requirements such as hardware resources needed, number of application instances, security, networking, and more. The JSON file can be created through the GUI (or manually) and is used to automate application deployment.
Ease of integration with CI/CD tooling
Marathon API interface simplifies integration with CI/CD tooling. A single API deployment call alleviates the need to write complex automation scripts to deploy and configure virtual or physical machines, deploy the application instances, configure networking, and a multitude of additional steps. Marathon API interface simplifies the app deployment between testing and production DC/OS clusters or even across multiple clouds
How Does Marathon compare to Kubernetes?
You might also be wondering, how Marathon is different from Kubernetes. While both can run on top of Mesos, Kubernetes is designed to only run Docker containers. Marathon, combined with the UCR, is well positioned to run traditional application binaries such as Java EE, without having to migrate them to the Docker file format.
DC/OS Solves Java EE Nightmares
DC/OS automates running traditional Java EE applications in a scalable and high performance manner. Organizations now have a single platform for running traditional apps, Docker containers and stateful data services on any public or private infrastructure. Having a single, production proven, platform increases resource utilization, simplifies application architecture, and accelerates introduction of new technologies.
In the next blog post in this series, we'll show you how DC/OS secures and streamlines patching of migrated Java EE applications and their libraries. Please join our Painless Modernization of Java EE Applications webinar for more information.
