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.
8. LL: Building and Scaling Monoliths
• Monolithicapplication –everything is
package into a single .ear
• Reuse primarily by sharing .jars
• A “big” pushto productiononce or twice a
year
• Single database schema for the entire
application
• >= 500k loc
• >= Heavyweight Infrastructure
• ThousandsofTestcases
• Barely New Testcases
• >= 20 Team Member
• The single.ear requiringa multi-month
test cycle /
• Huge bug and featuredatabases
• User Acceptance Undefined
• Technical Design Approach
• Barely BusinessComponentsor Domains
• Requiringmultiple team involvement &
significant oversight
• Technical Dept
• Outdated Runtimes (Licenses,Complex
updates)
• Grown applications
10. New requirements
• Rather than acting ondata at rest, modern
software increasingly operates ondata
in near real-time.
• Shortenedtime-frames for putting
changes into production
• New business models evolve from
existing ones
• New questions need to be answered by
existing applications
• Datacenter costs needto go down
constantly
19. 1) Java EE helps building distributed
monoliths
• 100s of libraries are part of the base platform
• Upgrading individual libraries partly impossible
(e.g. RIs)
• Requires client libraries (e.g. JAX-RS and JMS) <=
logic drifts into the client.
• Doesn’t support other languages and can’t really
embrace the polyglot approach to microservices
• No independent technical evolution in teams
because of the common base platform
20. 2) Java EE has a threading-model that
isn’t ideal for microservices
• Request to thread binding.
• Can’t be scaled to thousands of servers easily.
• Responsiveness isn’t build in from the core.
• Clustering isn’t part of the specification and relies
on vendor specific features.
• No standardized asynchronous approach for
endpoints (e.g. JAX-RS, JAX-WS)
21. 3) Java EE doesn’t support the notion
of data in motion (streams)
• JDBC and JPA block on Socket I/O
• important methods are synchronized, thereby
allowing onlyone queryat a time on
one connection.
• Batch processing as default way to handle bulk
updates.
• Not even Java 8 Lambdas usable because
Fork/Join and Concurrency Utilities doesn’t play
nicely together in a managed environment
http://mail.openjdk.java.net/pipermail/lambda-dev/2013-April/009335.html
22. 4) Java EE doesn’t support resiliency
• No notion of replication, containment, isolation or
delegation.
• With the exception of vendor specific features
(which require clustering)
• Failures are propagated and not contained
• One component failure usuallybrings down the
complete application
• No support for bulkheading. Clients have to handle
failures.
23. 5) Java EE is implementedas
containers – no service elasticity
• Containerless development impossible
• Testing is hard (Arquillian makes it bearable)
• No simple development models
• Compile, Build,Deploy – cycles for every
microservice
• No class-reloading (unless you use AMAZING tools
like JRebel :-D)
• No increasing or decreasing of resources under
various workloads.(Back-pressure)
• With the exception of vendor specific features
(which require clustering)
24. 6) No notion of immutability
• Handling of large amounts of data within
distributed systems requires immutability for data
• Immutable services are the new paradigm in load
balancing, high availability, and dynamic resource
sharing.
• JPA works well with RDBMS
• CQRS and Event-Sourcing work well with
immutable data-structures and are beneficial for
microservices.
http://cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf
25. 7) Choice of data stores, use of
transactions and eventual consistency
• No NoSQL support in Java EE
• Polyglot persistence onlypossible in very few
frameworks.
• Heavily embracing distributed transactions with
2PC.
• Eventual consistencyis ignored and discouraged
http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf
26. 8) No outer architecture – while still
calling it a platform
• Monitoring
• Distributed Logging
• Security
• Service discovery
• Service locator
• API versioning
• Routing
• …
27. 9) Java EE doesn’t know services
• No service component model
• No service templates
• Hardly any endpoint documentation (WSDLs)
• No service boundaries
• No way to enforce decoupling
33. “Rules are for the obedience of fools and
the guidance of wise men.”
Generally attributed to Douglas Bader
34. Written for architects and developersthat must
quickly gain a fundamental understandingof
microservice-basedarchitectures, this freeO’Reilly
reportexploresthe journey fromSOAto
microservices,discussesapproachesto dismantling
your monolith,and reviews the key tenets ofa
Reactive microservice:
• Isolate all the Things
• Act Autonomously
• Do OneThing, and Do It Well
• Own Your State, Exclusively
• Embrace AsynchronousMessage-Passing
• Stay Mobile,but Addressable
• Collaborate as Systems to Solve Problems
http://bit.ly/ReactiveMicroservice
35. The detailed example inthis reportis based on
Lagom, a new frameworkthat helps you follow the
requirementsfor buildingdistributed,reactive
systems.
• Get an overview of the Reactive Programming
model and basic requirementsfor developing
reactive microservices
• Learnhow to create base services, expose
endpoints,and then connect them with a
simple, web-based user interface
• Understand how to deal with persistence,state,
and clients
• Use integration technologiesto start a
successfulmigration away fromlegacy systems
http://bit.ly/DevelopReactiveMicroservice
36. http://bit.ly/SustainableEnterprise
• Understand thechallenges ofstartinga greenfield
development vs tearingapart an existing brownfield
application into services
• Examine your business domain to see if microservices
would bea good fit
• Explorebest practices for automation,high availability,
data separation,and performance
• Align your development teams around business
capabilities and responsibilities
• Inspect design patterns such as aggregator, proxy,
pipeline, or shared resources to model service
interactions
41. •Keep all data in memory!
• Store all state changes as events
• Replay all events of an actor to recreate it
• Strong consistencyfor Actor (aggregate) and
Journal
• Eventual Consistencyfor Read Side
https://msdn.microsoft.com/en-us/library/jj554200.aspx