Microservices for java architects it-symposium-2015-09-15

Microservices for
Java Architects
Derek C. Ashmore
©2015, All Rights Reserved

Who am I?
 Professional Geek since 1987
 Java/J2EE/Java EE since 1999
 Author of “The Java EE Architect’s Handbook, Second Edition”
 Roles include:
• Developer
• Architect
• Project Manager
• DBA
• System Admin

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

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
 Standard Interface (typically Web Service/REST)
 Analogy: Stereo system, Linux utilities

Traditional Java EE Application Architecture
 Like a layer cake
 Highly cohesive
 Defined dependencies
 Deployed as one unit
(war/ear)
 Limited Scalability
• Code Size

What is a Monolith?
 Hard to change
• QA test cycles are long
• Change causes unintended consequences
 Hard to onboard new developers
 Married to your technical stack
 Harder to diagnose bottlenecks and memory issues

Refactoring into Microservices
 Databases physically
separated
 What to do with
common data needs?
• Service call or
• Data copy

No Technical Stack Lock-in
 Platform agnostic
• Freedom to choose database platform
• Freedom to choose languages / frameworks
 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
• Don’t go ‘crazy’ with your choices

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

Isn’t this SOA?
 Yes – More or less
 No concrete definitions
 SOA == dumb endpoints and smart routes
• ESB routes using Mule, Camel, etc.
• Transformations en route
 MS == dumb routes and smart end-points
• Simple routes
 Usually REST or Soap calls via http(s)
 Persistent queue route at it’s most complex
 Analogy: Electrical supply for Stereo

Design considerations
 Service Boundaries (gerrymandering)
 Service call Failure / Unavailability
 Data Integrity
 Performance

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

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

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

What about Code Base Size?
 Microservices are not about size!
• They are about having a single business purpose
 Microservices ‘happen’ to have a smaller code base
• Results from their single business focus

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

Retry Pattern
 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)

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.

Dispatch via Messaging
 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
• JMS Api (easy API – many use natively)
• Spring JMSTemplate or RabbitTemplate (producer)

Designing for Performance
 More network traffic
• Make services course-grained
• User Interfaces need a general manager
• Horizontal or Vertical Scaling helps
• Back-ends for Front-ends (a.k.a. API Gateway)
• Dispatch via Messaging
• Expiring Cache

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

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
• I recommend Google Guava
• EHCache, Gemfire, and other tools available

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
• Custom Rollback
 Write your own reversing transaction

Packaging Support
 Microservices are deployed as a process
• For Java, embedded containers are easy
• Spring Boot
• Dropwizard
 Docker – standardizes the process deployment and environment

Spring Boot
 Packages Java EE application into *one* deployment jar
• java –jar myApp.jar
 Support for health checks and other admin add ons via ‘Actuator’ add-on
 Supports either Jetty or Tomcat
 Best for ‘Spring-mvc’ apps
• For non-spring apps, it’s swimming upstream
 Required artifacts
• Maven
 spring-boot
 spring-boot-starter-jetty (tomcat is available)
 spring-boot-starter-actuator (optional – health checks, etc.)
• Application class with public static void main()
 Configuration coded (usually into the application class)
 Will read application.properties (app-specific properties)

Dropwizard
 Packages Java EE application into *one* deployment jar
• java –jar myApp.jar server myConfig.yaml
 Provides file configuration options (yaml format)
• Database connection pools
• Logging config
• Port and other container specs
 Provides easy metrics/healthcheck support
 Uses Jetty
 Required artifacts
• Application class (with main())
• Maven: dropwizard-core, maven-shade-plugin

Docker
 Is a “mini VM”
• runs a linux kernal
• Compare to shipping container
• Standard “connections” to outside world
 Supported formally by Oracle, Tomcat, Jboss, and many more
 Docker is Win-Win
• Easier for OPS and system administrators
 All software looks the same
 Standard interface for disk and network resources
• Containers can be “linked”
 Inherently automated
• Easier for developers
 Fewer environment difference issues
 Less to communicate to OPS / system administrators
 Easy to leverage work of others (docker-hub)
• If you haven’t tried Docker yet – you should!

Where’s the marketing fluff?
 Easier to manage
• Maybe
 You *must* be good at contract management
 You *must* be good at specifying precisely what a microservice needs to do
 You *must* ensure that services make no assumptions on how they get
invoked
 Easier for developers to “understand” applications
• No – sorry
 It is easier to understand a particular ‘cog’ in the machine (e.g. the function of
one service
 It is *not* easier to understand how microservices fit together to provide a
particular piece of business functionality

Where’s the marketing fluff? (continued)
 Increased Development Throughput
• Maybe
 Harder for business to ‘test’ a business function for a specific combination of microservices
 Developers work on *one* service at a time.
 You *must* be good at error detection (unintended consequences)
 The more assumptions a service makes about its execution context, the more unintended
consequences (e.g. errors) you are likely to have on deployment
 Services become disposable and can be “replaced” instead of “maintained / fixed”.
• Maybe
 It’s more easily replaced than when using traditional architectures
 Requires rigorous contract testing
• Can’t have the “replacement” act any differently than the original (except for the bug being
fixed, of course)
 Requires architecture support for cross-cutting concerns
• Can’t take a lot of time to implement / test

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

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/

Microservices for java architects it-symposium-2015-09-15

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Microservices for java architects it-symposium-2015-09-15

Similar to Microservices for java architects it-symposium-2015-09-15 (20)

Recently uploaded

Recently uploaded (20)

Microservices for java architects it-symposium-2015-09-15