The document presents a workshop on microservices using Scala, outlining key concepts, differences from monolithic architectures, and practical applications with tools like Spray, Play, and Akka. It covers topics such as microservices' architecture, deployment strategies, asynchronous processing, and event sourcing, along with relevant metrics for performance measurement. The speakers emphasize various approaches to handling databases, security, and scaling in a distributed system while discussing potential challenges and paradigms in programming microservices.

1. Microservices in Scala
workshop by Iterators
by Jacek Głodek, Łukasz Sowa and Andrzej Michałowski

2. Questions we try to answer today:
• What are microservices?
• What's the difference between them vs monolithic
architectures?
• What are the different flavours of microservices?
• How to use Spray.io, Play and Akka to do
microservices?

3. Agenda
• Short introduction to microservices
• Spec of our system
• "MS backbone - simple microservices with spray.io" talk
• Auth and url collection microservices
• "Asynchronous views and web services with Play and Akka" talk
• Image fetching — reactive deffered job — Play with websockets
• "Eventsourcing - total data immutability with akka persistence" talk
• Voting made with event sourcing
• Ops, testing and monitoring
• Summary

4. Architectures and practices
What architectures are we talking about?!
Don't think MVC, think MVC web-app run on multiple
nodes with load-balancing, memcached cache and
Postgres db.
What practices are we talking about?!
Think TDD, BDD, SOLID, etc.

5. Code and code-base
architecture and practices
• programming paradigms
• TDD, SOLID, BDD, etc.
• Folder structure
• Object naming conventions
• Separation of concerns
• Sharing data in threads

6. Distributed system
architecture
• Interfaces, protocols and
contracts between modules
• System modules
• APIs
• Deployment strategy
• Non-functional guarantees

7. “Microservices”
is a vague term
• multiple small apps with REST/HTTP interface,
• multiple small apps with deferred message
processing
• multiple single-file apps with less than 100 lines of
code
• multiple small apps possibly written in different
languages communicating with each other

8. Microservices
• small single-purpose apps with bounded domain
enabling polyglot programming
+ add your favourite ingredients
+ differences from monolithic architecture
© Marivlada | Dreamstime Stock
Photos & Stock Free Images

9. Microservices vs Monolithic architecture
Deployment units
Monolith Microservices

10. Microservices vs Monolithic architecture
Deployment strategy
Monolith Microservices

11. Microservices vs Monolithic architecture
Coupling
Monolith Microservices
• global variables
• messages
• function calls
• data structures
• shared memory
• multiple levels of indirection
managed with
• SOLID, encapsulation and other practices
• dependency injection, etc.
• different protocols
• shared DB’s
• shared message queues
managed with
• contracts

12. Microservices vs Monolithic architecture
Interfaces vs Contracts
Monolith Microservices
• written with code and shared interfaces
within code packages and libraries
• checked by tests or compilers (?)
• type validations
• api calls defined by the language
• encapsulation, single-responsibility
rule, etc.
Problems:
• meta-programming, monkey-patching,
global state and workarounds.
• spoken / unspoken
• should be defined on “paper”
• defined by protocols, and technologies
used, like:
• http, websockets, RPC, rabbitMQ,
shared MongoDB or Redis, etc. )
Problems:
• changing contract or having no contract
requires changing multiple services.
• multiple API versions without easy
solution for validating consistency

13. Programming microservices

14. Small single purpose code
• Low complexity
• No code-level coupling
with other modules
• “this big” or one
hundred lines of code
• Easy to rewrite
• Rewrite instead of
refactor
• Easy to spot inputs and
outputs
• Still requires readable
logic

15. Relevant metrics
• Measuring business
performance using relevant
metrics
• Visualisation
• Ex. Kamon, custom charts
Ex:
• forms processed,
• mails sent,
• PDF invoices generated
• performance metrics:
• response times
• queue sizes
• ex. New Relic, etc.

16. Continuous deployment with hot
swapping
Having all the metrics:
• You can deploy continuously
• You can test the service by deploying new and old
versions concurrently.
• Given enough fail-safety contracts, you can test in
production
• One service down shouldn’t break whole architecture

17. Polyglot programming

18. Problems and dilemmas

19. Problems and Dilemmas
• synchronous and asynchronous processing
• guarantees and SLAs
• shared and private databases
• making layers of micro services
• bare-metal vs platforms
• data-driven systems, eventsourcing and real-time
messaging

