a tale of two microservices
TRANSCRIPT
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
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 ….
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 concepts and help in making sound design decisions.
What is this talk about
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
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
Coupling
Services that interact with others suffer differents types of coupling
Time (synchronization)
Location (binding)
Knowledge (schema)
Control (orchestration)
Context (transactions)
State (persistence)
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
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
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
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
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
Event based communication
Asynchronous signaling by means of events
Events != messaging
log files anyone?
No global transactions
No coupling
No shared state
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
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)
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 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
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/