Microservices Architecture with Vortex — Part II

Microservice Architectures
Angelo Corsaro, PhD
Chief Technology Officer
angelo.corsaro@prismtech.com
with
Part-II

microservice
Architectural
style
“The microservice architectural style
is an approach to developing a single
application as a suite of small
services, each running in its own
process and communicating with
lightweight mechanisms.” [2]

Server Tier
Process
Functionality
Microservice
Architectures
Individual functionalities
become unit of
deployment and run in
their own process

Microservice
Architectures
Microservices
communicate through
some lightweight
mechanism
Server Tier
Process
Functionality

Server Tier
Benefits
Scaling microservice
applications is easier as we
can scale out individual
functionalities

Benefits
Unconstrained Innovation
as we choose the
technologies stack that
makes the most sense for
implementing a given
feature
Server Tier
Process
Functionality

Incremental Change is
facilitated allowing
incremental deployment of
new functionalities.
Potentially diﬀerent version of
the same micro service could
be running at the same time!
Benefits Server Tier
Process
Functionality

Loose Coupling and High
Cohesion are easier to
achieved to preserve as
the “barriers” between
functionalities are very
thick
Server Tier
Process Boundary /
Share Nothing
Benefits

Performance of
microservice architectures
may be degraded by the
higher cost of
communication if the right
technology is not used
Server Tier
Challenges
Monolithic
Implementation
Microservice
Implementation
In-Process
Communication
Inter-Process/Host Communication

Deployment and
Operation of systems
based on the microservice
architectures is inherently
more complex, especially
at scale and when the right
technologies are not used
Server Tier
Challenges
Monolithic
Implementation
Microservice
Implementation

Designing
Microservice
Architectures

Identifying
Microservices
Microservices are supposed
to capture business and not
technical features of a
system
Microservices

Identifying
Microservices
When a monolithic systems
is already existing, micro
services can be created by
separating the various
features
Microservices

When a system does not exist
we can use the Bounded
Context as deﬁned in [3]
System Objectives
Microservices
Identifying
Microservices Bounded Context

Bounded Context
Domain-Driven Design (DDD) divides a complex domain into a series of
Bounded Context. Where a context means a speciﬁc system
responsibility, and a bounded context means that responsibility is
enforced with explicit boundaries.
Each bounded context has its own canonical model and
communication between bounded context happens through a system-
canonic al model

Microservices are ideally mapped to
Bounded Context.
Each Bounded context has
potentially its own canonical model
Communication between Bounded
Context uses the system-wide
canonical model
Microservices
bounded context
micro-service canonical
model
system canonical model

Let’s imagine that we are
part of a team that has to
design the next massive
online gaming platform
For simplicity we’ll consider
a 2D adventure game
microcosmos

Scalability The architecture should be designed to
promote scale-out as opposed to scale up

Loose Coupling Features should be completely isolated
from each other in time and space

Unconstrained
Innovation
Innovation should not be constrained
with respect to supporting new input
kinds, new target platforms, new
visualisation engines, new strategies,
game engines, etc.
Additionally, functionalities should be
implemented in the most eﬀective
programming language

Incremental
Change
The gaming platform should be as
modular as possible to facilitate the
individual functionalities updates and
upgrade
Additionally, adding new features
should be as much as possible
transparent for the currently running
system

Performance The game should be able to run at 60
frames per second

Fault-Tolerance The gaming platform should be self-
healing

Physics Engine Load Balancing
User Input Game Output Strategy
Bodies
Scene Analytics …

Variability
Analysis
User Input
Keyboard
Mouse
Gyro +
Accelerometer
Joystick
…

Variability
Analysis
Game Output
PC Screen
Hololens
Mobile APP
Web App
…

Variability
Analysis
Load Balancing
Density-Based
Random
Geographical
…

Load Balancing
The run-time gaming
platform conﬁguration
should reﬂect the load
and optimise against it

Physics Engine
Physics Engine
Physics
Engine
Physics
Engine
Physics
Engine
Physics
Engine
Physics
Engine
Physics
Engine
Physics
Engine
Physics
Engine
Load Balancing
As an example
frequency based load
balancing may partition
the game space
depending on frequency
of users in a give n area

