Microservices for Architects - Atlanta 2018-03-28

Microservices for Architects
A Focus on Why
Given by Derek C. Ashmore
March 28, 2018
©2018 Derek C. Ashmore, All Rights Reserved 1

Who am I?
• Professional Geek
since 1987
• Java/J2EE/Java EE
since 1999
• AWS since 2010
• Specialties
• Refactoring
• Performance
Tuning
• Yes – I still code!

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

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

Microservices Application Architecture
• Separate Databases
• Eventual Consistency
• More network activity

Faster Delivery to Market
• High Deployment Rates
– Amazon = 23,000/day
– Netflix = 5,500 / day
• Business Benefits
– New features delivered more
quickly
– Quicker reaction to competitors
actions
• Combined with
– Continuous Delivery
– DevOps

Microservice Reuse

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

Better Availability and Resiliency
• Fault tolerance built in
– Reaction to failure part of the
design
– Failures designed to be localized
• Requirements for Resiliency
– Identify non-essential features
• Gogo and Twitter
– Context Independent Design

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

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

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

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

Challenges for Microservices
• More to manage
– More deployables
– More dependencies
– More complex deployments
• Contract design critical
– Quality Matters
– Minimize breaking changes
• Paradigm shift for managers too

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
The “What”
and “Why” of
microservices
Design
Considerations
and Patterns
Packaging
Options
Cross-cutting
concerns
When to use
microservices
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

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

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
– Service Call Mediator

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

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)

Service Call Mediator
• 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

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

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
• Not comprehensive solution
– Interruption usually causes inconsistent data
• 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

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
The “What”
and “Why” of
microservices
Design
Considerations
and Patterns
Packaging
Options
Cross-cutting
concerns
When to use
microservices
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

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!

Sample 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
The “What”
and “Why” of
microservices
Design
Considerations
and Patterns
Packaging
Options
Cross-cutting
concerns
When to use
microservices
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

Security
Note: Secure with service accounts, not end-user permissions

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!

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)

Agenda
The “What”
and “Why” of
microservices
Design
Considerations
and Patterns
Packaging
Options
Cross-cutting
concerns
When to use
microservices
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

Microservices Hype Cycle

Web Interest Over Time

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

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

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?

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 Architects - Atlanta 2018-03-28

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Ähnlich wie Microservices for Architects - Atlanta 2018-03-28

Ähnlich wie Microservices for Architects - Atlanta 2018-03-28 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Microservices for Architects - Atlanta 2018-03-28