4developers 2015: mikroserwisy - szanse, dylematy i problemy - Łukasz sowa

ITERATORSI T E R A T O R S @luksow

Microservices 101opportunities, 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● [email protected]● @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


OpportunitiesWhy 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

XResilience


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


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 FEDEV

BEDEV

DBA OPS QA vs


Cultural advantages (3)

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


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

MongoDBtoken

Redis PostgreSQL PostgreSQL

PostgreSQLidentity

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

Service

Domain

Repositories

Data mappers

Gat

eway

s

Applicationvs

● Well-structured● Requires time to

analyse● Easy to maintain● Longer

● Unstructured● Understandable

at a glance● Hard to maintain● Much shorter


Size & structure - exampleName 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


ProblemsDistributed 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-marketInternal API

External API


Frontend

● No microservices solution for frontend● Visual coherency coupling→

● Monoliths (ex. SPA)● Fragments


Conclusionstldr;


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● [email protected]● @luksow

Questions?

4developers 2015: mikroserwisy - szanse, dylematy i problemy - Łukasz sowa

Software

t o r s

architectureiteratorsi

soundclouditeratorsi

balanceriteratorsi t

luksowiteratorsi t e

microservicesiteratorsi

luksowcultural advantages

protocols communication