Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
A Tale of Two Microservices
Pablo Chacin
@pablochacin
Who is talking
20+ years experience
CTO of a startup
PhD in Distributed Systems
Software Architect
All things backend nut
...
Most of the industry feels like …
But this time we are going to use microservices
We have this new project, with tight dea...
But things are more likely to end like this
Are we talking about the same?
So, I’m doing this
microservices
stuff ...
Yeah, you mean
REST api and
containers,
right?
This is not an ideological
debate
It is a journey to explore the
two dominant microservice
approaches
Expect to clarify co...
Microservice Architecture
describes a particular way
of designing software
applications
There are certain common
character...
Just SOA by another name?
Complex applications are
composed of small,
independent services
communicating with each
other u...
Decoupled? That’s just like your opinion, man
Coupling
Services that interact with
others suffer differents types of
coupling
Time (synchronization)
Location (binding)
...
Exactly, what could possibly go Wrong?
Law of conservation of complexity
“When we break big things
into small pieces we
invariably push the
complexity to their
i...
What we can learn from the (recent) past
“I predicted that in the next
few years all the suite of
WS-* standards will be r...
How to decouple services?
Microservices - Services the Unix Way
“Write programs that do one
thing and do it well. Write
programs to work together.
W...
Know your services
A Service is the authority for
a given business capability
everywhere:
Owns of all the data that
suppor...
Service boundaries
Define service data
boundaries so that
consistency can be achieved
within one service but is not
necess...
Event based communication
Asynchronous signaling by
means of events
Events != messaging
log files anyone?
No global transa...
Sagas: distributed coordination without transactions
A coordinator of long-running
processes
Subscribe to relevant events
...
One brief example
A typical order fulfillment system
(source: Microservices: It’s not (only) the size that matters, it’s (also) how you use ...
An example
(taken from Microservices: It’s not (only) the size that matters, it’s (also) how you use them by Jeppe
Cramon)
Complex Service UI Integration
(taken from Microservices: It’s not (only) the size that matters, it’s (also) how you use t...
I strongly recommend
reading “Microservices:
It’s not (only) the size
that matters, it’s (also)
how you use them”, a
serie...
Conclusions
“Life is pain. Anyone
saying differently is
selling something”
Iñigo Montoya
Questions? … Thanks!
Nächste SlideShare
Wird geladen in …5
×

A tale of two microservices - Pablo Chacin

407 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Daten & Analysen
  • Als Erste(r) kommentieren

A tale of two microservices - Pablo Chacin

  1. 1. A Tale of Two Microservices Pablo Chacin @pablochacin
  2. 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. 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. 4. But things are more likely to end like this
  5. 5. Are we talking about the same? So, I’m doing this microservices stuff ... Yeah, you mean REST api and containers, right?
  6. 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. 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. 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. 9. Decoupled? That’s just like your opinion, man
  10. 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. 11. Exactly, what could possibly go Wrong?
  12. 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. 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. 14. How to decouple services?
  15. 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. 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. 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. 18. Event based communication Asynchronous signaling by means of events Events != messaging log files anyone? No global transactions No coupling No shared state
  19. 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. 20. One brief example
  21. 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. 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. 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. 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. 25. Conclusions “Life is pain. Anyone saying differently is selling something” Iñigo Montoya
  26. 26. Questions? … Thanks!

×