 Thank you so much for attending this presentation. I'm going to talk about Eclipse Micro Profile in the next 20 minutes. For the next 20 minutes. My name is Cesar Zavedra. I'm a Senior Principal Product Marketing Manager here at Red Hat. So let's get started. So what is Eclipse Micro Profile? It is an open source community specification for enterprise Java microservices. It's really a community of individuals, organizations and vendors collaborating within an open source, in this case the Eclipse Foundation to bring microservices to the enterprise Java community. So this slide shows a few of the individuals, organizations and vendors that are part of the Micro Profile community. Payara, Fujitsu, Tommy Tribe, IBM, Red Hat of course. Cumulus, LJC, the London Java Group. Hammock, Sojava which is a Java group in Brazil. I believe. Smart Bear Hazel Cast and the community keeps growing. I get this question often. What is the difference between Eclipse Micro Profile and the JCP process for Java E? Well first of all the Eclipse Micro Profile is an open source project and it has a time box release schedule and it focuses on incremental feature releases and the pace is controlled by the community. On the other hand the JCP is a standards organization. It has a large multi-feature releases and the spec lead controls the pace of that specific project of every specific project within the JCP. So this is a picture that shows you the release times or the times between releases when it comes to Java EE historically from JPE when it used to be called JPE. So as you can see the time between releases have been increasing since Java EE 5 came out and one of the reasons is that they're focused on standards so they have to build consensus across the community and again the coming up with standards is a slower process than for example an open source project that moves at a faster pace. On the other hand Micro Profile is focused on accelerating adoption of microservices so as I mentioned before the release schedule calls for a shorter time between releases and the goal is to put out about four to six releases per year. Micro Profile 1.0 came out in September of last year and it was the first release and the community decided to just include three Java EE APIs in it and one of the reasons was because they wanted the community to have input and be able to capture the feedback of the community as to the direction of Micro Profile and where to take it. At least Micro Profile 1.0 came out in August of 2017 and it includes an API that is a non-Java EE API obviously it's called the config 1.0 and what this configs it wants to solve or does it attempt to solve is as you move applications and microservices through different environments for example from dev to test to production each environment will have its own configuration information so this has been a challenge historically in application development in general so configuration 1.0 API attempts to address this solution I'm sorry this problem configuration 1.0 was not addressed or tackled in isolation the community looked at different existing solutions and based on best practices and lessons learned came up with configuration 1.0 some of the projects that served as an inspiration or influence for config 1.0 are listed here like Delta Spike, Apache Tamai and others and also the community considered current implementations like Apache Geronimo config and WebSphere Liberty as input to the design of this specification as mentioned before micro profile moves at a much faster pace than the JCP however the output of the micro profile project once an API has stabilized I guess or the community considered that it could be served or it could serve to belong in standards community like the JCP it would take that API and propose it to the JCP and this happened with configuration 1.0 it has now actually it was proposed last month to the JCP as a JSR and it now is a JSR candidate if you go to the JCP website you'll see a brand new entry for config 1.0 that comes from micro profile so what was in micro profile 1.1 it included obviously the first the initial APIs that were included in 1.0 plus the config 1.0 API and there's a PDF document that describes config as well as it includes a TCK, a technology compatibility kit Java docs, there's a spec document API Maven artifacts and a git tag a clips micro profile 1.2 actually it's being announced right now as I speak over at the Eclipse Foundation booth it was finished about a week and a half ago I want to say but it's been officially announced today and in 1.2 there are one update to an API so config 1.0 has been updated to config 1.1 and it also includes 4 extra APIs health check, metrics, fault tolerance and JWT propagation health check has to do with basically an API that allows you to implement a microservice and implement a UOK type functionality into your microservice and that's called health check metrics includes functionality to measure metrics CPU, RAM and things like that and there's a variety of metrics that are being specified in the API as part of the metrics 1.0 API fault tolerance has to do with functionality related to bulkheads retries to be able to include this type of functionality in your microservices and JWT is related to security so usually we're using java web talk it for this which is an adequate standard for microservices security for authentication and authorization and this API provides functionality that supports that actually in fact I have some slides on those I got ahead of myself so again metrics adds a well known monitoring endpoint for each process in this case your specifics microservices there's three types of metrics there's the base metrics which are required so if you're implementing this API in your microservices you have to at least add functionality or implement these functions methods which are the base metrics application metrics which are not required but these would capture business type metrics and vendor specific metrics if an implementer wants to have something specific to their platform then those metrics will fall under that again just like in config we had the community looked into other projects looking for best standards and lessons learned this is a list of the projects that they were able to base to study in order to come up with a metrics 1.0 API now one point of clarification metrics are different from health checks which are primarily targeted at a quick yes no response to is my application surrounding okay health checks are used to probe the state of a computing node from another machine for example a Kubernetes service controller with a primary target being cloud infrastructure environments the goals of the health check API 1.0 API was to be compatible with well known cloud platforms in other words Kubernetes it had to be appropriate for machine to machine communication and it should give you enough information for a human administrator. Fault Tolerance is another API that was introduced in 1.2 this is the API or the functionality that includes things like retry policies, bulkhead circuit breakers and concepts that are fall within that type of fault tolerant concepts and they dictate whether and when executions should take place and fallbacks offer an alternative result when an execution does not complete successfully for example. The influence projects were histrics and failsafe that's where the community looked for best practices as well as lessons learned and the logic was to separate the responsibility of executing logic like rentables and callables from guiding when executing execution I'm sorry should take place through retries, bulkheads and circuit breakers. JAWT propagation is all about security requirements that involve microservice architectures since they are related to RESTful type security and this style of service is usually stateless and insecurity associated with a client is sent to the target service on every request in order to allow services to recreate a security context for the caller and perform both authentication and authorization checks. Again the community looks for inspiration and for best practices and lessons learned to open ID connect and JAWT and the goal was to propagate of this API was to propagate the security state from clients to services or even from services to services and for RESTful base microservices security tokens offer a very lightweight and interoperable way to propagate identities across different services so what's in Micro Profile 1.2 Again there was an update to config 1.1 which is listed here, health check 1.0 is there, metrics 1.0, fault tolerance and JAWT propagation. In this slide there are links for each of the product pages as well as links to the TCKs, technology compatibility kits, the Java docs, the spec PDF documents API maven artifacts and git tags. So speaking of the future and roadmap Micro Profile 1.3 is scheduled to come out later this year and the plan is to include functionality related to open tracing and open API. And Micro Profile 2.0 also scheduled to come out later this year will have updates to CDI JSONP, JAX IRS and it will possibly contain JSONP 1.0 which will be part of JEE 8 So there are many vendor implementations for Micro Profile, for example on this chart you see that Red Hat uses Wildfly Swarm to implement Micro Profile which is an open source project, in fact they're all open source projects on this page, IBM uses Open Liberty Tomitribe uses Apache Tomi and Piara uses Glassfish to implement Micro Profile There is this application that was put together last year, it's called the conference application and it's a combined effort from all vendor implementers of Micro Profile that is basically an application that is similar to a conference like Java 1 where you have sessions and you can build pick sessions that you want to attend search sessions and things of that type and it's made up of different microservices and in this chart for example there is a microservice Red Hat developed the session microservice using Wildfly Swarm, the other vendors developed other microservices in their own open source based platforms and then they were all integrated into a single UI and this basically showed and demonstrated the interoperability across different vendor implementations of Micro Profile and this is of great benefit to end users of Micro Profile When it comes to Red Hat and Micro Profile you could develop Micro Profile based microservices obviously using Wildfly Swarm which is what we use at Red Hat but if you look at the other offerings that we have in our portfolio like FreeScale, our Fuse Integration Solution or BPM Suite for example, Red Hat, J-Bos Data Virtualization EAP, Data Grid, BRMS or even Mobile Application Platform all these offerings could potentially use or call out or manage APIs that front Micro Profile based microservices How does Red Hat deliver Micro Profile? OpenShift Application Runtimes is a product actually whose beta we announced this week here at Java One and it's our offering that is made up of many runtimes and it's our multi-cloud, multi-tech application platform and modernization platform it's made up of many runtimes for example it has Apache Tomcat, Node.js Java EE in the form of Red Hat's J-Bos EAP Micro Profile implemented in Wildfly Swarm and Vertex which is for reactive programming this chart is a very high level picture of what Roar is. It also includes certified versions of Spring Boot, Netflix OSS Ribbon and Histrix. So I get this question often, so what's the difference between Micro Profile and Spring Boot Cloud? So Roar which is Red Hat OpenShift Application Runtimes includes both Micro Profile and Spring Boot so by using Roar you basically have all the run, if you're a Spring Boot or Cloud or Spring user in Roar you'll have support for that as well as Java EE and reactive type programming as well as Node.js runtimes so you can use Roar as to run your current workloads as well as you are safe for future type greenfield development of microservices Micro Profile is an open source project owned by the community and managed by the community whereas Spring is really managed by a single vendor namely Pivotal and we fully support Micro Profile Roar and certified Spring Boot and Cloud which I already mentioned so what are the advantages of using Micro Profile as I mentioned it's an open community based specification. There is no single vendor that manages the project, it's really the community the open source implementation of Micro Profile is Wildfly Swarm, it's a project that is moving fast and innovating fast it's constantly improving and it's introducing new capability in specification and implementation at a fast pace. If you are a Java EE developer or a company that has a lot of Java EE developers with long expertise and experience in this in Java EE then there is little to no learning curve when it comes to using Micro Profile also Micro Profile is delivered as a container based in a container based Polyglot platform, Red Hat OpenShift application runtime like I mentioned before So a couple of words about this Java EE a few weeks ago Oracle announced that Java EE is moving to the Eclipse Foundation we see this as a great move and great for the future of Java EE Eclipse Foundation has a strong experience and involvement with Java EE and related technologies the Eclipse Foundation is vendor friendly and vendor neutral and we believe that actually the last bullet here are some of the major points included in the Oracle announcement Oracle believes that they will be able to transition Java EE rapidly by using Eclipse create a community friendly processes for evolving the platform and leverage complementary projects such as Micro Profile and that's what these two relate So what assets are moving to Eclipse from Java EE that are moving to Eclipse you can read this in your spare time and again this move has benefits to Java developers enterprises and obviously Red Hat for Java developers they all have a channel for their innovation the project will be owned by the community for enterprises and Java will continue to innovate for their needs as they move from apps to containers and for Red Hat we support Java EE and EAP as well as in Roar as I mentioned and also EAP running on OpenShift container based platform using Docker and Kubernetes benefits to customers again just emphasizing that now Java EE is going to be community powered we're hoping that the release schedule will speed up a bit once Java EE move actually I should say I should not use Java EE anymore the new name is for the project under Eclipse is called EE for J and it will be an evolution for Java EE not really a revolution but it will speed up with a call to action for everybody I've included here some links in this slide for you to visit the Micro Profile IO website Wildfly Swarm website Roar there's a link to the Roar announcement also there is a Roar there is a Roar web page as well a landing page that you can go there too as well as the beta we announced this weekend is available for anybody who would like to participate in that program there's a link also for the value of the Red Hat subscription that shows you and lists all the benefits of that subscription by Red Hat gives you and finally just if you have any questions further questions please contact your Red Hat account executive also if you would like to participate in our tech program for Roar Red Hat, thank you very much