20. Synchronous vs
Asynchronous processing
Synchronous processing
• immediate responses
• fast and hard failure
• “asking”
• request timeouts
• problematic to debug series of request
Ex. chain of HTTP request and getting 200
Success response
Asynchronous processing
• posting jobs to be processed
• tell don’t ask
• fire and forget
• need of pooling or waiting for response
• longer jobs
• failures can be recovered from!
Ex. uploading a video file to be processed
and getting “Video uploaded successfuly”
response.

21. Guarantees and SLA’s
Is clicking like button same as performing bank transfer? Do we really need full
ACID DB for holding chat messages? Will it perform fast enough to serve
thousand of clients concurrently without building whole cluster of DB’s?
100% consistency and synchronicity is not possible to achieve in distributed
system without introducing system wide locks.
System-wide locks affect performance a lot, while we try to achieve reactive and
scalable system.
In microservices we can keep different parts of system with different guarantees
and different approaches

22. Shared vs private databases
Shared database
• pretty strong contract
• convenient for simple domain problems
• easier to maintain
• problems:
• coupling too many services, too deeply.
• can become performance bottle-neck
Private databases
• useful for decoupling and reuse
• useful for performance
• useful for embedding in microservices that abstract
complicated domain models
• difficult to maintain, although can many databases can
work on single db cluster/instance.
• useful for giving microservice authority over some data
• problems:
• data sharding

23. Layers of micro services
frontend, public facing micro services,
background workers and services

24. Layers of micro services
frontend issues
• CORS (Cross Origin Resource Sharing)
• Rendering of HTML: server-side or in javascript
• Moving caches to CDN
• Keeping modularity and reusability also on the frontend side
• One backend microservice failure shouldn’t break whole frontend.

25. Layers of micro services
user facing services issues
• CORS
• Versioning of API
• Authentication
• Caching
• Loadbalancing
• Security

26. Layers of micro services
internal services
• Security
• Scalability
• Monitoring for failures
• Keeping the data consistent
• Garbage-in garbage-out

27. Platform abstraction level
bare-metal servers vs platforms
Higher level framework = more difficult polyglot
programming + easier maintenance + possible code
sharing + more tight coupling opportunities

28. Stateful databases vs
eventsourcing
Stateful databases
• State stored in the database
• Ex. “John has $3122
USD on his account”
• Transactions and locks that
enable us to mutate the
state
Eventsourcing
• No state just events.
• Ex. “John got spent $12 USD”
• State is inferred from the past
events…
• Every situation can be replayed!
• Events are immutable = no
problem with locking, etc.
We can also not care about keeping the data at all.

29. … and other dilemmas.
But…

30. Why not mix all the approaches?

31. Can sole database
be a microservice?

32. Must microservice be
based on
REST interfaces?

33. How would you
model microservices
for the last system
you developed?

34. That’s it for the intro
Thanks!
jacek@theiterators.com

35. Summary
Microservices come in different flavours:!
sync, async, rest, mq, databases, events, hard
and easy guarantees, with private and shared
databases, based on bare-metal machines and
high level platforms.
© Marivlada | Dreamstime Stock
Photos & Stock Free Images

36. Summary
Spray is great foundation:
for simple HTTP services
for connecting with awesome Akka processing framework
with great directives for strictly defining what requests get
processed
with great marshalling and serialisation
who make simple easy and abstractable

37. Summary
Play is has some useful elements:
!
nice routing DSL,
nice controller with Action composing
nice Websockets with Akka actors
lots of libraries to integrate to
big boilerplate

38. Summary
Akka is great for messaging, makes concurrent
programming easy!
! Actors are not threads
Messages and Questions with timeouts
Scheduling
Watch not to make bloated — keep it single
purpose

39. Summary
Eventsourcing !
! Don’t store mutable state
Store immutable events
Rebuild state by processing the past events
Akka persistance stores the events for you in a
journal of choice (Mongo, Redis, Postgres, Maria,
Mysql)

40. What haven’t we talked about
!
JVM microframeworks — Finagle, etc.
Frontend — how to keep modularity, where to generate HTML,
how to handle caching.
Monitoring — health checks and metrics (spray directives?) and
monitoring front end
DevOps — How to configure loadbalancers, CORS, handling
configuration and discovery of microservices, prepare auto-scaling,
and handling situations when services fail, or how to make
hot swap deployments.

41. Thanks!
Łukasz Sowa @luksow
lukasz@theiterators.com
Jacek Głodek @jacekglodek
jacek@theiterators.com