Microservices 101 - Opportunities, Dilemmas and Problems Explained

ITERATORSI T E R A T O R S @luksow
Microservices 101
opportunities, dilemmas and problems
Łukasz Sowa, 4Developers 2015

Hi, I'm Łukasz
●
Co-founder, engineer @ Iterators (http://iterato.rs)
●
Highly concurrent & distributed systems
●
Pizza, beer & football lover
●
http://luksow.com
●
contact@luksow.com
●
@luksow

What's in it for you?
●
Learn
– What are microservices?
– Why they might be useful?
– What questions do they bring up?
– What's hard about them?
●
Takeaways
– Feel enthusiastic but cautious about microservices
– Be able to design your next project using microservices

What are microservices?
●
Architectural style (MSA)
●
System is composed of multiple services
– Small*
– Independently deployed
– Communicate using (lightweight) protocols
– Organized around business capabilities
●
Bounded Context (DDD) or Single Responsibility
Principle (OO) implemented in architecture

Why? Why now?
●
Post-SOA (or SOA done right?)
●
DevOps revolution (provisioning, deployment)
●
Cheap hardware
●
Existing systems got too big and too boring?
●
Innovation market got immensely demanding
(Netflix, Gilt, Tumblr, Amazon, SoundCloud)

Let's design!
Design a system that allows users to login/register using FB, email-password or
codecard. Authenticated user can subscribe to different events from BTC
markets (ex. rate changed, volume over N, ask below M etc.) and get real-time alerts
about them. Make sure to gather relevant business metrics.
auth-fb auth-pass auth-codes
btc-users
btc-ws
identity
metrics
session
token
frontend
btc-market
load balancer

Opportunities
Why people love microservices?

Technical advantages
●
Horizontal scaling performance→
●
Designing for failure resilience→
btc-users
btc-ws
identity
metrics
session
token
frontend
btc-market
load balancer
btc-wsbtc-ws
Scaling
X
Resilience

Cultural advantages (1)
Any organization that designs a system (defined
more broadly here than just information systems)
will inevitably produce a design whose structure is
a copy of the organization's communication
structure.
Melvin Conway, How Do Committees Invent, 1968

●
Siloed teams vs cross-functional teams
●
Less communication overhead
●
Business-oriented teams – microbusinesses
●
The True Way of (scrum) team scaling
●
Agility + autonomy → short time-to-market
MGR UX
FE
DEV
BE
DEV
DBA OPS QA vs

●
Easy to understand
●
Dispose/rewrite vs refactor
●
Polyglot environment, better tools utilization
●
Mythical reusability?
●
Fun!

Dilemmas
Decisions, decisions, decisions...

Communication, protocols
●
Communication - most important MSA concern
●
Microservices ≠ REST
●
Plethora of possibilities
– Universal: REST+JSON/XML, MQs, binary TCP/UDP, ... simple, decoupled,→
polyglot but low-level, full of boilerplate, possible code duplication
– Platform-specifc: Akka, Finagle, … easier to code & maintain, code reuse→
but tightly coupled, platform-dependant, not polyglot
●
Prefer universal & lightweight (UNIX - smart endpoints, dumb pipes)
●
Microservices are mostly REST
●
Remember about Postel's law

Synchronous vs asynchronous
●
Request-response
●
ASAP response
●
“Asking”
●
Fail-fast
●
Easy to reason about
●
Timeouts?
●
Don't scale
Ex. REST, ...
●
Message passing
●
Deferred processing
●
“Telling”
●
Unnatural
●
Complicated, hard to debug
●
Recovering from failures
●
Scale
Ex. WebSockets, MQs, Akka,
UDP, ...

Protocols in action
btc-users
btc-ws
identity
metrics
session
token
btc-market
REST/JSON WebSockets
REST/JSON Akka
AkkaHTTP Keep-Alive

Guarantees
●
What guarantees do you need?
– What's the cost of a single message being lost?
– What happens if system is in inconsistent state?
– …
●
No ACID (atomicity, consistency, isolation, durability)
●
But CAP theorem (consistency, availability, partition tolerance)
●
Eventual consistency, 2PC, 3PC, Paxos & others are your friends
now
●
What do you need? What can/cannot you afford?
●
And no, you can't have everything

Shared vs private data stores
●
Source of truth
●
Strong
contract/protocol
●
Convenient
●
Coupling
●
Don't scale
●
Ownership issues
●
Service becomes an
abstraction over DS
●
Polyglot persistence
●
Decoupling
●
Scale
●
Truth is distributed
●
Façade issues
●
Recommended

Private data stores
btc-users
btc-ws
identity
metrics
session
token
btc-market
MongoDB
Redis PostgreSQL PostgreSQL
PostgreSQL
MongoDB
Event journal

Shared data stores
btc-users
btc-ws
metrics
session
btc-market
MongoDB
token
Redis PostgreSQL PostgreSQL
PostgreSQL
identity
MongoDB
Event journal

Size & structure
●
How big is microservice?
– ~100 lines rule is a lie
– Up to a couple of thousands LOC in most cases
– Rule: as short as possible but as big as necessary
●
Clean & structured vs short & hacky
Resources
Service
Domain
Repositories
Data mappers
Gateways
Applicationvs
●
Well-structured
●
Requires time to
analyse
●
Easy to maintain
●
Longer
●
Unstructured
●
Understandable
at a glance
●
Hard to maintain
●
Much shorter

Size & structure - example
Name Structured? LoC / eLoC
auth-fb Yes 215 / 189
auth-pass Yes 301 / 258
auth-codes Yes 337 / 299
identity No 77 / 66
session No 48 / 43
token Yes 182 / 167
metrics No 160 / 150
btc-ws No 155 / 140
btc-users Yes 153 / 141
btc-market No 51 / 40
TOTAL 5 Yes / 5 No 1679 / 1493

Code sharing
Sometimes the same code is required in two or
more services – how to share it?
●
Shared library coupling, not polyglot→
●
Nanoservice maintenance burden, performance→
●
Copy-paste duplication, more code to maintain→
No good answer here (3rd is the most popular)

Polyglot vs monoculture
●
Tower of Babel problem
●
Unmaintainable code rewrites costs→ →
●
Multiple platforms lots of ops costs→ →
●
But you want to use best tools and have fun
●
Make recommendations about defaults – and innovate from there
– “We use Scala for such tasks unless there's a better solution”
– “PostgreSQL is our default database because XYZ”
– “We prefer Redis with Rediscala library for caching”

Testing
●
Don't test
– “This big” correctness rule
– Run in production, rollback on problems
●
Test – good ol' style
– Unit tests, integration tests, component tests, contract tests, end-to-
end tests
– Favour black-box tests
●
Test – in a distributed system way
– No way to really do that
– Chaos monkey

Problems
Distributed systems are hard

Operations
●
Infrastructure, different machine utilization strategies
●
Provisioning
●
Deployment pipeline
●
Monitoring
●
Service discovery & confguration management
●
Code templates with boilerplate
●
Close collaboration of developers & operations DevOps→
●
Costs time & money

Complexity
●
Complexity never goes away
●
Code complexity communication complexity→
●
It's easy to make (worse) spaghetti there as well
●
MSA requires more code to be written (boilerplate)
●
More work at the initial stage (foundations)
●
Avoid nanoservices maintenance burden→

Distributed computing
●
Fallacies of distributed computing (Peter Deutsch, 1994)
– The network is reliable
– Latency is zero
– Bandwidth is infnite
– The network is secure
– Topology doesn't change
– There is one administrator
– Transport cost is zero
– The network is homogeneous
●
Ex. RPC (vs local call)
– It can fail
– It can timeout (and still execute successfully!)
– It is a couple of magnitudes slower

Contracts
●
What API should I have?
●
Who are my collaborators?
●
How can I contact them?
●
Make product owners defne API & protocols
●
Service discovery & confguration management (ex.
ZooKeeper, Consul.io)
●
Think about help from providers (libraries, stubs, ex.
Swagger, pact)

Versioning
●
How to handle changes?
●
How to handle external (ex. API) changes?
●
Keep multiple versions in production
●
Observe their behaviour
●
Let the load balancers do the heavy lifting
●
Embrace it to do A/B testing

Monitoring, metrics
●
Monitor/measure all the things!
●
(You should be doing it in monolith anyway)
●
System metrics, health monitoring
●
Business metrics
●
Keep yourself informed about anomalies
●
Observe analyse react→ →

Logging & debugging
●
How do you debug distributed system?
●
Next to impossible, completely different from
monolith
●
Centralized logging with correlation id and
efficient search (no, grep doesn't work anymore)
●
Tracing whenever possible
●
Again, monitor/measure everything (including
network traffic)

Security
●
Larger network larger attack surface→
●
Ex. internal API leakage
btc-users
btc-ws
identity
metrics
session
token
btc-market
Internal API
External API

Frontend
●
No microservices solution for frontend
●
Visual coherency coupling→
●
Monoliths (ex. SPA)
●
Fragments

Conclusions
tldr;

Is it worth it? When?
●
For problems that microservices likely solve
●
If you're working on a well-funded, innovative
products, in a big teams
●
If you have certain DevOps maturity
●
If you can write proper monoliths
●
If you're not expecting a free lunch

How to start?
●
Try gradually migrating from monolith, don't
start from scratch
●
Make sure you have DevOps capabilities
●
Reorganize teams around features
●
Think in microservices, not in monolith
●
Don't do “new architecture”, “new platform”,
“new languages” all at once

What to remember?
●
Microservices are hard
– Operations
– Complexity
– Distribution
●
But they can be very rewarding
– Team scaling & developer happiness
– Scaling
– Resilience

Thanks!
●
Łukasz Sowa
●
http://luksow.com
●
http://iterato.rs
●
contact@luksow.com
●
@luksow
Questions?

Microservices 101 - Opportunities, Dilemmas and Problems Explained

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (19)

Similar a Microservices 101 - Opportunities, Dilemmas and Problems Explained

Similar a Microservices 101 - Opportunities, Dilemmas and Problems Explained (20)

Último

Último (20)

Microservices 101 - Opportunities, Dilemmas and Problems Explained