Migrating JavaEE Applications To the Cloud
Java EE began with less than 10 individual specifications, but it has grown over time through subsequent updates and releases to encompass 34. Compared to microservices-based architectures, Java EE and its included specifications were originally designed for a different development and deployment model. Only one monolithic server runtime or cluster hosted many different applications packaged according to standards. Such a model runs opposite to the goal of microservices. The latest versions of Java EE added a ton of developer productivity to the platform alongside a streamlined package. [Modern JavaEE Design Patterns]
There are a lot of technologies from the Java EE specification that barely offer any advantages to microservices-based architectures, such as the Java Connector Architecture or the Batch Processing API. When building microservices architectures on top of Java EE, look at the asynchronous features and use the best available parts.
The document below details which Java EE specifications are a proper fit for implementing cloud native apps. Apps that leverage the JavaEE Web Profile make the best candidates to movet to the cloud. Please see the table below for a detailed treatement of Java EE spec. suitability in the cloud.
Deployment of Java EE Apps To Cloud Foundry
The restrictions imposed by the Cloud Foundry platform allow the platform to scale and provide qualities of service like app lifecycle management, dynamic routing, health management, monitoring, recovery, log aggregation and infrastructure orchestration. Cloud Foundry as a platform optimizes for stateless web apps with light footprint. Some of the recent features ofCloud Foundry like TCP Routing, Deigo container runtime and Docker support have reduced the constraints of the apps running on the cloud.
Cloud Foundry leverages buildpacks to create immutable app artifactions called droplets. A droplet represents a fundamental unit of scaling and immutable deployment in Cloud Foundry. Java apps in CF can be staged and run with the Java Buildpack, TomEE Buildpack, JBOSS Buildpack and Liberty Buildpack.
The capabilities of these buildpacks as they relate to running JavaEE apps are as follows:
Java Buildpack
Provisions a plain vanilla Tomcat servlet contatiner. This buildpack is ideal for spring apps, fat jar apps or apps that come with batteries included. JBP auto-configures data-source beans in the Spring Application context to connect to the appropriate services in the cloud.
WebSphere Liberty Buildpack
Buildpack uses IBM JRE 8 and enables Java EE 7 Web Profile features for WAR and EAR applications. Liberty Buildpack can be easily configured to switch to JavaEE6 or JRE7 using configuration override environment variables. This is the most natural target for moving apps from WebSphere Application Server Network Deployment or Websphere Application Sever Base apps. The following list of Liberty features will be enabled in the default configuration:
beanValidation-1.1, cdi-1.2, ejbLite-3.2, el-3.0, jaxrs-2.0, jdbc-4.1, jndi-1.0, jpa-2.1, jsf-2.2, jsonp-1.0, jsp-2.3, managedBeans-1.0, servlet-3.1, websocket-1.1. The Liberty Buildpack accepts .ear. .war. .jar files and full server packages. [Upcoming Liberty buildpack changes]. The Liberty buildpack auto-configures the server based on managed services bound to the application.TomEE Buildpack
The TomEE buildpack is the smallest delta on top of the Java Buildpack to support the Java EE specification. Apache TomEE is an all-Apache Java EE 6 Web Profile certified stack. Apache TomEE is assembled from a vanilla Apache Tomcat zip file. TomEE starts with Apache Tomcat, adds jars and zips up the rest to provide the Apache TomEE Web Profile i.e. Servlets, JSP, JSF, JTA, JPA, CDI, Bean Validation and EJB Lite .
JBOSS Buildpack
The JBOSS Buildpack provisions full and web profile implementations of Java EE. The buildpack only stages war files and has no support for ear files. JBOSS Buildpack function is currently being enhanced to autogenerate the standalone.xml configuration based on bound services.
Java EE Web Profile
| Specification | Versions | Suitability | Cloud Nativity |
|---|---|---|---|
| Servlet | 3.0, 3.1 | Yes | Non-blocking I/O, upgrade to WebSocket, security. The servlet specification also allows the use of asynchronous request processing. The parts that need to be implemented are thread pools(using the ExecutorService), AsyncContext, the runnable instanceof work, and a Filter to mark the complete processing chain asynchronous. |
| JSP, EL, JSTL, JSF | 2.2 | Yes | Although JSF 2.2 is a point release it contains a number of features important to the community.In general there are few issues using HTML 5 with JSF. HTML 5 features such as JavaScript, WebSocket, local storage, canvas and web workers can easily be used with JSF. The only identified issue thus far had been using newer HTML 5 markup with JSF components since JSF components do not recognize these markup elements out of the box. The solution in JSF 2.2 is to allow for freely mixing and matching HTML 5 markup with JSF via pass-through elements and attributes.The older and redundant managed bean model is now being deprecated in favor of the CDI programming model. This is part of the overall platform alignment with CDI. As part of this alignment the very useful view scope previously limited to JSF managed beans is now available to CDI beans.The flow scope is an extremely useful addition to JSF. It allows for beans that automatically live and die within a given boundary in the application (e.g. account management section, catalog section, search section). |
| JAX-RS | 1.1, 2.0 | Yes, JAX-RS is the primary building block of the Java EE microservice stack | The primary goal of JAX-RS 2 is improving portability by standardizing common non-standard features in JAX-RS implementations like Jersey, RESTEasy and Axis. One of the most significant changes is adding a client-side REST API. The Fluent API uses the builder pattern and is at the same time very simple but powerful.The addition of message filters and entity interceptors significantly improve the extensibility of JAX-RS. While message filters are conceptually similar to Servlet filters, entity interceptors are similar to CDI interceptors. While it is possible for end users to use message filters and entity interceptors the more likely users are framework and plug-in writers.Asynchronous processing can significantly improve scalability for the most demanding applications. JAX-RS 2 adds simple asynchronous processing capabilities both on the client and server sides. |
| WebSocket | 1.0 | Yes, WebSockets are supported by CF | WebSocket is a key part of the HTML 5 family of standards. It allows for TCP like stateful, full-duplex, bi-directional, asynchronous communication over the web. Unlike stateless vanilla HTTP, WebSocket is useful for cases such as online multiplayer game-like applications, online chat-like applications or stock ticker-like applications.The Java API for WebSocket is a high level API similar to JAX-WS and JAX-RS. There is both a server-side and a client-side API for easily developing with WebSockets. Most of the time you will likely be writing Java server-side endpoints while the client side is written in JavaScript.There is both a declarative annotation centric API as well as an interface centric programmatic API. You will most often likely use the annotation-centric API. The programmatic API is useful for dynamically changing WebSocket endpoints at deployment time, perhaps very helpful for framework writers. |
| JSON-P | 1.0 | Yes | JSON is quickly becoming the de-facto data serialization protocol on the web, especially with HTML 5.The goal of the Java API for JSON Processing (JSON-P) in Java EE is to standardize JSON for Java, reduce dependence on party frameworks and reduce application complexity.Similar to the Java API for XML Processing (JAXP), JSON-P is a lower level API to handle JSON. It is not a higher level declarative binding API like the Java API for XML Binding (JAXB). Such an API is forthcoming in Java EE 8 and will be named the Java API for JSON Binding (JSON-B). |
| JPA | 2.0, 2.1 | Yes, As long as the database and the 2nd level cache is injected as a backing service. | JPA 2.1 standardizes a bunch of non-standard features like schema generation and stored procedures. JPA 2nd level caches should be located outside the JVM and injected as a backing service. Unsynchronized persistence contexts and entity graphs are other optimization introduced. |
| CDI, Interceptors, Managed Beans, DI | 1.0, 1.1 | Yes | The CDI specification has become the fundamental building block of the Java EE platform. Java EE7 and Java EE8 is completely being reworked on top of CDI. In addition to providing dependency injection CDI provides eventing, interceptors, decorators and other core application services. |
| EJB | 3.1, 3.2 | Yes | Java EE 6 EJBs run perfectly fine on Cloud Foundry as long as the remoting protocol is HTTP. Stateless session beans and singleton EJBs run unchanged on the platform as long as the EJB container. Stateful EJBs should not be passivated locally. Stateful EJB passivation will only work with an external distributed cache. |
| JTA | 1.1, 1.2 | NO | 2PC Transactional commit does not work across multiple distributed REST services. Prefer BASE(Basically Available, Soft state, Eventually consistent) over ACID(Atomicity, Consistency, Isolation & Durability). Transaction managers typical write transaction logs to local file system and rely on persistent server identity - both of these are not available by design in CF. The workaround here is using standalone transaction managers like Atomikos and Bitronix. Introduce eventual consistency patterns |
| Concurrency Utilities | 1.0 | Yes | The concurrency utilities for Java EE provide a framework of high performance threading utilities and thus offer a standard way of accessing low-level asynchronous processing. |
Java EE Full Profile
The JavaEE full profile has a numnber of management and security technologies that no longer apply in the cloud. Since the platform takes care of application lifecycle management, deployment, scaling , health management and monitoring of apps. Therefore specifications like J2EE Management, Javabeans managment framework are no longer relevant in the cloud. A small subset of specifications like JAXB, JDBC and JMX still apply in the cloud and will work as is in cloud foundry.
In terms of web technologies in the full profile most specifications work unchanged in the cloud; however specifications like JAXR and JAX-RPC are no longer relevant to modern microservices architectures. SOAP based JAXWS webservices will run unchanged in an app server- buildpack that supports the full profile.
Full profile Java apps in general poor candidates to migrate to the cloud.
Other Technology Constraints in moving to the cloud
In addition to the evaluating the suitability criteria from a Java EE perspective there are other views of suitability as well. It is critical to look at the app from multiple lens to determine app suitability. Some of these technology Barriers To Moving Apps and Services to Cloud Foundry are:
- Language/Runtime Characteristics: CF only supports languages that have a buildpack that run on Linux. Cloud Foundry currently supports Ubuntu Trusty and CentOS 6.5 on vSphere, AWS, OpenStack, and vCloud infrastructures.
- Degree of Statefulness - Runtime state includes caching and Sessions. Coordination of state across peer instances impacts performance. Any application that requires persistent heavy data processing. Apps that require large-scale stateful connections to external services. Use of frameworks that persist client state on the server side like JSF. Apps that keep a large amount of critical runtime state within the JVM i.e. stateful apps are bad candidates to the PaaS. Ideally all persistent state should reside outside the app in a HA data persistence tier.
- File System - Cloud app instances are ephemeral. Local file system storage is short-lived. Instances of the same app do NOT share a local file system.Avoid writing state to the local file system. Does the app rely on a persistent local filesystem or storage ?
- Configuration - Configuration should live external to the deployed app. Config must come from the Environment via environment variables via external configuration server. Apps that have embedded property files or one war/ear file per environment require the refactoring of configuration code before running on the PaaS. We recommend one code base tracked in revision control across multiple deploys. Can you deploy to multiple environments with single codebase.
- Web Frameworks : Does the app leverage Java EE or Spring Frameworks and if so are the libraries bundled within the app or come with the app server. If there is strong dependence on an application server like WebSphere to provide dependencies or if proprietary application server APIs are used then that forces the app to use a particular buildpack or worse refactoring to start embedding the libraries within the app.
- Startup/Shutdown Characteristics: Prefer apps that start cleanly without a lot of upfront initialization, coordination and shutdown without the need for comprehensive cleanup of state.
Is a startup/shutdown sequence necessary for your app to run effectively. Avoid creating any process instances outside the staged runtime. - Scalability of the App - Does the app rely on X-axis(horizontal duplication, Scale by cloning), Y-axis (functional decomposition, scale by splitting different things) or Z-axis (data partitioning, scaling by splitting similar things) ?. Design app as one or more stateless processes enabling scale-out via process model.Which other dependent services needs to be scaled when the app is scaled ?
Dependencies - How are external dependencies wired into the app ? Are dependencies isolated and explicitly declared.http://microservices.io/articles/scalecube.html - Inbound Protocols - Only a single inbound port is open to an application. Only protocol supported by CF is HTTP/HTTPs/WebSocket. No other protocols like RMI or JMX will work (unless tunneled over HTTP) on the inbound side. HTTPS is terminated at the load balancer. App that relies on transport security at the server will need to be modified. Apps that hold persistent long running socket connections to the server will not work, with apps using WebSocket being the only exception. Any sort of direct peer-to-peer messaging or custom protocol will not work since the warden containers are configured for ingress only over HTTP.
- Logging - Are there multiple log streams ? Is there a strong requirement on local persistence of the logs ? Treat Logs of the app as event streams. Prefer console based logging to file based logging. Configure app server logging to log to the console (stdout/stderr) and thereafter drain to a long-term log analytics solution. Logs written to the local file system in CF are not persisted.
- Rollback - Immutable code with instant rollback capability. Can the app tolerate multiple versions ? Can the app be reverted to a previous version with a single action ? Does deployment of the app require orchestration of multiple steps.
- Security - Does the app rely on network centric or app centric security model ? We recommend relying on on application Layer 7 security rather than network security based on Firewall rules. How are application users authenticated and authorized. Is a Federated Identity and Authorization solution in place ? In CF, outbound egress from the app is controlled by application security groups applied to the warden container. You will need to configure whitelist rules for the services bound and protocols used for outbound communication.
- Application Size - cf push times out for apps bigger than 250MB. Staging of apps that exceed a certain size becomes a big drain on resources for network marshalling/unmarshalling as well as runtime memory footprint. Keeping the droplet smaller results in faster deployment. client_max_body_size can be used to changed the max upload size on the Cloud Controller.
- Performance & Monitoring - Can the app exhaust CPU under load? Are there any concurrency bottlenecks ? Can the app be instrumented for metrics ? Does the app provide a health check/actuator support in production. Does the app leverage app correlation IDs for distributed requests & responses. Does the underlying platform provide basic monitoring(CPU, Disk, Memory) and recovery (Spawning of exited instances) and instant(manual/automated) scaling. Can the logging and admin operations be enabled via runtime switches aka curl requests ?
- Developer Experience - Does app architecture and web frameworks facilitate local development and cloud production. Does the app ruin on runtimes that run equally locally and in the cloud. Does the app use (Spring) profiles to encapsulate conditional app. configuration.
- Cloud Native Architecture - Does the app compensate for the fallacies of distributed computing by leveraging framework libraries like Netflix OSS and/or SpringCloud OSS ? Does the app leverage zero downtime practices of forward and backward schema compatibility for REST microservices and databases. Can one service be deployed independently of other services. Is lockstep deployment of physical war’s needed to manifest a logical app ?
- Data Tier Services/Databases - Any persistence employed by the app has to be synchronized across datacenters and availability zones. The data tier/ Stateful tier of the app has to be managed in lock-step with the stateless tier. Focus has to be put on live content and data migration along with CAP theorem issues. App code has to be forward and backward compatible with schema changes in the data tiers.
Summary
Java EE provides an excellent substrate for a next generation microservices development. As long as you stick to the more recent versions of Java EE (6,7,8) particularly the web profile applications can be implemented and scaled at web scale. It is critical that services follow good design principles of domain driven design, designing for failure, decentralized data management, asynchronous inter-service communication, discoverability and evolutionary design. Existing apps that run on WebSphere Application Sever Network Deployment today are natural candidates to move to the WebSphere Liberty Profile Buildpack. Use the JBOSS and TomEE buildpack for non-WebSphere apps that need a ligter weight more agile runtime in Cloud Foundry. A couple of other options that have not been explored are Dockerizing apps and running apps as fat-jars within Cloud Foundry. For a complete treatement of using Dockers and fat jars please see article and workflow below on migrating WebSphere apps to Cloud Foundry.
