Łukasz Sowa presented an overview of microservices including opportunities, dilemmas, and problems. Microservices break systems into independently deployable services that communicate via lightweight protocols. This allows for improved scalability and failure resilience but introduces complexity in areas like communication protocols, data management, testing, and operations. While microservices require more upfront work, they can improve developer autonomy and system agility if the team has sufficient DevOps maturity.

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

2. ITERATORSI T E R A T O R S @luksow
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

3. ITERATORSI T E R A T O R S @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

4. ITERATORSI T E R A T O R S @luksow
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

5. ITERATORSI T E R A T O R S @luksow
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)

6. ITERATORSI T E R A T O R S @luksow
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

7. ITERATORSI T E R A T O R S @luksow
Opportunities
Why people love microservices?

8. ITERATORSI T E R A T O R S @luksow
Technical advantages
●
Horizontal scaling performance→
●
Designing for failure resilience→
auth-fb auth-pass auth-codes
btc-users
btc-ws
identity
metrics
session
token
frontend
btc-market
load balancer
btc-wsbtc-ws
Scaling
X
Resilience

9. ITERATORSI T E R A T O R S @luksow
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

10. ITERATORSI T E R A T O R S @luksow
Cultural advantages (2)
●
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

11. ITERATORSI T E R A T O R S @luksow
Cultural advantages (3)
●
Easy to understand
●
Dispose/rewrite vs refactor
●
Polyglot environment, better tools utilization
●
Mythical reusability?
●
Fun!

12. ITERATORSI T E R A T O R S @luksow
Dilemmas
Decisions, decisions, decisions...

13. ITERATORSI T E R A T O R S @luksow
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

14. ITERATORSI T E R A T O R S @luksow
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, ...

15. ITERATORSI T E R A T O R S @luksow
Protocols in action
auth-fb auth-pass auth-codes
btc-users
btc-ws
identity
metrics
session
token
btc-market
REST/JSON WebSockets
REST/JSON Akka
AkkaHTTP Keep-Alive

16. ITERATORSI T E R A T O R S @luksow
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

17. ITERATORSI T E R A T O R S @luksow
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

18. ITERATORSI T E R A T O R S @luksow
Private data stores
auth-fb auth-pass auth-codes
btc-users
btc-ws
identity
metrics
session
token
btc-market
MongoDB
Redis PostgreSQL PostgreSQL
PostgreSQL
MongoDB
Event journal

19. ITERATORSI T E R A T O R S @luksow
Shared data stores
auth-fb auth-pass auth-codes
btc-users
btc-ws
metrics
session
btc-market
MongoDB
token
Redis PostgreSQL PostgreSQL
PostgreSQL
identity
MongoDB
Event journal

20. ITERATORSI T E R A T O R S @luksow
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

21. ITERATORSI T E R A T O R S @luksow
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

22. ITERATORSI T E R A T O R S @luksow
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)

23. ITERATORSI T E R A T O R S @luksow
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”

24. ITERATORSI T E R A T O R S @luksow
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

25. ITERATORSI T E R A T O R S @luksow
Problems
Distributed systems are hard

26. ITERATORSI T E R A T O R S @luksow
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

27. ITERATORSI T E R A T O R S @luksow
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→

28. ITERATORSI T E R A T O R S @luksow
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

29. ITERATORSI T E R A T O R S @luksow
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)

30. ITERATORSI T E R A T O R S @luksow
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

31. ITERATORSI T E R A T O R S @luksow
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→ →

32. ITERATORSI T E R A T O R S @luksow
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)

33. ITERATORSI T E R A T O R S @luksow
Security
●
Larger network larger attack surface→
●
Ex. internal API leakage
auth-fb auth-pass auth-codes
btc-users
btc-ws
identity
metrics
session
token
btc-market
Internal API
External API

34. ITERATORSI T E R A T O R S @luksow
Frontend
●
No microservices solution for frontend
●
Visual coherency coupling→
●
Monoliths (ex. SPA)
●
Fragments

35. ITERATORSI T E R A T O R S @luksow
Conclusions
tldr;

36. ITERATORSI T E R A T O R S @luksow
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

37. ITERATORSI T E R A T O R S @luksow
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

38. ITERATORSI T E R A T O R S @luksow
What to remember?
●
Microservices are hard
– Operations
– Complexity
– Distribution
●
But they can be very rewarding
– Team scaling & developer happiness
– Scaling
– Resilience

39. ITERATORSI T E R A T O R S @luksow
Thanks!
●
Łukasz Sowa
●
http://luksow.com
●
http://iterato.rs
●
contact@luksow.com
●
@luksow
Questions?