Eclipse Microprofiletm White Paper

Eclipse MicroProfileTM white paper

Pro bono by Lars Röwekamp

AN OPEN FORUM TO OPTIMIZE ENTERPRISE JAVA FOR A MICROSERVICES ARCHITECTURE BY INNOVATING ACROSS MULTIPLE IMPLEMENTATIONS & COLLABORATING ON COMMON AREAS OF INTEREST WITH A GOAL OF STANDARDIZATION.” A Technical Focus THE MISSION OF MICROPROFILE

MicroProfile enables Java EE developers to A benefit of adopting MicroProfile is that This White Paper discusses popular right-sized microservices architecture can help leverage their existing skill set while shifting its eleven specifications (at the moment of programming patterns that streamline engineer an application that is stable, scalable their focus from traditional 3-tier applications writing) are community driven, free, and open microservices development. MicroProfile and fault tolerant. to microservices. MicroProfile APIs establish which encourages and has resulted in multiple addresses those patterns by leveraging and an optimal foundation for developing implementations. Multiple implementations extending a developer’s existing skillset. For the Unfortunately, those benefits come at the microservices-based applications by adopting a eliminates the risk of vendor lock-in and sake of brevity, a developer will be referred to expense of additional complexities for which subset of the Java EE standards and extending maintains the developers’ freedom of choice. in its plural form: we. typical Enterprise Computing Frameworks them to address common microservices In addition, MicroProfile continues to evolve like Java EE, now Jakarta EE, are not patterns. delivering roughly three annual releases, Microservices is the most popular architecture sufficient. Although each microservice can offering an opportunity to include both new when creating cloud-native applications. It be implemented easily, managing, securing, MicroProfile specifications include: and updated specifications to keep pace with significantly shortens the time to market of new and monitoring a highly distributed collection MicroProfile Config developer needs. application features by changing, testing and of microservices is complex. This is among deploying each service, individually, without others mainly because of a lack of a centralized MicroProfile Fault Tolerance All this is possible because of the great affecting other services. A well-designed and runtime in the design of any distributed system. MicroProfile Health Check engagement and the collaborative work of the MicroProfile Metrics permanent growing MicroProfile community as excellently described by Mike Croft in his blog MicroProfile Open API post “MicroProfile Turns One“. MicroProfile Rest Client MicroProfile JWT Authentication Lets do this! MicroProfile Open Tracing API 02 03 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

W h y Microservices?

Decomposing a monolith into independent microservices on the whole or only partially while leaving the remaining The difficulties associated with developing, testing, fixing, and updating an functionality unchanged has many advantages. For applications has relegated big monolithic applications to the past. Today, example, each microservice is easy to understand, develop application architecture must support agile and continuous development by and maintain. A microservice can be deployed, scaled and decomposing systems into smaller services focused on specific business domains. run independently. Local changes can be done without These domain-specific services can then be developed and modified independently the risk of unanticipated side-effects and potential faults according to evolving business needs, without impacting the system as a whole. are isolated by definition thanks to the microservices boundaries. Such advantages help shorten the time to market by facilitating advanced agility.

Unfortunately, a single application that consists of tens or maybe hundreds of microservices can also have its drawbacks. As mentioned before managing, securing, and monitoring a highly distributed collection of microservices with no central runtime, management or monitoring instance is complex.

04 05 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

Example Use-Case: IN ADDITION WE WILL NEED… MicroProfile >> an inventory service that helps maintain the products availability or inventory; >> a shipping service for the products’ delivery; e-Commerce >> a search service for an optimized highperformance product search; and >> a recommendation service for personalized product recommendations. Let’s take a look at a simple microservices-based, web-application called “MicroProfile e-Commerce”: LET’S TAKE A DEEPER LOOK AT ONE USE-CASE: With the help of the e-Commerce solution, currently customers can search for products, add SHOPPING CART CHECK-OUT*. them to their virtual shopping cart, and check-out at any time. (*The following use case description is simplified for a better understanding)

During check-out, the application has to do several things in parallel. TO IMPLEMENT ABOVE ACTIVITIES REQUIRES AT LEAST FOUR SERVICES: 1. Check the availability of the requested product via inventory service. 2. Fulfill the payment via payment service. >> a customer service that allows customer registration and self-administration; 3. Trigger the physical shipment via shipment service. >> a catalogue service that maintains the available products; Each service, detailed above, by itself seems to be quite easy to implement, test, >> a cart service that manages the customers shopping carts; deploy and monitor. However what happens when it come to real life use-cases where services interact? >> a payment service that enables the customers to pay during check-out

06 07 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

