o I I started
hearing about microservices some various colleagues of mine about a year year and
a half ago two years ago I can't remember now
and like many of these things
it's because I don't do any real work anymore I just tried to listen to people
who do so i hear some talking about something I go
that's kinda sound of interesting a little bit weird and I can elicit a bit
more and once I begins to reach a certain amount of it's been around for a
bit and then getting enough chatter on it i think i need to try and and figure
out what this thing is and try and understand it so i'll begin by clicks
but by giving the kind of the high-level explanation at a very high level
it's a contrast between two styles of building software
what the micro service people referred to as the monolithic system is really
saying we're trying to build all the capabilities of people's piece of
software and get it to run as a single executable a single process in a single
I mean I'm being kind of a way with words like process and executable that's
basically the idea there is one kind of thing that has all the capabilities
within them
well microservices tried to split this up and say let's take every individual
capability of the piece of software and put it in its own process and so that
they all talk to each other with inter process communication things such as
restful
HTTP or some simple message queue or something of that kind
and then when we wanted to distribute and deploy this software with a model if
we have to take the whole thing and copy too many servers
while with the micro services we can place them on different services
according to different needs if one capabilities required more we can put it
on more servers etc etc we have more flexibility of deployment
many ways similar to service oriented architecture i'll talk about the hell i
see the difference between the two later on but that very broadly is what I was
hearing about microservices now that said that leaves open a lot of questions
you got a feel for what it is but not much more than that
so I thought myself can we can we get a bit further I would like microservices
to have a definition and this is partly because of the fact that one of the
problems i saw with service oriented architecture was it was ill defined
right from the very beginning and that caused a lot of confusion and I'll i
like to have definitions of things so i can clearly see whether something is one
thing or another but the problem of course with terms like this is it's
almost impossible to come up with a definition of them had to spend a while
writing a book on no sequel databases and again that was a very very ill
defined kind of think you can't come up with a concrete definition because we
don't have some official body of computing vocabulary that comes up with
definitions of things
I mean I would very much like to be that body especially if it's only me that's
on it because the argument so much easier to settle that way but it doesn't
exist and instead what we can say is one maybe we can't get a definition but we
can identify common characteristics and so what i did is i sat down with my
colleague James Lewis who's been very much into microservices camp over the
last couple of years and we wrote an article that's on my website that talks
about and the characteristics of micro services and i'm going to go through
some of these we identified nine common characteristics and I haven't got time
to talk through all of them in my little 20-minute format but i'll highlight some
but i think is particularly interesting and i want to stress these are not sort
of hard definitional items in that every micro service architecture exhibits all
of these things they're common characteristics so the way I think of it
is most microservice architectures have most of these characteristics but
there's always going to be a certain amount of variation
so the first one component ization was the vice services is in some ways one of
the most subtle ones i mean it really comes down to this notion of what we
think of as a component
I've been active in the software industry for 20 plus years now and we've
always talked about components
some people say well objects of components I remember at one point
accenture changing their object Systems Group two component systems group
because component was the more sexy name at the time and thinking well over same
kind of thing and it has a lot to do with we're trying to modular eyes
software into smaller boxes that you can kind of put together more easily but
does that mean a component is the same as a class or some kind of modular
structure in our software what is it actually mean
and to me the the definition was broken down very nicely by Ralph Johnson when
he said well it's not about necessarily how we think of the software is we're
building it but how we want to see how users want to relate to the software
they want to redirect to the software like they do this stereo where you can
just take a box and replace it and plug it in you one
and so the idea is that component a key element of what makes a component is
that you can replace it independently
you can say i don't want this piece so I can get rid of it
bringing something new and a corollary to that which is actually more common in
software is that we can upgrade it independently but it is i can decide
where no need to upgrade this bit
I don't have to upgrade everything else in fact far more common but will
independently upgrade then we'll actually replace and when we have
components there are two broad ways we can go about doing it
one is we can bring in libraries jars in the Java world gems in the Ruby world
very every kind of language environment has them where we can take a library
from the third party and we can bring that into our software we use whatever
our languages environments call mechanisms to call
at library but that library effectively good becomes part of our single
executable and we do that all the time we bring in libraries that one of the
nice things that's happened over the last 10 20 years in software development
is libraries are so much more common now
now I can usually grab a library of things we're 20 years ago are almost
certainly force with writing it from scratch
services are very similar except instead of bringing me into my executable and
using in process calls i'm at remote calls between different executables and
that's really all it is that when we think of how we component eyes our
system we do it by these separate process services rather than using
libraries
another important characteristic is the organization of the teams but the and
and the services that they build our round business capabilities rather than
about infrastructure so many organizations people will organize
around a particular technology technology layer and things of this kind
when you see separations like this of people
that's the kind of technological separation you might see this within a
project you might service within a larger organization the micro service' .
says no you want to instead have relatively small teams that are
completely owning a business area
the the often quoted example of this is that of Amazon where you say where that
said each team has to be fairly small there to pizza teams they're American
pizzas
so we're still taking about a pretty enormous piece of things food but you're
still talking about you know a dozen people also
you're not talking about 50 you talking about a dozen and he and this is the
point and that point is well known that you have your team's about sighs what
often seems to be missed is again from from what I got from listening to Amazon
people is it's very important that each of these teams has a direct
communication right the way through to a customer and user so each team has that
connection
so if it's the team that's for instance to do with recommendation
it's on the Amazon side they're actually responsible for making sure that they
see how that recommends station engineers used the business side is
channeled right the way through and although I've seen lots of breaking
people down in two teams that part of it but it has to go all the way through to
the end user that is a thing that's often missed
so this brings in a very important that but microservices is as much about a
team organizational attitude as it is about a technological attitude in many
ways and embracing of Conway's law , mais law says that the software will
follow the organization of the people chosen to build it or common theme that
you hear in microservices circles is well we actually want teams a small
customer focused and relatively separated from each other so we create
that and force the software to follow that kind of view
so it's as much a team organizational thing as it is a software architecture
thing because of course software architecture and team or organization
are always heavily coupled together
anybody who denies that is lit leading themselves into trouble if is one
universal law in software development software architecture
i would say it's Conway's law if you try to break it it will bite you back
much harder than you can try and force it so focused around business
capabilities
they're very important thing is how we consider the smarts of how things should
connect to each other a lot of service oriented architecture approaches that we
run into in Enterprises has the idea of various systems to communicate through a
very smart infrastructure area commonly something called an ESB and the idea is
that this central piece
we'll figure out how to root messages from one thing to another had to
translate from vista that will actually figure out an often have the whole
business process you know if you don't have your workflow you put it in there
as well
the micro service approach very much reject this and says now the pipes that
network must be done
all the smarts must live in the applications all that work really should
be able to do is say tell me where this message has got to go and i'll make sure
it gets there and so it's very much a dumb pipes approach and this i would say
is the biggest difference between microservices thinking and what a lot of
people call this away
is this focus on the smarts go to the end points and there's no room the
complicated complex middleware and things of that kind
and this is a lot of people find this very interesting because of the problems
that we've had dealing with this complex middleware it's often very difficult to
deal with in terms of continuous delivery for instance i mean it is
I don't know however it's still as bad as it used to be but i certainly
remember the days when the ESPYs could not be put under version control in any
meaningful for I mean that the closest to get is oh it and take a binary and
throw in subversion
that's really helpful thank you we can't go in version control that isn't it has
no business being any part of our development environment that's my
opinion
so smart endpoints another aspect is decentralization of the management and
in particular data management
so while a monolithic approach will typically operate off a usually
relational database but the point is there will be a single database solution
for the whole monolith in fact usually worse than that is usually one database
the many mullets but we won't go down that particular rat hole
there's service oriented approach says each service gets its own data storage
and does not share that data directly with anybody else
again this is inspired by amazon's example where it was made a complete
edict to their architecture but you never share data directly all sharing
has to go through the services that wrap the data and so as a result each service
chooses what database to use not just the schemer and things of the database
but also what kind of database
do you want a relational is that suitable for what you're doing or would
you be better off with some no sequel flavor
perhaps the document database or a graph database maybe you just use plain files
in the file system
it's up to individual sir
this is what they do and all communication occurs through the
services that wrap those that's an example of decentralized decision making
you don't have a central group laying out standards and deciding how things
should be done other than the very minimum connectivity figures you push
almost all your decision making out to the individual teams so that they make
those decisions
I'm infrastructure automation
anybody doing microservices is really into the whole continuous delivery thing
for instance because if you're going to do this kind of stuff you want the
services to be upgradeable at any point you've got to push them all out so I do
things like continuous delivery blue-green deployment which are
techniques that are being able to deploy new systems about any downtime
phoenix service you hear phrases like that a lot of infrastructure automation
comes as part of the microservices world and also the realization but things are
going to fail if you've got microservices they are gonna break
they're gonna break frequently even to the point that netflix or on a major
uses a of microservices have this thing called the chaos monkey
one of my favorite tools of infrastructure which is a tool that goes
around and randomly stop services around their infrastructure just randomly takes
him down during a working day when people monitoring but the point is
people are aware of the fact that things will break a force the breakage to occur
and then they make sure that they're monitoring and recovery is able to deal
with it
now that's an interesting thing if you're going to do micro service as well
you've got to be confident that you could let a chaos monkey into your
service area and you would be able to deal with it
operating and you should do that because failure will happen with any large
distributed system and that affects everything
it doesn't just affect how you manage and run your servers it affects how you
design your code
you can't expect your roots remote service calls to necessarily succeed
it was one of the biggest problems with a lot of distribution strategies such as
distributed objects with this notion of we can make a remote call look just the
same as a local call
well there's many reasons why that's complete
a bad idea and one of them is local calls don't tend to fail
that's the only way to fail is if the whole thing goes down anyway
but remote calls will and so you have to decide what happens when i get a fairly
what I'm going to do about it
how am I gonna ride over that what does it mean to me
how can i minimize the impact on the user so there's a whole bunch of
different things that come in here
as I said this is just a I've just highlighted what I think the most
interesting characteristics here so I've raised this question a couple of times
are microservices just SOA and I mean the answer to this question really
depends very much on what you think SOA means for some people
SOA is what I've just described in which case microservices and is just a fancy
new word that people are shelling on top of the old idea of s away and I quite
understand that point of view
a lot of people have it and I understand where they come from from it but there
are many people think SOA means the Enterprise Service bus the very spots
and centralized management things of that kind and to them microservices is
very different
so the way I tend to think of it is that microservices is a subset of what you
might call this away
no more firmly defined area in that subset and I think it's a useful term
because it calls out that particular style of SOA but the unfortunate thing
with the term microservices is that microbe it right which implies something
about sighs any microservices person I've talked to two keeps telling me that
size is not an important part of what microservices is about but with a word
like microservices it kind of forces it doesn't it
you can tell I wasn't involved in coming up with the name i would have come up
with a much better name
so the question is how big should microservices be
and the answer is actually is a lot of variation is to help people take
services for our me out sort of 15 people 10 services for people 200
services I mean that's a big difference and it's not clear yet
how that maps are in terms of of usage so I mean explains a bit about what
microservices about we can then address the interesting question which is when
you should use a monolith and when you should use a micro service and this is
an important point because with any new idea
people tend to over use it and it's reasonable because people have a new
idea of a they tend to push it because you don't really know where the
boundaries of a good idea or until you've stepped over them and realize
though that was a bad idea
and then you know where the boundary is and so it's natural that people over
user and I've already heard of people over using microservices the great
advantage of a monolith is that it's simple but when I've heard people use
microservices badly
what I've heard is look this will be a straightforward monolithic application
and they've gone and thrown a whole bunch of microservice stuff in it and
now we've got a distributed system to the big complexity booster often in
order to get performance good on a micro service system
you've got to use asynchronous messaging asynchrony is a huge complexity booster
whenever you want to play the distribution card or the asynchrony card
you know you're increasing the complexity of what you doing it's often
worth it
it's often necessary but you've gotta hesitate before playing that card if you
can undermine my sexual tendencies that this is a big another reason say if
you're not sure what you should do microservices stick with a monolith
because it is going to be simpler microservices do give you an advantage
of partial deployment you don't have to redeploy a whole system you can redeploy
part of it that that was a driver for netflix they had difficulty deploying
new versions of the software that was one of the things that push them towards
microservice approach
having said that i dunno of organizations that can successfully do
regular deployments of even very large mammal it's so it doesn't have to force
you to microservices microservices can give you a degree of availability
if you do your family management well one service can keep giving some degree
of degraded but still useful work even if the services fail and what with a
monolith of course
if anything breaks everything breaks but then you know if the availability is
good
you know what that means consistency is probably going to be a problem and yes
Michael services you would begin to enter the world of eventual consistency
and all of that kind of stuff I've got a whole other talk on that topic but
that's another complexity area that comes into play
how monoliths allow it might let you much more easily to change the shape of
the cold because if I need to refactor and move some behavior from over here -
over here and I'm within the same code base within the same executable
it's a relatively easy thing to do if I've got now two different services then
it's much much harder and if at your service boundaries will really force
early on if you get your service boundaries wrong
early on on a micro service project then you're going to find it very difficult
to fix them with a model if you have more move
remove the flexibility so that's another argument that if you're not sure
good stay with him only that and I should point out that many of the
examples of relatively successful microservices that I've come across so
far started with a monolith and then went microservices when they ran into
trouble
that may not be the best way of doing it and just maybe historically the way
people have done it but the fact that most of the cases so far is interesting
interestingly as a kind of almost like account of this you can actually be
easier to preserve modularity with micro services and that's because our
programming languages actually don't do a very good job of forcing modularity
it's too easy to jump around the module boundaries and so one of the criticisms
people have a monolithic code bases is well it ought to be well-defined modules
but it's just got corrupt it's too easy to corrupt it
one of the nice things about the microservices approaches it's really
hard to jump around the boundaries
and Michael service is allowed to support multiple platforms so as a
result
you don't have to all use the same programming language or even the same
programming environment you can go as crazy as having some c++ some golang
some . naps and java some closure you know all different languages and
platforms and stuff that obviously can be a recipe for disaster if you've got
too many but it can be very useful if you pick a small set that work well
together because different languages and different platforms are better for
different kinds of problems
so those are the kind of some of the major trade off pieces
although i've written a lot about microservices and i'm very interested in
them and where they go
at the moment I'm still most of the time stick with a model if I only go in a
micro service when you feel the real push in that direction
not all of my colleagues would agree with that advice but that's still where
i am and i want to finish go with if you are interested in using microservices
there's some really important things you've got to make sure you get before
you begin
not necessarily before you start building the micro services but you
certainly need to have these things in place the day you deploy the first live
version first thing is make sure you can provision machines rapidly
you've got to be certainly in a matter of hours
not a matter of days to get a new machine from scratch up and deployed
obviously with cloud environments this makes it more straight forward to do
that
make sure you can do that rapidly it means automatically
you've got to be in a position where you can go that way because otherwise you
are going to have a whole load of delay and provisioning new machines
now this is going to mess things up for you make sure you've got monitoring in
place the basic monitoring and making sure you know when one of your services
goes down because they will go down and you will have to react to it
so you've got to have good decent monitoring their you've got to be able
to deploy your applications rapidly into these newly provision environments
not just the latest version but again be able to roll back quickly
so a lot of continuous delivery stuff i was talking about early on this is a
prerequisite
and you're gonna need that DevOps culture but I talked about early on
because this raises the bar and complexity on operations people
significantly so the applications people have to be working together to make this
work
you don't think you can get these things into play with your first deployment
definitely don't use micro services and this isn't the end of course there's a
whole bunch of further things that you're going to have to do in order to
do microservices any further
and that's it I'm done
