microservice-based software architecture
DESCRIPTION
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.TRANSCRIPT
Microservice-based softwarearchitecture
Michael Hackstein@mchacki
November 23, 2014
www.arangodb.com
Michael Hackstein
ArangoDB Core TeamWeb FrontendGraph visualisationGraph features
Host of cologne.js
Master’s Degree(spec. Databases andInformation Systems)
1
Monolithic Applications
One large applicationIn most cases designed to run on one serverLoose coupling of objects due to object orientation
2
Drawbacks
Grows large over timeHard to maintain, refactoring expensiveTypically written in one language
Hard to scale-outProbably contains local state informationCan only be scaled as a whole“Hot-spots” require multi-threaded implementation
High basic hardware requirementsParts of the app is CPU intensiveParts of the app is RAM intensiveBoth have to be large
3
Drawbacks
Grows large over timeHard to maintain, refactoring expensiveTypically written in one languageHard to scale-out
Probably contains local state informationCan only be scaled as a whole“Hot-spots” require multi-threaded implementation
High basic hardware requirementsParts of the app is CPU intensiveParts of the app is RAM intensiveBoth have to be large
3
Drawbacks
Grows large over timeHard to maintain, refactoring expensiveTypically written in one languageHard to scale-out
Probably contains local state informationCan only be scaled as a whole“Hot-spots” require multi-threaded implementation
High basic hardware requirementsParts of the app is CPU intensiveParts of the app is RAM intensiveBoth have to be large
3
Microservices philosophy
“Bring object orientation to architecture”Designed to run in a cluster of serversDefine many services, each for one purpose onlyEach microservice offers a documented public APIA microservice can make use of other microservicesEach service should not have a large code base
“Smart endpoints and dumb pipes”BUT: Do not overdo it. (Function 6= Microservice)
4
Microservices philosophy
“Bring object orientation to architecture”Designed to run in a cluster of serversDefine many services, each for one purpose onlyEach microservice offers a documented public APIA microservice can make use of other microservicesEach service should not have a large code base“Smart endpoints and dumb pipes”
BUT: Do not overdo it. (Function 6= Microservice)
4
Microservices philosophy
“Bring object orientation to architecture”Designed to run in a cluster of serversDefine many services, each for one purpose onlyEach microservice offers a documented public APIA microservice can make use of other microservicesEach service should not have a large code base“Smart endpoints and dumb pipes”
BUT: Do not overdo it. (Function 6= Microservice)
4
Benefits and CostsImplemented indepen-dently from one anotherSingle-threaded implemen-tationEach might use a differentlanguageSeamless replacement bynew implementation“Hot-spots” individually scal-ableSpecific server configura-tion per serviceHighly flexible
Communication overheadRequires load balancingNeed to get used to Archi-tectureImprecise definition so far
5
Benefits and CostsImplemented indepen-dently from one anotherSingle-threaded implemen-tationEach might use a differentlanguageSeamless replacement bynew implementation“Hot-spots” individually scal-ableSpecific server configura-tion per serviceHighly flexible
Communication overheadRequires load balancingNeed to get used to Archi-tectureImprecise definition so far
5
Architecture
Application
6
Architecture
Application
6
Architecture
Load Balancer
µS µS µS
6
Architecture
Load Balancer
µS µS µS
µS µS µS
6
Architecture
Load Balancer
µS µS µS
µS µS µS
6
Scaling
µS µSµS
7
Scaling
µS µSµS
Load Balancer
7
Scaling
µS µSµS
Load Balancer
µS µS
7
Communication Layers
µS µS µS
µS µS µS
8
Communication Layers
µS µS µS
µS µS µS
Load Balancer
8
Communication Layers
µS µS µS
µS µS µS
Load Balancer
8
Advises
You pay with network trafficKeep the tree as flat as possibleRequest async. in parallel wherever possibleYou should always have a treeNo circles, no communication within the same layer
9
Node.js a perfect match?
Node.js can be set up fastFollows a single-threaded architectureGood tooling to build REST interfacesScaling pattern is equal
BUT Not the only option: Rails, Java, Erlang, . . .Select the language that fits best
10
Node.js a perfect match?
Node.js can be set up fastFollows a single-threaded architectureGood tooling to build REST interfacesScaling pattern is equalBUT Not the only option: Rails, Java, Erlang, . . .Select the language that fits best
10
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
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
ArangoDB Cluster Setup
Coordinator Coordinator
DBServer DBServer DBServer
12
ArangoDB Cluster Setup
Coordinator Coordinator
DBServer DBServer DBServer
12
ArangoDB Cluster Setup
Coordinator Coordinator
DBServer DBServer DBServer
12
ArangoDB Cluster Setup
Coordinator Coordinator
DBServer DBServer DBServer
12
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
Architecture Revisited
Load Balancer
µS µS µS
µS µS µS
14
Architecture Revisited
Load Balancer
µS µS µS
µS
14
Architecture Revisited
Load Balancer
µS µS µS
µS
14
Thank you
Further Questions?Follow me on twitter/github: @mchackiWrite me a mail: [email protected] @arangodb on TwitterJoin our google group:https://groups.google.com/forum/#!forum/arangodb
Visit our blog https://www.arangodb.com/blogSlides available at https://www.slideshare.net/arangodb
15