microservices rule

1. microservices
from monolith to microservices
Kevin Buckley
coder at Chatham Financial

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

3. what we’ll talk about
the monolith
what’s a microservice?
path to microservices (successes and struggles)
value we got

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

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

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

7. 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 gathering
service
communication
etc…monitoring swagger plugin

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

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

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

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

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

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

14. discussion
Can anyone else share stories of refactoring a monolith?

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