Optimizing Enterprise Java
for a Microservices Architecture


Enterprise Java Standards History

J2EE 1.2

J2EE 1.3

J2EE 1.4

Java EE 5

Java EE 6

Java EE 7

Java EE 8







Java EE has been an extremely successful platform. The JCP has been the steward of over 20 compatible implementations over its nearly 20 year history, resulting in a $4B industry. These are just some of the Java EE compatible implementations that exist.

In its early stages, J2EE grew somewhat quickly (perhaps too quickly) as the platform needed to address the immediate needs of the enterprise. Beginning with Java EE 5 in 2006, the pace began to slow as the platform began to mature. Java EE is now following the slower release cadence that a standards organization typically reflects. A standards-based release cadence by design does not address ew and rapid innovations.

Fundamental Shifts in Computing

  • Deliver new features more quickly
  • Smaller, more agile teams
  • Deliver business features as discrete services
  • Scale services independently
  • Reduce time to market
  • Address unpredictable loads
  • Pay as you go
  • Containerization



While the industry was delivering Java EE 7 and planning Java EE 8, some fundamental shifts were occurring during this time. The first was the growth of cloud computing. Driven by Amazon early on, the primary benefit was the ability to deliver features to market more quickly by offloading the infrastructure to a 3rd party, combined with the ability to scale up and down as needed and paying for only the compute power that is utilized. More recently, containerization is becoming much more popular thanks to Docker. While there are many benefits to containers, the most interesting is that it brings the value proposition of Java’s WORA (Write Once Run Anywhere) to the cloud. Applications/services packaged in docker containers can run in any cloud that supports containers.

Developers saw these changes infrastructure changes occuring in the cloud, and for disruptive organizations like NetFlix for example, began to re-architect their services with the cloud in mind. The goal was to deliver features into production more quickly, and the means to do so was to break up “slow moving monoliths” to fine grained and fast moving services that individually solve a specific business domain problems. This is known as microservices today.

MicroProfile Background

  • Began as a collection of independent discussions
    • Many innovative “microservices” efforts in existing Java EE projects
    • Projects already leveraging both Java EE and non-Java EE technologies
    • Creating new features/capabilities to address microservices architectures
  • Quickly realized there is common ground
  • Java EE technologies are already being used for microservices,
    but we can do better

During late 2015 until mid 2016, there was little to no movement on Java EE 8 since Oracle, who is the specification lead of many JSRs including Java EE 8, simply stopped working on Java EE 8 with little to no communication as to why (even today). However, many vendors had already solved the traditional “large monolithic Java EE runtime” problem, relying on the fact that Java EE defines APIs but allowed vendors to innovate on implementations.Vendors were extending their lightweight runtimes by experimenting with Microservices by not only utilizing Java EE APIs but also going beyond Java EE APIs.

Vendors were innovating quickly beyond Java EE 8 and they, along with the community, realized that there was a lot of shared interests. We were all trying to solve the same or similar problems, and did not want to risk splitting the Java EE community into vendor communities. Vendors and the community got together and realized that we were all far better off if we came together. Yes, microservices can be written with Java EE APIs, but we could do much better by bringing our shared experiences together to deliver a portable platform optimized for Microservices.

MicroProfile Release Philosophy

Release 1.0




Rapidly iterate
and innovate

Sept 2016

The goal of the MicroProfile release philosophy is to strike a healthy balance between the benefits of open collaboration, open source, and the value of standards. While MicroProfile started as an initiative in June 2016, release 1.0 was delivered in three months - just prior to JavaOne in Sept, 2016. The goal was to get the MicroProfile into developers hands quickly to prove our intent and jumpstart the community.

Vendors and various open source projects will continue to innovate with microservices within their own communities, but collaborate in areas of common interest. For example, there are common use cases that need to be addressed, popular 3rd party frameworks and standards we all support, and perhaps new APIs that we can co-develop. Even during these iterations we’ll be raising the bar for application portability. After multiple iterations of MicroProfile there will be enough features and consensus to result in a formalized standard. The process then starts over again with a new set of use cases.

Bridging Community and Standards

Vendor Choice

Implementation Choice

Application Portability

Backwards Compatibility

Reduced Risk

