Microservices is one of the hottest technology trends nowadays, and also one that brings the more vehement arguments regarding of what a microservice is and what's the proper way to implement them. Underlying these apparently irreconcilable arguments there is a fundamental difference in terms of the philosophy and architecture of microservices: should they be coarse level business components exposing an API or should they actually integrate all layers up to the UI? Should they connect by api call or should be event based? In this talk we explore these two approaches, their differences and also the common concepts with the intention to clarify them and help in making sound design dessions.

1. A Tale of Two Microservices
Pablo Chacin
@pablochacin

2. Who is talking
20+ years experience
CTO of a startup
PhD in Distributed Systems
Software Architect
All things backend nut
Bare-hand developer (have an
issue with frameworks)
Retro-futuristic technology
observer

3. Most of the industry feels like …
But this time we are going to use microservices
We have this new project, with tight deadlines
And we are going to rule ….

4. But things are more likely to end like this

5. Are we talking about the same?
So, I’m doing this
microservices
stuff ...
Yeah, you mean
REST api and
containers,
right?

6. This is not an ideological
debate
It is a journey to explore the
two dominant microservice
approaches
Expect to clarify concepts and
help in making sound design
decisions.
What is this talk about

7. Microservice Architecture
describes a particular way
of designing software
applications
There are certain common
characteristics
There is no precise definition
of this architectural style
Martin Fowler
Back to the basics
Independently deployable
Organized around Business
Capabilities
Smart endpoints and dumb
pipes
Decentralized Governance
Decentralized Data
Management
Infrastructure Automation

8. Just SOA by another name?
Complex applications are
composed of small,
independent services
communicating with each
other using APIs.
These services are small,
highly decoupled and focus
on doing a small task

9. Decoupled? That’s just like your opinion, man

10. Coupling
Services that interact with
others suffer differents types of
coupling
Time (synchronization)
Location (binding)
Knowledge (schema)
Control (orchestration)
Context (transactions)
State (persistence)

11. Exactly, what could possibly go Wrong?

12. Law of conservation of complexity
“When we break big things
into small pieces we
invariably push the
complexity to their
interactions”
Michael Feathers
https://michaelfeathers.silvrback.com/microservices-until-macro-complexity

13. What we can learn from the (recent) past
“I predicted that in the next
few years all the suite of
WS-* standards will be re-
invented for micro services,
and it will be the fourth time
I have seen such a set of
standards being re-
invented” - Greg Young

14. How to decouple services?

15. Microservices - Services the Unix Way
“Write programs that do one
thing and do it well. Write
programs to work together.
Write programs to handle
text streams, because that
is a universal interface”
Doug McIlroy

16. Know your services
A Service is the authority for
a given business capability
everywhere:
Owns of all the data that
support this business
capability
Enforces business rules
Is autonomous: does not
rely on any other service

17. Service boundaries
Define service data
boundaries so that
consistency can be achieved
within one service but is not
necessary between services
Most transactionality
problems can be solved by
looking at the use case and
re-evaluating the consistency
thesis

18. Event based communication
Asynchronous signaling by
means of events
Events != messaging
log files anyone?
No global transactions
No coupling
No shared state

19. Sagas: distributed coordination without transactions
A coordinator of long-running
processes
Subscribe to relevant events
from multiple services
Keep process’ progress state
Triggers new events to drive
process work flow
Emits compensating events
to handle failures

20. One brief example

21. A typical order fulfillment system
(source: Microservices: It’s not (only) the size that matters, it’s (also) how you use them by Jeppe Cramon)

22. An example
(taken from Microservices: It’s not (only) the size that matters, it’s (also) how you use them by Jeppe
Cramon)

23. Complex Service UI Integration
(taken from Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 5 by
Jeppe Cramon)
Traditional service mashups
just shifts service coupling
one layer up to to UI
If services own data
everywhere, they must
supply also a display of this
data
Platform specific apps (IOS,
Android) poses a challenge

24. I strongly recommend
reading “Microservices:
It’s not (only) the size
that matters, it’s (also)
how you use them”, a
series of articles by
Jeppe Cramon
Kudos
https://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-matters-its-
also-how-you-use-them-part-1/

25. Conclusions
“Life is pain. Anyone
saying differently is
selling something”
Iñigo Montoya

26. Questions? … Thanks!