Microservices for Java Architects (Chicago, April 21, 2015)

Microservices for Java Architects

Given by Derek C. Ashmore

April 21, 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.amazon.com/gp/product/0972954880/ref=as_li_ss_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0972954880&linkCode=as2&tag=dvtpresscom-20

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 microservices

Design Considerations

and Patterns

Packaging Options

Cross-cutting concerns

When to use microservices

Summary / Q&A


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


Microservices organize by domain

• Silo by business competency

• Divide and Conquer

• How to divide is the hard part


Microservices 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 Microservices

• 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


Alternate Database Strategy

• Centralized databases are hurdles for MS

– i.e. multiple apps use the same db

• MS-Central DB compromise

– Data items only maintained by *one* service

• All other services/apps consider that data item read-only

• Helps data corruption investigations


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

13 ©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


Microservices are not about size


….. Microservices 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 microservices 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


Context Independence

• No context assumptions

– Think in terms of a stereo system

• 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


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



Special Problems

• Versioning – Issues same as more traditional applications

– “Breaking” vs. “Non-Breaking” changes • Feature “additions” usually are “Non-Breaking”

• Trend away from breaking changes

– Versioning is a last result • It greatly increases number of contract tests

• Backward compatibility not always obvious to developers

• Prefer header versioning to URL versioning

• Explicitly error out for versions no longer supported

• More info here


http://martinfowler.com/articles/enterpriseREST.html#versioning

Special Problems (continued)

• External Calls to 3rd Party Products

– Wrap external interfaces with a separate service

– Product upgrades or changes should only affect the interface service

– Log all requests/responses


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


Agenda



and Patterns

Packaging Options



Summary / Q&A


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)


Spring Boot Actuator

• Actuator automatically adds endpoints

– Health (needs configuration)

– Metrics

– Mappings

– Trace

– Env


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/



Sample Java/EE Microservice

• Moneta – Greek goddess of ‘memory’ – Open source: https://github.com/Derek-Ashmore/moneta

• Objective: – Provide a RESTful Web Service interface to a relational database

• Feature set: – Provides generic ‘core’ services – Returns Json-formatted data – Supports startRow and maxRows query options – Supports a security call-out – Built-in Dropwizard, Spring Boot, and War-file deployments

• Sample contract spec – currently read-only (writes in progress)

– /moneta/topics – lists ‘topics’ of information • E.g. – Topic Customer configured

– /moneta/topic/customers?startRow=5&maxRows=25 – /moneta/topic/customer/111-222-333






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

• 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


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


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

• Exposing MS to the browser – Causes performance issues – Use Back-ends for Front-ends – Keep MS traffic behind the firewall and on a fast

network


Why Now?

• SOA an old idea • Virtualization and Cloud advances (e.g. Docker, AWS,

etc.) – Less dependent on server set-up

• Hardware cheaper than it’s ever been – We’re not as concerned with the extra process overhead

for MS

• Infrastructure Automation advances – Additional tooling support(e.g. Chef or Puppet) – Easier to manage larger numbers of deployments

• Can you think of other possible reasons?


Future Directions

• What about Jigsaw?

– Java platform support for modularity

– Coming with Java9 (rumors are 2016)

• Early release is available

– Compared to Microservices

• More limited scaling flexibility

• More limited technical stack

• Chief benefit over MS is reduction in process memory – Less important as memory is cheaper these days


Future Directions

• What about OSGi? – OSGi supplies modularity to JVM

– Compared to Microservices • More limited scaling flexibility

• More limited technical stack

• Chief benefit over MS is reduction in process memory – Less important as memory is cheaper these days

– Low adoption to date • Jobs oscillate around 0.01% (indeed.com)

• Google Trends shows steady decline


Future Directions (continued)

• Trend toward product releases designed to be deployed as microservices

– Already seeing increase on GitHub

– Takes PAAS to a new level

• Will Microservices become main stream?

– Too early to tell


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


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

https://github.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 (Chicago, April 21, 2015)

Technology

Transcript of Microservices for Java Architects (Chicago, April 21, 2015)