Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Microservices, DevOps and PaaS - The Impact on Modern Java EE Architecture

Microservices, DevOps and PaaS - The Impact on Modern Java EE Architecture


InfoQ recently sat down with Markus Eisele, developer advocate at Red Hat, at the Devoxx BE conference, and asked about his thoughts on implementing microservice architectures within large-scale enterprise organisations. Eisele has recently released a mini-book via O'Reilly, “Modern Java EE Design Patterns: Building Scalable Architecture for Sustainable Enterprise Development", which explores the relationships between microservices, architecture, tooling, vendors and people in more depth.

InfoQ: Hello Markus, and thanks for taking time out today to talk to InfoQ. Could you introduce yourself and also talk a little about your recent O'Reilly mini-book publication?

Eisele: My name is Markus Eisele and I work for Red Hat as a Developer Advocate. I've been involved with Java EE servers since more than 15 years and even been part of the Java EE 7 expert group. Beyond that, I always tried to be active for the broader Java community and became a Java Champion last year.

Before joining Red Hat, I worked as a consultant for various big enterprises and helped them built individual solutions based on Java technology. This has been a tremendously challenging, but also rewarding time of my life. Gathering all this experience together and helping developers to put recent buzz-words (e.g. Microservices, Cloud, Container, DevOps) into perspective while still working in enterprise settings has been the topic of my sessions and talks for quite some time.

I have recently been looking into 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.

That is where the idea to the mini-book came from. Putting an outline to modern enterprise architecture that helps to enable tomorrow's architectures and foster the adoption of currently available best practices. And because Java EE is still the most used platform in enterprises today, 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. This is where the mini-book will give you a head start.   

InfoQ: How much time do you think it will take before traditional 'enterprise' companies embrace microservices (or will they not)?  

Eisele: In general I believe that microservices aren't the one-stop solution for all modern software projects. They solve a particular problem-space within highly distributed and fault tolerant systems. My guess is, that only about 20% of applications might have the ultimate need for a 100% microservice based architecture. The rest 80% are better off using the established platforms and runtimes. However, the lines are blurry today and will be tomorrow because the basic software design principles that apply to maintainable monolithic applications also apply to microservices.

The difference lies in the outer architecture and the communication patterns. Assuming that our industry learned something from the early service-oriented-architecture (SOA) hype, I expect enterprises to fully embrace the best and suitable parts of microservices in about five years. Until then, many enterprise requirements need to still be solved - chief among them are transactions and interaction with host systems. Developers may say that this is not needed when designing a microservice architecture, but in reality is most likely required by enterprises.  

InfoQ: What do you believe will happen to the traditional enterprise vendors and products during any transition to microservices?  

Eisele: As a matter of fact, the short-term hype-cycle driven product management leads to the first "microservice-washed" products. Either ESBs get particular features or existing functionality is rebranded. Both not very promising, but ultimately misleading. The more trustworthy vendors will add relevant products or features to their existing product-line. And of course help with mastering architectures and consulting, which I believe will always be a big part of this transition.

I hope that we don't see a microservice platform. 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.

Figure 1. Pyramid of Modern Enterprise Development

InfoQ: Do you believe Java EE technology is suitable for creating Java-based microservices, in comparison with, say, Spring Boot or Ratpack?  

Eisele: 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.

Looking at it from the 80/20 perspective again, I think that Java and Java EE-based solutions will complement existing applications using microservices technology.  

InfoQ: Why do you think that concepts from the Domain-driven Design (DDD) movement have taken so long to gain traction?  

Eisele: Having designed and architected a couple of systems myself, I think the problem here lies in how projects in our industry tend to be managed. The initial effort of creating a particular piece of software is done by one team, the maintenance and further development by another. Of course, I'm not even taking operations into account.

Thinking a business domain through and applying the DDD concepts obviously still isn't a broadly practiced skill, because when project teams disband, the knowledge and patterns they have accumulated also disband. And they were successful. Exactly as much as they needed. Almost no enterprise wants to pay for a brilliantly designed piece of software, but a reasonable priced and usable one. You get away with design mistakes easier under these circumstances.

