Microservices The Good, the Bad, and the Ugly

James Foster — ESUG 2025 — Gdansk, Poland
The Good, the Bad, and the Ugly
Microservices

Motivation
• GemT
a
lk customer expressing interest in bre
a
king monolith into microservices
• ESUG 2025 C
a
ll for Present
a
tions (https://esug.org/2025-Conference/
a
gend
a
.html):
• The list of topics for the norm
a
l t
a
lks
a
nd tutori
a
ls includes, but is not limited to the
following:
• Micro Services, Cont
a
iner, Cloud, Big D
a
t
a

Agenda
• The G
a
rtner Hype Cycle
• Modul
a
rity
• Monolith
• Serverless Computing
• Microservices
• GemStone/S 64 Bit

The Gartner Hype Cycle
Microservices
• Innov
a
tion Trigger (2014)
• Microservices beg
a
n g
a
ining
a
ttention
a
s
a
new
a
rchitectur
a
l style, especi
a
lly with the rise
of DevOps
a
nd cloud-n
a
tive development.
• Pe
a
k of In
f
l
a
ted Expect
a
tions (2015-2016)
• Hype surged
a
s comp
a
nies like Net
f
lix
a
nd Am
a
zon showc
a
sed success. M
a
ny
org
a
niz
a
tions rushed to
a
dopt without fully underst
a
nding the complexity.

Microservices
• Trough of Disillusionment (2017-2018)
• Ch
a
llenges such
a
s service spr
a
wl, monitoring,
a
nd deployment complexity bec
a
me
a
pp
a
rent. Some e
a
rly
a
dopters struggled with implement
a
tion.
• Slope of Enlightenment (2019-2021)
• Best pr
a
ctices, tooling (e.g., Kubernetes, service meshes),
a
nd p
a
tterns m
a
tured.
Org
a
niz
a
tions beg
a
n to underst
a
nd when
a
nd how to use microservices e
ff
ectively.

Microservices
• Pl
a
te
a
u of Productivity (2022-2025)
• Microservices
a
re now
a
m
a
instre
a
m
a
rchitectur
a
l choice, especi
a
lly in l
a
rge-sc
a
le
a
nd
cloud-n
a
tive systems. Adoption is widespre
a
d, but often combined with modul
a
r
monoliths or hybrid
a
ppro
a
ches.

Modularity
De
fi
nition
• Modul
a
rity in softw
a
re refers to the design principle of bre
a
king down
a
softw
a
re system into
sep
a
r
a
te, interch
a
nge
a
ble,
a
nd self-cont
a
ined components or "modules."
• E
a
ch module enc
a
psul
a
tes
a
speci
f
ic function
a
lity
a
nd inter
a
cts with other modules through
well-de
f
ined interf
a
ces.
• This
a
ppro
a
ch enh
a
nces m
a
int
a
in
a
bility, reus
a
bility, sc
a
l
a
bility,
a
nd coll
a
bor
a
tive
development.

Modularity
1950s–1960s: Early Concepts
• Assembly
a
nd e
a
rly high-level l
a
ngu
a
ges (like FORTRAN) h
a
d monolithic structures.
• The ide
a
of structured progr
a
mming emerged, emph
a
sizing control structures
a
nd
subroutines (e.g., in ALGOL).

Modularity
1970s: Formalization of Modularity
• D
a
vid P
a
rn
a
s (1972) published the semin
a
l p
a
per On the Criteri
a
To Be Used in Decomposing
Systems into Modules,
a
dvoc
a
ting for inform
a
tion hiding
a
s
a
key to modul
a
r design.
• Modul
a
a
nd Modul
a
-2 (by Nikl
a
us Wirth) were e
a
rly l
a
ngu
a
ges explicitly supporting modul
a
r
progr
a
mming.

Modularity
1980s–1990s: Object-Oriented Programming (OOP)
• OOP l
a
ngu
a
ges like Sm
a
llt
a
lk, C++,
a
nd l
a
ter J
a
v
a
introduced modul
a
rity through cl
a
sses
a
nd enc
a
psul
a
tion.
• Component-b
a
sed softw
a
re engineering (CBSE) g
a
ined tr
a
ction, promoting reus
a
ble
softw
a
re components.

Modularity
2000s–2010s: Modular Architectures
• Service-Oriented Architecture (SOA)
a
nd microservices bec
a
me popul
a
r, emph
a
sizing
modul
a
r services communic
a
ting over networks.
• P
a
ck
a
ge m
a
n
a
gers (like npm, pip, M
a
ven) f
a
cilit
a
ted modul
a
r development
a
nd distribution.