In an orchestration based approach the ORCHESTRATION The coordination of the above mentioned steps can be orchestrating service sends commands to the different services and receives their done in two different ways: responses. This could be done synchronously a success response to the checkout service. via RESTful calls or asynchronously with the After receiving the response the checkout help of queues. service creates a second command to fulfill the workflow which is “fulfill payment for CHOREOGRAPHY pressing the “checkout” button the service After being called from the UI by pressing the customer Y and product X” and sends it to creates a domain event “checkout initiated “checkout” button the cart service creates a the payment service. And so on. Figure 3 for customer Y and product X” which will be command “reserve product X for customer illustrates the orchestration of the checkout In a choreography based approach the consumed by the inventory service. After Y” and sends it to the inventory service. The workflow. workflow of the use-case is implicitly defined checking the availability of the requested inventory service tries to reserve the product by a sequence of domain events and service product, the inventory service will reserve the after receiving the request and sends back DISTRIBUTED CHECKOUT actions. Each involved service signals a product and create a second domain event WORKFLOW VIA ORCHESTRATION successful or faulty fulfilment of its part of the “product X reserved for customer Y” by itself. workflow via a corresponding domain event. This domain event again is the signal for the Other services may listen to this domain payment service to fulfill the payment and event and start working on there part of the create a third domain event “payment fulfilled workflow after receiving it. for customer Y and product X” which triggers the physical shipment of the product to the Let’s assume that the cart service offers customer (via shipment service). Figure 2 a convenient API to trigger the checkout illustrates the choreography of the checkout workflow from the UI. After being called by workflow.

DISTRIBUTED CHECKOUT WORKFLOW VIA CHOREOGRAPHY

Whether Choreography or Orchestration is used, there are still a lot of additional things to take care of in a microservices-based application. It is essential to make sure that each service by itself as well as the the system as a whole is up and running as expected from technical and functional point of view.

08 09 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

RESILIENCE & FAULT TOLERANCE As the number of services grows, the odds of any one service failing also grows. If one of the involved services does not respond as expected, e.g. because of fragile network communication, we have to compensate for this exceptional situation. Therefore, we have to build up our microservices C r o s s - C u t t i n g architecture to be resilient and fault tolerant by design. This means we must not only be able to detect but also to handle any issue automatically.

Concerns CONFIGURATION The fact that there is no central runtime also implies that there is no single point of configuration. Let’s assume that two of the involved microservices, Every system included in MicroProfile e-Commerce has a number of cross-cutting e.g. catalogue service and search service, share a company cloud account. In concerns that need to be addressed such as logging, monitoring of service health and that case, they may want to share a common configuration. Alternatively, it metrics, fault tolerance, configuration, and security. In a microservices architecture, where may be helpful that a microservice can access configurations from multiple there is no central point of control, these cross-cutting concerns are challenging. sources in a homogeneous and transparent way.

AUTHENTICATION & AUTHORIZATION LOGGING During checkout, the customers of our MicroProfile e-Commerce solution do not want to log in repeatedly to every participating microservice. Since MicroProfile e-Commerce is spread across multiple microservices, Instead, a mechanism to handle distributed authentication and authorization developers need a solution for distributed logging and tracing. Each is required. Due to the stateless character of microservices the solution service must be able to log and trace its specific part of the processing must offer security context propagation in a web-friendly way. In addition so that logging and tracing information across the system can be merged the security solution must be verifiable to make sure that the original automatically and can be analyzed as a whole. service call is not forged in any way.

HEALTH CHECKS & METRICS STANDARDIZED INTERFACE DOCUMENTATION From the microservices developer‘s point of view, it is important to Due to the fact that we do not have a single service and therefore no single understand how to interact with any of the other microservices and how point of control, we also have to change the way we monitor our application to test that the services APIs are still valid and backward compatible. state. For each microservice we need to know if it is healthy (health check) Therefore standardized API documentation that can be also used for API and performing as expected (metrics). testing is needed.

010 011 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

What we are looking for is a consistent and interoperable way to handle these challenges without the risk of vendor lock-in. This is the mission of MicroProfile. MicroProfile to MicroProfile creates specifications that focus on portability and interoperability while remaining vendor agnostic: Write once, run everywhere!

MicroProfile utilizes a very small subset of Java EE APIs to define its core t h e r e s c u e programming model:

After pointing out the cross-cutting concerns in a CDI 2.0 for Dependency Injection JSON-B 1.0 for JSON Binding microservices application, the big question is how do JAX-RS 2.1 for REST APIs To name a few... we deal with these concerns? JSON P 1.1 for JSON Parsing

