Following the classical software architecture patterns we tend to design large monolith of software applications. These monoliths are typically quite difficult to scale as they often require powerful machines, making the option to scale out very expensive. In most cases these monoliths of software are designed to run on a single machine only, hence scaling out is complicated or even impossible without refactoring large portions of the application. Therefore a new design pattern called microservices arose. The pattern of microservices keeps the need of a clustered server setup in mind and helps to keep the application very modular. This allows to simplify a scale out of your application and even allows to scale the bottlenecks of your application only and hence reducing the total cost for a scale out approach. In this talk I will introduce the concept of microservices, how they are defined and how to design an application with them. Furthermore I will show how to scale the application properly and why this is only possible due to the use of microservices. Also we will have a look at Node.js and why it is a perfect, though not the only, fit to this design strategy. However scaling is not the only purpose of microservices, they also increase the flexibility and maintainability of applications, this will also be discussed in the talk.

1. Microservice-based software
architecture
November 23, 2014
Michael Hackstein
@mchacki
www.arangodb.com

2. Michael Hackstein
ArangoDB Core Team
Web Frontend
Graph visualisation
Graph features
Host of cologne.js
Master’s Degree
(spec. Databases and
Information Systems)
1

3. Monolithic Applications
One large application
In most cases designed to run on one server
Loose coupling of objects due to object orientation
2

4. Drawbacks
Grows large over time
Hard to maintain, refactoring expensive
Typically written in one language
3

5. Drawbacks
Grows large over time
Hard to maintain, refactoring expensive
Typically written in one language
Hard to scale-out
Probably contains local state information
Can only be scaled as a whole
“Hot-spots” require multi-threaded implementation
3

6. Drawbacks
Grows large over time
Hard to maintain, refactoring expensive
Typically written in one language
Hard to scale-out
Probably contains local state information
Can only be scaled as a whole
“Hot-spots” require multi-threaded implementation
High basic hardware requirements
Parts of the app is CPU intensive
Parts of the app is RAM intensive
Both have to be large
3

7. Microservices philosophy
“Bring object orientation to architecture”
Designed to run in a cluster of servers
De1ne many services, each for one purpose only
Each microservice offers a documented public API
A microservice can make use of other microservices
Each service should not have a large code base
4

8. Microservices philosophy
“Bring object orientation to architecture”
Designed to run in a cluster of servers
De1ne many services, each for one purpose only
Each microservice offers a documented public API
A microservice can make use of other microservices
Each service should not have a large code base
“Smart endpoints and dumb pipes”
4

9. Microservices philosophy
“Bring object orientation to architecture”
Designed to run in a cluster of servers
De1ne many services, each for one purpose only
Each microservice offers a documented public API
A microservice can make use of other microservices
Each service should not have a large code base
“Smart endpoints and dumb pipes”
BUT: Do not overdo it. (Function6= Microservice)
4

10. Bene1ts and Costs
Implemented indepen-dently
from one another
Single-threaded implemen-tation
Each might use a different
language
Seamless replacement by
new implementation
“Hot-spots” individually scal-able
Speci1c server con1gura-tion
per service
Highly 2exible
5

11. Bene1ts and Costs
Implemented indepen-dently
from one another
Single-threaded implemen-tation
Each might use a different
language
Seamless replacement by
new implementation
“Hot-spots” individually scal-able
Speci1c server con1gura-tion
per service
Highly 2exible
Communication overhead
Requires load balancing
Need to get used to Archi-tecture
Imprecise de1nition so far
5

12. Architecture
Application
6

13. Architecture
Application
6

14. Architecture
Load Balancer
S S S
6

15. Architecture
Load Balancer
S S S
S S S
6

16. Architecture
Load Balancer
S S S
S S S
6

17. Scaling
S S S
7

18. Scaling
Load Balancer
S S S
7

19. Scaling
Load Balancer
S S S S
S
7

20. Communication Layers
S S S
S S S
8

21. Communication Layers
S S S
Load Balancer
S S S
8

22. Communication Layers
S S S
Load Balancer
S S S
8

23. Advises
You pay with network traZc
Keep the tree as 2at as possible
Request async. in parallel wherever possible
You should always have a tree
No circles, no communication within the same layer
9

24. Node.js a perfect match?
Node.js can be set up fast
Follows a single-threaded architecture
Good tooling to build REST interfaces
Scaling pattern is equal
10

25. Node.js a perfect match?
Node.js can be set up fast
Follows a single-threaded architecture
Good tooling to build REST interfaces
Scaling pattern is equal
BUT Not the only option: Rails, Java, Erlang, . . .
Select the language that 1ts best
10

26. The database Layer
There are several microservices that form a Data Access Layer.
Very little logic in the service, basically data access.
Abstraction is used to get more independent from DB technol-ogy.
If you switch DB only reimplement this service and migrate data.
11

27. The database Layer
There are several microservices that form a Data Access Layer.
Very little logic in the service, basically data access.
Abstraction is used to get more independent from DB technol-ogy.
If you switch DB only reimplement this service and migrate data.
Life-cycle equal to the DB technology.
Scales similar as the DB in terms of computation.
Data content can scale differently.
11

28. ArangoDB Cluster Setup
Coordinator Coordinator
DBServer DBServer DBServer
12

29. ArangoDB Cluster Setup
Coordinator Coordinator
DBServer DBServer DBServer
12

30. ArangoDB Cluster Setup
Coordinator Coordinator
DBServer DBServer DBServer
12

31. ArangoDB Cluster Setup
Coordinator Coordinator
DBServer DBServer DBServer
12

32. ArangoDB Foxx
Execute JavaScript code directly on the database.
Extend ArangoDB API.
Foxx is executed on coordinators.
Move data access microservice into the DB.
Scale data content and computation independently.
Reduce the microservice tree by one level.
13

33. Architecture Revisited
Load Balancer
S S S
S S S
14

34. Architecture Revisited
Load Balancer
S S S
S
14

35. Architecture Revisited
Load Balancer
S S S
S
14

36. Thank you
Further Questions?
Follow me on twitter/github: @mchacki
Write me a mail: mchacki@arangodb.com
Follow @arangodb on Twitter
Join our google group:
https://groups.google.com/forum/#!forum/arangodb
Visit our blog https://www.arangodb.com/blog
Slides available at https://www.slideshare.net/arangodb
15