Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Why you should never build Microservices - and why we do it

No description
by

Martin Larsen

on 22 May 2018

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Why you should never build Microservices - and why we do it

Why you should never build Microservices...
and why we do it anyway

Virtual Waiting Room Service
Waiting Room
Support
Subscription
Reporting
Fraud
Forecasting
Monolith
Microservices
...
...
UI Layer
Business Layer
Data Layer
Database
mostly it is about the
promise
of
decoupled
and
independent
services
Why are Microservices so
appealing
?
Is it
valuable
?
What are the
trade-offs
?
Any
pitfalls
?
Is it
valuable
?
How to
scale
the development
teams
working
on a
single product
?
Cross functional autonomous teams
We are a
small team
, can we
benefit
from Microservices?
Yes, but
Do you have special requirements for:
scaling
,
availability &

reliability
,
technology
?
Erhh, what
trade-offs
?
Development
Opperations
Test and debugging
Pitfalls
you say?
Requires
skilled
people
Be aware of the
distributed monolith
Embrace
eventually consistency
Your
organization
may need to
change
Your
organization
may need to
change
Get to know your
domain
and
bounded contexts
Imperfection
MonolithFirst
Think
bounded contexts
into the architecture
UI Layer
Business Layer
Data Layer
Database
API/Controller
Business Layer
Data Layer
Database
UI Layer
First things,
first
Build and deployment
pipeline
Setup and automize
development environments
Logging
and
monitoring
Choose your
technology
carefully
Have options for
asynchronous messaging
Enjoy!
It's
amazing
Identify your
bounded contexts
and
core domain
Where does it
hurt
Key
services
Low risk
services
New
requirements
real
value
talks.com
twitter: real
value
talks
ml@real
value
talks.com
Build/deployment pipeline
Bootstrapping
Projects
Installation Scripts
Repositories
APIs
Serialization
DTOs
Asynchronous Messaging
REST
Multiple Programming Languages
Tools
Frameworks
Service and data stores
Debugging
Versioning
Availability
Redundancy
IO Latency/Errors
Multiple services
Can't just hit 'debug'
Can't run everything locally
Environments to support
test and debug
Unit test are less valuable
Integration tests
Site Reliability Engineering
Chaos Engineering
Multiple Services
Technology (e.g. containers/cloud)
Logging
Distributed Tracing
Monitoring
A lot more error cases
IO Errors/Latency
Troubleshooting
Transition to devops
Availability
and
reliability
99.9% x 99.8% x 99.7% x 99.3% =
98.7%
4.7 days downtime / year
Full transcript