Writing microservices in Java -- Chicago-2015-11-10
2 likes665 views
This document summarizes a presentation on writing microservices in Java. It discusses: - What microservices are and common traits like single functional purpose and standard interfaces - Reasons for using microservices like no lock-in, easier management, and higher throughput - Design considerations like service boundaries, handling failures, data integrity, and performance - Common patterns for designing microservices around failures, transactions, and performance - Cross-cutting concerns like deployment, security, and contract testing - When microservices are appropriate to use The presentation provides examples and references additional resources on GitHub for sample code.
Writing microservices in Java -- Chicago-2015-11-10
- 1. Writing Microservices in Java Given by Derek C. Ashmore November 10, 2015 ©2015 Derek C. Ashmore, All Rights Reserved 1
- 2. Who am I? • Professional Geek since 1987 • Java/J2EE/Java EE since 1999 • Roles include: • Developer • Architect • Project Manager • DBA • System Admin ©2015 Derek C. Ashmore, All Rights Reserved 2
- 3. Discussion Resources • This slide deck – http://www.slideshare.net/derekashmore • Sample code on my Github – https://github.com/Derek-Ashmore/ • Sample Java Microservice (Moneta) – https://github.com/Derek-Ashmore/moneta • Slide deck has hyper-links! – Don’t bother writing down URLs ©2015 Derek C. Ashmore, All Rights Reserved 3
- 4. Agenda The “What” and “Why” of microservices Design Considerations and Patterns Cross-cutting concerns When to use microservices Summary / Q&A ©2015 Derek C. Ashmore, All Rights Reserved 4
- 5. What are Microservices? • No concrete definition • Common microservice traits – Single functional purpose • Most/all changes only impact one service • Not dependent on execution context – “loosely coupled” – Independent process/jvm – Stateless – Standard Interface (typically Web Service/REST) – Analogy: Stereo system, Linux utilities ©2015 Derek C. Ashmore, All Rights Reserved 5
- 6. Refactoring into Microservices • Databases physically separated • What to do with common data needs? • Service call or • Data copy ©2015 Derek C. Ashmore, All Rights Reserved 6
- 7. No Lock-in • Platform agnostic • Fewer dependency conflicts • Still have cross-cutting concerns • “Toll” for first app • Still have support concerns • Others need to be able to support your work 7©2015 Derek C. Ashmore, All Rights Reserved
- 8. Easier Management / Higher Throughput • Easier to manage large numbers of developers – Concentrate on intelligently drawing service boundaries – Manage/enforce service contracts • Each service team works independently • Team independence leads to higher development throughput ©2015 Derek C. Ashmore, All Rights Reserved 8
- 9. Agenda The “What” and “Why” of microservices Design Considerations and Patterns Cross-cutting concerns When to use microservices Summary / Q&A ©2015 Derek C. Ashmore, All Rights Reserved 9
- 10. Design considerations • Service Boundaries (gerrymandering) • Service call Failure / Unavailability • Data Integrity • Performance ©2015 Derek C. Ashmore, All Rights Reserved 10
- 11. Service Boundaries • Core Services – Services responsible for maintaining a specific business area data – Usually named after Nouns • Service is a system of record for a <blank> – Student, Course, Classroom, etc. • Process Services – Services responsible for performing single complex tasks – Usually represents an Action or Process • Service is responsible for processing <blank> – Student applications, Debt collection, etc. – These services rely on core services • Partitioning is an art – Too few same drawbacks as traditional architecture – Too many excessive network hops ©2015 Derek C. Ashmore, All Rights Reserved 11
- 12. Boundary Sanity Check • Verbalize a mission statement in one sentence in business terms – Examples • This service is the system of record for Student information • This service registers students for classes • This service suspends students • This service records student payments • This service produces official transcripts ©2015 Derek C. Ashmore, All Rights Reserved 12
- 13. Context Independence Check • Does your service have multiple consumers? – Could it? • Could your service execute as easily in batch as online? – If ‘No’, then you’re making context assumptions • Warning Signs – Spending time analyzing service call flow • Your services likely make context assumptions – Agonizing over which service should do a given activity • Maybe you need a new service ©2015 Derek C. Ashmore, All Rights Reserved 13
- 14. Microservices are not about size ©2015 Derek C. Ashmore, All Rights Reserved 14 ….. Microservices are about having a single business purpose!
- 15. Designing for Failure • Dependent services could be down – Minimize human intervention – Fail sooner rather than later – Horizontal scaling / clustering is your first line of defense – Coding patterns can help as a backup • Common Patterns: – Retry – Circuit Breaker – Dispatch via Messaging – Service Call Mediator ©2015 Derek C. Ashmore, All Rights Reserved 15
- 16. Retry Pattern ©2015 Derek C. Ashmore, All Rights Reserved 16 • Best for asynchronous tasks • Limit the number of tries • Use sleep interval between tries • Only addresses temporary outages • Sample Retry Pattern implementation here. • Tooling Support: – Apache CXF supports Retry – Spring Batch RetryTemplate – Apache HttpClient (Example here)
- 17. Circuit Breaker ©2015 Derek C. Ashmore, All Rights Reserved 17
- 18. Circuit Breaker (continued) • Objective: Error out sooner – Conserves resources – Automatically “recovers” after a time period • Modeled after home circuit • Works on thresholds – Number of errors required to trip circuit – Amount of time required to attempt retry • Has Hysterix support • Best embedded in interface clients / delegates • More information here. • Sample Circuit implementation here. ©2015 Derek C. Ashmore, All Rights Reserved 18
- 19. Dispatch via Messaging ©2015 Derek C. Ashmore, All Rights Reserved 19 • Place work instruction on persistent queue • If receivers are down, work stacks in queue • Work throttled by number of receivers • Queue can be JMS or AMQP • Tooling Support: – JMS Api (easy API – many use natively) – Spring JMSTemplate or RabbitTemplate (producer)
- 20. Service Call Mediator ©2015 Derek C. Ashmore, All Rights Reserved 20 • Provide “Partial” functionality when dependent services are down • Providing partial functionality better user experience than complete outage – Airline Wifi provider providing service even if payment processing is down • Sample implementation here
- 21. Designing for Performance • More network traffic – Make services course-grained – User Interfaces need a general manager – Horizontal or Vertical Scaling helps • Common Patterns: – Back-ends for Front-ends (a.k.a. API Gateway) – Dispatch via Messaging – Expiring Cache ©2015 Derek C. Ashmore, All Rights Reserved 21
- 22. Back-ends for Front-ends ©2015 Derek C. Ashmore, All Rights Reserved 22
- 23. Back-ends for Front-ends (continued) • Consolidates service calls for the browser – Enhances performance • Open web often not as performant as local LAN • Also known as “API Gateway” • Implications – Don’t expose microservices directly to the browser ©2015 Derek C. Ashmore, All Rights Reserved 23
- 24. Expiring Cache ©2015 Derek C. Ashmore, All Rights Reserved 24
- 25. Expiring Cache (continued) • Look up data once and cache it – Evict data from the cache after a defined time period – Sometimes known as “Cache Aside” – Reduces network calls for data – Trades memory for speed – More information here • When to use – Only use with static data – Different clustered nodes “could” have different data for a short time • Tooling Support: – I recommend Google Guava – EHCache, Gemfire, and other tools available ©2015 Derek C. Ashmore, All Rights Reserved 25
- 26. Designing for Integrity • Services are context independent – Have no knowledge of how/when they are executed • One service == One Transaction – Two-phase commits/rollbacks are a much larger problem • Common Patterns: – Custom Rollback • Write your own reversing transaction ©2015 Derek C. Ashmore, All Rights Reserved 26
- 27. Custom Rollback ©2015 Derek C. Ashmore, All Rights Reserved 27
- 28. Custom Rollback (continued) • Reverses a transaction previously posted • Only use this for multi-service transactions – Keeping the transaction within one service is preferred • This pattern is completely custom – No special product support available • Not comprehensive solution – Interruption usually causes inconsistent data • More information here ©2015 Derek C. Ashmore, All Rights Reserved 28
- 29. Common code between services? • Yes, but…. – Version it; services make decision as to when to upgrade – Changes to common code can’t require the deployment of multiple services • That ‘common code’ needs to be its own separate service • Tends *not* to have business logic as that can change and impact multiple services ©2015 Derek C. Ashmore, All Rights Reserved 29
- 30. Agenda The “What” and “Why” of microservices Design Considerations and Patterns Cross-cutting concerns When to use microservices Summary / Q&A ©2015 Derek C. Ashmore, All Rights Reserved 30
- 31. Cross-cutting Concerns • Deployment • Transaction tracking • Security • Contract Testing • Same as traditional applications – Health checks – Logging consolidation – Performance measurement ©2015 Derek C. Ashmore, All Rights Reserved 31
- 32. Deployment • Microservices are deployed as a process – For Java, embedded containers are easy – Spring Boot – Dropwizard • Docker – standardizes the process deployment and environment • Sample here. ©2015 Derek C. Ashmore, All Rights Reserved 32
- 33. Correlation IDs • Provides context for service calls or user actions • Track using HTTP Header • Log it on all messages / error reports • Include it on all service calls or message dispatches • Code sample here • Spring Boot support has been requested 33©2015 Derek C. Ashmore, All Rights Reserved
- 34. Security ©2015 Derek C. Ashmore, All Rights Reserved 34
- 35. Security (continued) • Keep User-level security to the UI • Microservice security in layers – Layer 1 – Network routing enforcement • Limit access only to within the firewall • Limit access to specific hosts or subnets – Layer 2 – Use Service Accounts • Similar to database access – Microservices must be context independent! ©2015 Derek C. Ashmore, All Rights Reserved 35
- 36. Contract Testing • Critical for MS architectures – Contract changes can break other services – Bulkhead for rogue developers – Makes individual services more disposable • Consumer-based testing • Tooling support – Apache HttpClient – SoapUI – ActiveMQ for JMS (embedded broker) ©2015 Derek C. Ashmore, All Rights Reserved 36
- 37. Agenda The “What” and “Why” of microservices Design Considerations and Patterns Cross-cutting concerns When to use microservices Summary / Q&A ©2015 Derek C. Ashmore, All Rights Reserved 37
- 38. When to consider MS • Starting out with MS isn’t recommended unless – Parts of the application will have extremely high volume • Need to scale a portion of the application differently • Note: MS isn’t all or nothing! • Warning signs for app that’s too large – Unintended consequences after release – High technical debt / design rot – Release testing cycles abnormally large – Need to coordinate large numbers of developers for a single code base • Large number == takes more than two pizzas to feed ©2015 Derek C. Ashmore, All Rights Reserved 38
- 39. Common Mistakes • Inappropriate Service Boundries – Services that are not truly loosely coupled • One change Multiple services deployed – Services that make ‘assumptions’ about execution context • Deployments cause unintended consequences • Not recording all requests/responses – Support developers need to localize problems – Include request/response data in exceptions • Contexted Exceptions in Commons Lang ©2015 Derek C. Ashmore, All Rights Reserved 39
- 40. Common Mistakes (continued) • Not checking arguments up front – Derivative exceptions take longer to debug/fix – Error out faster – NullPointerException == Argument not checked! • No Change in Governance – Easier / quicker path to production – Automated Deployments/Backouts • Less manual intervention • Less manual testing (quick reaction vs prevention) – Continuous Delivery / DevOps / Microservices go hand-in-hand ©2015 Derek C. Ashmore, All Rights Reserved 40
- 41. Further Reading • Microservices reading list – http://www.mattstine.com/microservices • Microsoft’s Cloud Design Patterns – https://msdn.microsoft.com/en-us/library/dn600223.aspx • Moneta Java microservice example – https://github.com/Derek-Ashmore/moneta • This slide deck – http://www.slideshare.net/derekashmore ©2015 Derek C. Ashmore, All Rights Reserved 41
- 42. Questions? • Derek Ashmore: – Blog: www.derekashmore.com – LinkedIn: www.linkedin.com/in/derekashmore – Twitter: https://twitter.com/Derek_Ashmore – GitHub: https://github.com/Derek-Ashmore – Book: http://dvtpress.com/ ©2015 Derek C. Ashmore, All Rights Reserved 42