In addition, not every company is a startup and can afford or is aiming at always keeping their teams up-to-date with latest improvements and trends. This is how our industry rolls. If the individual isn't taking care for his own further education, nobody does it. With the advent of DevOps and full-stack developers who take responsibility for their systems back to back, this changed a lot. And the effect is a positive one.

Instead of waterfall and planning we're now investing a lot more trust into individual teams. Even if the enterprise market still suffers from fixed price contracts and old ideas about project management, the overall competitive advantage for them and their complete supply chain starts to become visible.  

InfoQ: How important are the people and process parts of implementing a microservice architecture?  

Eisele: When you have to pay the price for every design mistake you make, and the team, infrastructure and methodologies don’t support quick and agile development then you end up with what made the word "enterprise" a synonym for "heavyweight, immovable". Combining the new microservices architecture with heavyweight methodologies and processes wont work. You can't deploy changes quickly enough, you can't automate your processes sufficiently and you will end up with a non-functional piece of software.

With the individual services being developed hand-in-hand, and the evolving need to quickly swap failing pieces out with working parts, the demand for DevOps practices emerges even more. And this is only a piece of the puzzle. In an enterprise context a lot of people will have to support this. It starts with contracts in technical procurement and will end with how external vendors are allowed to push their changes into production.

Infrastructures need to scale differently and the self-service model for projects takes centre stage. This will only be possible by using Platform as a Service (PaaS) offerings.