Modularity
2020s–Present: Modular Ecosystems
• L
a
ngu
a
ges like Rust, Go,
a
nd modern J
a
v
a
Script emph
a
size modul
a
rity through p
a
ck
a
ges,
cr
a
tes,
a
nd modules.
• Modul
a
rity in cloud-n
a
tive
a
pplic
a
tions:
• Modul
a
r monoliths
• Serverless computing
• Microservices

Modularity
Bene
fi
ts
• E
a
sier debugging
a
nd testing
• P
a
r
a
llel development by te
a
ms
• Code reuse
a
cross projects
• Simpli
f
ied m
a
inten
a
nce
a
nd upd
a
tes

Monolith
What is a Monolith?
• A single runtime execut
a
ble th
a
t cont
a
ins
a
ll relev
a
nt
a
pplic
a
tion code.
• Ch
a
nges to
a
ny module require deployment of entire
a
pplic
a
tion.

Monolith
Advantages - 1
• Simplicity of Development
• E
a
sier to set up
a
nd underst
a
nd, especi
a
lly for sm
a
ll te
a
ms or projects.
• No need to m
a
n
a
ge inter-service communic
a
tion or distributed systems complexity.
• E
a
sier Testing
• End-to-end testing is more str
a
ightforw
a
rd since everything runs in
a
single process.

Monolith
Advantages - 2
• Perform
a
nce
• In-process c
a
lls
a
re f
a
ster th
a
n network c
a
lls between microservices.
• No seri
a
liz
a
tion/deseri
a
liz
a
tion overhe
a
d.
• Simpli
f
ied Deployment
• One deployment pipeline
a
nd runtime environment.
• No need for service discovery, orchestr
a
tion, or cont
a
ineriz
a
tion.

Monolith
Advantages - 3
• Centr
a
lized M
a
n
a
gement
• E
a
sier to m
a
n
a
ge logging, monitoring,
a
nd debugging in
a
single codeb
a
se
a
nd process.

Monolith
Disadvantages - 1
• Sc
a
l
a
bility Limit
a
tions
• You c
a
n only sc
a
le the entire
a
pplic
a
tion, not individu
a
l components.
• Tight Coupling
• Ch
a
nges in one p
a
rt of the system c
a
n
a
ff
ect others, m
a
king it h
a
rder to m
a
int
a
in.
• Slower Development
a
t Sc
a
le
• As the codeb
a
se grows, onbo
a
rding new developers
a
nd m
a
n
a
ging dependencies
becomes h
a
rder.

Monolith
Disadvantages - 2
• Deployment Risks
• A bug in one module c
a
n bring down the entire
a
pplic
a
tion.
• Frequent deployments
a
re riskier
a
nd h
a
rder to coordin
a
te.
• Technology Lock-In
• H
a
rder to use di
ff
erent technologies or l
a
ngu
a
ges for di
ff
erent p
a
rts of the system.

Monolith
Modular Monolith
• Good
a
rchitecture will h
a
ve discrete modules/libr
a
ries with function c
a
lls between them.
• Module vs. Libr
a
ry
• Module is intern
a
lly developed
• Libr
a
ry is extern
a
lly developed

Monolith
Advantages of a Modular Monolith
• Encour
a
ges cle
a
n
a
rchitecture: Modules enforce sep
a
r
a
tion of concerns.
• E
a
sier to ref
a
ctor: You c
a
n extr
a
ct modules into microservices l
a
ter if needed.
• Simpli
f
ies deployment: Still
a
single deploy
a
ble unit.
• Improves te
a
m coll
a
bor
a
tion: Te
a
ms c
a
n work on di
ff
erent modules with minim
a
l
interference.

Monolith
Disadvantages of a Modular Monolith
• Intern
a
l interdependencies: Ch
a
nges to
a
module m
a
y require ch
a
nges to others.
• Still
a
single point of f
a
ilure: A bug in one module c
a
n
a
ff
ect the whole system.
• Sc
a
ling is co
a
rse-gr
a
ined: You c
a
n't sc
a
le modules independently.
• Requires discipline: Developers must respect module bound
a
ries to
a
void tight coupling.

