The document discusses merging microservices architecture with SOA practices. It begins with background on the presenter and an agenda that includes defining and sizing microservices, DevOps practices for deployment, and avoiding fragility. Microservices are defined as small, independent, and process-isolated services. The document explores benefits and challenges of microservices, including proper sizing of services and managing dependencies. It provides examples of DevOps practices for loose coupling like service isolation and separate databases. The conclusion emphasizes starting small and reconciling SOA and microservices when sharing capabilities, APIs, and building applications.
2. 2
About
the
Presenter
• Chris Haddad
๏ VP
Pla?orm
Evangelism
๏ F500/G2000
Advisor
๏ Cloudy
DevOps
for
Dev
guy
๏ API
Strategy
and
SOA
Roadmap
consultant
๏ Former
Gartner
research
team
leader
Architect
๏ SaaS
and
PaaS
๏ Service
por?olio
and
infrastructure
๏ Data
management
๏ Java,
.NET,
JavaScript,
Open
Source
Learn more about me
• Follow me @cobiacomm on Twitter
• Blog: http://blog.cobia.net/cobiacomm
• Decks: http://www.slideshare.net/cobiacomm/
• Profle: http://www.linkedin.com/in/cobiacomm/
• On Google+ too
3. Agenda
• Service
Success
and
Service
Angst
• Are
microservices
the
answer?
• Microservice
Mindset
• How
to
properly
define,
decouple,
and
size
a
microservice.
• What
DevOps
prac9ces
overcome
microservice
deployment
roadblocks
• When
microservices
create
fragile
instead
of
an9fragile
building
blocks
3
6. Service
Success
–
Useful
Service
Blocks
6
Customer
Account
Inventory
Product
Payment
Order
Invoice
Fulfillment
7. Service
Success
–
Agility
at
Scale
๏ How
do
you
measure
agility?
๏ Have
services
increased
your
agility?
๏ Does
IT
service
agility
exist?
http://blog.cobia.net/cobiacomm/2013/03/19/accelerating-business-agility-with-app-factory-devops-paas/
9. Do
SOA
An9-‐Pa_erns
Prevail?
Symptoms
๏ Isola9on,
Uniqueness,
Duplica9on
๏ Tight
Coupling
and
Build
Again
Cause
๏ Lack
of
Trust
-‐
Not
Invented
Here
[NIH]
๏ Shared
Service
Invisibility
๏ Teams
do
not
know
about
a
service
๏ Non-‐func9onal
and
func9onal
requirements
are
not
well
documented
9
10. Tired
of
Big
SOA?
๏ Set
up
a
cross-‐func9onal
SOA
Working
Group
๏ Develop
a
SOA
Adop9on
Plan
๏ Define
Target
Service
Por?olio
๏ Develop
a
Business
Case
๏ Plan
and
Fund
Development
of
SOA
Infrastructure
๏ Establish
New
Roles
๏ Plan
Training
and
Mentoring
for
Staff
๏ Develop
Corporate
Policies,
Guidelines,
and
Best
Prac9ces
๏ Ins9tute
SOA
Governance
Processes
๏ Establish
New
Incen9ves
that
Reward
Good
Behavior
๏ Iden9fy
Candidate
Projects
๏ Establish
Priori9es
๏ Reassess
Your
Sogware
Development
LifeCycle
(SDLC)
10
13. Microservices
to
the
Rescue
Microservices
Defined
๏ A
small
problem
domain
๏ Built
and
deployed
by
itself
๏ Runs
in
its
own
process
๏ Integrates
via
well-‐known
interfaces
๏ Owns
its
own
data
storage
13
Source: http://www.brunton-spall.co.uk/post/2014/05/21/what-is-a-microservice-and-why-does-it-matter/
14. Microservices
to
the
Rescue
“designing
so<ware
applica?ons
as
suites
of
independently
deployable
services.”
Common
Characteris9cs
๏ organiza9on
around
business
capability
๏ automated
deployment
๏ intelligence
in
the
endpoints
๏ decentralized
control
of
languages
and
data
Source:
Mar9n
Fowler
h_p://mar9nfowler.com/ar9cles/microservices.html
14
16. SOA
==
Microservices
๏ Services
expose
a
business
capability
๏ Factor
applica9ons
into
composable
services
๏ Re-‐use
service
building
blocks
๏ DRY
(Don’t
Repeat
Yourself)
๏ Shared
service
delivery
๏ “Microservices
is
SOA,
for
those
who
know
what
SOA
is”
Source:
Steve
Jones
16
17. SOA
!=
Microservices
SOA
๏ Services
Deployed
in
a
Shared
Bus
๏ One
Team
Goal
๏ Centralize
Media9on
๏ Not
prescrip9ve
on
the
back-‐end
implementa9on
pa_ern
17
Micro-‐services
๏ Services
Deployed
at
the
Edge
๏ Teams
aligned
with
Business
Units
๏ Dumb
Infrastructure
๏ Prescribes
back-‐end
implementa9on
pa_ern
“SOA is a lame enterprise approach, whereas microservices are a cool hacker approach.”
Source: Ycombinator
18. Microservice
Roadblocks
๏ How
big
is
a
micro-‐service?
(UX-‐first
approach,
data
domain
approach)
๏ How
decoupled
is
a
micro-‐service?
(Dependencies,
versioning,
rou9ng,
linking
data)
๏ How
to
micro-‐size
a
business
capability
(granularity,
user
experience
composi9on)
๏ How
to
take
a
RESTful
approach
towards
managing
micro-‐service
dependencies
(DNS,
/etcd,
load
balancing)
18
19. Microservice
Myths
and
Legends
๏ The
NetFlix
Legend
–
QoS
and
rapid
delivery
๏ Micro-‐services
Foster
Rapid
Evolu9on
๏ Agility,
Crea9ve
Experimenta9on,
and
Dynamic
Composi9on
๏ Silos
are
good
(if
Micro-‐serviced)
๏ Containeriza9on
Panacea
๏ Lifecycle
Complexity
is
Overblown
๏ Micro-‐services
don’t
require
SOA
principles
to
succeed
19
20. Agenda
• How
to
properly
define,
decouple,
and
size
a
microservice.
• What
DevOps
prac9ces
overcome
microservice
deployment
roadblocks
• When
microservices
create
fragile
instead
of
an9fragile
building
blocks
20
21. DevOps
Prac9ces
Microservices
Pre-‐requisites
๏ Business
Domain
Responsibility
Decomposi9on
๏ User
Interface
Integra9on
๏ Communica9on
Protocols
๏ Data
Formats
๏ Redundant
Data
๏ Business
Intelligence
Interfaces
๏ Root
Cause
Analysis
(Logging,
Monitoring)
๏ High
Availability
and
Fault
Tolerance
๏ Dynamic
Service
Management
Adapted
From:
Stefan
Tilkov
h_p://www.infoq.com/presenta9ons/Breaking-‐the-‐Monolith
21
23. DevOpS
Pa_erns
Loosely
couple
๏ Bounded
Context
๏ Tolerant
Reader
๏ Consumer
driven
Contracts
๏ Ubiquitous
Language
๏ Silos
per
business
capability
๏ Separate
database
per
product
23
Source: Martin Folwer http://martinfowler.com/articles/microservices.html#MicroservicesAndSoa
24. Agenda
• How
to
properly
define,
decouple,
and
size
a
microservice.
• What
DevOps
prac9ces
overcome
microservice
deployment
roadblocks
• When
microservices
create
fragile
instead
of
an9fragile
building
blocks
24
25. Fragility
and
An9-‐Fragility
“An9-‐fragility
does
not
merely
withstand
a
shock
but
actually
improves
because
of
it.”
๏ Redundancy
๏ Clustering,
Service
Farms
๏ Failover
๏ Watchdog
monitors
,
Circuit
breakers
25
26. Fragility
and
An9-‐Fragility
“An9-‐fragility
does
not
merely
withstand
a
shock
but
actually
improves
because
of
it.”
Achieve
High
Availability
in
Distributed
Systems
through:
๏ Redundancy
๏ Failover
Tradi9onal
Service
way
๏
Dedicated
ac9ve-‐ac9ve,
ac9ve-‐passive
instances
Micro-‐services
way
๏
Dynamic
instance
provisioning,
graceful
degrada9on
26
27. Fragility
and
An9-‐Fragility
๏ Redundancy
Strategies
๏ Clustering
–
maintain
session
state
๏ Service
Farms
–
iden9cal
ac9ve
nodes
๏ Infrastructure
๏ Load
Balancers
–
route
to
available
nodes
๏ Elas9c
service
provisioning
–
spin
up/down
based
on
load
and
availability
27
28. Fragility
and
An9-‐Fragility
๏ Failover
Strategies
๏ Load
Balancers
–
route
to
available
nodes
๏ Watchdog
Health
Monitors
-‐
iden9fy
break
points
๏ Circuit
breakers
[h_ps://github.com/Ne?lix/Hystrix
]
๏ Infrastructure
๏ Intelligent
Content
Rou9ng
๏ Topics
/
Queues
๏ Management
Scripts
–
restart
service
instances
๏ PaaS
Service
Management
28
29. Start
Small
๏ Implement
SOA
principles
on
a
project-‐by-‐project
basis
๏ Iden9fy
rela9onship
between
services
and
business
capabili9es
๏ Build
a
top-‐down
and
bo_oms-‐up
data
model
๏ Work
with
your
Enterprise
Architecture
Team
29
30. SOA
&
Microservices
Reconcilia9on
๏ When
to
create
services
๏ Create
a
service
when
sharing
a
business
capability
๏ When
to
create
APIs
๏ Sharing
a
service
outside
a
domain
of
control
๏ Targe9ng
the
widest
possible
reach
and
consump9on
๏ Offering
the
service
across
na9ve
web
infrastructure
๏ Maximizing
asymmetric
evolu9on
between
service
clients,
interface,
and
implementa9on.
๏ When
to
create
and
use
microservices
๏ Building
an
applica9on
crossing
domains
๏ Ra9onalizing
and
consolida9ng
your
SOA
por?olio
30
32. References
๏ SOA
and
API
Convergence
Strategy
and
Tac7cs
๏ Promo7ng
service
reuse
within
your
enterprise
and
maximizing
SOA
success
๏ REST
Easy:
API
Design,
Evolu7on,
and
Connec7on
๏ Mar7n
Fowler
on
Microservices
๏ Stefan
Tilkov,
Breaking
the
Monolith
๏ Brunton
Sprall:
What
is
a
microservice
and
why
does
it
maJer
32