Virtual JUG Session: http://www.meetup.com/virtualJUG/events/232052100/
With Microservices taking the software industry by storm, classical Enterprises are forced to re-think what they’ve been doing for almost a decade. It’s not the first time, that technology shocked the well-oiled machine to it’s core. We’ve seen software design paradigms changing over time and also project management methodologies evolving. Old hands might see this as another wave that will gently find it’s way to the shore of daily business. But this time it looks like the influence is bigger than anything we’ve seen before. And the interesting part is, that microservices aren’t new from the core. Talking about compartmentalization and introducing modules belongs to the core skills of architects. Our industry also learned about how to couple services and build them around organizational capabilities.
The really new part in microservices based architectures is the way how truly independent services are distributed and connected back together. Building an individual service is easy with all technologies. 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.
And there are more differences between Java EE and distributed and reactive systems. For example, APIs are inherently synchronous, so most Java EE app servers have to scale by adding thread pools as so many things are blocking on I/O (remote JDBC calls, JTA calls, JNDI look ups, even JMS has a lot of synchronous parts). As we know adding thread pools doesn't get you too far in terms of scalability.
This talk is going to explore the nine most important differences between classical middleware and distributed, reactive microservices architectures and explains in which cases the distributed approach takes you, where Java EE never would.