microservices for java architects (indianapolis, april 15, 2015)

Micro Services for Java Architects

Given by Derek C. Ashmore

April 15, 2015

©2015 Derek C. Ashmore, All Rights Reserved 1

Who am I?

• Professional Geek since 1987

• Java/J2EE/Java EE since 1999

• Roles include: • Developer

• Architect

• Project Manager

• DBA

• System Admin


http://www.chicagocoderconference.com/

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


http://www.slideshare.net/derekashmore


https://github.com/Derek-Ashmore




https://github.com/Derek-Ashmore/moneta



Agenda

The “What” and “Why” of micro services

Design Considerations

and Patterns

Packaging Options

Cross-cutting concerns

When to use micro services

Summary / Q&A


What are Micro services?

• No concrete definition

• Common micro service 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


Micro services organize by domain

• Silo by business competency

• Divide and Conquer

• How to divide is the hard part


Micro services follow the Org Chart

• Conway’s Law

– Systems copy the structure of the organizations that build them

• Why?

– Corps need one manager in charge

– Reduces inter-group conflict


Refactoring into Micro Services

• Large benefits to unified user interface

• Databases introduce unwanted coupling between services


Refactoring further

• Databases physically separated

• What to do with common data needs?

• Service call or

• Data copy


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

12 ©2015 Derek C. Ashmore, All Rights Reserved

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


Agenda



and Patterns

Packaging Options



Summary / Q&A


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


Micro services are not about size


….. Micro services are about having a single business purpose!

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)

https://github.com/Derek-Ashmore/Insanity

http://cxf.apache.org/docs/failoverfeature.html

http://docs.spring.io/spring-batch/trunk/reference/html/retry.html

http://hc.apache.org/httpcomponents-client-ga/tutorial/html/fundamentals.html#d5e303

Circuit Breaker


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

• No formal tooling support for this pattern • Best embedded in interface clients / delegates • More information here. • Sample Circuit implementation here.


http://martinfowler.com/bliki/CircuitBreaker.html

https://github.com/Derek-Ashmore/CircuitBreaker

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 • Tooling Support:

– JMS Api (easy API – many use natively) – Spring JMSTemplate or RabbitTemplate (producer)

http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/jms.html

http://docs.spring.io/spring-amqp/api/org/springframework/amqp/rabbit/core/RabbitTemplate.html

http://docs.spring.io/spring-amqp/api/org/springframework/amqp/rabbit/core/RabbitTemplate.html

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


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 micro services directly to the browser


Expiring Cache


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


https://msdn.microsoft.com/en-us/library/dn589799.aspx

https://code.google.com/p/guava-libraries/wiki/CachesExplained

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


Custom Rollback


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

• More information here



Agenda



and Patterns

Packaging Options



Summary / Q&A


Packaging Support

• Micro services 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


Package Once, Run Anywhere!

Why Docker?

• 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!


https://hub.docker.com/



Agenda



and Patterns

Packaging Options



Summary / Q&A


Cross-cutting Concerns

• Transaction tracking

• Security

• Contract Testing

• Same as traditional applications

– Health checks

– Logging consolidation

– Performance measurement


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


https://github.com/Derek-Ashmore/RequestCorrelationSlf4J

https://github.com/spring-projects/spring-boot/issues/2343

Security


Security (continued)

• Keep User-level security to the UI

• Micro-service 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


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)


http://hc.apache.org/httpcomponents-client-4.4.x/index.html

http://www.soapui.org/

http://activemq.apache.org/how-to-unit-test-jms-code.html

http://activemq.apache.org/how-to-unit-test-jms-code.html

Agenda



and Patterns

Packaging Options



Summary / Q&A


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


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 micro service 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 micro services 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 micro services

• 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

• Micro services reading list – http://www.mattstine.com/microservices

• Microsoft’s Cloud Design Patterns – https://msdn.microsoft.com/en-us/library/dn600223.aspx

• Moneta Java micro service example – https://github.com/Derek-Ashmore/moneta

• This slide deck – http://www.slideshare.net/derekashmore


http://www.mattstine.com/microservices

http://www.mattstine.com/microservices











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/


May 14-15, 2015 http://www.chicagocoderconference.com/

http://www.derekashmore.com/

http://www.linkedin.com/in/derekashmore

https://twitter.com/Derek_Ashmore

https://twitter.com/Derek_Ashmore






http://dvtpress.com/



http://www.amazon.com/gp/product/0972954880/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0972954880&linkCode=as2&tag=dvtpresscom-20





microservices for java architects (indianapolis, april 15, 2015)

Technology

micro services large

micro services summary

service team

dumb routes

github https

smart routes esb routes

support concerns

stereo system