so microservices have been talked about a lot of the the last year or so I see a
huge amount of stuff on Twitter and the like talking about this topic
it's something I've been hearing about for a good bit for a little bit longer
last two or three years various of my colleagues and friends have been talking
about microservices and for me the struggle was trying to figure out well
what exactly are they
what do what do people really mean when they talk about micro services and also
you know when should we consider using this technique is it new or not
do we use it do not use it and what nurses in the first place
I mean the basic idea is very straightforward you contrast it with
what is considered to be a traditional monolithic application a monolithic a
monolithic application means you've got various capabilities
various things that you want to provide and you put them all in the same
application to be running in a single process and you think of it as one thing
the micro service approach and its crew disposal trying to take each of these
capabilities and put them into separate processes and instead of having one
process have this network of communicating processes
a lot of people like to use the example of of the unix command line where if you
want to get a list of all the files in your directory sorted you might use two
or three different programs put together in a pipeline to do so
it also has a consequence for distribution
if you've got a model if you scale by effectively cookie cutter during the
mama lip and putting it on multiple machines while we microservices you've
got more of a flexible approach because you can put different services on
different machines
so if some services get more loads than others they can have more copies of the
maid
that's the kind of very crude overview but this is still a long way away from
what I would really call the definition of it i mean how does vary from
everything i've been hearing people Yammer on about service-oriented your
car
architecture for the last 10 years the trouble is with something like a topic
like microservices it's very hard to come up with any kind of firm definition
and just enough so the same thing with no sequel right me no sequel databases
and what's the definition no sequel and even think about coming in you know what
is the definition of how can we come up with really solid definition of the
functional programming
well you ever planning out there you can choose from quite a wide range
what I think it's better to think about it instead of thinking about a
definition to talk about common characteristics and what I mean by
common characteristics is to say if you burn to talk to a whole bunch of people
doing microservices and you look for the common things that most of them are
doing your test is that most people who say they're doing microservices should
be doing most of these things and i got to every one of my colleagues who is one
of these guys has done a lot of work with micro services and we came up with
an article that we were published earlier this year
those of you back again a struggle with all that everything on the slides into
the bottom because of the way the things laid out but it's out there and I'm just
going to summarize some of these were the nine common characteristics that we
came up with in writing that article and i'm not going to talk through them all
because i don't have enough time but i will highlight some but i think
particularly interesting
so the first thing is this notion of component ization various services and
the idea of software should be broken up into components has been around again
forever we always a lot of people have talked about component based software
and how it would be good to have components that you can work with but
often the term component of course has had a lot of problems in terms of
definition as well
I remember one point object being substituted for components and then
components came back to objects again and it all got very confusing when I
focus on for a definition of component really comes from Ralph Johnson
he said that what we're trying to do is we're trying to build software the way
people with assemble stereo components
you know you have an amplify have speakers you have a CD play have a tape
player
you can replace any of these items independently
that's a cruel thing and indeed you can upgrade any of these items independently
so if i want to in get an improved amplifier
I don't have to change everything else that's a goal of what we're aiming for
component is something that's independently replaceable independently
upgradeable so in terms of software and we see components to be coming to forms
we obtain libraries that we use from third parties and we make them part of
our process and to some extent we have been the choice of when they will want
to upgrade that do we want to get a new version of our XML processing library or
do we stick with the one that we've currently got and hopefully the upgrade
isn't going to affect the rest of our application too much depending on how
the dependences all laid out a service is a different kind of component where
it's running in its own process and while with the library we talk using the
language communication facilities that we have built into whatever language
were using with a service we typically using inter-process communication
facilities such as web service calls or messaging or something of that kind and
the services
give us some useful advantages and when it comes to replace ability
upgradability if I've got a model if we have components that are libraries and
I've got you know somebody brings out a new version of a component that would be
really nice but it only works on java 8 and I've got another component in my
model if that doesn't work with java 8 and can only work with java 7
what do I do I'm stuck but on the other hand with if they were separate services
that would be running in completely different runtimes and they could
operate there could be upgraded more independently now is the cost of course
with that but that's part of the notion of how it ties into the independent of
great ability
so the next one organization in around business capabilities is another
important theme in microservices view of the world
so a lot of lot even development organizations organize themselves around
technology
I mean you see this in a lot of big companies are have a DBS and the
database group they might have a completely different group of people on
the UI it's focused around technology
the key thing with microservices view of the world is that we should instead
organized around business capabilities and that each team should have some
elements right the way through and ideally focusing directly on the end
users themselves
there's an interesting example of this from amazon which is a a common
certainly inspiration for the micro services community where when they
divided everybody knows amazon divided themselves up into two pits of teams and
that's talked about a lot but what's talked about a lot less often is the
fact that each team was responsible for the communication right way through to
the end user experience and the idea that should connect right the way
through to the people at the end and they should be judged on how does this
affect business outcomes right away through is a very important part of that
thinking
so we have this notion of divide yourself up around some kind of business
organization and make that azz full stack as possible
perhaps when it comes to comparison to what a lot of people have come across in
terms of services
one of the biggest shifts is this shift about
let's have smart endpoints and dumb pipes when a lot of people talk about
service oriented architecture
they talked about the idea of let's get some powerful piece of middleware that
will automatically do all sorts of stuff it'll route messages reply business
rules
it does all sorts of things this of course is the the ESB the Enterprise
Service bus or is it more correctly known the egregious spaghetti box
the manga service community very much regret reject this notion and says the
smarts instead should move to the end points themselves
what we want is everything to connect together and to be able to easily route
message years or communications between them but it should be up to the end
points where all that smartness girls any business logic any routing staff all
of it should be based on the endpoints just give us a good efficient piping
mechanism and the inspiration in many ways is of course the Internet itself
which works very well because of the fact that it is a relatively dumb set of
pipes and puts all the intelligence on to the end points
another thing that also brings out this variation to a lot of service stuff is
the notion of decentralization decentralisation in terms of the overall
way in which service landscape is governed and in particularly
decentralisation in terms of data management
so again if we think of the the monolithic world we think of the fact
that generally all of the data is sitting in one honking big relational
database
all right and it's often can be too right across the company now our company
standards oracle or our company standards db2 everything goes in the
same place and even a lot of service-oriented architectures
it's really a lot about multiple services all pulling data in and out of
one logically large database microservice the point point of view is
to say no every service should be responsible for its own data and its own
persistence
again this is another thing that is inspired by the Amazon experience amazon
made that one of their rules when they shifted to a service oriented approach
and said you may never talk to another services data store you can only talk to
another service through its api and that's the rule that the micro service
people and push as well
now this is a couple of advantages first it removes this horrible mess of
integrating through a database which causes no end of problems in enterprises
all over the floor plates
the second thing it does it frees up individual services to use a data store
that makes sense to them some that services a relational database will make
sense
others would want to use one of these hot new no sequel fancy things and in
which case they use it for that but the idea is your choice of datos positions
should be entirely up to the individual service themselves and that's part of
this general notion as I said of decentralisation it also goes to the
point of things like languages and tools should again be individually chosen by
different service groups to make all of this work it's really important to have
infrastructure automation
so a lot of things such as continuous delivery techniques like blue green
deployment allow you to put stuff to live with zero downtime these kinds of
things are mandatory in in order to get this kind of stuff to work because
you're talking about building what would be one application as a dozen or two
dozen services
so it's very important to have a very automated way of getting these things
going
you also want to be able to get new boxes and spend them up rapidly
it also puts a lot of emphasis on monitoring as well and you've got to
have good monitoring so that when things go wrong you can easily spot the fact
that something's gone wrong and you can use the monitoring tools to help you
debug it and that of course then leads into the notion that you have this
explicit design for failure if you're going to have remote services they're
gonna fail
particularly as you distribute them across multiple nodes so this is another
part of the reason why monitoring is so important and of course its most famous
level you have things like the chaos monkey
Netflix is one of the most well-known more microservice architectures and they
built a tool that goes around randomly destroying nodes and I use that in order
to detect how resilient their overall network is
I mean I don't run it all the time they're in it during office hours when
is somebody there to fix things up but the fact that you've got a tool that
deliberately causes failure in order to help make sure your resilience
I think it encapsulate very well the attitude that the micro service people
have and of course this is essential in any kind of distributed system you have
to assume things are going to break so that was a set of common characteristics
and i'll give you a bit of a flavor for the kinds of things that people talk
about but it still raises a number of him of questions of which one of the
biggest things is is this really service oriented architecture is this just the
same kind of stuff that we've been hearing about for a long time in the
context of SLA
but in order to answer that question you have to say to yourself well what is SOA
in the first place and that is really i think at the heart of the problem
because I've heard SOA defined in many different ways in many different
incompatible ways by different people for some people
SOA is exactly what we've been talking about in the micro service world and
that's why I met a number of people in the SOA community are really ticked off
at the micro service people because state their attitude is what we've been
doing all of this and calling it is away for years why do you invent this new
term and bring it along
what's what are you just pointing words because everybody knows of course we
become incredibly rich by corning terminology
I wish but of course SOA means different things to different people
too many people in the micro services community they've been around big
enterprises and to them
SOA means the Enterprise Service bus it means committees of people who are there
to lay down standards for health services opposed to connect to each
other
it's a very different world indeed so why I tend to think of it is saying well
SOA is this very broad term and microservices is a subset of its usage
and the value of the term microservices is it allows to put a label on a useful
subset of the SOA terminology in my view the SOA term is too broad
I mean it means so many different things it's practically meaningless but the
value microservices is it carves out a coat and consistent space within that
but it is perfectly fair to say that the micro service approach
has been done by people under the name of s away for at least a decade if not
more so it's not a new technique at all and it's perfectly reasonable that and
people are annoyed about it when i say all sniper services and nothing new
that's a perfectly reasonable response
now one of the problems with micro services as a term and I like to stress
I didn't come up with this term right i would have come up with a better term
but one of the things about my services as a term is it has this implication of
size and of course as soon as you sign my crew as well
how big is a micro service and you actually talk to any of these people in
the micro service world and they're always very reluctant to answer this
question
they always say well you know it should be one responsibility
that's a kind of bogus thing to say right i can imagine
payroll being one responsibility and I know that's a pretty big system
all right i mean it's all sighs I mean it's very responsibilities are very
flexible
right James Lewis has this statement says Marcus services have got to be
small enough to fit in my head now James has config a great deal in his head
as it turns out but his point is of course the service that if you've got a
service it should be understandable to a single person that's his test for it but
it's still a bit vague
I started asking around people trying to get a sense of size
people are extremely reluctant in many ways but the way I was able to get some
thinking by saying or how many people per service in your application and I
got a lot of different answers
as you can see there's quite a spread here are 15 people 10 services for
people 200 services
there's quite a range of different sizes
it's certainly true that pretty where everywhere come across the notion of the
two pizzas a team from amazon is is fairly well regarded the sense that you
should never have a team that's bigger than you could feed with two pizzas
i should say of course this is to American pizzas and you can feed a hell
of a lot of people
with two American pieces but i think the notion is still there but within that we
still a lot of variability
so that's the best i can do when it comes to defining microservices for you
it's still I'm afraid pretty fuzzy but that's the way things go
I think however it is it does carve out a reasonable class of systems
the next question of course is when you should use it what are the advantages of
microservices compared to model it's one big advantage of a monolith easy to
relatively simple and familiar approach to use and this is not to be
underestimated
I mean I've already started hearing and trickling in stories of projects that
you know decide you know we want to use this microservice stuff because it's so
cool we want to do it and i ended up getting themselves into trouble where
they really should have built a simple among with instead
now if you look at an application and you say yeah that would work really
nicely as a simple rails app you don't want to build start building it as a
micro service because microservices introduce distributed computing
they often introduced asynchronous communication and those are significant
complexity boosters
so the model if still has the advantage of up to a certain size at least
simplicity
one of the great advantages of microservices is the ability to deploy
the various pieces independently if you want to upgrade a model if you've got to
upgrade the whole thing i heard the story of an insurance company where they
got one model if that handled all their different lines of insurance if they
wanted to in to upgrade their auto insurance that had to upgrade the home
insurance as well they couldn't do them independently and that's the
disadvantage of a model if you forced to upgrade all at once
now if you're really good at your continuous delivery pipe lines i think
you can make that work
but you but it's much harder than trying to upgrade and the separate pieces and
that was in fact one of the crucial reasons why netflix went down this route
they had difficulties getting their systems being able to deploy as rapidly
as they need to do
so they found that switching to a micro service approach grave and more
flexibility and this is of course very important in you into the age where we
need to be able to deploy new applications not once every few months
but every week every day and often many times a day and then we can change your
micro services that can give you a greater degree of availability
if your recommendation service goes down for some reason you can still run your
shopping cart and this is important because what is the most important thing
to Americans shopping
alright so nothing to stop the shopping their availability of course comes from
being handled be able to handle failure effectively but if you've got
availability
what does that mean you lose consistency
it's much harder to maintain consistency with micro service applications
so you embrace eventual consistency which may or may not be a good thing
depending on what where you are and it's particularly difficult of course to get
the right kind of consistent behavior so that i can actually post an update when
interacting with a web app and actually make sure that I see it and not go
where did that go did it get lost which is the kind of thing that goes wrong
when you don't do consistency well another big issue with model with the
monolith is that it makes it relatively easy to refactor particularly between
modules now with any kind of software design you want good modularity you want
to divide yourself to air up into pieces so that in order to make a change
I don't have to understand the whole system I can just understand one or two
modules but that means you've got to get your module boundaries right
and if you don't get your module boundaries right you've got to be able
to change them
now if you've got a model if that kind of thing isn't too bad you can say oh I
need to move this object from over here in that module over there
it's not a hard refactoring to do in a microservices world that becomes a hell
of a lot harder because now you're talking about these remote calls
so that's also i think one of the problems with running to monitor
microservices to quickly if you don't mind
standing module boundaries well you're very easy to get a lock yourself into a
pure design and a monolithic can be a good way of figuring out what your
module boundaries are before you actually i'm doing a split and he said
that one of the interesting things about microservices is that they actually help
you preserve modularity a lot of people you know like me
waffle on endlessly about how important it is to have good modules and follow
Bob Martin's rules about clean dependencies and all the rest of it but
the reality is most systems find it hard to do in practice it's too easy to kind
of do little end runs around and exposing all things are not keep your
module boundaries solid on the other hand in a micro service world your
communications are purely through your network interfaces and it's made me
makes it really easy to ensure you don't share mutable state which is of course
one of the best ways to get yourself into a confusion in a monolith module
architecture
so in many ways microservices kind of a discipline that forces you to keep your
modularity together and then I mean the last big advantage of microservices they
allow you to go with multiple platforms
if some parts of your application stack best off with a traditional you know
java or whatever language you can use them in some places and then you use or
even experiment we have say a closure on other areas
you've got the flexibility now of course you don't necessarily want to go so mad
that you've got plenty services written in 30 programming languages but on the
other hand that flexibility can be very valuable
just as you don't know use JavaScript that's the one thing I really don't want
anybody to do
you gotta fight back against that monster somehow
so that's the trade-offs microservices are not straightforward route to go in
many ways i'd say if you're not sure if you got a relatively small system don't
worry about it
but on the other hand they can be an appropriate appropriate architecture in
a lot of places and we're still trying to understand what the boundaries are
between them
it's still fairly early and the last point I want to say is if you're going
to go down the micro service . there are certain things you've got to make sure
that you get sorted out of what you're going to get into a lot of trouble
you've got to make sure that you can provision new machines rapidly if you're
in a situation where it takes you a month to get a new server setup and
provisioned and ready for use
you're going to have a lot of problems in the micro service world this is of
course of my career services go very nicely with cloud
if you can provision a new machine in the cloud very quickly which is for
instance what Netflix do then that allows you a lot of flexibility there
make sure you have at least the basics of monitoring you want to know when any
of your services go down you want to know if something becomes unresponsive
or if important interactions or transactions are getting dropped on the
floor
you've got to have at least a basic level of monitoring in place and also
you've got to make sure that your services can be automatically and
rapidly deployed and you don't want to be spending two days deploying the
service it's going to be there in hours at the very little most and preferably
minutes and it should be as much as possible
automatic process that's just the basics that's just the running with just a
couple of certain amount of services and to do more
you've got to add more as a whole bunch of other stuff that you've got to get
into play as well so make sure you've at least got those basics on the 1i missed
devops culture that is you've got a break down the barriers between the
operations group in the applications groups of that they're working together
if you've got a difficult communications between the two again you not being able
to manage the quantity of services that you've got a deal with
so as I said those i think at a minimum things to have
when you first go live you don't necessarily have to have them when you
start building but you definitely have to have them when you go live with this
thing
so that's microservices a very brief introduction
I've written various things on it was tons of stuff out there on the web you
can go and find out more and that's the end of my first talk