One option is to find a separate solution solutions for the same problem, making within a baseline platform, developers will for each cross-cutting concern (e.g. it more difficult for developers to switch MicroProfile’s mission is to close the continue to benefit from rapid innovation, logging, tracing, health checks, metrics, projects. gap between the Enterprise Java and application portability, and interoperability, authentication, documentation). The the real-life challenges of microservices with multiple vendors to choose from. problem with this approach is that we Another approach is to find an “all- architectures. might end up in a bunch of incompatible around package” that addresses many Vendors, the community, and open source solutions that may not have been tested cross-cutting concerns. Yet an all-in-one The community has been using Enterprise projects bring their solutions to the real together and are evolving without solution could result in vendor lock-in Java technologies like Java EE, today world while at the same time collecting consideration to other services, making constraining organizations to the release re-branded as Jakarta EE, within end user feedback. In common areas, overall testing and version management schedule and capabilities of a single microservices architectures in innovative where there is enough stability and more difficult. In large organizations, vendor. ways for quite a while (see Jakarta EE functionality individual solutions can result different teams may choose different Community Survey for details)! While the in standardization. community members have been innovating independently, MicroProfile now allows Open Source collaboration and innovation wherever there is a commonality. By leveraging these commonalities, such as the Up Up & Away afore-mentioned cross-cutting concerns,

012 013 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

What is under APIS OF MICROPROFILE 3.0 APIS the MicroProfile hood?

The MicroProfile project specifies several solution blocks - a.k.a. APIs - each of them addressing a specific topic. power

014 015 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

The following example shows how to use Config via injection to configure the shopping MICROPROFILE cart service of our MicroProfile e-Commerce application: CONFIGURATION // inject a boolean property @Inject @ConfigProperty(„ONE _ CLICK _ CHECKOUT _ ALLOWED _ KEY“) MicroProfile Config externalizes installation. Regardless of it deployment, Boolean oneClickCheckoutAllowed; 1.3application configuration by providing microservices ought to be possible microservices with the means to obtain without the need to repackage the // inject property with default value configuration properties through whole application binary. @Inject @ConfigProperty(„MAX _ ITEM _ COUNT _ KEY“, defaultValue=”100”) several environment-aware sources. Integer maxItemCount; These sources can be accessed in MicroProfile Config provides type-safe

parallel both internal and external to the injection of configuration properties, no // inject a custom class property application and made available through matter which configuration source they @Inject @ConfigProperty(„MINIMUM _ AMOUNT _ KEY”) dependency injection or lookup in a originate from. Developers can decide Amount minimumAmount; unified way. MicroProfile Config also if the configuration properties should allows developers to implement and be read at service or application start register their own configuration sources or just-in-time with a given refresh rate. in a portable way, e.g. for reading Default and custom converters take the configuration values from a shared responsibility for the type conversion database in an application cluster. needed to guarantee type-safeness.

Microservices often contain functionality that behaves slightly differently depending on the deployment. This might be different REST endpoints (e.g. depending on the customer for whom a WAR is deployed). Or it might even be entire features that need to be MP CONFIG MERGES switched on and off depending on the MULTIPLE CONFIGURATION SOURCES

016 017 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

The following example shows a simple timeout and fallback scenario. If the originally MICROPROFILE called method getAllProducts could not handle the request within a given period of FAULT TOLERANCE time the fallback method, getAllProductsCallback, is called automatically.

Listing: Example of MicroProfile Fault Tolerance usage.

