MicroservicesSOA reminded of what it
was supposed to deliver?
Jeppe Cramon - @jeppec
µService Conference London
2014
SOA or Microservices?
Better ROI, More Security, Fewer Defects, Reusable assets, Better Maintainability, More reuse, Better parallelism in development, Better scalability, Higher availability….
… building blocks that can be reused and tweaked as needed. There’s also a redundancybenefit: Should one … fail the other ones will work in the app.
Higher reusability, significant reduction of development cost, increased reliability, improved maintainability, enhanced quality…
For years no one talked about
SOAMostly because of the many failures…
Example:I've used service-oriented architecture for the better part of a decade, and I can honestly report the following …
Source: http://www.techrepublic.com/blog/tech-decision-maker/the-unfulfilled-promise-of-soa/
• I have never seen the "contract" feature of any service I've written or designed be leveraged to enable its re-use
• I have never seen a service from one system be recoupled to another• I have never seen encapsulated logic used in multiple applications
In my opinion SOA is not to
blame for the dissapointment
I believe that Microservices is a
welcome opportunity to brush off
the dust, learn form the past and
perhaps improve
Beware of
sales pitches
The fine-grained, stateless, self-
contained nature of
microservices creates decoupling
between different parts of a code
base and is what makes them
easy to update, replace, remove,
or augment.
Microservices: The resurgence of SOA principles and an alternative to the monolith
Trying hard to pretend it’s not difficult to develop distributed systems
It seems the argument is that just
by making things fine grained
We by magic achieve decoupling
Decoupled?
Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx
Monoliths are often blamed for being
the lasagna of software due to
coupling
Spaghetti in layers
So if we keep up the same
habits that resulted in messy
monolithsWhat’s makes us think that we
won’t end up with
Microservice spaghetti?
Most “Services” today are built
on top of Monoliths
Monolith A Monolith B
Monolith C Monolith D
Service A.1
Service A.2
Service A.3
Service A.4
Service B.1
Service B.2
Service B.3
Service B.4
Service D.1
Service D.4
Service D.3
Service D.2
Service C.4
Service C.3
Service C.2
Service C.1
DB DB
DB DB
Monolith A Monolith B
Monolith C Monolith D
If we create naïve
microservices
Service A.1
Service A.2
Service A.3
Service A.4
Service B.1
Service B.2
Service B.3
Service B.4
Service D.1
Service D.4
Service D.3
Service D.2
Service C.4
Service C.3
Service C.2
Service C.1
DB
DB
DBDB
DB
DB DB DB
DBDBDB
DB
DB DB
DB
DB
DB DB
DB DB
Then we’ve IMO just gone from
bad
To Worse
So does that mean that
breaking things apart is a bad
thing?
Definitely NOT!
But we need some guidelines to
avoid things becoming messy
(once again)
So how do we get there?
Let’s look at some of the
characteristics of Microservices
(that most seem to agree upon)
Microservice characteristics
• Single Responsibility Principle (SRP)
• Small
• Own process
• Valuable
• Replaceable
• Upgradeable
• Independent
• Encapsulated
• Composable
• Testable
• Fast startup/shutdown
• Client friendly
Single Responsibility Principle
(SRP)
Billing
DB
Order Fulfillment
DB
SMS Gateway
Shipping
DB
Management Reporting
DB
A Service should have a single responsibility
and
this responsibility should be entirely encapsulated within the service
Does a Microservice own its
data?• Remember layered SOA?
• IMO a service that only deals with data persistence is best called a database/datastore
• It already has a nice API– We don’t need to bubble wrap it with REST or
Async messages
• Don’t split the atom – we need cohesion as well as decoupling!
• If we want datastore abstraction (so we can swap out Postgresql with Mongo or Redis) there this little pattern called Respository.
So how big/small should a
microservice/responsibility be?
But I’ve heard that a
“Microservice should be no larger
than 100 Lines of Code!?”
Enough already!
When did we get away from solving business problems and start
talking technology, JSON over XML, REST, LoC’s, Frameworks again?
It reminds me of the early SOA
daysAll that was talked about then was which ESB
to purchase, to how set it up, etc.
No body discussed the problems that the
ESB was supposed to solve (or when it was
appropriate) or what services to build.
We were caught in technology silver bullet
again!
We kind of forgot that
SOA was about business
agilityIt was too much
“Build it and they will come”
There is value in making
things smaller
For one thing it easier to reason
about them in isolation
Going small has its advantages
Source: @aviranm
SRP
This sounds really good but what
about cross Service relationships?
Customer Orders
Products
Beware…
When we break up big things
into small pieces we invariably
push the complexity to their
interaction. Michael Feathershttps://michaelfeathers.silvrback.com/microservices-until-macro-complexity
Should we replace joins with
RPC?
Change Address Response
ConsumerChange Address Request
Provider
RPC or Request/Response - Synchronous 2 way communication
Remote Procedure Call
Request/Reply – Asynchronous 2 way communication
Consumer Provider
Change Address RequestChange Address
Request
Change Address
Reply
Change Address
Reply
Request
Channel
Reply
Channel
VS.
Size this and Size that!
Be Careful
If Microservices are good, then
Nanoservices must be even
better?
Why not one-liner services?
Nano Services
Unless we have a very reason for doing so,
we risk building services
that are so fine-grained
that their costs outweigh their utility*
*Read Arnon Rotem-Gal-Oz’s Nano Services Anti Pattern:http://arnon.me/wp-content/uploads/2010/10/Nanoservices.pdf
Microservices are valuable
The value of a microservice must
exceed the cost of building &
operating it.
Microservices entail costs for serializations, deserializations, security, communication, maintenance, configuration, deployment, monitoring,
etc.
Too small services
With too small services there’s a big risk that what’s left
of coherence goes out the window and we get:
• Communication-related and Layered coupling– E.g. Logic and persistence are not the same service
• Temporal coupling – Our service can not operate if it is unable to communicate with the
services it depends upon
• Behavioral coupling– Our services assume behaviors with regards to what and who.
– The sender/client determines what to do and knows something about
how the receiver/server should satisfy the request
Microservices == distributed
objects?
Service star chart
Service Dependencies
Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx
All these services needs to be
integrated
And often in the form of
Request/Response calls
(and often over the network – aka
RPC)
Synchronous Remote Calls
can lower our Fault tolerance• When servers crashes
• When databases are down
• When deadlocks occurs in the database– Do you retry?
With synchronous RPC style Services interaction we can easily loose business data unless we use an Orchestration engine or find another way to achieve call/retry semantics, combined with compensations and lifecycle handling.
Note: Automatic retry of calls only works if our Service operations are idempotent.
Also remember: REST isn’t
magic!
What’s less fat – XML or JSON?
• They’re equally slim and fast!
• http://balisage.net/Proceedings/vol10/html/
Lee01/BalisageVol10-Lee01.html
RPC and Distributed computing
• As soon as a service request/response
calls to another service across the
network we must adhere to the laws of
distributed computing*.
– Reliability, Latency, Bandwidth,
Transportation costs, Security
• If the other services is not available then
my service cannot conduct its business,
which minimizes my services autonomy
* See http://www.rgoarchitects.com/Files/fallacies.pdf for a walkthrough of the 8 fallacies of distributed computing
Service autonomy
Service
B
Service
C
Service
A
System X
Service
A
System Y
Service
B
Service
C
System X
Slow/unreliable network
Different SLA
Slow system
A distributed system is one where
a machine I’ve never heard of
can cause my program to fail.— Leslie Lamport
Availability goes down(without additional instances of each service)
Service A
Service B
Service C
Availability: 99% Availability: 99% Availability: 99%
Combined availability: 97%
Decide if you can live with the
consequences of coupling
services to each other using
Request/Response
Different situations – different tradeoffs
SOA was about business
agility through IT/Business
alignment
Which require maturity
• Organizational maturity
Be aware of Conways Law
“organizations which design systems ... are
constrained to produce designs which are
copies of the communication structures of
these organizations”
Teams are typically aligned with Systems/Projects and NOT with Services as I
believe they should
Which require maturity
• Organizational maturity
• Technical/operations maturity* – DevOps
– Build
– Test
– Deployment
– Monitoring
– Etc.
* See: http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
We need a strong foundation for development to
achieve thisA
lign
me
nt
Hig
hly
alig
ned
Less
alig
ned
EffciencyLess effective Highly effective
”Maintenance Zone” ”Well-Oiled IT”
”Alignment Trap”
11%
74%
7%
8%
+13
-14
-2 -15
+11
-6
+35
”IT enabled Growth”
% of the 504 respondents % difference compared to the overall averages IT spending
Combined yearly growth-rate over a 3 year period
Sou
rce
: Bai
n A
nal
ysis
+0
To break things up
We need to understand our business and its processes
-
How is data flowing?
In order to build the right
boundaries
Claim
Most of us are trained to think in Entities and Structural models and this is where we get our selves
into trouble.
We create big entangled models and forget
about model boundaries and different consistency level requirements!
The mental capacity required to
understand big domain models
is huge
Many perspectives on data
Online Retail System
Product
Unit PricePromotional PricePromotion End Date
Stock Keeping Unit (SKU)Quantity On Hand (QOH)Location Code
PriceQuantity OrderedName
The lifecycle of the data is VERY important!
Customer
Pricing
Inventory
Sales
Management Reporting
Different perspectives on
entitiesWith in a given Domain, e.g. Retail, there will exist multiple bounded contexts/sub-domains/business capabilities such as:
– Product management– Purchase– Sales– Pricing– Inventory– Shipping– Support– Accounting– Management
Each of these lines of business have very specific and unique needs which are relevant for them alone in order to conduct their business. They might use the same name for the entities they’re interested in or they might use different names for the same logical entity.
BillingBounded
Context
Product
CatalogueBounded
Context
Shipping Bounded
Context
Sales
Bounded
Context
Inventory Bounded Context
PricingBounded
Context
Retail domain split into a
Macro architecture
What’s a macro architecture
• It’s the static/stable(r) parts of your
architecture
– Which are very costly to refactor and change
• Closely aligns business capabilities /
bounded contexts with services
DDD doesn’t enforce
problem domain and solution
domain alignment for Bounded
Contexts
Which is why I prefer to use the
term Business Capability
Service and Business Capability
alignment“The advantage of business capabilities is their remarkable level of stability. If we take a typical insurance organisation, it will likely have sales, marketing, policy administration, claims management, risk assessment, billing, payments, customer service, human resource management, rate management, document management, channel management, commissions management, compliance, IT support and human task management capabilities. In fact, any insurance organisation will very likely have many of these capabilities.”
See http://bill-poole.blogspot.dk/2008/07/business-capabilities.html
Don’t split into services too
early
Cross boundary refactoring is
costly
A Service is
• The technical authority for a given businesscapability
• It is the owner of all the data and business rules that support this business capability –everywhere
• It forms a single source of truth for that capability
• This form of business and IT alignment ensures that we can maintain service Autonomy & Encapsulation
So where does that leave
microservices?
Service and deployment
• A Service represents a logical boundary
• Logical responsibility and physical deployment of a service DOES NOT have to be 1-to-1
– It’s too constraining
– We need more degrees of freedom
– Philippe Krutchen 4+1 views of architecture: Logical and Physical designs should be independent of each other
A service needs to be deployed everywhere its data is needed
Service
Service Microservice
1..*
Is implemented by
A Service is the technical authorityof a specific Business Capabilitye.g. Sales, Shipping, Billing
Services are the implementation of business processes.Business processes can span multiple services, but there will always be a single service that is the actual authority on the business process.
Service
Service Microservice
1..*
Is implemented by
Microservices are a division of Services along Transactional boundaries (a transaction stays within the boundary of a Microservice)
Microservices are the individually logical deployable units of a Service with their own Endpoints. Could e.g. be the split between Read and Write models (CQRS) - each would be their own Microservice
Also known as Autonomous Components
Microservices are logical
deployable units
That doesn’t mean they HAVE to be deployed individually.
Design for Distribution
But take advantage of locality
Services are the corner stone
• We talk in terms of services, business capabilities and the processes/usecases they support
• Microservices are an implementation detail
• Microservices are much less stable (which is a good thing – it means they’re easier to replace)
• A microservice in one service can subscribeto events from another Service or calloperations on another Service (which again is implemented/supported by an internal microservice)
Coupling matrix*
* Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/
Behavioral
coupling
Temporal
coupling
Low High
Low
High
Event oriented Command oriented
Emergency services Distributed 3 layer
Using Business Events to drive
Business Processes
Sales Service
Shipping
Billing
Sales
CustomersB
us
Online Ordering System
Web Shop
(Composite UI)
Billing Service
Shipping ServiceOrder
Accepted
Event
AcceptOrder
Command
The sales
fulfillment
processing
can now
begin…
Cascading events give rise to
business processes
Event driven process
Sales ServiceOrder
Accepted
Billing Service
Orderfulfilment ServiceProcess Manager/
Saga/
Orchestration-Engine
Shipping Service
Online Ordering System
Bu
s
Order
Accepted
Order
Accepted
Customer
Billed
Customer
Billed
Order
Authorize
d
Order
Authorize
d
Works as a Finite
State Machine
(WorkFlow)
handling the life
cycle of Shipping
and thereby forms
a very central new
Aggregate in the
System
This form of architecture is called
an
Event Driven Architecture (EDA)
SOA and EDA are two sides of
the same coin
So are Microservices the
future?Gartners Pace layered Application strategy:
• Systems of Record — Established packaged applications or legacy home-grown
systems that support core transaction processing and manage the organization's
critical master data. The rate of change is low, because the processes are well-
established, common to most organizations, and often are subject to regulatory
requirements.
• Systems of Differentiation — Applications that enable unique company processes
or industry-specific capabilities. They have a medium lifecycle (one to three years),
but need to be reconfigured frequently to accommodate changing business practices
or customer requirements.
• Systems of Innovation — New applications that are built on an ad hoc basis to
address new business requirements or opportunities. These are typically short
lifecycle projects (zero to 12 months) using departmental or outside resources and
consumer-grade technologies.
• "These layers correspond to the notion of business leaders having common ideas,
different ideas, and new ideas,"
Conclusions
• In my opinion Microservices is one SOA delivery model
• Focus should be on aligning Services to Business Capabilities
– Make service as small as possible and as big as
necessary
• Beware of the coupling matrix – avoid synchronous
communication between services unless you’re ready to pay
the price
• Implement Services as a set of Microservices that are
logically deployable and divide them along transactional
boundaries
• Be aware of the requirements for organizational, business and
technical maturity
• If we can get there then I believe Microservices will be able to
help us achieve a some of what SOA promised, but due to
different factors rarely delivered
Thank you
Jeppe Cramon
TigerTeam
www.tigerteam.dk
www.tigerteam.dk/category/soa/
www.tigerteam.dk/category/soa/microservices/
Twitter: @tigerteamdk and @jeppec