A new industry collaboration called MicroProfile announced at the Red Hat Summit in San Francisco promises to make...
it easier for developers to use Java EE technologies and APIs for building microservice applications. The initiative should make it easier to combine elements from different tool sets for microservice architectures. This effort also aims to help enterprise architects tip the balance towards Java against less mature development languages.
Newer reactive programming languages may offer some advantages in terms of time to code, but it is not clear how well they will do in terms of security and supporting GRC requirements across the entire software development lifecycle. The Java community is pushing back to make Java a first-class alternative.
In some ways, this effort can draw upon enterprise Java bean components. The EJB model was small, but the containers were not, said Antonio Goncalves, a senior software architect based in Paris. "Java EE containers have evolved. They have been lighter, smaller, faster, so it was time to have MicroProfile -- micro components in a micro container," he explained.
Focus on light apps
The goal is to create a standard subset of components of the Java EE runtime suitable for microservices. A Java EE profile includes a well-defined set of features like the Web Profile. MicroProfile initially supports JAX-RS for exposing RESTful web services, Servlets, JSON-P and CDI for context and dependency injection. The immediate goal is to deliver a minimum platform that boots in seconds. Red Hat, IBM, Tomitribe and Payara all plan to release reference applications by September.
The release cadence will be heavily influenced by the features that are decided on through community input. The group hopes to move much more quickly than a standards body because this is a pre-standardization collaboration.
"Enterprise Java deployment artifacts are incredibly small, runtimes are light-weight and can easily be layered onto a standard Linux Container," said Steve Millidge, founder and director at Payara, a Java server vendor. "Building on these foundations the next step is to come together, involve the community, innovate and drive forward a new standard runtime tailored specifically for the demands of microservice architectures."
Reacting against reactive
In some ways, this effort could be seen as a reaction against the rise of reactive programming languages. Reactive programming involves a different development model -- described as a spreadsheet with functions embedded into the cells. Making a change in one cell propagates instantly to other cells. In a reactive programming model, a change in one section of the application is propagated to files that make up the application.
This makes it possible to think about a system that facilitates the ability to change things in the application more efficiently. If the address of the customer changes, for example, this can kick off a process involving other functions. This is a very different model and the debugging is more challenging. On the plus side, this style of programming provides better scalability because it is all asynchronous and non-blocking.
Some of the popular technologies for this programming model include Reactive Extensions, Scala, Clojure, Vert.x, Akka and Node.js. However, these languages are still relatively young compared to Java.
"It is important to caution developers that want to use a new language," said Rich Sharples, senior director of product management for Red Hat JBoss Middleware. "Mature languages are popular because they are stable and well-tested. It is a mature platform and is really the standard for enterprise applications."
Java does not have to be heavy
Enterprise architects have to address some of the concerns by new developers that Java is old. Java EE is actually well-suited to be used as a microservices platform today. "The biggest challenge has actually not been technical, it's been the perception that Java EE is heavy and can only be used to address traditional workloads," Sharples said.
On the contrary, the Java EE community has evolved with distributed computing architectures over the last 20 years and can be optimized to better address microservice applications. For example, the Java EE platform requires a rich set of technologies (JSRs), but not all of them are commonly used with microservice applications. To date, managing this rich functionality hasn't been a problem because modern Java EE implementations are lightweight and modular, so they boot in seconds and make efficient use of RAM.
The MicroProfile approach to optimizing for microservices is to start with a small core set of features and grow from there with heavy involvement from the community. The core platform will likely add functionality over time, some of which will come from Java EE related JSRs, and some that are not directly related to Java EE at all. For the latter, the MicroProfile community will investigate how to more directly address microservice-related patterns like circuit breakers, bulkheads and service discovery.
The MicroProfile project aims to get Java EE back on the edge of innovation, Sharples said. "The goal is to ensure that when developers think about microservices they start with Java and Java EE; this enables them to start with the standards-based platform with familiar Java APIs."
How JBoss middleware is aiming to increase the role of microservices
What is the real relationship between microservices and the cloud?
Take this quiz on microservices vs. SOA