SOA to Microservices
23 likes36,465 views
10 yrs ago, SOA promised a lot of the same things Microservices promise use today. So where did we go wrong? What makes microservices different? In this talk, we discussed from an architectural view how we went sideways with SOA, why we must embrace things like Domain Driven Design and scaled-out architectures, and how microservices can be built with enterprises in mind. We also cover a step-by-step, in-depth tutorial that covers these concepts.
Ad
More Related Content
What's hot (20)
Viewers also liked (6)
Ad
Similar to SOA to Microservices (20)
Ad
More from Christian Posta (20)
Recently uploaded (20)
![Pixologic ZBrush Crack Plus Activation Key [Latest 2025] New Version](https://cdn.slidesharecdn.com/ss_thumbnails/fashionevolution2-250322112409-f76abaa7-250428124909-b51264ff-250504160528-fc2bb1c5-thumbnail.jpg?width=560&fit=bounds)
SOA to Microservices
- 1. SOA to Microservices @christianposta Principal Architect at Red Hat 6/30/16 Modernization with microservices and containers
- 3. Christian Posta Principal Middleware Architect @ Red Hat Twitter: @christianposta Blog: http://blog.christianposta.com Email: [email protected] • “Microservices for Java developers” (6/2016) • Committer Apache Camel, ActiveMQ, Fabric8, others • Worked with large Microservices, web-scale, unicorn company • Blogger, speaker about DevOps, integration, and microservices
- 4. What if we just do Microservices!
- 5. Increased Interoperability Increased Vendor and Technology Diversity Increased Federation Increased Organizational Agility
- 6. Sound familiar? That was SOA
- 7. Where did we go wrong?
- 8. One large database mentality
- 9. Layers as a general-purpose architecture
- 10. • Single, self-contained, autonomous • Isolated and Resilient to faults • Faster software delivery • Own their own data • Easier to understand individually • Scalability • Right technology for the problem • Test individual services • Individual deployments Microservices to the rescue…
- 11. Infrastructure for scale Organizational structure Identify a useful domain model with boundaries Microservices: Challenges for Enterprises
- 12. People try to copy Net,lix, but they can only copy what they see. They copy the results, not the process. Adrian Cockcroft, former Chief Cloud Architect, Netflix
- 13. Enterprises have complex domains and scale requirements
- 16. Book checkout / purchase Title Search Recommendations Weekly reporting
- 17. Domain Complexity • Break things into smaller, understandable models • Surround a model and its “context” with a boundary • Implement the model in code or get a new model • Explicitly map between different contexts • Model transactional boundaries as aggregates
- 19. What about the data!?
- 20. Which one? Transactional Consistency or Eventual Consistency?
- 21. Modeling components • Entity • Value Object • Aggregate • Domain Events
- 23. Domain Aggregate • Design for consistency boundaries, not data model composition • Single transaction per aggregate • Based on business invariants • Eventual consistency between aggregates
- 24. Embrace Autonomy! No Two-Phase Commit! • Always use idempotent consumers • Relax foreign key constraints between aggregates/ bounded contexts • Embrace eventual consistency between time domains
- 25. Which one? Transactional Consistency or Eventual Consistency? Ask yourself “Who’s job is it”?
- 26. Automation
- 27. • Self service • Built in deployments • Cluster logging, metrics, monitoring • Blue/Green deployments, Canary deployments • Service Discovery built in • Continuous Integration / Continuous Delivery Platform automation
- 28. • Circuit breakers/bulkhead • Client-side load balancing • Forward proxying • Service routing • Centralized configuration management • Leadership election Microservices libraries/frameworks
- 30. • Load balancing built-in • Service discovery built-in • Self healing built-in • No complicated service-discovery infrastructure! • Just use DNS for the 95% use case • Save client-side load balancing for the 5% use case Kubernetes Services
- 34. • WildFly Swarm (wildfly-swarm.io) • Kubernetes / OpenShift (openshift.org) • Apache Kafka (kafka.apache.org) • Debezium (debezium.io) • Apache Camel (camel.apache.org) • Spring Boot (projects.spring.io/spring-boot/) • Liquibase (liquibase.org) Technologies used
- 39. • Better, richer, aggregate design • CQRS for the orders bounded context • Security with Keycloak • Tracing with Zipkin • Sidecar circuit breakers with Netflix OSS Hystrix • CI / CD with Fabric8 / OpenShift Left todo
- 40. Christian Posta Principal Middleware Architect @ Red Hat Twitter: @christianposta Blog: http://blog.christianposta.com Email: [email protected]