Broad Collaboration

Encouraged experimentation

Fail Fast

Rapid innovation

The community and fast-moving startups often think that standards are too slow, and enterprises often think that fast-moving community projects move too quickly and introduce too much risk. The MicroProfile bridges that gap by collaborating in areas where eventual standardization and shared investment makes sense in order to increase the pace towards standardization.

An Eclipse Foundation


  • Meritocracy; vendor neutrality
  • MicroProfile leadership can change over time
  • Legal and technical infrastructure
  • Trademark Ownership
  • Accepts Apache License

MicroProfile has moved to the Eclipse Foundation. There was a discussion in the community over governance and project ownership. The consensus was to move MicroProfile to a foundation. The benefit of a foundation is to ensure vendor neutrality, so that no one vendor (or individual) can control or own MicroProfile. The community agreed on the Eclipse Foundation along with the Apache License. As of December 2016, MicroProfile is an official Eclipse Foundation project.

The Eclipse Foundation encourages project leadership and core team membership based on merit. Those who provide the most valuable contributions (code or otherwise) are core team members or project leaders. It is expected that leadership and core team members will change over time. Members may desire to step away for a period of time to focus on other things, for example.

The Eclipse Foundation also provides other benefits, like legal support, trademark ownership, established governance processes, and more. As open source development has changed over the years, the Eclipse Foundation has evolved with it, and the consensus is that the Eclipse Foundation is the most natural choice for MicroProfile.

The MicroProfile team has agreed to place all code under the Apache License

MicroProfile 1.1 Underway

Security: JWT Token Exchange 1.0

Health Check 1.0

Configuration 1.0

Fault Tolerance 1.0 (Stretch goal)

Second Quarter


MicroProfile 1.1 is underway, and scheduled for the 2nd quarter of 2017. The community has decided to focus this release on Configuration, Security (JWT Token Exchange), Health Check, and Fault Tolerance.

Configuration: Separates (externalizes) a microservice from its configuration.

Health Check: Specifies a REST endpoint with service health information. Enables cloud infrastructure to detect the health of a service. If a service is unhealthy, a cloud runtime can restart (or fail and re-create) a service instance

Fault Tolerance: APIs that cover popular microservice programming patterns, including Fallback, Circuit Breakers, and Bulkheads

Feature Backlog* - Help us prioritize [1 of 2]

  • Container API
  • Microservic-y annotations (Ex: @CircuitBreaker)
  • Testing
  • Distributed Logging
  • Distributed Tracing
  • OAuth2/OpenID Connect
  • Microservice Security
  • Service Discovery
  • Health Check
  • Configuration
  • Metrics/Monitoring
  • WebSockets
  • JSON-B
  • Bean Validation
  • JPA
  • JTA
  • Concurrency Utilities for Java EE

* Some Items may be removed due to lack of interest

This is an initial list of potential JSRs and non-Java EE technologies that could be part of MicroProfile. The exact means of proposing and working on these features is being worked on (as of Nov 2016), but it is clear that the interests of the MicroProfile community is very diverse. Expect multiple sub-projects to work in parallel.

Feature Backlog* - Help us prioritize [2 of 2]

  • Messaging / Eventing
  • Asynchronous/Reactive Support / Patterns
  • Integration with Reactive / Eventing systems
  • Big Data/NoSQL strong & weak consistency support
  • NetFlix OSS Integration
  • JCache
  • JDK 8 Lambda+Streams
  • EJB Lite
  • Servlets
  • HTTP/2
  • Startup Time
  • Disk Space
  • Memory
  • Uber-jar
  • Java 9 Modularity

* Some Items may be removed due to lack of interest

This is an initial list of potential JSRs and non-Java EE technologies that could be part of MicroProfile. The exact means of proposing and working on these features is being worked on (as of Nov 2016), but it is clear that the interests of the MicroProfile community is very diverse. Expect multiple sub-projects to work in parallel.

Release Schedule

Sep 2016


Q4 2016



Move to



This is a calendar that is mean to define important milestones and intent. MicroProfile was released in September of 2016 and is currently being moved into the Eclipse Foundation. After that the intent is to have multiple releases per year.

Join the Community!

Join the Discussion!


MicroProfile - Google Slides