Physics Engine Load Balancing User Input
Game Output Strategy
Bodies
Scene Analytics …
Canonical Data Model

A state that is periodically updated
Examples are the reading of a sensor
(e.g. Temperature Sensor), the
position of a vehicle, etc.
Soft State
Reliability => BestEffort
Durability => Volatile
History => KeepLast(n)
Deadline => updatePeriod
LatencyBudget => updatePeriod/3
DestinationOrder => SourceTimestamp

A state that is sporadically updated
and that often has temporal
persistence requirements
Examples are system conﬁguration, a
price estimate, etc.
Hard State
Reliability => Reliable
Durability => Transient | Persistent
History => KeepLast(n)

The occurrence of something
noteworthy for our system
Examples are a collision alert, the
temperature beyond a given
threshold, etc.
Events
Reliability => Reliable
Durability => any
History => KeepAll

Data-centric design leverage the
same principle of Feedback-control
loops to assert a state
In other terms, the desired state is
asserted by writing a topic and the
actual state is monitored.
A control action is taken when the
desired and the actual state diﬀer
Feedback Control Loop

Data-centric design leverage the
same principle of Feedback-control
loops to assert a state
In other terms, the desired state is
asserted by writing a topic and the
actual state is monitored.
A control action is taken when the
desired and the actual state diﬀer
Feedback Control Loop Hard State
Soft State
microservice

struct UUID {
long long low;
long long high;
};
enum FixtureKind {
CAPSULE_KIND,
CIRCLE_KIND,
E_TRIANGLE_KIND,
I_TRIANGLE_KIND,
R_TRIANGLE_KIND,
RECTANGLE_KIND
};
struct Circle {
float radius;
};
struct Rectangle {
float widht;
float height;
};
struct Capsule {
float widht;
float height;
};
struct RightTriangle {
float base;
float height;
};
struct IsoscelesTriangle {
float base;
float height;
};
struct EquilateralTriangle {
float side;
};
One of the class of concepts we need
to represent in our Canonical Data
Model are the graphical entities that
we may use to deﬁne the “world” as
well as the bodies/objects that are
rendered and animated within the
“world”
To keep our example simple, we will
assume that our game can be built
with simple geometrical shapes
Geometry
union Fixture switch (FixtureKind) {
case CAPSULE_KIND:
Capsule capsule;
case CIRCLE_KIND:
Circle circle;
case E_TRIANGLE_KIND:
EquilateralTriangle etriangle;
case I_TRIANGLE_KIND:
IsoscelesTriangle itriangle;
case R_TRIANGLE_KIND:
RightTriangle rtriangle;
case RECTANGLE_KIND:
Rectangle rectangle;
};
struct Color {
long r;
long g;
long b;
};
struct Vector2 {
float x;
float y;
};
Hard State

Worlds need to be discovered and
Body have to be deﬁned
Body and World
struct World {
UUID worldId;
Vector2 p0;
Vector2 p1;
};
#pragma keylist World worldId.low worldId.high
struct Body {
UUID bodyId;
UUID worldId;
float mass;
Vector2 ipos; // initial position
Fixture fixture;
Color color;
};
#pragma keylist Body bodyId.low bodyId.high
Hard State

Action need to be performed such as
adding bodies to a world, removing
them or moving those around
Another example is applying forces to
body, or causing change in their ﬁxture
(e.g. as a result of a collision)
Actuation
struct Body {
UUID bodyId;
UUID worldId;
float mass;
Vector2 ipos; // initial position
Fixture fixture;
Color color;
};
#pragma keylist Body bodyId.low bodyId.high
struct BodyAction {
UUID bodyId;
Vector2 value;
};
#pragma keylist BodyTelemetry bodyId.low bodyId.high

The state of the system has to be
sensed in order to react to it.
Diﬀerent telemetry topics are deﬁned,
such as BodyPos, BodyVelocity,
BodyForce, etc. that rely on the same
underlying type
Sensing
struct BodyTelemetry {
UUID bodyId;
Vector2 value;
};
#pragma keylist BodyTelemetry bodyId.low bodyId.high
Soft State

