The latest Virtual JUG session was about software architecture. This time we focused on microservices and how our understanding of the role that middleware takes should change to accommodate to the new distributed approach to designing complex systems.
Markus Eisele is a Java Champion, former Java EE Expert Group member, Java community leader of German DOAG, founder of JavaLand, reputed speaker at Java conferences around the world, and a very well known figure in the Enterprise Java world. These days he works for Lightbend as a developer advocate.
For quite some time now, Markus has been looking into containers and microservices architectures in depth culminating in a book he wrote about modern Java EE Design Patterns with O’Reily. He is excited to educate us more about how microservices architectures can integrate and complement existing platforms, and also talked about how to successfully build resilient applications with Java. You can find and chat with him on Twitter, where he goes by a magnificently short handle: @myfear.
This was the third time Markus has presented a session on Virtual JUG and he was one of the top presenters of 2015, a feat that earned him the prestigious vJUGgernaut title!
This session was not about what a microservice is, or even how to build one. Building an individual service is easy with any technology stack. Building a system out of many is the real challenge because it introduces us to the problem space of distributed systems. And the difference to classical, centralized infrastructures couldn’t be bigger. There are very little concepts from the old world which still fit into a modern architecture.
In this talk Markus explored the nine most important differences between classical middleware and distributed, reactive microservices architectures. He goes on to explain where the distributed approach takes you. Those places that Java EE never would.
Here’s the session on Youtube so you can click play, lean back in a comfy chair and enjoy it:
Nine Neins – Where Java EE will never take you
First of all we need to understand the current vision of what a good, sensible architecture for our application might look like. If you’re anything like Markus or us, then you’re probably dealing with web applications. And when you hear the term architecture, you’ll probably imagine something like the diagram below. There is an application server which hosts the app and all the dependencies. It’s all broken down into separate EAR, WAR or JAR files, and on the opposite end, away from the user’s direct reach you have a database, which serves the data to all the servers in the cluster.
This is pretty much what we’ve all been doing so far: building the models, packaging the system components, scaling the cluster horizontally to handle the load.
But now we see more and more companies getting to the level where scaling a monolith is not the best approach. This is especially true when you have ridiculous amounts of users and you gather tons of data.
The microservices architecture allows you to scale individual modules. It tries to divide the application into multiple separate and standalone components which can have their own technological stack, own kind of the database and own development and deployment process.
And with this different approach, the requirements to the platform you develop with are different too. If you think adopting microservices is just a matter of building smaller monolith applications, you’d be surprised (and wrong). Here are just a handful of the problems that you’ll have to provide answers to in order to be successful using microservices.
And of course your ability to quickly find answers to these problems, from enabling the service discovery to monitoring, to API management, heavily depends on the platform you use to develop your applications.
Sometimes you can use reasonable tools to deal with the problems by the virtue of using the right tool for the right job. If you’re based on a platform that doesn’t provide you with the correct tools out of the box, you might find yourself jumping through hoops and reinventing the wheel over and over again.
Then Markus went into describing what exactly had he in mind when calling the session: Nine Neins. A “Nein” (no in German) is a lost benefit of a microservice based system. Something that the platform, in this case Java EE, doesn’t offer you by default and where you’ll ultimately find yourself spending extra cycles patching the platform to get the functionality right.
Here’s a list of the 9 “neins” that were explored in the talk.
- Java EE helps build distributed monoliths. With hundreds of megabytes of libraries in the base platform, Java EE is a slowly moving entity. Upgrading individual components is hard, evolving individual libraries too. This goes against the main idea of the microservices.
- The Java EE threading model is not perfect for microservices. Concurrency is hard, and the present Java EE standard only contains some options to make the request processing asynchronous. We’re not even talking about other models, like using actors and so on.
- Java EE doesn’t support the notion of data in motion (streams). Building reactive systems, in the reactive manifesto sense of being reactive, requires you to deal with streams of data. But Java EE doesn’t yet support or incorporate streams in whatever fashion.
- Java EE doesn’t support resiliency. Resilient systems isolate the failure and can retry actions or restart components at will. The Java EE model doesn’t encourage that behavior or lifecycles.
- Java EE has poor service elasticity. Java EE is implemented as a container, which makes testing harder. It therefore makes the fast development process harder and scaling resources under various loads almost impossible.
- Java EE has no notion of immutability. Command Query Responsibility Segregation (CQRS) and event sourcing work especially well with the immutable data structures and immutable services. Both are lacking from the standard.
- Java EE is mostly focused on being transactional. A distributed system cannot only rely on the transactional data manipulation. Eventual consistency might be a better model. However, Java EE does not pay enough attention to enable it. Polyglot persistence, when you mix your data stores is a hassle.
- Java EE has no outer architecture. There are many add ons that are needed to support a fleet of microservices, from the service discovery hubs, to monitoring, gathering logs, analyzing data, and API versioning. That support has to be added in from ground zero based on the common sense and the best practices, that the standard doesn’t talk about it.
- Java EE doesn’t know services. There is no service component model or any templates, the documentation of the services is at most WSDL, and it is hard to achieve decoupling of the services.
If you’re wondering what each of these “Neins” mean, Markus did a great job explaining them in detail during the session. Watch the video and your questions will be answered.
So what does all this mean? Is Java EE completely unsuitable as a platform to host microservices? Markus definitely didn’t want to say so. You can build anything using any technological stack, but some are just better at offering you tools to support your services.
And to make the best decision about what would be the best choice for you, educate yourself in what options are available. Take a look at Akka and Play, at Lagom, at Vert.x? Spring has recently started integrating the reactive components, project Reactor, into the core of their platform.
There are many options to look at and you are better when you’re aware of the best tools for the specific problems you have.
Useful links to the resources
First of all, if you’re interested, the slides of the session are available on Slideshare.
If you want to learn what microservices are all about, to better understand this session, consider watching the Architecting Large Enterprise Java Projects by Markus Eisele first. In that session Markus explained what microservices are, what are their most identifiable qualities, and how should you think about them.
To better understand what it means to be reactive, read the reactive manifesto, even if you need to better grasp the general vocabulary: reactivemanifesto.org.
For a deeper dive into how to build a reactive microservice, Markus has recommended the Reactive Microservice book.
If you’d prefer learning from the first person experience, check out Reactive Summit, the conference focused on building and maintaining reactive systems: http://reactivesummit.org/.
To learn about building resilient systems, you can watch a previous Virtual JUG session, by Jonas Boner: Resilience is by design by Jonas Boner.
A friendly chat with Markus
Following every session we interview the Virtual JUG speaker, and Markus answered a couple of questions about what has changed his opinion on Java EE, since the time he was the Java EE evangelist at RedHat. If you’re interested in what Lightbend’s Lagom can offer above other microservices platforms, including the problems that Markus foresees us hitting in the upcoming years, watch the interview below.
And if you have any further questions, ping Markus on Twitter.