►
Description
Ortelius has gone through an architecture update moving to a microservice implementation. Yes, it is important to ‘eat our own dog food’ as they say. Join Ayesha to learn how Ortelius is moving away from its monolithic roots to a modern microservice implementation.
A
A
I
am
from
pakistan,
I
am
a
software
engineer
by
profession
and
I
have
been
in
the
industry
for
around
10
years
and
at
present,
I'm
working
as
an
engineering
manager
in
a
local
tech
company
and
I've
been
part
of
our
tvs
community
for
around
1.5
years
and
it's
one
of
my
first
conferences.
So
I'm
really
glad
and
excited
to
be
part
of
it.
So
yeah,
that's
all
about
me
and
now,
let's
move
on
to
our
presentation.
A
So
what
arterius
is
so
our
release
is
basically
it's
basically
designed
for
cataloging
micro
services.
It
tracks
and
version
micro
services
maintains
the
dependencies
and
the
blast
radius
information.
All
of
this,
by
providing
a
logical
view
of
the
architecture,
it's
an
incubating
project
that
is
under
the
governance
of
cd
foundation,
and
the
mission
is
basically
to
simplify
the
adoption
of
microservices
by
providing
the
catalog
that
is
maintained
by
the
diverse
and
global
and
a
constantly
growing
open
source
community
that
we
have
so
yeah.
A
So
why
there
is
a
need
of
a
catalog
for
microservices.
At
the
first
place,
I
mean
to
better
understand,
let's
think
of
a
scenario
that
let's
say,
you're
working
on
a
product
or
a
project
that
is
designed
using
microservices
and
the
consumers
and
customers
are
using
it
right
and
one
day
you
got
a
call
from
a
support
that
okay,
something
is
not
working.
What
would
you
do
in
that
case,
usually
to
cater
the
situation?
A
So
this
means
that,
apart
from
micro
service
right
there
are,
there
is
a
need
to
track
certain
attributes
that
are
associated
with
this
with
this
micro
service.
So
so
what?
What
are?
What
are
these
things
that
I
mean
that
we
need
to
track
right?
So
if
we
talk
about
micro
service
domain,
so
I
mean
each
micro
service
itself
is
a
component
right
and
that
and
that
com
component
it
has
its
own
deployment
logic
right,
I
mean
a
micro
service.
A
Can
be
deployed
using
ansible
or
it
can
be
replaced
using
help
chart
and
then
it
can
be
and
it
can
be
deployed
deployed
to
different
environments.
Right
I
mean
we
can
have
tests
for
and
stage
all
these
kind
of
environments
with
different
environment
variables
attached
to
it,
and
then
it
can
have
an
owner,
it
will
be,
it
will
be
consuming
some
other
micro
services
and
of
course
there
would
be
other
services
that
will
be
calling
us
or
consuming
this
service
and
that
and
then
it
can.
It
can
also
have
a
lot.
A
A
It
is
a,
it
is
a
new
version
and
we
can
easily
know
and
track
the
differences
from
the
previous
version,
and
we
also
know
which
version
is
deployed
on
what
particular
environment
right,
but
in
case
of
microservice
design
I
mean,
since
each
service
is
totally
independent
component
like
like,
I
said
earlier,
so
it's
if
the
concept
of
a
and
a
whole
application
version
is
it's
something
that's
missing
right.
We
can
track
a
single
micro
service,
but
a
higher
level.
How
things
are
impacted
is,
is,
I
would
say,
that's
missing.
A
So
what
we
have
to
do
is
we
have
to
create
and
rely
on
a
logical
view
to
keep
track
of
all
those
things,
changes
and
differences,
and
this
is
what
a
catalog
engine
like
rtds
can
provide
so
yeah.
So
I
mean
in
in
summary,
whenever
a
new
micro
service
is
created,
so
it
needs
to
be
registered
to
a
catalog
and
that
catalog
can
can
actually
track
following
attributes
for
it.
A
Like,
like
the
pipeline,
I
mean
who
owns
the
who
owns
that
service,
what
deployment
method
it
supports
key
value,
pairs
secrets,
inventory
version,
logical
application,
so
yeah.
So
this
is
all
this
is
what
that
that
we
have
to
like.
We
have
to
track
and
that
that
basically,
a
catalog
service,
too,
is
to
track
all
those
attributes
for
of
a
micro
service,
so
yeah
I
mean
now
now.
A
A
So
once
we
have
that
so
once
that
image
is
pushed
to
our
registry,
so
what
we
got
out
of
it
is
is
a
digest
right
and
and
so
what
so,
what
artes
does
it
is?
It
comes
in
and
it
captures
that
information
right.
I
mean
the
get
commit
the
registry
info,
how
the
tagging
is
done
and
then
what
it
does
it
that
it
automatically
creates
component
and
application
versions,
and
then
it
it
start
building
building
that
relationship
that
how
this
incoming
service
is
being
consumed.
Who
is
consuming
it?
A
What
will
be
the
logical,
app
now
looks
like
and
so
and
and
in
the
end,
a
new
version
of
micro
services
will
be
created
and
then,
of
course,
a
new
version
of
complete
app
will
be
created
and
then
from
in
the
as
you
can
see
in
this
the
right
side
of
the
of
the
picture.
So
what
ortega's?
After
I
mean
capturing
all
this
information?
A
What
it
does
it
can,
then
it
can
also
trigger
the
deployment
that
I
mean
deployment
engine
that
can
automatically
do
do
the
deployment
or
it
can
do
that
deployment
using
that
using
the
existing
ci
cd
in
process
and
and
the
end
result
is
that
it
basically
push
out
that
micro
service
to
the
cluster
and
and,
of
course,
while
keeping
that
it's
maintaining
its
inventory,
that
which
environment
is
that
that
micro
service
is
being
sent
to
in
case
there
are
multiple
environments
right.
So
these
are.
A
These
are
some
reports
that
we
get
out
that
we
get
out
from
from
once
I
mean
once
or
twist
us
all
this
process.
So
these
these
are
some
reports
that
that
can
get
gets
generated
right.
So
the
first
report
that
that
we
have
in
the
in
the
on
the
on
the
left
side
is
that
is
the
bomb
report
right
this
this
this
one
actually
from
application
standpoint
this
this
diagram
shows
that
what
application
is
consuming.
A
What
is
is
actually
made
up
of
from
right,
and
then
we
have
a
blast
radius.
This
basically
tells
that
who,
who
is
this
service,
that
is
being
changed
or
being
pushed
right,
and
what
are
the
other
service
that
that
it
has
impacted
like
here?
We
can
see
this
car
service
has
affecting
three
other
services
yeah
so
down
there.
We
can
see
that
there's
a
difference
report
that
that
track
and
and
says
that,
okay,
this
card
service
got
updated.
A
A
So
now
I
mean:
let's:
let's
shift
our
focus
a
bit
to
see
that
what
is
the
architecture
of
orterius
itself
is
and
how
I
mean
what
what
are
the
flaws
that
we
are
seeing
and
how
we
are
trying
to
to
improve
them
so
yeah
so
artes
from
architecture's
point
of
view.
It's
basically
a
monolith,
app
right
now,
that's
written
in
java
and
c
plus,
plus
mainly,
and
since
we
have
now,
since
we
have
ortillius
to
keep
track
of
our
microservice.
A
So
now
it's
the
right
time
to
move
to
to
move
arterius
itself
to
microservice
architecture
yeah.
So
no!
No,
I
mean,
of
course,
that's
not
the
reason,
only
reason,
but
I
mean
microservices
moving
to
I
mean
there
are
a
lot
of
a
lot
of
good
reasons
that
we
have
due
to
which
we
are
planning
to
move
arteries
to
microservice
architecture,
and
some
of
them
are
written.
You
can
see
are
mentioned
here.
Since
I
mean
it
would
be
now
easy
to
review
review.
A
The
code
will
have
smaller
services
that
can
leads
to
less
breaking
changes
and,
and-
and
the
major
thing
is
that,
since
ortelius
is
a-
is
an
open
source
community,
it's
a
growing
community.
So
so
we
have
a
very
diverse
skill
set
of
people
that
are
coming
in
so
so
it
would
be
good
not
to
bound
to
a
single
programming
language,
and
we
can
always
have
I
mean
we
can
we
can
do
the
development
in
parallel
and
all
those
I
mean
all
those
these
are
the
benefits
that
we
are
hoping
to
get
out.
A
I
mean
these
and
many
more
benefits
that
we
are
hoping
to
get
out
once
we
we
have,
the
rtvs
as
itself
is
when
it
authentic
will
be,
will
will
be
converted
to
microservice
architecture
so
yeah.
So
this
is
this.
Is
you
can
see
a
pictorial
representation
of
what
the
existing
architecture
of
ortegius
looks
like,
and
you
can
see
that
this
picture
in
the
right?
It
it
it's
it's.
It's
simply
telling
that
it's
basically
a
tom
k,
tomcat
based
web
application
and
the
front
end
is
in
javascript.
A
Back-End
is
in
java,
and
we
have
one
single
rest.
Api
class
and
also
there's
a
single
db
handle
that
is,
that
is
connected
to
our
postgres
db.
We
have
one
db
and
that
is
postgres
and
it's.
The
connection
is
made
made
via
jdbc
connection,
and
all
of
this
you
can
say
it's
been
it's
since
it's
a
monolith
tab.
A
So
it's
around
three
sorry
30
000
lines
of
code
that
we
have
at
the
moment
so
yeah-
and
this
is-
and
this
is
the
I
mean
this-
is
the
proposed
architecture
that
we
are.
We
are
I
mean
that
we
are
taking
steps
towards
to
to
make
it
look
something
like
this.
So
in
this
approach,
what
we
are
doing
is
basically,
we
are.
A
The
approach
we
are
taking
is
to
divide
the
monolith
to
microservices,
and
then
I
mean
how
we
are,
how
we
are
going
to
do
is
basically
is
we
will
first,
the
first
and
foremost
thing
to
do
is
to
identify
the
problem
sets
in
our
monolith
code,
page
right
once
the
problem
sets
are
identified,
and
then
I
mean
once
they're
identified,
basically
as
a
group
of
objects
or
functionality.
Once
we
have
that,
then
the
idea
is
to
basically
define
them.
A
A
credit
card
operations
around
it
and,
for
example,
I
mean
an
example,
could
be
that
let's
say
we
have
our
object:
identifiers
that
that
deals
with
our
credentials,
functionality
right
now.
The
functionality
that
that
deals
with
credentials
is
is
embedded
in
one
single
code
code
base,
and
once
we
know
what
is
this
object
and
object
does
and
that
operations
around
it
are
identified.
A
We
can
make
a
micro
service
for
it.
However,
I
mean
there's
one
more
thing
that
this
is
not
may
not
be
the
most
granular
division
that
we
have.
We
can
further
split
this
micro
service
into
two
and
that's
based
on
the
type
of
trade
right,
so
we
can
have
for
every
object.
We
may
have
two
services,
one
is
for
read,
and
one
is
for
for
right.
So
so
I
mean,
if
we
I
mean
so
read,
operations
are
basically
the
ones
that
are
that.
That
does
not
updates
the
database.
A
Another
important
thing
that
that
that
will
be
supporting
is
that
is
that
we'll
be
doing
is
the
hybrid
approach
during
that
transition.
This
means
that
monolith
app
will
be
running
and
the
new
stuff
stuff
that
that's
being
developed
will
be
in
micro,
service
style
and
and
and
will
also
be
moving
our
monolith
gradually
to
to
micro
service.
So
we
will
there
will
be.
A
Of
course,
there
will
be
a
time
where
we'll
be
in
a
hybrid
state
that
the
monolith
will
be
or
all
will
also
be
active,
and
then
new
microservices
will
also
they
can
become
part
of
this
architecture.
So
so
to
to
to
to
do
that,
I
mean
to
support
that
that
kind
of
thing
we
have.
We
have
service
mesh
or
more
more,
precisely
istio,
that
can
help
in
that
transition
and
from
yeah.
So
I
mean
from
implementation
point
of
view.
A
Istio
is
like
it's
a
basic:
it's
a
simple
yaml
based
structure
right
which
we
can,
which
can
define,
rules,
policies
and
destinations,
and
these
destinations
will
then
help
us
in
routing
their
traffic
to
appropriate
destinations
based
on
certain
rules.
So
during
the
transition
phase,
since
our
monolith
is
also,
I
mean
container
rice
right.
So
it's
it's
itself
is
a
micro
service.
A
I
mean
it
will
be
a
big
huge
micro
service,
but
it
will
be,
it
will
be
a
separate
entity
and
and
it
will
be
the
default
destination
for
all
the
all
the
traffic
that
comes
in
so
yeah,
so
it
will
be
the
default
destination
for
the
traffic.
I
mean
that
will
be
our
monolith
and
our
news
and
all
the
new
services
or
or
any
replace
service.
I
mean
there
is
reimplementation
of
some
some
part
monolith.
A
We
can
define
the
new
routes
in
our
istio
conference
and
then
for
each
microservice.
So
any
new
call
that
comes
in
for
a
particular
microservice
will
bypass
the
monolith
and
go
directly
to
that
microservice.
So
this
is
where
stu
can
play
a
huge
role
in
supporting
that
hybrid
phase
and
not
even
that
istio
can,
but
even
after
I
mean
once
everything
is
migrated
to
microservice,
we
can
of
course
make
use
of
steel
during
our
testing
and
and
roll
backs
and
other
stuff
as
well.
A
That's
that's
the
plan
that
we
have
yeah
so
now.
Lastly,
I
mean
some
points.
I
mean
some
in
my
intro
that
I
mentioned
that
there
would
be.
There
are
some
considerations
that
we
some
some
decisions
that
we
made
a
while
moving
to
to
to
this
by
planning
these
this
architectural
move.
So
some
points
around
that
that
I
mean
first
thing
that
we
that
we
came
across
while
when
we
decide
to
move
to
microservice
is
basically
the
language
choice.
A
I
mean
what
would
be
the
right
language
for
for
our
microservice,
since
each
language
has
its
own
pros
and
cons,
and
let's
say
we
don't
have
a
time
constraint
and
instead
of
being
trained
on
completely
and
new
language,
the
idea
idea
would
be
to
go
with
the
one.
That's
that
that
I
mean
that
the
developers
already
well
well
versed
with
right.
So,
however,
I
mean
time
time
back
to
the
benefits
of
microservice.
A
The
thing
that
that
that
we
should
kept
in
mind
is
that,
in
the
end,
the
micro
service
should
be
simple,
but
it
will
be
simple
enough
to
understand,
make
changes
with
you
and
onboard
new
people.
So
what
we
did
is
we
went
with
this
this
this
five
minute
rules
right,
basically
to
figure
out
what
a
micro
service
does
in
in
five
minutes
I
mean
if,
if
someone
is
skilled
in
a
particular
language,
then
it
then
he
or
she
should
take
only
five
minutes
to
to
understand
what
that
microservice
is
doing.
A
I
mean
that
should
be
that's.
You
can
say
that's
the
rule
that
we
that
is
put
in
place,
because
we
have
it's
an
open
source
community
right
and
we
have
many
new
contributors
coming
in
on
on
monthly
basis,
so
it
would
be
so
it
should
be
simple
enough
that
can
that
new
people
can
be
easily
onboarded
onwarded
without
any,
without
going
through
any
any
trouble,
so
yeah.
A
A
It
is
a
huge
focus
on
rest,
api
based
back
and
micro
services,
and
it
was
quick
for
us
to
get
started
and
based
on,
and
it's
also
based
on
an
asynchronous
server
gateway
interface.
Hence
it's
it's
very
fast
in
terms
of
performance
and
and
the
runtime
environment
is
pretty
small,
it's
at
a
very
simple
and
straight
straight
docker
file.
So
the
next
thing
is
the
database,
which
is,
of
course,
one
of
the
major
component
for
any
stateful
applications,
and
it
needs
to
be
designed
properly.
There
are
again
multiple
directions
to
it.
A
That
is
the
choice
of
the
database,
sql
versus
nosql,
number
of
databases,
database
engine,
basically
poli
versus
single
database,
to
name
a
few,
so
pulley
database
is
basically
the
one
that
is
that's
actually
a
separate
database
database
at
times
a
separate
database
engine
too
per
micro
service.
We
have
a
separate
database.
The
advantage
of
advantages
of
this
would
be
that
we
can
put
security
measures
around
each
database
as
per
need
in
such
a
way
that
only
one
micro
service
can
access
this
database.
A
So
apart
from
poly
database
discussion,
sequel
versus
nosql
choice
is
that
we
need
to
make
based
on
the
data
that
we
are
storing
so
right
now
in
orterius,
as
I
mentioned
earlier,
that
we
have
a
sequel
database,
but
that
is
not
the
best
choice
that
we
feel
that
right
now
I
mean
it
was
a
traditional
approach,
which
is
kind
of
not
very
efficient
due
to
high
transaction
load
will
have
so
moving
forward.
The
plan
is
actually
use
the
graph
database
with
a
separate
database
and
engine
per
micro
service.
A
The
engines
are
usually
lightweight,
so
it
won't
be
an
issue.
However,
I
mean
the
transition
to
new
databases.
Actually
is,
is
actually
a
major
rewrite
and
we
need
to
have
both
databases
running
during
our
transition
phase,
which
is
of
course
I
mean
we
would
need
an
overlap
that
same
entries
will
be
inserted
in
both
of
them.
So
arterius
is,
I
mean,
is
keeping
the
relational
monolith
database
as
part
of
transition.
We
are
not
going
to
change
it
at
the
same
time
as
that
of
spreading
the
apps.
A
A
These
major
I
mean
there
are
other
things
that
should
be
kept
in.
Mind
is
basically
the
design
of
the
transaction
layer,
which
is
basically
how
to
retrieve
and
store
data
into
database
like
how
to
interact
with
the
database.
So
this
is.
This
is
kind
of
closely
linked
with
the
functionality
of
microservice.
A
So
so
I
mean
ideally,
the
each
table
in
a
database
will
have
his
crud
operation
and
that
that
will
be,
of
course,
written
in
in
the
corresponding
microservices.
So
some
things
that,
to
keep
in
mind
I
mean
we'll,
of
course,
keep
in
mind
would
be
around
the
transit
transaction
layer.
I
mean
once
we
design
that
once
we
come
to
that
point,
when
we
design
the
transaction
layer
so
would
be
to
to
minimize
the
braking
changes,
I
mean
it
should
be
backward
compatible.
A
So
this
can
be
done
by
making
use
of
defaults
at
the
input
side
for
the
values
which
are
not
supported
in
the
new
version,
as
well
as
adding
data
structure
at
the
output
side
retain
the
whole
column
column
in
the
database,
and
that
that
I
mean
I
mean
that
will
be
removed
eventually,
when
no
one
is
using
them.
So
I
mean
so.
A
The
the
the
main
thing
is
not
to
to
break
the
database
while
moving
to
to
the
other
version,
and
another
thing
would
be,
I
mean
or
tls
right
now
has
huge
data
store
in
it.
So
I
mean
one
small
thing,
but
important
thing
would
be
that
it's
basically
to
avoid
the
selects
static
qd,
because
it
can
cause
a
lot
of
load
on
the
db.
I
mean
it
may
not
hurt
in
the
start,
but
this
is
something
that
can
hurt
in
the
longer
run
once
the
db
size
grows.
A
And
third
thing
is
that
I
mean
micro
services,
census
micro
services
and
all
of
them
are
interacting,
so
micro
service
might
have
to
call
another
micro
service,
so
we'll
have
to
make
sure
to
to
avoid
any
any
circular
references,
so
yeah,
so
in
arterius,
yeah,
so
inaudible
what
I
mean
right
now.
What
we
have
is
that
the
db
class,
the
database
class,
we
have
a
database
class.
A
That's
I
mean
that's
the
only
class
interacting
with
the
database
as
I've
shown
in
the
in
my
existing
architecture
diagram.
Here
you
can
see
we
have
a
single
db
that
is
20k
something
lines
of
code
and
now,
like
I
explained
earlier,
the
plan
is
to
to
limit
our
database
interactions
to
one
or
two
tables,
as
for
microservice,
so
that
it
can
simplify-
and
I
mean
and
and
prevent
the
above
mentioned
issues
that
I've
explained.
So
so
so.
Yes,
that's
all
that's
all.
A
I
have
to
say
and
thank
you
very
much
for
joining
the
session
and
if
you
have
any
questions
or
anything
that
you
would
like
to
discuss,
feel
free
to
reach
out
to
me,
I
can
be
reachable
on
linkedin.
This
is
my
handy
and
and
and
also
I'm
part
of
our
tedious,
open
source
community
and
support
channel.
So
you
can
reach
out
to
me
there
as
well
yeah.
Thank
you
so
much.