Microservice Everything Redux Eng

3/28/2019 Microservices, microservices everywhere
ﬁle:///home/jakub/workspaces/slides/microservices-microservice_everything/slides.html?print-pdf#/ 1/98
MICROSERVICES,
MICROSERVICES,
MICROSERVICES EVERYWHERE
MICROSERVICES EVERYWHERE
Jakub Marchwicki [@kubem]

View Slide

@kubem ~ http://jakub.marchwicki.pl
the 5 why’s of microservices
the 5 why’s of microservices
Microservices?
Microservices?
Microservices?
Microservices?
Microservices?
Why?
Why?
Oh, why?
Oh dear God, why?
Damn it! Why?

View Slide

Software engineer
Chief Mob O cer
Jakub Marchwicki <@kubem>
http://jakub.marchwicki.pl

View Slide

microservices, how it all started?
microservices, how it all started?
All names, characters, and incidents portrayed in this story are ctitious. No identi cation with actual persons (living or
deceased), places, and buildings is intended or should be inferred.

View Slide

on day one there was a lonely architect sitting
on day one there was a lonely architect sitting

View Slide

in a tower made of ivory
in a tower made of ivory
sitting in an uncertainty and sadness

View Slide

and the architect said
and the architect said

View Slide

let there be µservices
let there be µservices

View Slide

let there be small modules
let there be small modules
which have only a single reason to change

View Slide

let the modules communicate
let the modules communicate
over well de ned interfaces

View Slide

let the output of one module
let the output of one module
becomes the input of the other

View Slide

and the architect saw it was good
and the architect saw it was good

View Slide

and the architect called it
and the architect called it
a distributed system

View Slide

and developers seen it
and developers seen it
and it was good

View Slide

and there was evening, and there was morning
and there was evening, and there was morning
(Genesis. 1, 1-25)

View Slide


View Slide

microservices
microservices
— James Lewis and Martin Fowler
“the microservice architectural style is an approach to developing
a single application as a suite of small services, each running
in its own process and communicating with lightweight
mechanisms, often an HTTP resource API

View Slide


View Slide

µservices
µservices
Small business domain
Independent; independently deployed
Running in it’s own process
Managing it’s data
Loosely integrated using common communication protocols

View Slide


View Slide

monolith are bad - mmkey??
monolith are bad - mmkey??

View Slide

microservices are good
microservices are good
Clean code
Single responsibility modules
Faster than monoliths
Easier to manage
Easier to scale
Docker, Docker, Docker, Docker
potentialy
faster to deploy, works faster
independent teams, independent codebases
at this point we should at least mention Docker

View Slide

microservices are good - mmmkey?
microservices are good - mmmkey?

View Slide

(… ) collection of task-oriented or dedicated systems that pool their resources and capabilities
together to create a new, more complex system which offers more functionality and performance
than simply the sum of the constituent systems

View Slide

system of systems
system of systems
(… ) collection of task-oriented or dedicated systems that pool their resources and capabilities
together to create a new, more complex system which offers more functionality and performance
than simply the sum of the constituent systems

View Slide


View Slide

so what can possibly go wrong?
so what can possibly go wrong?

View Slide


View Slide

// Exibit A
+------------------+
+-------------+ | |
| Resources | | |
| service | +------------------+
| |
+-+-------+---+
^ |
| |
| | +----------------+
| | | |
| | | Users |
| | (2) | repository |
| +-----------> | |
| +----------------+
(1)
+
//

View Slide

// Exibit A
+------------------+
+-------------+ | |
| Resources | | |
| service | +------------------+
| +<---------+
+-+-------+---+ (3) |
^ | |
| | |
| | +----------------+
| | | |
| | | Users |
| +-----------> | |
| +----------------+
(1)
+
//

View Slide

// Exibit A
+------------------+
+-------------+ | |
| | (4) | Access control |
| Resources +------------>+ |
| service | +------------------+
| +<---------+
+-+-------+---+ (3) |
^ | |
| | |
| | +----------------+
| | | |
| | | Users |
| +-----------> | |
| +----------------+
(1)
+
//

View Slide

