After one year vacations Java EE 8 was rebooted and is going to be optimised to run on hypervisors and / or container environments. Java EE 8 will focus on the following areas below -- it is a proposal and very likely to change in the JCP process:
Extend for reactive programming
Unified event model
Event messaging API
JAX-RS, HTTP/2, Lambda, JSON-B, (...)
Package applications, runtimes into services
Standalone immutable executable binary
Key Value/Doc Store
Persistence and query interface for key value and document DB
Automatically event out
changes to observed data structures
New spec - interfaces,
packaging format, manifest
Unified API for accessing configuration
Tenant-aware routing and deployment
API to store externalized state
Extension to support client-side circuit breakers
Standardize on client-side format for reporting health
In the screencast below I created Java EE 7 projects with maven, developed and build them, created and build docker images, created a user defined network and finally launched the WARs on payara and wildfly and let them communicate:
In the first part of the JavaOne 2016 session in San Francisco I did the same. For unknown reasons docker was unbelievably slow during the presentation (I guess caused by network timeouts), so I re-recorded the first part.
Now you can fast-forward over "boring" parts in the JavaOne presentation:
Java EE is productive and easy to learn and runs smoothly on containers such as Docker and rkt. It has become the perfect microservices platform. Unfortunately, no one in the enterprise is interested in managing thousands of nanoservices “just for fun.” In this session, the presenter hacks on stage a couple of Java EE 7/8 “rightsized” services, links them together, runs them on Docker, and explains the architectural decisions and best practices in real time.
My name is Grzegorz Huber and I'm a software developer at www.consdata.com. There are other titles that change depending on my current role in different projects, but I prefer the down-to-earth description instead.
What are you currently building?
We're building a mailbox application for one of the banks here in Poland. The idea is to give clients a better tooling for their needs to contact the bank whether it's a support question or a complaint. Obviously this also means integrating with internal bank mechanisms and now clients are receiving their bank statements in a much more convenient way. It probably sounds boring because we've all been using emails for years. However, designing your own messaging application turns out to be quite a challenge especially when everyone just keeps on saying just do it like Google does ;-). The domain is simple, yes, but the scale of the system make things much more challenging. Plus it's not only for messaging. We're currently integrating our mailbox application with some of our other products that add more functionalities like internet forms and automated workflow. Most of the features have already been implemented and I'm still in awe that our whole backend is under 20k lines of code. And people say Java makes your systems big.
After the Java EE Microservices workshop at MUC Airport in January you decided to refactor your current application towards pure Java EE Microservices.
What is the progress?
Actually, It was a brand new application and we started in late February so the timing was perfect for us. The current progress is 10 microservices. I guess that's one way to describe our "advancement". Using other metrics we're currently in performance testing and getting closer to the production stage. That's for my current project. The side effect is a very small change within our organization that's about to take it's ripple effect to a whole new level.
How many microservices comprise your application / system?
Currently ten, but it was our first time and there were some disbelievers, who were skeptical at first, plus the learning curve so we definitely see there could be more closer to 15.
Which application servers, tools or IDEs are you using?
The most interesting is probably the Java EE part of the whole architecture where we decided to use Payara, Payara Micro, Embedded Payara for testing. Obviously is many ways inspired by the training in Munich. On top of that we developed our own installation platform based on Docker, which help us manage different parts of our application.
How big is your WAR?
It's between 3 and 8 MB. We're not super light, but we're very happy with the final result. Some compromises had to be made. For example we decided to use lombok, which adds almost 2MB to each war. Logback and its dependencies add another 700KB. Plus our db backends use mybatis, which adds almost 2MB as well. We like this strategy anyway... we try to keep these values in check and we consciously select what should be provided by the Jave EE container and what should be included with our application. I would like to be able to go with the javaee-api alone, but that's not possible ;-).
The whole microservice backend without tests is like 20-30 seconds. I normally don't divide build time with and without tests, but we did something here that should be mentioned. We write basic JUnit test cases in 3 layers... sort of. Layer one are basic junit tests based on mockito for simple business logic tests. Layer two includes real bean tests using CDI injection and everything that's possible within one microservice and using specialization beans that serve as mocks to other microservices. Layer three is the most expensive, but I think the pros are much more important than the disadvantage of extra added time. Our layer 3 test use the embedded Payara Micro, which takes the target wars and tests the real application stuff and including communication between microservices. We have Junit tests that use up to 6 microservice modules depending on the user story. I think that's one of the bigger challenges awaiting those who adopt this architecture so it was really handy to have Payara ready for that. The whole build, the one we use to build upon every commit for pull requests, takes up to 5 minutes at the moment.
Does "stock" Java EE fit well with the microservices idea?
Yep! It seems that it was designed this way and it's asking to be used this way. I really don't know why this approach wasn't picked up faster by developers around the world :).
You are using the porcupine as Bulkhead. Which problem does it solve?
Well, even though Glassfish (and Payara) have built-in monitoring it wasn't what we wanted it to be. Instead with a proper application design and splitting code across different microservices and different executors we were able to get our own dedicated monitoring service via REST plus other small things like named threads for each module. Additionally there's this feeling that you're in complete control over how different modules have different configurations for their own executor services. The added benefit of using Porcupine right away is that when you think about stuff like thread pools at the beginning of your application it's much easier to scale your system in the future.
I don't think we use that in the direct way. We definitely don't use technical names for organizing the core within our microservices and our approach is still based on the business responsibilities of the classes.
Any major challenges so far?
Apart from different approach to testing, which I think we tackled head on, the biggest challenge is probably some sort of microservice registry that's we're still missing in our project. Using Docker helps here a little bit, but when you get 10+ microservices and you really want to use them independently it's good to have something this figured out. One of the main reason why I came across your training was an idea to replace OSGi with something lighter. Microservices are indeed lighter, but you still have to manage them on your own. There are many solution that help with that, but I feel we need to be careful here, cause adding a registry is a good idea, but it can't become a single point of failure for us.
Any closing thoughts on Java EE and microservices?
It's nice to be able to design modules in such way that the main
application operation is designed to work 24hrs per day and other
heavy operation, which may bring instability to the system are in
separate modules on different servers with different boundaries.
That's nearly impossible with a monolith and usually it's too late. In
our case we had 9 microservices at one point and the 10th was brought
to life when we realized that our core business logic is so fast and
small that it runs smoothly on 1GB of RAM and the other module is
doing this big batch operations and needs additional 6-8GB of RAM. It
would be ill-advised to run them both together on a 8GB RAM system.
Business-wise both modules send messages. The microservice way of
thinking let's you split code not only using domains but ever further
when there are other benefits like performance and stability.
Live Coding "No-Ceremony" Microservices, CON3436, September, 20th, 14:30, 15:30, JavaOne Conference, San Francisco. Last year I got too many questions and there was no time left for coding. This year I plan to code, build and deploy as many cycles as only possible. Docker, Java EE, Networking, Configuration & Co. topics included. I will answer the questions from the audience concurrently -- without any breakpoints.
Live streaming session, Internet Mobile World, "Building Backend Services -- Fast and Straight" imworld.ro
Live streaming session, High Load Conf, October, 15th, "Lightning Java EE -- What Is Possible With Stock Servers", hdconf.by
October, 19th, JUG Poznan session: "Microservices in 2016 — What Worked Well (this time completely without slides)". This session is about lessons learned and the most frequently asked questions about Microservices and Java EE. This time I plan to spend 99,99% of the time in the IDE. The more questions -- the better.
airhacks.com workshop: MUC airport, October, 25th Building Angular 2 Apps. In this workshop I will focus on Angular 2 and will cover the typical project lifecycle - from setup over deployment. This workshop is similar to the "Building React Apps", but only covers Angular 2.
Coming this winter: 5 days Java EE Airhacks: from Bootstrap, over best practices, architectures, testing to microservices: http://workshops.adam-bien.com
A typical Java EE application comprises the following layers:
airhacks/java: the OS + Java layer. Only serves as a base, "abstract" layer. Changes on OS and Java releases and patches.
airhacks/[appserver]: this layer inherits from airhacks/java and only contains the application server installation. Only changes on new application server releases.
airhacks/[appserver]-configured: inherits from 2. and contains project-specific configuration like e.g. JMS Queues, JDBC DataSources etc. Has to be rebuilt on projects-specific configuration changes like e.g. -Xmx or -Xms changes. This layer is optional
airhacks/[project-name]: inherits from 2. or 3. Only contains a Thin War. Is rebuilt with each mvn package
Fortunately the base images are big, but have to rebuilt only a few times in year. The application / project images change several times a day, but are tiny. The creation of a full docker image with https://github.com/AdamBien/docklands takes usually: ~100ms and only adds the WAR size (usually a few MB) to the total size.
The base images exist only once at your hard drive and are shared across different application servers and applications (aka microservices).
Try it: docker run -d -p 8080:8080 --name payara-ping airhacks/payara-ping