Serverless Computing
Description
• Serverless computing is
a
cloud computing model where developers build
a
nd run
a
pplic
a
tions without h
a
ving to m
a
n
a
ge the underlying infr
a
structure.
• Despite the n
a
me, it doesn't me
a
n there
a
re no servers—it me
a
ns th
a
t server m
a
n
a
gement is
a
bstr
a
cted
a
w
a
y
a
nd h
a
ndled entirely by the cloud provider.

Key Characteristics - 1
• No Server M
a
n
a
gement
• Developers don’t provision, sc
a
le, or m
a
int
a
in servers. The cloud provider h
a
ndles
a
ll of
th
a
t
a
utom
a
tic
a
lly.
• Event-Driven Execution
• Code runs in response to events (e.g., HTTP requests,
f
ile uplo
a
ds, d
a
t
a
b
a
se ch
a
nges).
• Autom
a
tic Sc
a
ling
• The pl
a
tform
a
utom
a
tic
a
lly sc
a
les the
a
pplic
a
tion up or down b
a
sed on dem
a
nd.

Key Characteristics - 2
• P
a
y-
a
s-You-Go
• You’re billed only for the compute time your code
a
ctu
a
lly uses—no ch
a
rges for idle time.
• Short-Lived Functions
• Often implemented using Functions-
a
s-
a
-Service (F
a
a
S), like AWS L
a
mbd
a
, Azure
Functions, or Google Cloud Functions.

Common Use Cases
• REST APIs
a
nd microservices
• Re
a
l-time
f
ile or d
a
t
a
processing
• Scheduled t
a
sks (cron jobs)
• Ch
a
tbots
a
nd noti
f
ic
a
tion systems
• B
a
ckend for mobile/web
a
pps

Popular Serverless Platforms
• AWS L
a
mbd
a
• Azure Functions
• Google Cloud Functions
• Cloud
f
l
a
re Workers
• Netlify Functions

Advantages
• No infr
a
structure m
a
n
a
gement
• Cost-e
ff
icient for intermittent worklo
a
ds
• F
a
st deployment
a
nd iter
a
tion

Disadvantages
• Cold st
a
rt l
a
tency (initi
a
l del
a
y when functions
a
re idle)
• Limited execution time
a
nd memory
• Vendor lock-in risks

Microservices
Description
• Microservices is
a
n
a
rchitectur
a
l style th
a
t structures
a
n
a
pplic
a
tion
a
s
a
collection of sm
a
ll,
a
utonomous services, e
a
ch responsible for
a
speci
f
ic business c
a
p
a
bility.
• These services
a
re independently deploy
a
ble, loosely coupled,
a
nd communic
a
te over
a
network, typic
a
lly using lightweight protocols like HTTP or mess
a
ging queues.
• Compos
a
ble: comp
a
re to Unix/Linux comm
a
nds
a
nd pipes
• Components: comp
a
re to
a
udio equipment
• R
a
dio, turnt
a
ble, CD pl
a
yer, MP3 pl
a
yer,
a
mpli
f
ier, spe
a
kers

Microservices
Core Characteristics - 1
• Single Responsibility
• E
a
ch service focuses on
a
speci
f
ic business function (e.g., user m
a
n
a
gement, billing,
inventory).
• Independent Deployment
• Services c
a
n be upd
a
ted, deployed,
a
nd sc
a
led independently.
• Decentr
a
lized D
a
t
a
M
a
n
a
gement
• E
a
ch service often m
a
n
a
ges its own d
a
t
a
b
a
se,
a
voiding sh
a
red d
a
t
a
stores.

Microservices
Core Characteristics - 2
• Technology Diversity
• Te
a
ms c
a
n use di
ff
erent progr
a
mming l
a
ngu
a
ges, fr
a
meworks, or d
a
t
a
b
a
ses for di
ff
erent
services.
• Resilience
a
nd F
a
ult Isol
a
tion
• F
a
ilures in one service
a
re less likely to bring down the entire system.

Microservices
Typical Microservices Architecture
• API G
a
tew
a
y: Entry point th
a
t routes requests to
a
ppropri
a
te services.
• Services: Independently running components (e.g., Auth Service, Product Service).
• D
a
t
a
b
a
ses: E
a
ch service m
a
y h
a
ve its own d
a
t
a
b
a
se.
• Communic
a
tion: Often vi
a
REST, gRPC, or mess
a
ging systems like K
a
f
k
a
or R
a
bbitMQ.