// Exibit A
+------------------+
+-------------+ | |
| | (4) | Access control |
| Resources +------------>+ |
| service | +------------------+
| +<---------+
+-+-------+---+ (3) |
^ | | |
| | | |
| | | +----------------+
| | | | |
| | | | Users |
| | | (2) | repository |
| | +-----------> | |
| | +----------------+
(1) |
+ |
(5)
v
//

View Slide

microservices journey

View Slide

— Christopher Alexander
“A Piecemeal Growth is the process of building something a step
at a time. Each step consists of evaluating the current system,
deciding what should be done next (what should be fixed or
improved) and then adding a piece or making a change.

View Slide

a scoring engine
EXIBIT B
EXIBIT B
-- 2009

View Slide

+-----------------------------------------------+
| |
| +-----------------------------------+ |
| | | |
| | Boundary: SOAP | |
| | | |
| +-----------------------------------+ |
| | | |
| | EJB | |
| | | |
| +-----------------------------------+ |
| |
| |
| +--------+ +-------+ +----------+ |
| | | | | | | |
| | JAX-WS | | JPA | | DROOLS | |
| | | | | | | |
| +--------+ +-------+ +----------+ |
| |
| |
| JBoss 4.2.x |
| |
+-----------------------------------------------+

View Slide

Can you visualize this? A UI?
Webservices are so hard to sell.
business value?
business value?

View Slide

+-----------------------------------------------+
| |
| +--------------------+--------------+ |
| | | | |
| | Boundary: SOAP | JSF | |
| | | | |
| +--------------------+--------------+ |
| | | |
| | EJB | |
| | | |
| +-----------------------------------+ |
| |
| |
| +--------+ +-------+ +----------+ |
| | | | | | | |
| | JAX-WS | | JPA | | DROOLS | |
| | | | | | | |
| +--------+ +-------+ +----------+ |
| |
| |
| JBoss 4.2.x |
| |
+-----------------------------------------------+

View Slide

+-----------------------------------------------+
| |
| +-----------------+-----------------+ | +---------------+
| | | | | | |
| | Boundary: SOAP | REST endpoint | <--------------+ | Dedicated |
| | | | | | mobile |
| +-----------------+-----------------+ | | Single Page |
| | | | | Application |
| | EJB | | | |
| | | | | |
| +-----------------------------------+ | +---------------+
| |
| |
| +--------+ +-------+ +----------+ |
| | | | | | | |
| | JAX+WS | | JPA | | DROOLS | |
| | | | | | | |
| +--------+ +-------+ +----------+ |
| |
| |
| JBoss 4.2.x |
| |
+-----------------------------------------------+

View Slide

Keep separate things
separately
NOTE TO SELF
NOTE TO SELF

View Slide

microservices checklist






View Slide







View Slide

retrospective
retrospective

View Slide

— James Lewis
“ We define libraries as components that are linked into a
program and called using in-memory calls, while services are
out-of-process components who communicate with remote
procedure calls

View Slide

consumer driven contracts
consumer driven contracts
(… ) drives the development of the Provider from its Consumers point of view,
which means consumer describes what and how it wants to receive the
information (in a form of a contract) and then provider implements the service
following the given contract.

View Slide

huge image repository
EXIBIT C
EXIBIT C
-- 2007

View Slide

+--------------------------------------+
| |
| web / controllers |
| |
+-----------+--------------------------+
|
| (1) ^
| |
v | (5)
|
+-------------------------------------+
| |
| application logic |
| |
+--+-------------------------+--------+
| |
| (2) ^ | (4)
| | |
v | (3) v
|
+----------+--+ +------------------+
| | | |
| MySQL | | filesystem |
| | | |
+-------------+ +------------------+

View Slide

can’t work with it
The search function is unbelievably slow
business value?
business value?

View Slide

business as usual
There is
no such thing as
legacy — what can’t be
killed, becomes

View Slide