Relevant events also need to be
modelled to allow for appropriate
actions to be taken.
Events struct CollisionEvent {
UUID a;
UUID b;
Vector2 contact;
};
#pragma keylist CollisionEvent
Event

Physics Engine Load Balancing User InputBodies
Game Output StrategyScene Analytics …
CanonicalDataModel
microcosmos:telemetrymicrocosmos:actuation
Body
World
WorldClock
BodySpeed
BodyPosition
BodySpeed
BodyPosition
BodyForce
microcosmos:telemetry
CollisionBegin
CollisionEnd

Physics Engine Load Balancing User InputBodies
Game Output StrategyScene Analytics …
CanonicalDataModel
microcosmos:telemetrymicrocosmos:actuation
Body
World
WorldClock
BodySpeed
BodyPosition
BodySpeed
BodyPosition
BodyForce
microcosmos:telemetry
CollisionBegin
CollisionEnd
BodyForce

Vortex-Based
Microservices
Key Benefits

Device implementations
optimised for OT, IT and
consumer platforms
Native support for Cloud and
Fog Computing Architectures
Device-2-DeviceDevice-2-Cloud
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infrastructuresdk

The relevant portion of the data
space is projected on the
application address space. Each
typed projection is commonly called
a Cache
No single point of failure or
bottleneck
No central server to conﬁgure/
manage
Decentralised
Data Space
Data
Writer
Data
Writer
Data
Writer
Data
Reader
Data
Reader
Data
Reader
Data
Writer
TopicA
QoS
TopicB
QoS
TopicC
QoS
TopicD
QoS
TopicD
QoS
TopicD
QoS
TopicA
QoS

Vortex provides a high
performance distributed
durability service that can be
used to achieve diﬀerent level
of temporal decoupling
Durability Services take
ownership for “Partition/Topic “
expressions
Distributed
Durability

High
Performance
30 μs peer-to-peer latency
7 μs inter-core latency
4+ Mmsgs/sec p2p throughput
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infrastructuresdk

<10 μs fog/cloud routing
latency
High
Performance Device-2-DeviceDevice-2-Cloud
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infrastructuresdk

Microservice
deployment
Vortex location transparency
and intra-host
communication optimisation
allow to exploit the beneﬁts
of micro-service
architectures without major
performance costs
Ultra-Low Latency
Inter-Process Comm

Vortex is a Polyglot and
Interoperable across
Programming Languages
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infrastructuresdk

Fully Independent of the
Cloud Infrastructure
Private Clouds
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infrastructuresdk

Native Integration with the
hottest real-time analytics
platforms and CEP Device-2-DeviceDevice-2-Cloud
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infrastructuresdk

Integration with mainstream
Dashboard Technologies
Fog-2-Cloud
Device-2-Fog
Cloud-2-Cloud
Fog-2-Fog
infrastructuresdk

Native Support
for Microservices
Patterns

Timeout
As a general rule Vortex APIs
are non-blocking
Blocking API calls are all
equipped with timeout
#include <dds.hpp>
int main(int, char**) {
DomainParticipant dp(0);
Topic<Meter> topic(“SmartMeter”);
Publisher pub(dp);
DataWriter<Meter> dw(pub, topic);
while (!done) {
auto value = readMeter()
dw.write(value);
std::this_thread::sleep_for(SAMPLING_PERIOD);
}
return 0;
}

Worker Pattern
Vortex provides several
ways of supporting the
worker pattern

CIRCUIT BREAKER
Vortex communications
primitive implement the
circuit breaker pattern thus
reducing the complexity of
adopting it

Microservices architectures bring
several architectural beneﬁts
Vortex ensures that the operational and
performance cost of adopting micro
services architectures if minimised
In
Summary

[1] S. Newman. Building Microservices.
[2] M. Fowler, J. Lewis. Microservices
[3] E. Evans, Domain-Driven Design

Microservices Architecture with Vortex — Part II

More Related Content

What's hot

Viewers also liked

Similar to Microservices Architecture with Vortex — Part II

More from Angelo Corsaro

Recently uploaded

Microservices Architecture with Vortex — Part II