microservices

from monolith to microservices

Kevin Buckley

coder at Chatham Financial

caveats…

we’ll be focusing mainly on the coder’s perspective, not the devops

perspective

most of this work and ideas aren’t mine. I work with a whole bunch of

great people at Chatham Financial in Kennett Square, PA (25 minutes

from Wilmington)

https://github.com/chatham

http://www.chathamfinancial.com

https://chatham.tech

@chathamfintech

what we’ll talk about

the monolith

what’s a microservice?

path to microservices (successes and struggles)

value we got

the monolith

single application that grew over time that got a bit unwieldy

over time in the monolith…

the object structure grew

the number of coders grew

coding became slower

regression testing took more time

identifying performance bottlenecks got harder

technology progression stopped

build times got slower

what’s a microservice

it’s a unit of code exposed over a service that:

loosely-coupled

one concern

independent

Derivative/specific version of SOA

path to microservices

REST over HTTP to guide product rather than project based services

agile approach (small changes to how we coded). we’ll go over 4 steps:

1. Common Components

2. New Service

3. Refactor Clients

4. Service Tests

5. Refactor Data

path to microservices

1. Common Components: first make it easier to build microservices by first

refactoring cross cutting concerns into re-usable components:

central config stats gatheringservice

communication

etc…monitoring swagger plugin

path to microservices

2. New Service

picked a business capability in our monolith. start a new service using our new

components.

caveat: we didn’t do significant refactoring of the code at first, it was more of a

straight port from the app to the service.

cards

simulation

runner

… …

…

…

cards

simulation

runner

… …

…

…

simulation

service

simulation

runner

path to microservices

3. Refactor Clients: refactor monolith and clients to use this new service

• you’ll have code duplication as you convert

• use run-time switches to fail-back in case something goes wrong

(http call)

let’s look at some code

cards

simulation

runner

… …

…

…

simulation

service

simulation

runnerswitch

path to microservices

4. Service Tests: Automated tests for the new service allows

for future refactoring

Testing Approaches:

BDD – behavior driven design (given/when/then) using a

cucumber framework

write a wrapper for CURL that has assertions on what you expect the

results to be

POSTMAN

path to microservices

4. Refactor Data: Now that data access is isolated to the

microservice, refactoring your data store is much easier.

Different approaches for each microservice:

• Refactor existing SQL tables

• Move to a document data store

• Put in a caching layer

things to keep in mind

“right-sizing” the service.

too small = spaghetti service calls/dependencies

too big = same problem as the monolith

port exhaustion is easy to run into under load

make coding AND deploying a service easy

how to deal with lower level services changing

value we got

able to support way more developers with fewer

development bottlenecks than before

deploying small changes is easier

initially provided a much simpler “hot-fix” process

leads us to continuous delivery

easier to pinpoint performance bottlenecks and fix them

lower risk changes to production

discussion

Can anyone else share stories of refactoring a monolith?

resources

The most used resource was all the people I work with at Chatham

Financial. To remember all the fancy words though, I read the links below:

http://martinfowler.com/articles/microservices.html

http://thenewstack.io/springone-2gx-conference-managing-migrating-monoliths-mud

https://auth0.com/blog/2015/09/04/an-introduction-to-microservices-part-1/

http://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html