Today many organizations are leveraging microservice architecture (MSA), which is becoming increasingly popular because of its many potential advantages. MSA itself is divided into two areas – inner and outer architectures – which require separate attention. Moreover, MSA requires a certain level of developer and devops experience too. This talk will be an awareness session about MSA and will also discuss WSO2′s strategic initiatives in both the platform level and WSO2 MSF4J framework level.

1. Understanding
Microservice
Architecture
(MSA)
Sagara
Gunathunga
So7ware
Architect
WSO2

2. Monolithic
Applica-ons
Built
as
a
single
unit,
so
they
are
responsible
for
every
possible
funcConality:
handling
HTTP
requests,
UIs,
execuCng
domain
logic,
database
operaCons,
communicaCon
with
the
browser/client,
handling
authenCcaCon
and
so
on.

3. Drawbacks
of
Monolithic
u Even
smallest
changes
involves
building
and
deploying
the
whole
applicaCon.
u Scalability
issues
:
have
to
run
mulCple
instances,
even
if
you
know
that
boPlenecks
are
lay
on
one
component.
u One
technical
stack
is
defined
for
whole
soluCon,
without
considering
most
suitable
technology
for
each
components.
u High
coupling
among
project
teams.
u Can’t
evolve
or
replace
part
of
the
applicaCon
easily.

4. What
is
‘MSA’
?
An
architectural
style
to
developing
a
single
applica-on
as
a
suite
of
small
services
-­‐
Mar&n
Fowler

5. Monolithic
Vs
Microservice

6. ‘MSA’
-­‐
Two
Architecture
Viewpoints
The
Inner
Architecture
-­‐
Architecture
of
an
individual
Microservice.
The
Outer
Architecture
-­‐
Architecture
of
the
ecosystem
in
which
Microservices
will
be
built,
deployed
and
executed.
Inner
Architecture
Outer
Architecture

7. ‘MSA’
-­‐
Inner
Architecture
Inner
Architecture

8. Characteris-cs
of
Microservice
1.
“Micro"
is
a
concept
of
scope
rather
than
size.
A
microservice
must
have
a
single
purpose
and
be
loosely
coupled
in
design
• NOT
a
service
implemented
with
a
small
amount
of
code.
• NOT
a
simple
API
to
a
more
complex
service
implemented
as
part
of
a
monolithic
applicaCon.
• NOT
a
service
exposed
via
API
by
another
party

9. 2.
Microservices
should
be
independently
deployable
and
independently
disposable
Characteris-cs
Microservice
• Microservices
must
to
be
disposable.
If
a
microservice
fails
or
is
superseded
a
bePer
service,
then
simply
dispose
of
the
old
one.
• Require
lot
of
support
from
deployment
architecture
and
operaConal
environment
in
which
microservices
will
be
built,
deployed
and
executed.

10. 3.
Organized
around
Business
CapabiliCes
not
around
management
focused
teams
such
as
UI
,server-­‐side,
DB
Characteris-cs
of
Microservice

11. 4.
Decentralized
Data
Management
Characteris-cs
of
Microservice

12. 5.
Supports
Technology
Heterogeneity
among
services
Characteris-cs
of
Microservice

13. MSA
and
SOA
MSA
is
not
based
on
all-­‐new
architectural
principle;
It
combines
SOA
best
prac-ces
with
modern
applica-on
delivery
tooling
and
organiza-onal
disciplines.
+

14. ‘MSA’
-­‐
Outer
Architecture
Outer
Architecture

15. ‘MSA’
-­‐
Outer
Architecture
• Service
Gateway
•
Expose
services
as
managed
APIs
• Provides
traffic
and
policy
(security)
management
• Service
RouCng
• Route
message
to
right
service
based
on
clients
and
service
polices
• Load
Balancing
• Support
service
scalability
• Service
Discovery
• Register
and
find
services
and
endpoints
dynamically

16. ‘MSA’
-­‐
Outer
Architecture
• Shared
configuraCon
• Sharing
configuraCon
details
among
new
nodes.
• Dependency
management
• Track
and
manage
dependencies
among
services
• Messaging
channels
• Support
asynchronous
communicaCon
based
on
publish/subscribe
and
event
sourcing
paPerns.

17. MSA
challenges
–
End
to
end
Monitoring
1. Service
level
(APM)
&
deployment
level
dashboards
2. TransacCon
tracing,
replay
and
log
analysis
3. Service
InstrumentaCon

18. MSA
challenges
–
Security
1. AuthenCcaCon
and
AuthorizaCon
2. Security
context
propagaCon
among
services

19. MSA
challenges
–
Service
Discovery
• Client-­‐side
Service
Discovery
• Server-­‐Side
Service
Discovery

20. MSA
challenges
–
Deployment
Scalability
• ApplicaCon
pladorm
as
a
service
(aPaaS)
• WSO2
AppCloud
• OS
container
management
systems
• Google
Kubernetes
• Apache
Mesos
• Lightweight
server
OS
• CoreOS
• Atomic

21. MSA
and
WSO2
Although
aPaaS
pladorms
come
closest,
they
are
sCll
general-­‐purpose
pladorms,
and
there
is
currently
no
such
thing
as
a
holisCc,
commercially
supported
"microservice
pladorm"
that
brings
together
all
of
the
necessary
capabiliCes.
- Gartner (January 2015)
WSO2
offer
….
①
A
compeCCve
Microservice
framework
to
support
“Inner
Architecture”
(WSO2
MSF4J)
② A
complete
pladorm
to
support
“Outer
Architecture
“
(
AnalyCcs,
Security,
discovery
,
gateways,
MQ
etc.)

22. MSA
and
WSO2
Service
Gateway
Service
Rou-ng
Service
Discovery
Shared
Configura-on
Dependency
Management
Messaging
Monitoring
Security

23. WSO2
MSF4J
2.30
PM

24. MSA
Drawbacks
• Complexity
Is
Moved
Not
Removed
-­‐
Understanding,
managing
and
tesCng
dependencies
is
difficult.
• Centralized
governance
is
not
possible
-­‐
Large
numbers
of
Microservices
are
difficult
to
orchestrate
• Increase
Network
communicaCon
-­‐
Independently
running
component
interact
with
each
other
using
N/W
calls.
Such
system
require
reliable
and
fast
network
connecCons.

25. MSA
Drawbacks
• Network
Security
-­‐
Inter
Service
CommunicaCon
need
to
be
secured
to
avoid
any
inter
communicaCon
security
breach
these
applicaCon
are
more
prone
to
security
vulnerabiliCes.
• ProducCon
monitoring
-­‐
Monitoring
the
applicaCon
in
producCon
deployment
becomes
a
complex
job,
with
mulCple
services.

26. Thank
You