A quick introduction to microservices. Given at the January Oakland JUG meetup.

1. @crichardson
Introduction to
Microservices
Chris Richardson
Author of POJOs in Action
Founder of the original CloudFoundry.com
@crichardson
chris@chrisrichardson.net
http://plainoldobjects.com
http://microservices.io

2. @crichardson
About Chris

3. @crichardson
About Chris
Founder of a buzzword compliant (stealthy, social, mobile,
big data, machine learning, ...) startup
Consultant helping organizations improve how they
architect and deploy applications using cloud computing,
micro services, polyglot applications, NoSQL, ...
Creator of http://microservices.io
Organizer of @oakjug - http://bit.ly/ebjava
Co-organizer of http://meetup.com/oakland-scala

4. @crichardson
About Chris - really jet lagged!
I

5. @crichardson
Agenda
The (sometimes evil) monolith
Decomposing applications into services

6. @crichardson
Let’s imagine you are
building an online store

7. @crichardson
Tomcat
Traditional application
architecture
Browser/
Client
WAR/EAR
MySQL
Database
Review Service
Product Info
Service
Recommendation
Service
StoreFrontUI
develop
test
deploy
Simple to
Load
balancer
scale
Spring MVC
Spring
Hibernate
Order Service
HTML
REST/JSON

8. @crichardson
But big, complex, monolithic
applications
big problems

9. @crichardson
Intimidates developers

10. @crichardson
Obstacle to frequent
deployments
Need to redeploy everything to change one component
Interrupts long running background (e.g. Quartz) jobs
Increases risk of failure
Fear of change
Updates will happen less often - really long QA cycles
e.g. Makes A/B testing UI really difficult
Eggs in
one basket

11. @crichardson
Overloads your IDE and
container
Slows down development

12. @crichardson
Lots of coordination and
communication required
Obstacle to scaling
development
I
want to update the
But
the backend is not working
yet!

13. @crichardson
Conflicting resource
requirements
e.g In-memory database/cache vs CPU intensive
algorithm

14. @crichardson
Requires long-term commitment
to a technology stack

15. @crichardson
Agenda
The (sometimes evil) monolith
Decomposing applications into services

16. @crichardson

17. @crichardson
The scale cube
X axis
- horizontal duplication
Z
axis
-data
partitioning
Y axis -
functional
decomposition
Scale
by
splitting
sim
ilar
things
Scale by
splitting
different things

18. @crichardson
Y-axis scaling - application level
WAR
Storefront UI
Product Info
Service
Recommendation
Service
Review
Service
Order
Service

19. @crichardson
Y-axis scaling - application level
Storefront UI
Product Info
Service
Recommendation
Service
Review
Service
Order
Service

20. @crichardson
Product Info
Y-axis scaling - application level
Product Info
Service
Recommendation
Service
Review
Service
Order
Service
Browse Products
UI
Checkout UI
Order management
UI
Account
management UI
Apply X-axis and Z-axis scaling
to each service independently

21. @crichardson
Service deployment options
VM or Physical Machine
Docker/Linux container
JVM/Process
JAR/WAR/OSGI bundle/...
Isolation, manageability
Density/efficiency

22. @crichardson
Partitioning strategies...
Partition by noun, e.g. product info service
Partition by bounded context
Partition by verb, e.g. Checkout UI
Single Responsibility Principle
Unix utilities - do one focussed thing well

23. @crichardson
Partitioning strategies
Too few
Drawbacks of the monolithic architecture
Too many - a.k.a. Nano-service anti-pattern
Runtime overhead
Potential risk of excessive network hops
Potentially difficult to understand system
Something of an art

24. @crichardson
Example micro-service
require 'sinatra'
post '/' do
phone_number = params[:From]
registration_url = "#{ENV['REGISTRATION_URL']}?phoneNumber=#{URI.encode(phone_number, "+")}"
<<-eof
<Response>
<Sms>To complete registration please go to #{registration_url}</Sms>
</Response>
eof
end
Responds to incoming SMS messages
via Twilio

25. @crichardson
More service, less micro
But more realistically...
Focus on building services that make
development and deployment easier
- not just tiny services

26. @crichardson
Real world examples
http://highscalability.com/amazon-architecture
http://techblog.netflix.com/
http://www.addsimplicity.com/downloads/
eBaySDForum2006-11-29.pdf
http://queue.acm.org/detail.cfm?id=1394128
~600 services
100-150 services to build a page

27. @crichardson
There are many benefits

28. @crichardson
Smaller, simpler apps
Easier to understand and develop
Less jar/classpath hell - who needs OSGI?
Faster to build and deploy
Reduced startup time - important for GAE

29. @crichardson
Scales development:
develop, deploy and scale
each service independently

30. @crichardson
Improves fault isolation

31. @crichardson
Eliminates long-term commitment
to a single technology stack
Modular, polyglot, multi-
framework applications

32. @crichardson
Two levels of architecture
System-level
Services
Inter-service glue: interfaces and communication mechanisms
Slow changing
Service-level
Internal architecture of each service
Each service could use a different technology stack
Pick the best tool for the job
Rapidly evolving

33. @crichardson
Easily try other technologies
... and fail safely

34. @crichardson
But there are drawbacks

35. @crichardson
Complexity

36. @crichardson
Complexity of developing a
distributed system
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

37. @crichardson
Multiple databases
&
Transaction management
e.g. Fun with eventual consistency

38. @crichardson
Complexity of testing a
distributed system
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

39. @crichardson
Complexity of deploying and
operating a distributed
system
You need a lot of automation
http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

40. @crichardson
Developing and deploying
features that span multiple
services requires careful
coordination

41. @crichardson
When to use it?
In the beginning:
•You don’t need it
•It will slow you down
Later on:
•You need it
•Refactoring is painful

42. @crichardson
Summary
Modular, polyglot, and
scalable applications
Services developed,
deployed and scaled
independently

43. @crichardson
Questions?
@crichardson chris@chrisrichardson.net
http://plainoldobjects.com http://microservices.io