@GET MicroProfile Fault Tolerance enables us to build resilient microservices @Ti m eout(500) by separating the execution logic from business logic. Key aspects of the @Fallback(fallbackMethod = “getBestsellersFallback”) Fault Tolerance API includes well known resilience patterns like TimeOut, public Response getPersonalRecommendations() throws InterruptedException { RetryPolicy, Fallback, Bulkhead, and Circuit Breaker processing. // retrieve personal recommendations by delegating the call to // Personal Recommendations Microservice In a distributed system, like a microservices-based architecture, it is ... increasingly important to build in fault tolerance by default. Fault tolerance } is about leveraging different strategies to guide the execution and result of some logic. Retry policies, bulkheads, and circuit breakers are popular public Response getBestsellersFallback() { concepts in this area. They dictate whether and when executions should // retrieve bestsellers instead of personal recommendations as fallback take place, while fallbacks offer an alternative result when an execution // by delegating the call to Bestsellers Service does not complete successfully. ... } The main design of MP Fault Tolerance is to separate the execution logic MP FAULT TOLERANCE from execution. The execution can be configured with fault tolerance API IN ACTION policies, such as RetryPolicy, Fallback, Bulkhead and CircuitBreaker. The Fault Tolerance specification defines a standard API and approach for applications to follow in order to achieve resilience.

018 019 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

The following example demonstrates how to implement a simple readiness check to make sure that the connection pool of the customer service of our MicroProfile MICROPROFILE e-Commerce example is up and running as expected and therefore the microservice is HEALTH CHECK ready to process requests.

Examples of MicroProfile Health Check usage.

MicroProfile Health Check lets should only be directed to a service @Readiness developers define and expose a that is both live and ready. The MP @ApplicationScoped domain-specific microservices Health Check has been designed with public class ConnectionPoolCheck implements HealthCheck { health status (“UP” or “DOWN”) so Kubernetes, Cloud Foundry and Mesos unhealthy services can be restarted by in mind, so leveraging the provided @Override the underlying environment. Health orchestrator features is natural. public HealthCheckResponse call() { Check is a “machine-to-machine” API, if (isConnectionPoolHealthy()) { where orchestration services like Determining the state of a service is return HealthCheckResponse(“customer-cp”) Kubernetes can automatically detect often more complex than checking .up() and restart unhealthy services without whether an HTTP endpoint is .build(); manual intervention. available. It can be composed by a set } else { of verification procedures. Multiple return HealthCheckResponse(“customer-cp”) Health checks are used to determine domain-specific health checks can .down() both the liveness and readiness of a easily be added to a microservice .build(); service. Even though a service may by implementing the corresponding } be “live” and running it may not yet HealthCheck interface. MP Health } be ready to accept traffic, such as Check discovers and compose these when a database connection is being procedures to compute the overall // check that there is no connection shortage established. This has a direct impact outcome. private boolean isConnectionPoolHealthy() { … } on the traffic routing, because traffic

}

As shown above a health check for readiness allows a third party service to know if a microservice is ready to process requests or not. In contrast a health check for liveness - indicated via @Liveness annotation - allows a third party service to determine if a microservice is running. This means that if this procedure fails the microservice can be discarded (terminated, shutdown) without any negative side-effects.

020 021 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

MICROPROFILE METRICS METRICS SUPPORTS DIFFERENT DATA TYPES:

COUNTER: HISTOGRAM: a monotonically increasing numeric value a metric which calculates the distribution (e.g. total number of requests received or of a value (e.g. items per checkout in an MicroProfile Metrics delivers details about the microservices the total number of concurrently active e-commerce application). runtime behavior by providing a unified way for MicroProfile servers HTTP sessions). to export monitoring data to management agents. Metrics also TIMER: provides a common Java API for exposing their telemetry data. METER: a metric which aggregates timing durations a metric which tracks mean throughput and provides duration statistics, plus In order to run a service reliably developers need monitoring. There and one-, five-, and fifteen-minute throughput statistics (e.g. response time or is already JMX as a standard to expose metrics, but remote-JMX is exponentially-weighted moving average calculation time of complex logic). not easy to deal with and does not fit well in a polyglot environment throughput (e.g. number of calls a function where other services are not running in a JVM environment. processes). GAUGE: a metric that is sampled to obtain its value To enable monitoring in such a polyglot environment it is necessary (e.g. CPU temperature or disk usage). that all MicroProfile implementations follow a certain standard with respect to the (base) API path, data types involved, always available metrics, and return codes used. The following example demonstrates how to measure the Listing: Examples of MicroProfile Metrics duration of the check-out process of our example application usage via annotations. Metrics serves to pinpoint issues, providing long-term trend data for MicroProfile e-Commerce: capacity planning, and pro-active discovery of issues (e.g. disk usage To be able to differentiate common metrics growing without bounds) via a simple to use RESTful API. Metrics can @POST from vendor or application specific metrics, also help scheduling-systems decide when to scale the application to @Produces(MediaType.APPLICATION _ JSON) MP Metrics also supports three different run on more or fewer machines. @Timed(absolute = true, sub-resources (aka scopes): name = „microprofile.ecommerce.checkout“, displayName = „check-out time“, base: metrics that all MicroProfile vendors description = „time of check-out process in ns“, have to provide unit = MetricUnits.NANOSECONDS) vendor: vendor specific metrics (optional) public Response checkOut(...) { application: application-specific metrics // do some check-out specific business logic (optional) ... return Response.ok()… build(); } 022 023 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

THE APPLICATION DEVELOPERS MICROPROFILE HAVE A FEW CHOICES:

OPEN API »» Augment existing JAX-RS annotations be written before any code, which is an with the OpenAPI Annotations. Using approach often adopted by enterprises 1.1 annotations means developers don’t have that want to lock-in the contract of the Exposing APIs has become an essential additional documentation, or inspection to re-write the portions of the OpenAPI API. In this case, we refer to the OpenAPI part of all modern applications. At the of network traffic. The description can document that are already covered by the document as the „source of truth“, by center of this revolution known as the be understood as a clear and complete JAX-RS framework (e.g. the HTTP method which the client and provider must abide. API Economy, we find RESTful APIs, contract. of an operation). which transforms any application into »» Use the Programming model to provide language-agnostic services that can be The MicroProfile Open API »» Take the initial output from OpenAPI a bootstrap (or complete) OpenAPI model called from anywhere: on-premises, specification provides a set of Java as a starting point to document APIs tree. Additionally, a Filter is described private cloud, public cloud, etc. interfaces and programming models that via Static OpenAPI files. It’s worth which can update the OpenAPI model allow developers to natively produce mentioning that these static files can also after it has been built from. For the clients and providers of these OpenAPI v3 documents. services to connect, there needs to be a clear and complete contract. Similar to the WSDL contract for legacy Web Services, the OpenAPI Specification (OAS) is the contract for RESTful Services.

OAS defines a standard, programming language-agnostic interface description for REST APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code,

MP OPENAPI DOCUMENTATION MECHANISMS

024 025 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

For example, to invoke the checkout process from another service, the service only needs to define a Java interface with appropriate annotations. Then a container or a builder will create a proxy capable of mapping between method invocations and REST MICROPROFILE requests. Knowing the JAX-RS API, this is very straightforward:

REST CLIENT @RegisterRestClient @Pat h(„/shop ping“) public interface ShoppingServiceClient { 1.3MicroProfile Rest Client simplifies Rest Client allows developers use plain building REST Clients by providing a Java interfaces to invoke a RESTful @POST type-safe approach for invoking RESTful service. It specifies the mapping @Path(„/checkout“) services over HTTP. The MicroProfile between a method on an interface @Produces(MediaType.APPLICATION _ JSON) Rest Client builds upon the JAX-RS 2.1 and a REST request using existing public Response checkOut(...); APIs for consistency and ease-of-use. JAX-RS annotations. In many cases, an } annotated client interface looks very Using MicroProfile Rest Client to write much like the corresponding REST Interfaces annotated with @RegisterRestClient can be simply injected into client applications allows for a more resource. It’s easy to reuse the same any CDI bean with the @RestClient qualifier annotation, for example: natural and model-centric coding style, REST client to avoid code duplication. while the underlying implementation A REST Client interface is also a very @Inject @RestClient handles the communication between natural way to specify and document ShoppingServiceClient shopping; client and service by automatically the contract between the client and the making the HTTP connection and RESTful service. Using Rest Client thus serializing the model object to JSON (or reduces a lot of boilerplate constructs Location of the RESTful service depends on the environment. It needs to be provided XML etc.), so that the remote service can and leads to a cleaner code. as a MP Config configuration property. The name of the property is derived from the process it. full class name of the interface and the property specifies the location for all injected proxies.

If needed, a proxy for the interface can be created programmatically with a builder. This also allows specifying the location for each proxy separately:

ShoppingServiceClient shopping = RestClientBuilder.newBuilder() .baseUri(new URI(„h t t p://l o c a l h o s t:8 0 8 0/“)) .build(ShoppingServiceClient.class);

026 027 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

MICROPROFILE FOR RESTFUL BASED MICROSERVICES, SECURITY J W T TOKENS OFFER A VERY LIGHTWEIGHT AND INTEROPERABLE WAY TO PROPAGATE IDENTITIES ACROSS DIFFERENT SERVICE WHERE A TOKEN 1.1MicroProfile JWT Authentication One of the main strategies to propagate FORMAT IS WELL KNOWN OR SERVICES CAN INVOKE defines a format of JSON Web the security state from clients to Token (JWT) used as the basis for services, or even from services to A SEPARATE SERVICES SO THAT: interoperable authentication and services, involves the use of security authorization by providing role-based tokens. In fact, the main security »» Services don’t need to store any state »» Services can enforce authorization access control (RBAC) microservice protocols in use today are based about clients or users. policies based on any information within a endpoints using OpenID Connect on security tokens such as OAuth2, security token. (OIDC). OpenID Connect, SAML, WS-Trust, »» Services can verify the token validity. WSFederation and others. While some »» Services need support both delegation The security requirements that involve of these standards are oriented to »» Services can identify the caller by and impersonation of identities. microservice architectures are strongly identity federation, they all share a introspecting the token. related with RESTful Security. In a common concept regarding security RESTful architecture style, services are tokens and token-based authentication. usually stateless and any security state associated with a client is sent to the target service on every request. This Today, the most common solutions involving RESTful and microservices security allows services to re-create a security are based on OAuth2, OpenID Connect (OIDC) and JSON Web Tokens (JWT) context for the caller and perform both standards. authentication and authorization checks.

MP JWT heavily relies on the above standards, therefore it offers an API making it very easy to access, verify and propagate JSON Web Tokens in a Java Security compatible way.

028 029 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

MICROPROFILE OPENTRACING

1.3MicroProfile OpenTracing enables services to easily participate in a The OpenTracing project’s purpose is to provide a standard API distributed tracing environment by defining an API. for instrumenting microservices for distributed tracing. If every microservice is instrumented for distributed tracing using the Distributed tracing is particularly important in a microservices OpenTracing API, then (as long as an implementing library exists for environment where a request typically flows through multiple services. the microservice’s language), the microservice can be configured at To accomplish distributed tracing, each service must be instrumented to deploy time to use a common system implementation to perform the log messages with a correlation id that may have been propagated from log record formatting and cross-service correlation id propagation. The an upstream service. A common companion to distributed trace logging common implementation ensures that correlation ids are propagated is a service where the distributed trace records can be stored (see in a way that is understandable to all services, and log records are also examples on opentracing.io). The storage service for distributed formatted in a way that is understandable to the server for distributed trace records can provide cross service trace records associated with trace record storage. particular request flows. In order to make MicroProfile distributed tracing friendly, it allows distributed tracing to be enabled on any MicroProfile application, without having to explicitly add distributed tracing code to the application.

030 031 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

The first common use case is digital services and applications for mobile and web applications that offer customers superb digital user experience, customer engagement, social and IoT integration, and other aspects of digital transformation. Such solutions typically require APIs on the backend, REST APIs or event streaming. MicroProfile microservices are the perfect Lessons learned choice for implementing back-end for such applications. They are fast, lightweight and easy to scale as they work perfectly with containers and can be deployed on Kubernetes-like environments, either on premise or hosted from real-world in the cloud. With microservices, it is easier to achieve scalability, high availability and resilience.

The major advantage for companies that have traditionally based their microservice developments on Java and Java EE (now Jakarta EE), is that the transition from classic application servers to MicroProfile is straightforward. Developers skilled in Java/Java EE can start using MicroProfile in relatively adoption short time, without having to learn new technologies, languages or APIs. Matjaz B. Juric By This brings us to the second common use case, the gradual migration from monolithic applications to microservices. Typical Java EE applications are large and complex. They have been developed over longer periods of time and often they are mission critical. Therefore companies cannot afford to The companies that are using Java services and applications for digital rewrite them for microservices. Migrating to MicroProfile allows to gradual microservices for their production channels, and gradual migration of transformation from a monolithic, application server based application and even mission critical systems existing applications from application to microservices. A common practice is to develop major changes or new come from different industries, servers to microservices. With each functionalities that need to be added to such applications as microservices including energy, banking, insurance, and every company that has adopted (for example, common new functionalities for banking applications in manufacturing, transport and logistics, microservices, we, at Kumuluz, EU are PSD2 (Payment Service Directive 2) APIs), leaving the rest as- public administration, and others. have observed one common thing – is on the application server. MicroProfile can work hand-in-hand with developers simply love microservices. application servers. Another practice is to migrate certain functionalities Companies are mainly using In this section, we will share those to microservices. Because MicroProfile microservices use the core subset microservices for two kinds of findings. of Java EE technologies,, it is relatively easy to migrate existing code to projects, development of new digital microservices.

032 033 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

The experience of companies that have adopted microservices also shows that microservices require automation of infrastructure and DevOps. It is almost impossible to gain benefits of microservices if companies do not have DevOps in place and if their Continuous Delivery cycle is not fully automated.

Microservices also allow companies to easily upgrade the version of Java. With new versions of Java scheduled every six months, developers can choose a new version ADVANTAGES OF MICROSERVICE ARCHITECTURE of Java only for selected microservices and not migrate everything at once, which is a common practice with application servers. Finally, adding other languages, such as Node.js or Go, for selected functionalities is straightforward with microservices. Business related advantages Technology related advantages

Increased business agility and flexibility Fast, lightweight THE BENEFITS OF MICROSERVICES ARE

NOT LIMITED TO TECHNOLOGY RELATED Order of magnitude shorter time-to-market Scalable ADVANTAGES ONLY. THEY ALSO BRING Better fulfilment of business requirements Highly available, fault tolerant, resilient IMPORTANT ORGANIZATION BENEFITS.

Faster digital transformation Docker and Kubernetes ready Companies using MicroProfile today have considerably improved their agility of the development and shortened time to market. This is achieved with the appropriate Parallel development and automation Deployable on premise or cloud hosted organization of their teams, organized around microservices allowing parallelization of development – and deployment. In other words, teams work in parallel and develop, deploy and test microservices independent of each other. Improved Business-IT alignment and lower Easy migration from Java/Java EE to technical debt microservices

MICROSERVICE APPROACH BRINGS Preserved existing investment in Should be combined with DevOps, CONSIDERABLE TIMESAVING AND IMPROVES technology and know-how Continuous Delivery and automated testing AGILITY AND TIME-TO-MARKET BY ORDER OF MAGNITUDE. THIS IS SOMETHING BUSINESS PEOPLE LOVE TO SEE. In conclusion, the experiences of companies that are using MicroProfile in the production for their mission critical systems, are mostly positive. The most important lesson is that companies have to address all aspects of the microservice architecture. As more developers are encouraged by their employers to do so, companies will definitely see the advantages in both technology and business.

034 035 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

P a r t n e r CURRENTLY AVAILABLE N e t w o r k IMPLEMENTATIONS Unlike the Java EE standard, MicroProfile does not have a reference By Markus Eisele implementation but only TCKs (test compatibility kits) to pass. Each runtime Enterprise Java technologies like Java MicroProfile is possible because of provider is self-motivated to implement new APIs as soon as possible and pass the EE have evolved with the industry the broad support from all its active corresponding TCK. At the moment of writing this paper, eight vendors provide full for nearly two decades to support members and the extensive partner or partial implementations of MicroProfile. distributed application architectures network. The partner network gives this based on RMI/IIOP, Web Services, and project a competitive advantage and the REST. MicroProfile is the next step in that opportunity to access a broader range of evolution. resources and existing expertise. Payara Tomitribe IBM Payara Server Apache TomEE Open Liberty In January 2017, MicroProfile became WebSphere Liberty a member of the Eclipse Incubation Payara Micro Projects group.

Fujitsu Hammock Red Hat INDIVIDUALS, ORGANIZATIONS, VENDORS Launcher Hammock JBoss EAP

The original MicroProfile efforts was kicked off and announced in late June 2016 by Thorntail Red Hat, IBM, Tomitribe, Payara and the London Java Community. A lot has happened WildFly since then. MicroProfile v 1.0 was released on September 19, 2016. Its implementation Red Hat Application Runtimes interoperability was demonstrated on November 2016 at Devoxx Antwerp, where Red SmallRye Kumuluz Hat, IBM, Tomitribe, and Payara demonstrated a unified web application with underlying SmallRye KumuluzEE microservices which had been developed separately by each vendor using MicroProfile. In addition, MicroProfile became part of the Eclipse Foundation as an incubation project back in December 14, 2016. New members have joined MicroProfile, such as SOUJava, Hazelcast, Fujitsu, Lightbend, Microsoft, Oracle, Hammock, and KumuluzEE.

036 037 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

Innovation & SANDBOX PROJECT “LONG RUNNING ACTIONS” Sandboxing The proposal for Long Running Actions introduces APIs for services to coordinate activities. The main thrust of the proposal introduces an API for loosely coupled services to coordinate long running activities in such a way as to guarantee a globally consistent outcome without the need to take locks on data.

MicroProfile has many serviceable features, After having reached an adequate degree of enabling it to address most of the challenges maturity, the initiator of the sandbox project SANDBOX PROJECT “REACTIVE” of a microservices architecture. But there is can ask for a MicroProfile repository and in more to come. this way start the MicroProfile feature init The Reactive working group is defining several specification to make process. Of course experienced MicroProfile MicroProfile applications more event-driven, asynchronous and efficient. As mentioned before the MicroProfile project committers will assist if desired. approach allows interested parties and The Reactive Streams Operators specification propose a set of operators partners to continue to innovate quickly and The MicroProfile process by definition for Reactive Streams. By mapping Java Streams API but for Reactive efficiency while collaborating where there facilitates the engagement of the community Streams, it provide a natural API to deal with stream of data, enforcing error is a commonality. Therefore MicroProfile while at the same time preventing any kind propagation, completion signals, and back-pressure. supports its community by offering a of vendor lock-in. sandbox for incubating ideas and code The Reactive Messaging proposal explores the question „what if Java examples that eventually turn into new Just to give an example, at the time of offered a new API for handling streams of messages - either point to point or specifications in the near future. The writing, there are four sandbox projects from a message broker - based on the JDK 9 Flow API or alternatively on the sandbox is meant to experiment and share available and up for discussion for the JDK8 compatible Reactive Streams API - that was lighter weight and easier to code and documents and allow discussions MicroProfile community. use than JMS/MDBs“. with the rest of the MicroProfile community.

038 039 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

SANDBOX PROJECT “GRAPHQL”

The proposal for GraphQL is an API specification making GraphQL available for microservice development.

GraphQL is an open-source data query and manipulation SERVICE MESH language for APIs, and a runtime for fulfilling queries with existing data. It provides an alternative, though not necessarily Beneath the above described sandbox project there a replacement for REST. is an ongoing discussion if and how MicroProfile could support Service Mesh solutions like Istio GraphQL is already widely used in Microservices architectures or Linkered. as an alternative API endpoint to REST. There are several Java- based GraphQL libraries available, but none with the reach of Cloud Native microservices developed with the MicroProfile community. MicroProfile can take advantage of a Service Mesh by extracting many concerns away from the development of the microservice itself and delegate it to the Service Mesh which is a dedicated SANDBOX PROJECT “CONCURRENCY” infrastructure layer for making service-to-service communication safe, fast and reliable. The proposal Concurrency introduces APIs - fully compatible with the EE Concurrency specification - for obtaining CompletableFutures that are backed by managed threads, with the ability to capture context from the thread that creates the CompletableFuture and apply it when running the CompletionStage action.

040 041 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

BEST TIME TO START Summary IS NOW!

MicroProfile enables developers to substantially increase the productivity and the quality of Microservices can significantly shorten Check out the MicroProfile APIs, microservices-based applications. This is why MicroProfile was chosen as the winner of one the time to market. In addition, they can listed below: off the most important community awards in 2018, the Duke’s Choice Award. help to build an application that is more

stable, scalable and fault tolerant. MicroProfile Config To ensure that getting started with MicroProfile is as easy as possible, the MicroProfile community has developed very helpful content, like tutorials, example applications, blog posts MicroProfile Fault Tolerance These benefits do not come for free. or presentations. Splitting up an application into tens or MicroProfile Health Check hundreds of microservices will results MicroProfile Metrics in a more complex operation scenario MicroProfile Open API due to the absence of a central runtime. New challenges arise for which typical MicroProfile Rest Client BLOG FAQ PROJECTS & Enterprise Computing Frameworks, like MicroProfile JWT Authentication DOCUMENTATION Newbies to MicroProfile In addition, answers Java EE, are not appropriate. MicroProfile Open Tracing API will find “getting frequently asked To gain a deeper started” tutorials for questions while MicroProfile defines a programming understanding of the nearly every aspect of starting to work with model for developing cloud-native different MicroProfile the MicroProfile usage the MicroProfile APIs microservices-based applications and projects and how to inside the MicroProfile can be found at the enables Java EE developers to leverage use them correctly and Blog. MicroProfile FAQs. their existing skill set while shifting their effectively, developers focus from traditional 3-tier applications can reference the to microservices. MicroProfile Projects & Documentation IF YOU ASK YOURSELF, WHEN IS THE BEST TIME TO START DEVELOPING YOUR MICROSERVICES-BASED APPLICATIONS USING MICROPROILE” THE ANSWER IS NOW. BECOME PART OF AN OUTSTANDING COMMUNITY & GIVE MICROPROFILE A TRY.

042 043 Eclipse MicroProfile Whitepaper 2019 2019 Eclipse MicroProfile Whitepaper

Wonderful MicroProfile White Paper Contributors

GENERAL REVIEW:

Emily Jiang, Heiko Rupp, Jean-Louis Monteiro, Cesar Saavedra, Kevin Sutter, Mark Struberg, Ken Finnigan, Clement Escoffier, David Blevins, John Clingan, Antoine Sabot-Durand, Scott M. Stark, Ondro Mihalyi.

CONTRIBUTED SECTIONS:

>> Lessons learned from the Real World Microservice Adoption by Matjaz B. Juric

>> Partner Network by Markus Eisele

STEWARDS:

Richard Monson-Haefel (Continuity of Content), Peggy Blevins (Copy/Edit), Ryan St. James (Design) & Amelia Eiras (360 Steward) ABOUT LARS RÖWEKAMP

OSS PROCESS: Lars Röwekamp is the founder and CIO New Technologies of open knowledge GmbH. https://github.com/eclipse/microprofile-marketing/issues/3 He has been advising customers on international projects for more than twenty years around the theme of enterprise and mobile computing. In his daily job Lars Röwekamp is responsible for the evaluation and rating of new technologies in context of marketability, sustainability and future viability. You can find him on Twitter at @mobileLarson.