Docebo: history of a journey from legacy to serverless

From legacy to serverless
history of a transformation

The ladder
Monolith architecture

User interface
Business layer (MVC)
Data interface
Data layerBrowser Web Server
Monolith

The good
● Fewer Cross-cutting
Concerns: logging, security
features such as audit trails, xss
and DOS protection, rate limiting
are shared across the code
base.
● Less Operational Overhead:
Less deployment complexity,
monitoring, testing and logging.
● Development ease: building a
monolithic application is far less
complex and need less
developer resources (also less
specialization)
● Performance: no multiple API
call means less overhead time
that could lead to a better overall
performance
The uglyThe bad Lesson
learned
● Harder to understand: can
have lots of dependencies, side-
effects, and magic which are not
straight forward for the new
comer
● Harder to change: a large
codebase harder to understand
is also harder to change.
● CI/CD: implementing a CI / CD
pipeline leads to a continuous
complete redeployment.
● Scalability: If you need to scale
fast you are in for big bucks,
costs will likely grow
exponentially.
● Poor reliability: a single bug
could take the whole system
down.
● Slowness: as the code base
grows, overall system
performance decreases
● Monolith are the starting point of
any small business and as it
scales up a choice must be
taken, microservices with
monolith core or full
microservices architecture?

The spiral staircase
Microservice architecture with a monolithic core

User interface
Business layer (MVC)x
Data layer
Browser Proxy
Microservice architecture with a monolithic core
Orchestration
Service A
Service B
Service C
Service Z
...
Monolithic

The good
● Scalability: scalability is good,
microservices can be deployed
as a singularity.
● CI/CD: CI / CD can be
implemented with overall
benefits.
● Maintenance: Easier to
understand and maintain
The uglyThe bad Lesson
learned
● More Operational Overhead:
More deployment complexity,
monitoring, testing and logging.
● Monolith database: the
database is still the one from the
monolith architecture
● Shared core: The core is shared
among all microservices
(dependency) this also means
project codebase
● Legacy code: it’s still among us
but this is not the architecture’s
fault.
● REST API can tend to be
developed in an unRESTful way
based on developer “sensitivity”.
Not much control over code
quality due to the stringent scale
up deadlines.
● Lots of bugs at first release.
● It works well, scales well and
with CI/CD in place the quality of
new releases has grown.

Stairway to heaven
Serverless Architecture

We had some issues...
All microservices in our
backend app were
highly dependent on
one another. When a
MS requires a resource
from another MS, the
first must know what
data is needed by the
other one
Tight coupling
All communications
between microservice
were done by a sync
API call. This caused
some issue when
performing heavy
operations on DB (like
importing users).
Blocking sync
execution
There was no standard
procedure to manage
errors occurred while
an event is triggered
and captured by
another service,
Error handling
When an event is
triggered and a
microservice service
fails, the event is lost
and not recoverable,
causing discrepancy in
DB and manual work to
recover missing data.
Rigidity

How to solve them, then?
MESSAGE QUEUES!
Wow, but i don’t
want to pay for
idle… maybe a
“serverless”
service?
But there are so
many services
out there...
Let’s try with an
AWS managed
service

Simple Queue Service
AKA - The Bread and Butter of AWS services Messaging
Ease of use
Read Throughput
No consumers coordination, no scaling out
management, no special libraries needed
It dynamically increase read throughput by
scaling number of tasks reading from a
queue
Single consumer
Message replayability
Once a message is processed by a
consumer, it is removed from the queue
SQS does not support replaying messages
that have already been published
Main use cases
Application integration
Decoupling microservices
Allocate tasks to multiple worker nodes
Decouple live user requests from intensive
background work
Batch messages for future processing
and so on...
Bonus: SQS CAN TRIGGER LAMBDA FUNCTIONS!

The benefits of serverless
No servers to
provision or manage
Never pay for idle
Scales with usage
Availability and fault
tolerance built in
Serverless doesn’t mean that servers are no longer involved. Serverless means:

Main SQS stream
queue in which
already validated
events are put.
Docebo microservices
put events here via a
shared library.
Global Queue
Lambda functions that
saves a map between
event types and
service queues. The
subscriptions are
stored in Elasticache
(Redis).
Subscriber
The orchestrator that
pushes the events
from the main stream
into the subscribed
service queues. It
reads subscriptions
map from Redis
Dispatcher
Services queues that can
implement different
strategies/services (SQS,
DynamoDB, streams,
etc…). Each lambda reads
the “stream” and call the
subscribed webhooks for
each event.
Service Queues
The real subscribers of
all events that are
processed by Event Bus.
Consumers must be
both Docebo
microservices or internal
webhooks.
Consumers
Event Bus modules
Each module has its own responsibility

The good
● Scalability: scalability at its best,
functions and services can be
deployed as a singularity
● CI/CD: CI / CD can be
implemented with overall
benefits.
● Maintenance: ~ ZERO effort in
maintain a serverless
architecture
● Developers only do their job:
write code
The uglyThe (almost)
bad
Lesson
learned
● Cold starts (latency triggering
a function): if there is no idle
container available waiting to run
the code..
● Not 100% predictable costs: be
careful to keep running time low
and find the right amount of
memory allocated for the
function
● Nothing (for now) ● Eventual consistency is not safe,
and that’s OK!
● No bugs at first release
● Developers can focus on writing
high quality code
● Automatic tests are essential

From idea to production
The “Legacy” way
Choose Language
+ framework
Master Language
+ framework
How to realize
microservices?
Capacity Planning
Figure out
deployment
Configure CI/CD Configure AMI
Configure ELB
Configure
autoscaling
Over provision for
launch
idea production

From idea to production
The “ ” way
Choose Language
+ framework
Master Language
+ framework
How to realize
microservices?
Capacity Planning
Figure out
deployment
Configure CI/CD Configure AMI
Configure ELB
Configure
autoscaling
Over provision for
launch
idea production

Serverless is not our goal
But it’s the “stairway” to reach our goals:
Build a product
that customers
love to use
Test ideas
against the
market quickly
Iterate on good
ideas
Deliver
frequently,
deliver quickly
Focus on
creating
Business Values

Thank You!
Fabio Pirovano, Alberto Galimberti

Docebo: history of a journey from legacy to serverless

Recommended

More Related Content

What's hot (20)

Similar to Docebo: history of a journey from legacy to serverless (20)

Recently uploaded (16)

Docebo: history of a journey from legacy to serverless