Apr 11, 2018
Mark Johnson
D2iQ
7 min read
Developers and application owners have many new tools and technologies such as microservices, Docker containers, CI/CD, and DevOps that help them produce better software, faster. Yet, the sad truth is that most organizations rely on untold numbers of legacy applications, many of which are Java EE, to power mission critical systems that can't be migrated to some of the emerging technologies and processes.
Legacy Java EE apps are almost a necessary evil, providing core business functions while forcing IT teams to face myriad operational problems including planning for and addressing scaling challenges, managing inefficient and unpredictable resource consumption, protecting unsecured confidential information, and applying patching and restarting applications without service disruption.
Rewrite? Re-architect? No way!
Many organizations become overwhelmed as they approach these challenges because they are often encouraged to re-architect their applications and migrate them to (Docker) containers or a Platform-as-a-service (PaaS) such as Red Hat Openshift or Pivotal Cloud Foundry. Unfortunately, re-architecturing the application can sometimes be time, cost or technically prohibitive, resulting in modernization initiatives that are doomed before they even begin.
The good news is that enterprises don't have to rewrite their applications or migrate them entirely to the cloud to solve these problems. There are solutions that allow enterprises to benefit from modern architecture without re-architecting or re-writing their apps. One of these solutions is Mesosphere DC/OS, which runs traditional Java EE applications with no modification necessary. DC/OS also provides simplified deployment and scaling, improved security, and faster patching, and saves money on infrastructure resources and licensing cost.
DC/OS includes two application orchestration options. The first is Marathon (part of DC/OS), a production proven orchestrator that supports application binaries without modification. For applications that can be migrated to Docker, DC/OS provides another option, Kubernetes, which can be deployed with a single click on DC/OS. Organizations now have a unified platform for running both legacy Java EE apps and Docker containers.
Let's discuss some of the operational challenges presented by modernizing Java EE apps and how Mesosphere DC/OS solves them.
Legacy Java EE application scaling can take months
Many developers politely (or not so politely) suffer through a process that involves new server requests that take 6 months to fulfill and add to the application cluster. That's fine if you can plan utilization levels 6 months in advance, but what if you only need the additional horsepower for a month or two? Given the challenges of provisioning the server in the first place, are you really going to remove it from the cluster? Probably not. The smart move from an application reliability perspective is to keep the new server attached to the cluster and have excess capacity. This leads to greater administrative costs, increased power consumption, a bloated data center footprint, and a server that cannot be repurposed for another application.
A modern approach is to use a datacenter-wide cluster manager such as Mesosphere DC/OS. Mesosphere DC/OS pools all the resources in the infrastructure and treats them as one giant resource pool. Developers interact with DC/OS using a self-service interface without having to migrate existing applications to Docker. Applications are then automatically deployed on existing capacity.
Applications are easily deployed and scaled up and down in just a few seconds. Applications owners can respond to business demands immediately, and infrastructure operators don't have to worry about unused capacity or virtualization licensing.
DC/OS runs on any Linux, and unlike a virtual machine based architecture, DC/OS consumes minimal resources so apps can leverage infrastructure fully. DC/OS guarantees resource isolation and efficiency, and employs access control mechanisms to make sure those resources are used appropriately, ensuring maximum utilization without risking application performance.
Password management is hard and often public
When your legacy app was initially created, security was a lot simpler than it is now. All that was required to secure your app was to set a password in a configuration file, and then to make sure that no one from the outside could access your administrative console or connecting databases. As time went on, more people within the organization became familiar with this password in order to support general maintenance and emergency debugging of the application.
The problem is exacerbated by clear text passwords and the explosion of apps that reference a common resource (such as a database) using shared credentials. In some organizations, changing a single database password can result in having to change the config-defined password for a hundreds of apps. Since changing a password oftentimes means a restart and an application outage, most passwords for resources such as databases rarely get changed. In addition, given the number of current and former employees who probably know the password, your applications and databases are at significant risk for a security breach.
A centralized secrets manager that is tightly integrated with the application deployment process alleviates this burden. Mesosphere DC/OS includes a built-in secure centralized secrets management store. To remove the potential for downtime, you can add a new password for the application resource (leaving the old password temporarily in place), change the secrets definition to the new password, and then update the service with the new password. Furthermore, it is now easier to frequently change the resource passwords to proactively prevent the situation described above where many people know the password.
Dealing with Unstable Java EE Legacy Applications and Application Server platforms
Another challenge with legacy applications such as Java Enterprise Edition (JEE/J2EE) is that these older applications and their application servers are noted for memory leaks and hanging connections. Many enterprises have addressed this problem through some form of automated cron process to restart the application server and all its applications on a nightly basis, resulting in an outage which can be as short as a few minutes or as long as a few hours. Maintenance outages around midnight each day or week were probably acceptable when the application was first deployed, but in today's 24x7 world, such outages are unacceptable.
With Mesosphere DC/OS, enterprises can set up an application specific health check that can be attached to each application instance so that if the application fails to respond, DC/OS automatically restarts the application. In this way, when DC/OS initiates the restart process, the original process remains operational until the new process with its clean memory and connection pool is healthy and ready for restart. In this manner, DC/OS assures application reliability for legacy applications without requiring coding changes from developers and application downtime for users.
Challenges patching legacy Java EE applications
We're inundated with a constant stream of news about data breaches caused by vulnerable applications and platforms that are the result of improperly or inadequately patched environments, out of date libraries (JAR files), or legacy code with built-in vulnerabilities.
Mesosphere DC/OS solves these problems by providing a simplified CLI/UI/API interface to deploy applications. Enterprises can either deploy directly using the CLI or UI, or use the API to integrate with a full non-opinionated Continuous Integration/Continuous Deployment (CI/CD) environment such as Jenkins or Gitlab. A frequent concern when enabling a CI/CD environment for legacy applications is that often source code is no longer available. Ideally, of course, you will want to load your source code into a source code repository such as Git where new checkins to the repository result in build, testing, validation and then deployment cycles. In cases where source code and perhaps individual libraries may not be available, you can integrate the components that are available into the CI/CD process and thus mitigate the risk.
DC/OS Enables Low Risk Legacy Java EE Application Migration
Mesosphere DC/OS provides a low risk distributed platform to host your legacy applications and orchestrate them with your choice of Marathon or Kubernetes.
Are you ready to get started? To complete the JEE application migration we will need to:
- Inventory the applications targeted for migration and their configurations.
- Decide whether you will deploy your native application server and targeted application binaries (JAR, WAR), or build a Docker image for your application server and then dynamically load your application binary at runtime.
- Load the source code and its configuration artifacts for each application into a source code repository such as JFrog Artifactory or Nexus, or your CI/CD server of choice, such as Jenkins, and then (optionally) integrate or set up the appropriate build pipeline.
- Protect your confidential credentials such as user names, passwords, configuration files, and certificates in the encrypted DC/OS Secret Store.
- Create an application deployment file (Marathon JSON or Kubernetes YAML), define a health check for the application, and specify the application group based on the application owner, with the appropriate application monitoring strategy as well as a no-outage-based restart plan if necessary.
After the completion of the above 5 steps, your legacy applications will be fully migrated and operational. Please check out out next blog post in this series for an in-depth description of how to run your JEE application on DC/OS or join our Painless Modernization of Java EE Applications webinar for more information.