Proxy
+-----+ +------------------+
| | /* | |
+----------------+--------------------------> | |
| | | | The Old stuff |
| | | | +--------+
| | | | | |
| | | +------------------+ |
| | | |
| | | | Elastic Search
| | | | data push
| | | |
| | | |
| | | +------------------+ |
| | | /search | | |
| | +--------------------------> | | <------+
| | | Elastic Search |
| | | index |
| | | |
+-----+ +------------------+

View Slide







View Slide

retrospective
retrospective

View Slide

Andrew Tanenbaum
— Distributed Systems (2007) - Principles & Paradigms
“(… ) as every parent of a small child knows, converting a large
object into small fragments is considerably easier than the
reverse process.

View Slide

Write through
update query +--------------------------+ +----------------------------------+
-------------------->| update denormalized view |-------->| update persistent (master) store |
+--------------------------+ +----------------------------------+
Write behind
update query +----------------------------------+ +---------------------------+
---------------->| update persistent (master) store |----------->| update denormalized views |
+----------------------------------+ +---------------------------+
Read through
read query +--------------------------+ +---------------------------+
<---------------------| update denormalized view |<--------------| read persistent store |
+--------------------------+ +---------------------------+

View Slide

lessons learned
lessons learned
from
all these projects

View Slide

start small
start small

View Slide

slightly less
distributed systems
monoliths are

View Slide

don’t diagram - trace and visualize
don’t diagram - trace and visualize

View Slide

let the application tell you
where it spends
time

View Slide

automate, automate, automate
automate, automate, automate

View Slide

event a single WAR
cannot be deployed
manually

View Slide

but we’ve already started!
but we’ve already started!
what do our services do when nobody watches?

View Slide


View Slide

distributed computing
Leslie Lamport
— Microsoft mailing list 1987
A distributed system is one in which the failure of a computer you didn’t even know existed can
render your own computer unusable.

View Slide


View Slide

fallacies of distributed computing
fallacies of distributed computing
— 1994 - 1998
(is) a set of assertions made by L Peter Deutsch and others at Sun Microsystems describing false
assumptions that programmers new to distributed applications invariably make

View Slide


View Slide

in other words
in other words

View Slide

network
sucks

View Slide

load balance
load balance
all the things

View Slide

… before choosing a load balancer

View Slide

AWS Elastic Load Balancer
nginx
Ribbon + Eureka
Ribbon + Consul
Kubernetes

View Slide

load balancing
load balancing

View Slide

server-side load balancing
server-side load balancing

View Slide

client-side load balancing
client-side load balancing

View Slide

Client-Side Service Discovery / Load balancing
Service registers itself in a central repository. The repository also
provides an information about other services availability. Other services
request the information and autonomously decide which instances are
called.
Server-Side Service Discovery / Load balancing
Service registers itself in a central repository. Other services access the
repository (single address), which internally forwards the request to an
available instance.

View Slide


View Slide

brewer’s theorem (cap theorem)
brewer’s theorem (cap theorem)
— 1998
(… ) it is impossible for a distributed computer system to simultaneously provide all three of the
following guarantees: Consistency, Availability and Partition tolerance.

View Slide

Consistency
Every read receives the most recent write or an error
Availability
Every request receives a (non-error) response – without the guarantee
that it contains the most recent write
Partition tolerance
The system continues to operate despite an arbitrary number of
messages being dropped (or delayed) by the network between nodes

View Slide

cap + network fallacies
cap + network fallacies

View Slide

either Consistent
or
Available
when Partitioned

View Slide

consistency vs availability
CP
All data is consistent (single store)

View Slide

AP
Data is distributed

View Slide


View Slide

cap + network latencies
cap + network latencies

View Slide

in the absence of partitions, one
has to choose between

View Slide

pacelc theorem
pacelc theorem
— Daniel J. Abadi 2012
Ignoring the consistency/latency tradeoff of replicated systems is a major oversight [in CAP], as it is
present at all times during system operation, whereas CAP is only relevant in the arguably rare case
of a network partition.

View Slide


View Slide

microservices are simple…
microservices are simple…

View Slide

… but ain’t easy
… but ain’t easy

View Slide

questions?
questions?

View Slide

@kubem .
http://speakerdeck.com/kubamarchwicki/microservice-everything-redux-eng
[email protected]
http://jakub.marchwicki.pl/

View Slide

Microservice Everything Redux Eng

Microservice Everything Redux Eng

Jakub Marchwicki

More Decks by Jakub Marchwicki

Other Decks in Technology

Featured

Transcript