Just recently, I was invited to talk about microservices on Virtual JUG. The idea was to point out the limitations of Java EE when using it as a base for creating microservices architectures (MSA). But before I actually talked about the nine major points according to the session title, it was time to revisit the motivation for this talk.
Enterprise developers have been traditionally thinking in terms of specifications (e.g. Java EE) and built their implementations inside containers without caring too much about their individual life cycle. Hooking into startup and shutdown events was easy, and accessing other components just an injected instance away. And the base platform or framework of choice made it comparably easy to map our objects into relational databases or connect to other systems via messaging.
The best part of all of this was the transactionality of the system, which was easily achieved. Beside the many drawbacks we experienced by implementing large enterprise Java projects over all these years, we managed to keep them up and running; however, classic middleware platforms have originally been designed with a very different development and deployment model in mind and they don’t necessarily provide what is required for modern applications today.
With the increasing number of connected devices and users, we need to think about data in motion and operating on incoming information in near real-time instead of relying on a centralized database which we analyze offline, when we have the time to do it. We now have new requirements...
It's critical for modern enterprises to stay competitive and adapt to new business models quickly. One of the key assets is the ability to answer new questions with the same data without having to rewrite significant parts of existing applications (all under continuously increasing cost pressure).
Which is why many architects and cloud development teams are turning to microservices. A microservice architecture is highly supportive for these kind of requirements and pretty much the opposite of what application servers were designed for. These architectures come with a very different set of needs to build and handle large-scale enterprise systems.
Taking these requirements and measuring the ability of Java EE as a specification and implementation to solve them breaks down to the “Nine Neins”. And the German word “Nein” (No) in this context is defined as a benefit lost when considering a microservice architecture with Java.
Java EE ...
1) … helps building distributed monoliths
2) … has a threading-model that isn’t ideal for microservices
3) … doesn’t support the notion of data in motion (streams)
4) … doesn’t support resiliency
5) … is implemented as containers – no service elasticity
6) … has no notion of immutability
7) … doesn’t give you a choice of data stores, use of transactions and eventual consistency
8) … delivers no outer architecture – while still calling it a platform
9) ... doesn’t know services
Watch the complete talk and see the slide deck to get the full story. Microservice architectures are about pragmatism not vendors raising barriers to competitors by creating overly complex specifications.
Watch on YouTubeAs a more in-depth companion to this presentation, I invite you to download my recent O'Reilly book, Developing Reactive Microservices: Enterprise Implementation in Java. In it, you'll see how we use Lagom, our real-life microservices framework to help you conquer your new Java project, as well as:
