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.