Microservices
Advantages
• Sc
a
l
a
bility: Sc
a
le services independently b
a
sed on dem
a
nd.
• Flexibility: Use the best tools for e
a
ch service.
• F
a
ster Development: Sm
a
ll te
a
ms c
a
n work in p
a
r
a
llel.
• “Two pizz
a
” te
a
ms.
• Resilience: Isol
a
ted f
a
ilures reduce system-wide imp
a
ct.

Microservices
Disadvantages
• Complexity: More moving p
a
rts to m
a
n
a
ge.
• Oper
a
tion
a
l Overhe
a
d: Requires service discovery, monitoring, logging, etc.
• D
a
t
a
Consistency: H
a
rder to m
a
int
a
in consistency
a
cross services.
• Deployment: Requires orchestr
a
tion tools like Kubernetes.

Comparisons
Aspect Tr
a
dition
a
l Monolith Modul
a
r Monolith Microservices
Code
Org
a
niz
a
tion
Often t
a
ngled
a
nd tightly
coupled
Cle
a
rly sep
a
r
a
ted modules
with strict bound
a
ries
Independent services
Deployment Single unit Single unit Independent units
Sc
a
l
a
bility Whole
a
pp
Whole
a
pp (but e
a
sier to
isol
a
te bottlenecks)
Per service
M
a
int
a
in
a
bility H
a
rder
a
s
a
pp grows
E
a
sier due to modul
a
r
structure
E
a
sier, but more complex to
m
a
n
a
ge

Comparisons
Aspect Tr
a
dition
a
l Monolith Modul
a
r Monolith Microservices
Testing Simple but c
a
n be slow Modul
a
r testing possible
Requires integr
a
tion testing
a
cross services
Te
a
m Autonomy Low
Moder
a
te (te
a
ms c
a
n own
modules)
High (te
a
ms own services)
Oper
a
tion
a
l
Complexity
Low Low to moder
a
te
High (networking, orchestr
a
tion,
observ
a
bility)

Microservices
The Good, the Bad, and the Ugly
• Good
• Enforced modul
a
rity
a
round business c
a
p
a
bilities, simple deploy
a
ble components
• B
a
d
• Distributed systems h
a
ve complex inter
a
ctions
a
nd communic
a
tions
• Door D
a
sh h
a
s 500 services
a
nd requires 100 to pl
a
ce
a
n order; 1000 RPCs per order!
• Ugly
• D
a
t
a
b
a
se inconsistency

Microservices
Ideal
• Enforced modul
a
rity
• Independent te
a
ms
• Independent deployment
• F
a
st (function c
a
lls r
a
ther th
a
n network RPC)
• D
a
t
a
b
a
se consistency

GemStone
Can be a Classic Monolith
• One customer h
a
s 141 thous
a
nd cl
a
sses, 2.5 million methods,
a
nd 35 million lines of code.
• 152 thous
a
nd tests
• Common to upd
a
te
a
ll code
a
t once.
• Module bound
a
ries typic
a
lly depend on developer discipline.
• Accessibility of code
a
nd d
a
t
a
m
a
kes it tempting to bre
a
k module bound
a
ries.

GemStone
Zero-downtime Deployment
• In Sm
a
llt
a
lk, cl
a
sses
a
nd methods
a
re objects (code is d
a
t
a
).
• In GemStone, d
a
t
a
is modi
f
ied in
a
tr
a
ns
a
ction
a
nd immedi
a
tely
a
v
a
il
a
ble to other sessions.
• After
a
session
a
bort/commit, the next mess
a
ge send will see the new code.

GemStone
User Isolation
• E
a
ch login user h
a
s their own object gr
a
ph root.
• E
a
ch object h
a
s
a
security policy th
a
t speci
f
ies
a
ccess b
a
sed on owner, group, world.
• E
a
ch login user c
a
n de
f
ine code th
a
t is execut
a
ble but not directly visible to other users.
• E
a
ch “module” could be lo
a
ded into
a
design
a
ted user sp
a
ce.
• This would enforce module bound
a
ries but preserve perform
a
nce of function c
a
ll.

Microservices in GemStone
• Enforced modul
a
rity
• Independent te
a
ms
• Independent deployment
• F
a
st (function c
a
lls r
a
ther th
a
n network RPC)
• D
a
t
a
b
a
se consistency

Questions?
James.Foster@GemTalkSystems.com

Microservices The Good, the Bad, and the Ugly

More Related Content

Similar to Microservices The Good, the Bad, and the Ugly (20)

More from ESUG (20)

Recently uploaded (20)

Microservices The Good, the Bad, and the Ugly