One Journey, Many Paths: A Pragmatic Guide for Migrating to Microservices

Z. Dehghani

Recorded at GOTO 2017

Get notified about Z. Dehghani

Sign up to a email when Z. Dehghani publishes a new video

before we get started I just want to say
thank you to go to con organizers I have
a nine month old little baby she's there
supporting mom and I we live in San
Francisco and I haven't really slept a
single night without her and the
organizers kind of accommodated the
three of us in the hotel I made it
possible for me to be here so thank you
again and the oldest queue and all the
parents who left their children at home
and traveled here made the fourth ski
with you so let's get us started the
journey from legacy system to market
services is an epic one unlike any epic
journey it starts with a dream and a
billion of the fire in the belly and a
bit of a pain in the back so for a lot
of our clients but pain their experience
is that they're stuck they can't change
their systems it costs too much and it
takes too long make changes so they
dream about market services so that they
can either scale their operations have
many teams building features and
capabilities for their growing market or
be able to experiment with their core
capability and by experimentation I
don't mean that the certainly changing
UI and do some sort of a B testing to
see how our customers respond
experimenting with their core business
if you're in a telco you know you're you
know product manager dreams of being
able to bundle between different
offerings together and experiment with
those if you're in insurance you know
industry you want to try with different
customer segments and policies for
different risk factors or in retail or
supply chain you want to be able to try
this routing algorithms to get the good
from warehouses to the stores and it's
really hard with legacy so their journey
starts with a courageous leader take
your leap of faith and basically starts
with building services around the edges
you know forward thoroughly decoupled
maybe some facade services in the
digital world to face your mobile
application and that that pays off
quickly you know we can get some quick
wings but the green doesn't get realized
until she faces the monolith deep in the
valley and that's going to be a hard
battle because that's where she needs to
kind of decouple core capabilities the
customers like customer information the
master product definition so that she
can experiment and change those more
rapidly and I have to be honest with you
this is a bloody battle and many we lose
a lot of people along the way the cost
of the first service I recall for one of
my clients was about two million dollars
so they got kind of disheartened and
quit the whole journey and not her Jen
is not over yet
so the battle that the journey continues
with an uphill push and a long climb of
changing organization along the way and
building the backbone delivery
infrastructure so you can actually host
them run the services so this is where
the protagonist of our story really gets
tested but arriving you know tasting the
sweet arrival of getting a capability or
asset on love she will forget all the
pain and do it over and over again so
just get a sense of the audience here
who feel that they are kind of in that
free fall not so much it's a free fall
you have a parachute building services
around the edges in the digital part of
the corporation okay a couple who are
deep in the valley decoupling services
are from a monolith only one to CEOs
okay few people told me it's a hard one
and who feel the kind of decline of
pushing the change through the
organization you made it up the hill
okay great so it's going to be an
action-packed talk and I know it's the
last person the day during the day but
hopefully we can get through this
together I'm going to start with kind of
overview of market services I have to
apologize from people who have been
sitting on this track I feel like like
every other
speaker I felt compelled to give you a
definition who write the services but
I'm going to promise it's going to be
short and painless I'm going to go
through it quickly and then we're going
to talk about seven kind of techniques
that can you can use for decoupling
capabilities out of my out of monolithic
systems and at the end we're going to
kind of come back and cover a bit of a
breast at a high level what what you can
I guess the processes and approaches we
can take to goes a long way to do the
market architectural evolution and go
through the transition at the
organizational level all right the dream
the dream of market services record
system if you realize I kind of
emphasized the word ecosystem quite a
bit in my talk because I feel we've
moved on from micro-services just being
an architectural style of you know post
continuous delivery and has evolved to
be a way we organize a team the way we
allocate budget and the way we the
capable the operational capabilities
that we built so a quick architectural
evolution history I'm going to be really
really quick the first dinosaurs then
the monolith that we got really smart
with kind of so intelligently integrated
services with middleware who got
fascinated with NP r--'s with
applications you know where specialized
hardware and software was designed for
certain technical capabilities web layer
and application server for the business
logic and database clusters to keep our
data and this is the point that we
started kind of playing with the micro
services usually as I said is in the
digital organization the morning go part
of our organizations we started building
facade services that represent some of
our capabilities but if you look behind
the scene there was still and monolith
whether it was the database share state
keeping this state or it was it's still
a legacy system keeping the behavior and
entangling the services and then we
reach the peak of revolution of micro
services well we felt you know quite
believes and we started building
services tiny services around business
capabilities and we you know form teams
around the business capabilities and
those services
everything was completely autonomous and
take care of the full stack of building
and running their services we started
arguing how tiny these services need to
be and they were talk given on the size
of the micro service and those a lot of
companies I get benefited from the state
collaboration we hear a lot of sad
stories that companies who we're in
really mature enough for operation
operating this level of kind of autonomy
they really had they felt a lot of
friction between the teams to get
anything working day itself a lot of
duplicate working costs are carrying
across the team's building the foods
that support and I feel what I what I
see now in the industry is that we are
we are maturing and we're reaching in
more I guess state of equilibrium with
what I call micro services ecosystem on
a platform we are at making an
abstraction of our you know the lower
level of operations in our compute
engine has its own services and API
whether you're running an Amazon or you
know Google Cloud you've seen that our
data layer has its own API to use and
we're building a platform of API and
most importantly self-serve kind of API
is exposed by these services so we are
removing that those kind of high
friction of using services of each other
services by introducing the product
thinking and platform thinking and I and
I fashioned this in a little while so
what are the fundamental characteristics
market services around business
capabilities I won't take this just a
little bit further when we started I
guess I am like in my experience when we
started thinking about services we had a
very kind of data centric it's easy to
think about Wesley stressful resources
as you know the data assets that we have
customers and orders and products but
what I want to encourage you to think
about is kind of high level higher level
of abstractions with your business
capability for so if you're working in
retail the you know you have a store
tolerably an asset or resource that
shows the stores but you have a
capability for a customer to be able to
of an island that evils both online on
store so it's a higher-level kind of
business capability you can encapsulate
which will use another service like a
sir store locator there's a good insight
article and thought worse if you're
interested around
well factored well factor services where
you can get them of our ion you know
your service refactoring we talked about
restful kind of dumb in sorry smart
endpoints down pipes using restful api
for for micro service that's what
happens when you bring your baby to the
conference she starts crying so yeah so
we use kind of successful API Department
of integration I want to take that one
step further with kind of the maturity
that we've seen over the last few years
on using API for integration we now look
at API at products and there is actually
a good coverage offense on take later
where developers consuming the API is
get the same treatment that the end user
would get using our you know mobile or
applications or any other user facing
application we apply the same user
experience I guess methodologies to
developing arity as good documentation
you know for different personas of the
developers consuming API with ability
accessibility having a console so they
can play so we kind of take that a step
further and the most fundamental
characteristic is that they can be
released independently and teams being
aligned around them a lot of the
speakers for this track already talked
with once I kind of skip through it and
and finally built on and self self
served platforms if you think about your
your operational stack where you run
them or orchestrate them think about
those capabilities also as API is
exposed in a self-service way to people
who write the services I think I
remember once using shared services was
almost a swear word in when we started
thinking about micro services but I
think by moving to product thinking and
so serve aspects of shared services that
no longer the case okay I promise it was
going to be fast so ready for the battle
good let's do it
number one because of the most
constraining factor early the knots I
still need a good name for this but
let's go with the knot for now so
basically remember that free fall of the
cliffs we started with kind of fairly
already decoupled services usually the
good candidate is let's just a couple
our authentication or you know a couple
of facade services but not when you get
to the money list you really want to go
for the heart where the the most of
things is part of your code that makes
everything else entangled what do I mean
by that let's give you an example I I
can challenge you that if you are
building web applications you probably
have a concept a bunch of classes or a
class that represents you web sessions
and session is a trap for all sorts of
you know parameters around the user
interaction that have been user
she has been authenticated session
usually coupled everything else we had
in one of our clients we were decoupling
if the retail system we were decoupling
different capabilities and we will shine
away with this session because nobody
knows what it was in it and everybody
every kind of other piece of code with
using it and that is stopped us to all
mostly couple anything else we always
went like oh we need to be composition
and please do not create a session
service somewhere in your topology
because all you're doing you're dragging
out all those tight coupling that were
interested in that other process in a
distributed system we have done that
don't do it so create create those
I guess concepts that are hidden and
trapped right now in decision probably
your customer interaction probably an
event log that represents you custom
into that customer interaction customer
preferences identity authentication and
so on and a tool that you can use to do
that you can use
structural analysis kind of tools to
find these tightly coupled kind of God
dependencies in your code okay number to
explore to build the couple capability
in our code so when you think about the
coupling in monolith we we always quite
bias towards the code we have written
and we so is just too precious to throw
it away but in my experience we often
underestimate how much it cost to reuse
code so the the recommendation here is
instead of using the code we implement
the capability and retired old code the
reason for that is because the code we
have written has aged and kind of old
assumptions around how it's going to run
where it's going to run and those
assumptions or environmental assumptions
are no longer true because at the time
that you migrating from Marshall
services very likely you're migrating
your delivery infrastructure and when
you're going to run you'll probably go
into cloud or you know going to path so
at the time you wrote but the previous
generation you weren't thinking about
total factor application principles so
how you were reading environment
variables how you were acting did all
this boilerplate code that we write are
tightly coupled to how we run that
application before so if you call it
this lot is the simple web application
or a simple application and doesn't have
a lot of intellectual property or you
know kind of complex algorithms it
doesn't do image recognition probably
those boilerplate code can be rewritten
and less costly to do that and the code
you can use or the tool you can use to
to help you make a judgment call whether
you should reuse the code or not is code
toxicity analysis tools to see how toxic
or have what was the quality of the code
that we are investing in to the couple
number three so what shall we decouple
of course with a couple something that
matters I heard these kind of quote from
Neil Ford and he might have been coded
one else but Sena evolving architecture
and the couple mother's is less like
playing with Lego pieces and most more
more like Orion surgery and if anybody
in the crowd the people who put their
hands up about the coupling kind of
services out of them unless probably
know what I mean by that the cost is
quite high so if you want to choose a
capability to decouple choose the one
that is getting a lot of love the one
accessed by users and has high value how
can you find that out well we can use
social code analysis tools like code
scene to see the pattern of the change
who's touching the code how often it's
being changed you kind of need to also
be careful with filtering out the noise
I've seen a lot of build systems that
kind of a view commit the code they run
a trigger to kind of touch touch some
files that has nothing to really to do
with the the high value change so you
want to kind of filter out those those
ones all right number four how should we
decouple capabilities so one of the
characteristics behind micro services is
that we can release you know we can
release the service independently of
each other and we know that kind of our
monolith internally it has still these
layers of kind of user interface and
domain services and you know kind of
data layer and very often when we start
you know getting capabilities out of the
monolith we find it very difficult to
change maybe the facade or the interface
to that capability why because we have
old applications and us accessing the
monolith that part we may be just
extract some back-end services we would
never kind of expect traffic data
because the data shared who knows who's
touching it so we can't do that
so we'll really encourage you to
decouple kind of you know slice through
you're at your capabilities from the
interface that it exposes to other
applications to its domain in
fermentation and the data or
communication with downstream services
kind of get a vertical slice of that to
be able to completely get the benefits
of Independence released ability so when
we talked about the anti patterns that
couple and if you really find it
difficult at the time I've experienced
this we have release capabilities that
we we couldn't change the interface and
it's still old you know clients were
touching the old man of it I would I
will probably be cautious about doing
decoupling without those kind of
vertical slicing number five minimize
dependency back into the monolith so why
are we migrating from analyst to micro
system ecosystem because changing
monolith is bloody hard it costs a lot
and it's painful so if the stress
services in a way that our core
capabilities are still locked up inside
the monolith we will be going back
probably to the mothers to make changes
so that my advice is if you really have
gone through different trade-offs to
pick the service and you go or between
the service and a and B I don't know
which one to pick
I would say pick the one that doesn't
have dependencies back to the monolith
and if you think about that first tactic
that we talked about take the one which
everybody else depends on and if you do
that iteratively you probably end up
with with this style we're seeing you
know you get a capability of you
redirect your channels to that and if
the monolith has a tendency to it that
okay but in some cases this is not
possible right
we still have dependencies back to the
monolith I give you an example we were
working on a project where there was a
lot of demand from our kind of business
side to change it with a retail system
to change the bypass how we
kind of comfort customers potential
customers to real customers they go from
you know their carts and Verizon
products to actually making it purchase
and that's an area the buy service if
you think about it and I needed a lot of
change and we decided okay that someone
to take out but the buy service had
dependencies to offer how we you know
get to give discounts to the customers
and offers and that was a still stuck to
the in the boundaries and because of the
release pressure and you know the
prioritization coming from the business
were I really able to take the offer
offered service out than then buy so we
decided to invest a little bit in the
money let's build API and expose API was
added them on an offer every other out
of the monolith and take the buyer but
rationally we probably should have done
it the other way around and if you have
a dependency back to them on this tooth
API bill anti-corruption layer in your
service so that in future
it came talk to a different service
different independent API number six so
max within micro actually stole this
one-time doesn't matter and so it's you
know the early days of my service
without really excited so we started
with kind of this whiteboard Academy
exercise of what are the right
boundaries and seeing for you know
decoupling our services and we brought
that those in a kind of data centric
view of the world and practices around
building rational databases and we
designed this well normalized they you
know kind of set of micro services
around around the data and really tiny
services but that that can be quite
painful if you're not operation is ready
to to handle a large number of services
so my suggestion would be if you're
studying think about larger kind of
services that it may contain a few
different smaller ones and in future you
can kind of be coupled them I had
someone coming to me and asking well we
had this capability we pulled it out
with too late to different services and
now we realize that oh we decouple
across it
transactional bounder and I now have to
deal with distributed transactions and
we have to kind of invest a lot of
effort into that or maybe just
suspicious services back together a good
example of that is a company called
stripes they provide credit card access
API to retailers and what they've
decided is that the past a certain path
within their credit card payment process
it has to be an atomic transaction I've
decided but that's not going to be a
microsystem there's going to be kind of
a macro service or a monolith and that's
perfectly fine however if you feel like
ok I'm not a person already I'm going to
try to build kind of macro service but I
know that logically there are different
resources here you can still use
hypermedia and hyperlink to those
services that they happen to he keeps
the same kind of end point in terms of
decouple those into separate physical
services and you probably won't get
affected at the promises you know kind
of restful services with with hyper
medium the final one migrates in atomic
steps of architecture evolution and if
you want to take one thing away from
this talk I really want it to be based
when I kind of came to this conclusion I
got so excited and maybe it's obvious to
everyone but it wasn't really obvious to
me and what's behind this technique is
the acceptance that when we evolve our
systems we usually get worse before we
get better and in a lot of times there
is this myth that we can you know we can
evolve our systems and move away from
legacy to micro services before we run
out of money or end up a life and that's
seriously a me so that's why enterprises
today are such a mess because they've
gone through so many rounds of
architectural evolution but in every
round they haven't a couple better place
so you got into a Messier place so you
have three system does the same thing
five system keeps
very information that nobody can get
access to so what shall we do I think we
should climb out architectural releases
in a way that we don't finish that you
know evolutionary step until we are
keeping a little bit of a better place
let me give you an example we were
building a authentication service out of
this monolithic retail e-commerce
application so anyways the first service
I just want to get a feel for what it's
like to build a service in this new
world so we build this new off based
kind of authentication service and we
created a path within the monolith so
that the new clients can touch them on a
list and then go through this new path
of authentication to the authentication
service and we didn't really change the
existing client so what we ended up with
was to execution path a switch somewhere
in the code that said oh if you coming
through this you know Oh
based authentication go to this service
and if you were still using the session
based valid authentication go to this
other path and our intention behind
doing that evolution was in the first
place get speed of delivery have we
really got closer to that state is it
faster to implement now in this world
the next poor soul who comes across this
code if then it's probably spend more
time to figure out how to make the
system work so we actually devolve that
evolved kind of if you look at that
diagram and that's what this diagram
tries to show if on the x-axis you have
the time as you go through evolution of
your architecture and your y-axis is
far you are in your architecture from
the targets objective of that
architecture we got a little bit worse
that was the bottom of that big the
hockey stick is where we had both
solutions active the old way of doing
things in the medium you know and the
new way and if we continued that project
to the point that we retired the old
clients or the using the authentication
and retired the code then we are in a
better place so sometimes the species
you know step of evolution is a tiny
step and sometimes it's a giant leap
so I really want you to think about when
you're designing your project and
allocating budgets where to go to try
this and the unit of migration can be
maybe described as the couple redirect
clients for the new service and retire a
to be honest I I played with this idea
why do I need to wait my time retire old
code are we going to just get rid of
this monolith anyway and just leave that
code in there nobody going to access it
but the reality is that Mallory is going
to probably stay around in one shape or
form after I've gone not from this world
hopefully but from from the company so
this better to go through is kind of
atomic steps of evolution quick recap
the couple of the most constraining
factor early the complicated listing out
code sometimes code if you have you know
high IP in your code the couple what
matters what gets a lot of love and
change the couple vertically think about
the data first minimize dependencies
back to the money listen if you do
expose api's go macro first and micro
and most definitely evolved in this
atomic steps towards evolution so shop
what number is the best one
I'm just waking people up now it's all
over the place five great ok good never
sounds good ones in there actually
somebody replanted alright
this yellow should wake you up now okay
I'll be ready for decline yes good agree
yes yes so this is going to be a long
journey and hard one I'm going to take
you to time to change organizations and
change the backbone of you know
infrastructure where you run micro
services but I guess my advice is just
once while you are going through that
hard time just stop for a moment take
back take a look and enjoy the view that
you have how far you've come
and then then continue how do they
define alright so this is going to be a
jam-packed side it's like I'm going to
go up a little bit and look at the big
picture we were deep down in the monthly
kind of decomposition
Martines it's sitting here of hope I
have both of you correctly the only
thing a Big Bang royalty picture
guarantees is a Big Bang
so from what if it's so far we must have
realized that I've taken a very
evolutionary approach to changing
architecture kind of a long transition
of transformation that needs to happen
number one start with a clear outcome
and intention behind your architectural
why are you evolving our architecture
where are you heading
Rebecca Parsons and knew forth those
roots or words they have a book actually
coming up called about evolutionary
architectures architectures like micro
system that evolves they can evolve and
change and what they talk about in terms
of the target space of your architecture
is a is a set of capabilities and a way
maybe you can visualize it for yourself
is the spider graph of all those
abilities that matter to you and that's
where you want to evolve your
architecture to in terms of outcome a
lot of our clients they say we want to
innovate we want to experiment faster
well that's probably an axis on that
blade or some people can't care about a
disability in security or throughput
whatever these kind of architectural
facets or abilities are let's put them
down and give them a score so that we
can measure and the deceit we can use
that as a way of testing that Fitness
function they
they use the analogy of genetic
algorithm clipit function that has far
as you go through these notations you
are from that target space
so once your intention is clear and I
just want to say please don't put
buzzword compliance on that radar
this doesn't belong to it's very hard to
test that one point you've got your kind
of picture of the world in terms of
outcome then you're going through a
series of okay I'm going to hypothesize
if I make this change I'm going to
evolve to a better place closer to my
outcome but how are you going to
actually measure that so it's really
important to as we go through changes we
have a way of measuring I'll be going
closer or we getting further away from
the evolution target and some of you
might argue and I probably did that as
well how am I going to measure the
impact of my architectural change up
here I have a measure of success but I'm
going to innovate and you know create
kind of innovative solutions for my user
and down here I'm doing architectural
change so how I'm going to actually
create a measure of success and that's
where you can kind of get creative and
think about leading indicators that show
that you're kind of moving towards that
outcome and the measure of success so
for instance if you are building a
platform of API and services for
innovation what you can measure is a
number of applications we have built
with the API the number of products we
have being able to change if you were
you know the objective was creating new
products through your API is how quickly
you've been able to change the change
and create a new API so those are the
leading indicators that should be fairly
easy to measure along the way that makes
sense if you know okay it's hard and to
be honest we are we are forcing
ourselves right now as part of the
digital platform strategy because we
think about kind of long-term evolution
why we're doing these small steps and
the promise that we have star clients is
that we're going to show you outcome
along the way so we are taking a moment
and think about all these leading
haters that we have to kind of show
progress and keep ourselves honest to
the strategy that we're building the
third one is enable your teams with
self-service platform I've kind of tried
to cover this is probably a talk in
itself but think of Amazon think of
Google Cloud think of companies that are
able to accelerate because they invest
in building the core capabilities their
foundational capabilities at self-serve
kind of API you don't have to hold hand
if somebody wants to use the API you've
created or somebody doesn't need to
create a backlog item for you to create
another you know feature for them it's
very it's easy and with less friction we
can kind of conceal the API I love this
one there is a code that says there are
no solution they're only trade-offs and
so what micro services it's not a silver
bullet it's a set of trade-offs that you
have to make as you go
for instance marking yesterday in his
keynote speech referred to using event
based systems for perhaps synchronizing
data or keeping data due to different
and eventual consistency is a trade-off
that now we need to have a solution for
so as you go through this evolution you
have to make a lot of trade-offs and a
good resource to go to is Chris
Richardson pattern languages where he
describes in every decision that you
make with a pattern and every pattern
creates a new set of problems that you
need to trade-off an answer with another
pattern and it's really good to be
explicit about the trade-offs that you
make and use some technique like
architecture decision records for
Michael nigra to document as not only
what trade-offs you're making but why
you're making those trade-offs so and
the trade-offs could be do I need to you
know use a different you don't need to
use events or restful api for the
trade-off might be do I need to reuse
code or rewrite and we touched on that
in those practices we took code talked
specifically and you know the entropy of
the code change
can make that decision or the trade-off
might be should I actually build this
service like the utility common service
I can get open source or shall I invest
in building it myself because it seems
is strategic it seems unique to my
business so be very kind of explicit
about those trade-offs and finally just
describing the service here
organizational alignment absolutely must
be there and I'm not only talking about
you know forming teams around your
services I'm talking about how you're
actually allocating budgets how does the
money flow in your organization because
how the money gets allocated leads to
measure leads to how people behave and
if you go back to the measurements of
success that we talked about in the
hypothesis side is that you if you think
about kind of why you make an
architectural change how what what makes
it to be successful then you can kind of
justify the allocation of money and
budget towards that so there is a whole
organizational and portfolio management
piece to to market services at least
that's in large organizations okay for
that as cloudsearch says the father of
Taoism the journey of a thousand miles
begins with one step and then add to
that and a dream and if you need help
along the way don't hesitate to contact
oK we've got some time for questions
using rest usually makes us create micro
services based on the data not the
business how do you deal with that um so
well instead of starting bottom up I
don't think it's really the rest fall
its what probably it's the way we think
about the world it's kind of bottom up
from the data I would say think about
there exercises like event storming when
you think about your customer your
journeys within the application and the
events that get generated you think
about kind of the interaction of the
users so at it at a higher level thing
instead of designing their services
bottom-up design the services top down
and think about all those capabilities
that get pushed as the customer goes
through a journey interacting with your
system or think about the events that
get generated as the customer tries the
system and and find the ones that kind
of belong to a cohesive implementation
or effect zone here could you tell us
more about how to deal with removing the
data layer from the monolith when we
don't know exactly who is using it no
you don't have to break them you'll find
out where we stopped working I was
really hoping at a TV on so for that
month out it really helped me out but we
we don't care like maybe nobody uses
those applications yeah it's actually
really good one is there a body of
resources from monolith to micro
services conversions eg a collection of
case studies so we are not reinventing
the wheel every time we need to tackle
on monolith across companies I was just
trying to convince mark into that is
there a body of resource a good point I
think we should all collectively start
putting one together I don't
no and yeah is that like a collection
resources on github about monolith
okay so just type awesome in to get it
also into Google that's going to sort it
out is it Daniel also microservices okay
so yeah what we should do that Randi if
you also did share some detail about
three or four examples where the
previous talk that's a really good idea
I think it's a good idea only some kind
of multinational consultancy
organization had resources that it sort
of stuff there we go okay that we solved
that problem there's now question here
about the about the challenges in
Northern Ireland in the Middle East so
if we can solve those ones as well
that'll be ap probably the time for one
more question as you in the evolution
you had showed how long are micro
services to stay so I guess that's the
question saying you know our if it is a
revolution is my microphone maybe the
destination or are they just a stepping
stone on the way to something else maybe
nano services are on the horizon i right
now that's where we are striving to get
to and from all the signals that we can
see it's it's even if it's a stepping
stone it's a good stepping stone because
it's a distributed system you know it
allows change and it has that nature of
composability and change ability so that
you can change implementations behind
the thing so I I feel even if it's an
it's a good question even if it's a
stepping stone it should be easier to
move from my services forward we have
another question coming in one of the
advantages of micro services is to be is
to independently scale functionality
should for for must be a criteria for
knowing what to split first so an
example I need to scale my whole model
if this functionality so this is a
candidate to split first right so
decided what capability you pull out
basis to scale that that might be the
need in it is one of the character
system us
market services but it's not necessarily
the main driver for any many of my
clients I we had a client where a lot of
the capabilities didn't need to scale
out so much because they were in for
instance CPU intensive but they weren't
getting a high throughput active but we
had we had one capability in the middle
of that architecture it was the pricing
engine which calculates the pricing that
was really pipe kind of CPU intensive
and that was a driver for pulling that
one out and skin but absolutely I think
it's in the list of the things that you
want to pick out if you have a component
that requires that scalability you
definitely want to get that out thank
you there's a number eight added to the
list okay I think maybe one one last
question and then we'll call time you
told us not to migrate our all system at
the beginning but should we prepare
ourselves now to do that in the future
and how would we identify when the right
time is to make that change if you are
deploying a service build test release
deploy without finding yourself
entangled in a large integration
environment and it's a painless exercise
then it's time to you know kind of go
from two services to four services I
think it's that itself is an evolution
but as as you build services you build
the operational infrastructure and your
culture and how you test and how you
build pipelines along the way and once
it feels painless then we kind of start
growing the number of services have you
killed me the thanking jamak for a great
talk thank you