Java EE microservices architecture - evolving the monolith
12 likes7,384 views
The document discusses the evolution from monolithic architectures to microservices, emphasizing the benefits of microservices like scalability, independent deployment, and flexibility. It outlines key principles, design patterns, and best practices for transitioning to a microservices architecture while acknowledging the complexities involved. The necessity for organizational changes and team alignment to effectively manage and leverage microservices is also highlighted.
More Related Content
Similar to Java EE microservices architecture - evolving the monolith(20)
Java EE microservices architecture - evolving the monolith
- 1. Java EE Microservices Architecture Evolvingthe monoliths
- 2.
- 3. monolith / ˈmɒn(ə)lɪθ/ noun noun: monolith;plural noun: monoliths
- 5. The Curse OfThe Monolith We know how to operate them • We know how to develop • We know how to deploy • We know how to scale but there is a price to pay • Large code-bases • Hard to understand and modify • Complex configuration
- 6.
- 8. The Curse OfSOA Increased everything • Interoperability • Federation • Business and technology alignment but there is a price to pay • Centralized infrastructures • Restricted communication protocols • Vendor driven movement
- 9.
- 11. What Are Microservices? SOAfor DevOps • Single, self-contained, autonomous • Easy(er) to understand individually • Scalability • Testing independently • Individually deployed, has own lifecycle • Single service going down should not impact other services • Right technology stack for the problem (language, databases, etc) • Fail fast • Faster innovation, iteration We want flexible systems and organizations that can adapt to their complex environments, make changes without rigid dependencies and coordination, can learn, experiment, and exhibit emergent behavior. „
- 12.
- 14. Enterprise Goals andObjectives Resistant to Change and Economically Efficient Developers Left Alone Technology-Centric Versus Business-Centric
- 15. Single Vendor Platformdecisions increasingly unattractive OpenSource moves quickly into this direction Platform as a Service offerings mature Increasing need for business value from software Quicker turnaround cycles for changes required
- 16. We need tobuild systems for flexibility and resiliency, not just efficiency and robustness.
- 17. And we needto start building them today with what we have.
- 18. From monolith tomicroservice architecture ?
- 19. Technology alone won’t solveyour problem.
- 20. Software Design Outer Architecture Methodologyand Organization Distributed Systems Platform As A Service
- 21. Organisation • Autonomous, self-directedteams • Transparency • Small (2-pizza rule) • Purpose, Trust, Empathy driven • Feedback • Experimentation • Respond quickly to change • Own services, delivery, operations • Build it, you own it
- 22. Model culture afteropen source organizations: meritocracy, shared consciousness, transparency, network, platforms. (Christian Posta, Red Hat) „
- 23. DEV Continuously deliver software Focus onadding value, not maintenance Deliver features faster OPS Minimize manual, repetitive work Stabilize operating environments Encounter issues of reduced complexity Resolve problems quicker
- 24.
- 25. Software Design Architecture Principles •Single Responsible Principle • Service Oriented Architecture • Encapsulation • Separation of Concern • Loose Coupling • Hexagonal Architecture Design Patterns • Domain-driven Design • Bounded Contexts • Event Sourcing • CQRS • Eventual Consistency • Context Maps
- 26. Design Constraints • Availability •Scalability • Performance • Usability • Flexibility
- 27. Best Practices • Designfor Automation • Designed for failure • Service load balancing and automatic scaling • Design for Data Separation • Design for Integrity • Design for Performance
- 28. Strategies For Decomposing Verbor Use Case e.g. Checkout UI Noun e.g. Catalog product service Single Responsible Principle e.g. Unix utilities
- 29. Distributed Systems • Thenetwork is unreliable • Design time coupling • Unintended, run-time coupling • Components will fail • Design for resilience, not just robustness
- 30. Control Dependencies • Whatcomponents depend on the others • Which teams need to engage to make a change • What services need to be changed if one changes • Coordination, contention, synchronization, blocking • Hidden dependencies
- 31. Platform as aService • Docker, Kubernetes • Developer focused workflow • Source 2 Image builds • Build as first-class citizen • Deployments as first-class citizen • Software Defined Networking (SDN) • Docker native format/packaging • Run docker images • CLI/Web based tooling
- 32. Outer Architecture Load Balancer ServiceAA DBClientCache APIGateway Security Service Registry Operational Capabilities (Scaling, SLA, Monitoring, Logging, Deployment) Developer Enablement (Documentation, Discovery, Debugging)
- 33.
- 34. Java EE 7Features
- 35.
- 36. Load Balancer App ServiceSDApp ServiceSD Java EE.ear .war .war .jar .jar .jar .jar DBClient App ServiceSD App ServiceSD ServiceAA .war .jar .jar DBCache GLUE
- 37. Load Balancer App ServiceSDApp ServiceSD Java EE.ear .war .war .jar .jar .jar .jar DB Client App ServiceSD App ServiceSD ServiceAA .war .jar .jar DBCache /service /order Read-only Access!
- 39. Let’s look atsome patterns
- 40.
- 41.
- 42.
- 43.
- 44.
- 45. Respect The Challenge •No silver bullet; distributed systems are *hard* • Dependency hell, custom shared libraries • Fragmented and inconsistent management • Team communication challenges • Health checking, monitoring, liveness • Over architecting, performance concerns, things spiraling out of control fast
- 46. http://martinfowler.com/bliki/MicroservicePremium.html The fulcrum ofwhether or not to use microservices is the complexity of the system you're contemplating. (M.Fowler) “
- 47. Lessons Learned Today •Correct functional decomposition is crucial for microservices: • pretty hard to get right from the start • a modular system can evolve to microservices • balance the needs with the costs • work on it evolutionary • Java EE can be a platform for microservices • You need a lot more than just technology
- 48. Fit all thepieces together
- 49. http://bit.ly/ModernJavaEE • Understand thechallenges of starting a greenfield development vs tearing apart an existing brownfield application into services • Examine your business domain to see if microservices would be a good fit • Explore best 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