Markus Eisele Answers Questions About Java EE and Microservices

I took the chance to catch up with Markus Eisele, Developer Advocate JBoss Middleware, this week about microservices and containers in the context of Java EE. There's been a lot of discussion around whether Java EE is really up to the task, or if the Spring ecosystem hasn't already outpaced EE. In this interview, Markus gives us the Java EE side of the discussion.

You've been talking about microservices in an Enterprise and Java EE context a lot lately. Why?

Before joining Red Hat, I worked as a consultant for various big enterprises and helped them built individual solutions based on Java technology both on the client but mostly server side. This has been a tremendously challenging, but also rewarding time of my life. Working in such environments quickly turns all the easy shopping applications into toy apps. You start to talk about integrating host systems, accessing age old databases and processing large amounts of data. And thanks to platform strategies and optimizations in operations most of the solutions we could propose weren't allowed to use the right tools for the job. It mostly burned down to tweaking the best out of what we had. What I learned in those years is something I want to pass on. I want to help developers put recent buzz-words (e.g. Microservices, Cloud, Container, DevOps) into perspective. Especially into one that works in enterprise settings. And those are for sure different.

One example is, to reflect on what ESBs would look like if they were created today, and more broadly talking about sustainable enterprise architecture. Thought-leadership is a great thing and we need people to spend time in the very early days of upcoming new methodologies and technologies, but bridging the gap between those ideas and the broadly adopted practices in enterprises is a challenge for many developers and those who call themselves architects.

Putting an outline to modern enterprise architecture that helps to enable tomorrow's architectures and foster the adoption of currently available best practices on the solid base of the available and mature platforms Enterprises are running today is one of my biggest goals. And this is where Java EE  comes in. I was particularly looking to identify the gaps and opportunities in applying DevOps, Microservices, Containers and Cloud to those environments. Obviously it is not a big secret that Java EE wasn’t built with the distributed application approach in mind, but rather as one monolithic server runtime or cluster hosting many different applications. If you’re part of an enterprise development team investigating the use of microservices with Java EE, there are several items to consider. I aim on filling those gaps in various ways: With conference talks, blog-posts and just recently published mini-book.

Talks about microservice architectures always at least mention two other topics: DevOps and Containers. Is this a prerequisite?

Agile is a broadly adopted methodology in Enterprises today. At least when it comes to software development. Budgeting is a comparably long running process still and requires a lot of forecasts and reliable data. This is where agility and iterative approaches touch base with everyday life. The various departmental silos are really hard to break down and goals are rarely aligned across organizations. What is saving the most money in operations might not work with the software development requirements. If Enterprises think about adopting a microservice architecture one of the biggest requirements is "full-stack-responsibility" for the individual services. Which means, there is very little room for departmental games and extended, official production ready procedures. A well known way to overcome this hurdle is to put DevOps practices in place. Strictly speaking this isn't a real prerequisite but a very strong recommendation. If you can shorten life-cycles and production times with your existing processes, nobody is going to complain. This is comparable to the container topic. Instead of forcing your full-stack teams into a common stack, you free them to use the best tool for the job they are trying to solve. And containers plus a reasonable orchestration tooling and maybe additional support for DevOps procedures are the best foundation for this. Bottom line is, that infrastructures need to scale differently and the self-service model for projects is taking center stage. This will only be possible by using a Platform as a Service (PaaS) offering which supports containers. Unless you want to build your own solution.

What else does it need to do microservice architectures?

I talked about something that is called "outer architecture" in my article for the latest DZone Enterprise Integration guide. With Microservices the need to manage even more polyglot and distributed services becomes overwhelming. The complexity to orchestrate services moved from the inner software architecture of applications towards the outer architecture of the complete system or even infrastructure. The outer architecture refers to the platform capabilities you need to help all those simple little microservices work together. And it isn’t enough just bringing the technology aspects together. The outer architecture also has to support development teams and the Software Development Lifecycle (SDLC) to deliver on the promises of flexible and scalable development and deployment. This is a particular area where Java EE as a platform has very little to offer and needs to be complimented with various projects. You get a good overview about those in my mini-book.

Java EE is known to be the platform for monolithic applications. How can it be a fit for Microservices?

To keep it brief, there are better alternatives. Java EE was created with a complete different set of requirements at hand. It doesn't mean that you can't use it, but it requires a lot more effort and caution to create successful microservices projects with this platform. There are alternatives out there and some promising first ideas. For example, WildFly Swarm which basically allows you to package a Java EE application as a so called fat-jar - an executable application. The balancing act between existing applications and ‘know how’ in enterprises and the adoption of a complete different platform will be a challenge for many enterprises. While the new (technological) kids on the block might be a better fit, the switch towards them will require a lot more efforts and money. I think that Java EE-based microservices will complement existing applications in the long run.

Do you think, microservices will become an important part of the platform in the future?

I hope that we don't see a microservice platform at all. This would suggest that there is a technical solution to the complete problem space, which I obviously deny at this point. More likely, I would love vendors and enterprises to fully address the pyramid of modern enterprise development (image included below). And this includes a change of methodologies, sustainable software architecture according to best practices and an infrastructure that can distribute and orchestrate container.

What do you think is the optimal size of a microservice?

This is a nice question. And as far as I know, it hasn't been answered in one correct way. The reason is, that there isn't one. As we typically read about those things: "It depends". Actually microservices aren't about size. As SOA has never been about size either. If you are looking for a hard metric like lines-of-code or kilobytes, every article out there will disappoint you. You might be able to answer the question about optimal size by looking at what your application does. There are various approaches which can help you to identify the right services. If you're working on migrating an application you can start to look for verbs and subjects in your domain model. As long as you design along the single responsibility principle you can for sure identify some solid candidates. Building applications from scratch will sooner or later lead you to Domain Driven Design (DDD) practices.

Spring boot is everywhere. How do microservices with Spring boot and Java EE compare?

Strictly speaking you just can't compare this. Spring Boot makes it easy to create stand-alone, Spring-based Applications that you can "just run". It takes an opinionated view of the Spring platform and third-party libraries get you started with minimum fuss. Most Spring Boot applications need very little Spring configuration. Java EE doesn't have this kind of approach. The smallest footprint can be achieved with the web-profile. A more reasonable comparison might be to compare Spring boot against something like WildFly Swarm. Swarm allows you to package only the needed Java EE technologies beside your application. At the end of the day both ecosystems share a lot of ideas and even Spring leverages a lot of Java EE APIs. If you look at microservices exclusively, there is no real advantage in using one or the other. But you have to take this one step further into the cloud and really think about how to run not only the individual service but the complete application. But this is for sure beyond the comparison of two individual technologies.