Microservices for java architects coders-conf-2015-05-15

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

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 ©2015 Derek C. Ashmore, All Rights Reserved 5

Traditional Java EE Application Architecture • Like a layer cake • Highly cohesive • Defined dependencies • Deployed as one unit (war/ear) • Limited Scalability • Code Size ©2015 Derek C. Ashmore, All Rights Reserved 6

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 ©2015 Derek C. Ashmore, All Rights Reserved 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 10©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 ©2015 Derek C. Ashmore, All Rights Reserved 11

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 ©2015 Derek C. Ashmore, All Rights Reserved 12

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 15

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 16

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 17

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 ©2015 Derek C. Ashmore, All Rights Reserved 19

Retry Pattern ©2015 Derek C. Ashmore, All Rights Reserved 20 • 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. ©2015 Derek C. Ashmore, All Rights Reserved 22

Dispatch via Messaging ©2015 Derek C. Ashmore, All Rights Reserved 23 • 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)

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 24

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 26

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 28

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 29

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 ©2015 Derek C. Ashmore, All Rights Reserved 31

Packaging Support • Microservices are deployed as a process – For Java, embedded containers are easy – Spring Boot – Dropwizard • Docker – standardizes the process deployment and environment ©2015 Derek C. Ashmore, All Rights Reserved 33

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) ©2015 Derek C. Ashmore, All Rights Reserved 34

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 ©2015 Derek C. Ashmore, All Rights Reserved 35

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 36©2015 Derek C. Ashmore, All Rights Reserved 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! ©2015 Derek C. Ashmore, All Rights Reserved 37

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 ©2015 Derek C. Ashmore, All Rights Reserved 39

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 ©2015 Derek C. Ashmore, All Rights Reserved 40

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

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 May 14-15, 2015 http://www.chicagocoderconference.com/

Microservices for java architects coders-conf-2015-05-15

More Related Content

Viewers also liked

Similar to Microservices for java architects coders-conf-2015-05-15

Recently uploaded

Microservices for java architects coders-conf-2015-05-15