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.

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: christian@redhat.com
• “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

14. We Need Boundaries!

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

22. Domain Aggregates
Source: https://vaughnvernon.co

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

32. Implementing these concepts

33. @christianposta
blog.christianposta.com
github.com/christian-posta

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

36. https://github.com/christian-posta/ticket-monster-ui

37. https://github.com/christian-posta/ticket-monster-admin
https://github.com/christian-posta/ticket-monster-orders
https://github.com/christian-posta/ticket-monster-search

38. https://github.com/christian-posta/ticket-monster-infra
https://github.com/christian-posta/ticket-monster-admin-camel
https://github.com/christian-posta/ticket-monster-orders-camel

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: christian@redhat.com