Eisele’s O’Reilly mini-book, “Modern Java EE Design Patterns: Building Scalable Architecture for Sustainable Enterprise Development” can be found on the Red Hat Developer Blog.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • The problem is Java

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The problem is not so much with JEE vs SpringBoot, but rather with Java.

    A typical Service or Microservice implemented in Java will require, on average, 6-8 classes of boiler plate code per operation:

    • 2 x request, response

    • A controller

    • A (micro)service impl. class

    • domain classes (since they are different from the request/response) classe

    I have seen this "pattern" at play everywhere I have looked, even in C#/WCF.

    The fun starts when you need to version your microservices, each version requires a new pair of (req,res), you will also start splitting the controller class, because not all operations are versioned at the same time. I have seen a case where someone wanted to change the type of a single property (from DateTime to Date) and that required 150+ lines of "new" code, that looked a lot like the old code. Let's say you do 3 versions per operation per year, you end-up with 20 new classes per operation per year, for zero value. Just plain Object Oriented Plumbing.

    Compare that to Javascript, Node.js/Express.js, in general you will end up writing 80-90% less code:

    • no need for req,res "classes", just use JSON and validation rules

    • Express is the controller, no need for classes there

    • A (micro)service impl. function

    • domain classes if you need to

    Compatible versioning is where the big win is. JSON is "extensible" unlike Java classes, you can support compatible versioning readily.

    You could get some of these benefits in Java by using a JSON like data structure for the Request/Response pipeline, but I have never seen someone doing that before. It seems that everyone prefers the comfort of rigid data structures, aka classes.

  • Re: The problem is Java

    by Mark N,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Ok. So you've state the Pros. how about the Cons? (i.e. no compile time checking, more Test code, etc).

    Also, using a good framework, like Spring, the overhead you describe is greatly reduced.

    I am doing JS (with a very popular) on the client and Java on the server. I spend most of my time on JS. While JS binding is pretty cool, I would not want to do JS on the server unless it was very minor. YMMV.

  • Re: The problem is Java

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    yes, this is exactly the tradeoff: a lifetime tax imposed by rigid data structures vs a few lines of validation code. I can only encourage people to study that question, honestly and openly, with versioning in mind. The problem is versioning, if all you'll ever need is one version of your API, then that trade off is not very important.

    Again, from experience, the problem stems from the fact that most people cannot project themselves, 2-3 years down the line and see how versioning will impact their code/cost of delivery.

    My best guess (from experience) is that Node.js will require 80-90% than SpringBoot after 12 months. It's like having 10 developers in your team instead of one.

  • Re: The problem is Java

    by Mark N,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Based on your experience with Spring and Spring Boot? :)

    FYI - this problem is not new. For us old people, we remember thinks like COBOL vs QuickJob. Using something like QuickJob and JS, for anything other than something small always was more problems than it was worth.

    Like i said, my experience with Java vs JavaScript is that most of my time is spent dealing with JS. YMMV.

  • Re: The problem is Java

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    yes, SpringBoot vs Node.js, compared side-by-side. There is a fundamental mismatch between a message pipeline and static data structures. You can use classes for domain logic, not much to say / gain there, the mistake is to use classes for handling messages that contain domain object data.

  • Re: The problem is Java

    by Paul Beckford,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree that the nominal type system in Java can hinder and get in the way as much as it can help :) Unfortunately you're fighting years of industry propaganda on this one, and many Java stalwarts are *very* closed minded on the subject.

    Where I disagree with you is on versioning. Versioning is best avoided IMHO regardless of your choice of language. The 'on the wire' representation of your data should be language independent anyway, and if you design things well, it should be open to extension (and of course closed to modifications).

    So using your JSON example, there is no reason why you can't serialise and deserialise to JSON with Java, and extend the serialised class when things change rather then creating a new version.

  • Re: The problem is Java

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    "closed minded" is an euphemism, I would rather say brainwashed. Everyone should code in Javascript for 2 weeks to see how much a difference it makes when you don't have classes in the way of everything you do. I don't think I can ever go back to Java or any object oriented language for that matter.

    Unfortunately, versioning cannot be completely avoided, but compatible versions should be preferred when possible to minimize the number of versions in production (typically 3 maximum).

    There are a number of ways for serializing/deserializing json in Java, but developers tend to prefer the most rigid mechanisms that systematically lead to breaking changes. The typical symptoms of a bad versioning strategy include a multiplication of boiler plate classes and controllers that shrink to a single API/operation. If you have a pointer that shows versioning done right in Java, I would certainly encourage you to share it.

    For an industry that grew on the value of being able to support constant change / unabated innovation, none of our languages support versioning. Quite ironic isn't it?

  • Re: The problem is Java

    by Paul Beckford,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    The problem isn't object orientation (have you tried Smalltalk, or Ruby? Or come across Self which is OO without Classes?). The problem is early (compile time) binding tied to a restrictive type system that doesn't allow the programmer to express their intent in a succinct and elegant way. It is this that leads to the boiler plate code you describe (coding around the compiler :)).

    I agree that Java wouldn't be my first choice, and whilst I haven't used Javascript on the server, I am absolutely certain that what you say here is true (based on my experience with Javascript on the client, and other dynamic languages) and yes people should try it for themselves.

    "For an industry that grew on the value of being able to support constant change / unabated innovation, none of our languages support versioning. Quite ironic isn't it?"

    Programming languages have become vendor products, and there is a lot of miss-information out there. The best ideas are not to be found in the mainstream. Our industry has grown on the value of producing constant profits, not unabated innovation alas :)

    Researcher's have looked at the how best to support change and there are many wonderful ideas out there. Google for Alan Kay's 1997 OOPSLA talk entitled the "computer revolution hasn't happened yet, and you will see that we are yet to catch up with many of the wonderful ideas of the 50's 60's and 70's. Modern languages like Clojure are merely mining that rich seam.

    I still think that versioning is best avoided (when possible). A recent language called Newspeak is working towards a novel approach where code naturally evolves over time. So all your deployed instances are automatically sychronised to the latest version, with new changes seamlessly pushed out over the network.

    The creator Gilad Bracha produced the JVM spec (amongst other significant achievements like Strongtalk), and has an interesting talk on the subject:


  • Re: The problem is Java

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree, I have been a bit unfair to "OOP", I should rather talk the way people use OOP and indeed I have coded in Objective-C for about 10 years, mostly in the 90s. I had even design a rudimentary NLP based on Objective-C's reflection API and NXDictionary. Yet, again, today I see most developers ignoring the dynamic aspect of that language.

    That being said, as Gilad mentions, the problem is how do we design properly complex composite systems? How could a language support that kind of endeavor? Java and statically typed MVC frameworks seem to be the wrong foundation. The conceptual heritage of JEE and Spring POJOs needs to be left behind.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p