A Tale of Two MicroservicesPablo Chacin@pablochacin

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

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

Decoupled? That’s just like your opinion, man

Coupling

Services that interact with others suffer differents types of coupling

Time (synchronization)

Location (binding)

Knowledge (schema)

Control (orchestration)

Context (transactions)

State (persistence)

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

How to decouple services?

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

One brief example

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/

Conclusions

“Life is pain. Anyone saying differently is selling something”

Iñigo Montoya

Questions? … Thanks!