Martin Fowler – Microservices

[Applause] now for the next one I'm going to move into the world of high fashion so I I started hearing about microservices from various colleagues of mine oh about a year year and a half ago two years ago I can't remember now um 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 kind of sound of interesting a little bit weird and and I kind of listen a bit more and once I

begins to reach a certain amount of it's been around for a bit and I'm 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 quickly 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 microservice people refer to as the monolithic system is really saying we're trying to build all the capabilities of the people's piece of software and get it to run as a

single executable a single process in a single I mean I'm I'm being kind of vague with words like process and executable but that's basically the idea there is one kind of thing uh that has all the capabilities within them well microservices try to split this up and say let's take every individual capability of a piece of software and put it in its own process so that they all talk to each other with interprocess communication things um such as restful HTTP or some simple message queue or something of that kind and then when we want to

to distribute and deploy this software with a monolith we have to take the whole thing and copy it to many servers while with the microservices we can place them on different Services according to different needs if one capability is required more we can put it on more servers etc etc we have more flexibility um of deployment many ways similar to service oriented architecture I'll talk about the how I see the difference between um the two later on but that very broadly is um what I was hearing about microservices now as I said that leaves open

a lot of questions you get a feel for what it is but not much more than that so I to 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 um one of the problems I saw with service oriented architecture was it was IL defined right from the very beginning and that caused a lot of Confusion And I I like to have definitions of things to say 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 um I just spent a while writing a book on no SQL databases and again that was a very very IL defined kind of thing 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 arguments are much easier to settle that way but it doesn't

exist and instead what we can say is well 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 um very much into microservices Camp over the last couple of years and we wrote um an article that's on my website that talks about um the characteristics of microservices and I'm going to go through some of these um we identified um nine common characteristics um and I haven't got time to talk through all of them in my little 20-minute format

but I'll highlight some that I think are particularly interesting and I want to stress these are not sort of hard definitional items in that every microservice 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 componentization vers via Services is in some ways one of the most subtle ones um and it really comes down to this notion of what we think of as a component um I've

been active in the software industry for 20 plus years now and we've always talked about components um some people said well objects are components I remember um at one point accenta changing their object systems group to component systems group because component was the more sexy name at the time and thinking well they're the same kind of thing and it has a lot to do with we're trying to modularize software into smaller boxes that you can kind of plug 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 does 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 as we're building it but how we want to see how users want to relate to the software they want to relate to the software like they do their stereo where you can just take a and replace it and plug it in you want and so the idea is that compon a key element of what makes a component is

that you can replace it independently you can say I don't like this piece so I can get rid of it and bring in something new and a corally to that which is actually more common um in software is that we can upgrade it independently that is I can decide when I need to upgrade this bit I don't have to upgrade everything else in fact far more common that we'll independently upgrade than 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 um very every kind of language environment has them where we can take a library from a third party and we can bring that into our software we use whatever our languages environments call mechanisms to call that library but that Library effectively becomes part of our single executable and we do that all the time we bring in libraries um 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 you know I

can usually grab a library for things where 20 years ago I'd almost certainly be forced with writing it from scratch services are very similar except instead of bringing them into my executable and using inprocess calls I make remote calls between different executables and that's really all it is that when we think of uh how we componentize our system we do it by these separate process Services rather than using libraries another important characteristic is the organization of the teams that the and and the services that they build are around business capabilities rather than about infrastructure so

in 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 a kind of technological separation you might see this within a project you might see this within a larger organization the microservice appoint 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 said where it said each team has to be fairly small there two Pizza teams they're American pizzas so we're still

taking about a pretty enormous um piece of thing to food but you're still talking about you know a dozen people or so you're not talking about 50 you're talking about a dozen and and this is the point that and that point is well known that you have your teams of that size what often seems to be missed is um 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

um connection so if it's the team that's for instance to do with recommendations on the Amazon side they're actually responsible for making sure that they see how that recommendation engine is used the business side is channeled right the way through um and although I've seen lots of breaking people down into teams that part of it that it has to go all the way through true to the end user that is um a thing that's often missed so this brings in a very important fact that microservices is as much about a team organizational attitude as it

is about a technological attitude it's in many ways an embracing of Conway's law Conway's law says that your software will follow the organization of the people chosing to build it or a common theme that you hear in microservices circles is well we actually want um teams that are 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 leading themselves into trouble if there one universal law in software development software architecture I would say it's Conway law if you try to break it it will bite you back much harder than you can try and force it so Focus around business capabilities another 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 that communicate through a very smart infrastructure area commonly something called

an ESB and the idea is that this Central piece will figure out how to root messages from one thing to another how to translate from this to that we'll actually figure out a and often have the whole business process you know if you're can to have your workflow you put it in there as well the microservice approach very much rejects this and says no the pipes the network must be dumb all the smarts must live in the applications all the network really should be able to do is say um 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 SOA is this focus on the smarts go to the end points and there's no room for complex 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 middle it's often very difficult to deal with in terms of continuous delivery for instance

um I mean I don't know how whether it's still as bad as it used to be but I certainly remember the days when esbs could not be put under Version Control in any meaningful form I mean the closest I get is oh you can take a binary and throw it in subversion well that's really helpful thank you if you can't go invion control then there's 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 the 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 it's usually worse than that it's usually one database for many monoliths but we won't go down that particular Rat Hole the service oriented approach says each service gets its own data storage and does does not share that data directly with anybody else again this is inspired by um Amazon's example where it was made a complete Edict of their architecture that 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 schema and things of a 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 SQL flavor perhaps a document database or a graph database maybe you just use plain files in the file system it's up to Individual Services 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 things you push almost all your decision- making out to the individual teams so that they make those um decisions um 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 for

being able to um deploy new systems without any downtime Phoenix servers you hear phrases like that a lot of infrastructure automation comes as part of the microservices world and also the realization that things are going to fail if you've got microservices they are going to break they're going to break frequently even to the point that Netflix or one of the major users of microservices have this thing called the chaos monkey one of my favorite um tools of infrastructure which is a tool that goes around and randomly stops services around their infrastructure just randomly takes them

down during the Working Day when people monitoring but the point is people are aware of the fact that things will break they force the breakage to occur and then they make sure that their monitoring and Recovery is able to deal with it now that's an interesting thing if you're going to do microservices 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 remote service calls to necessarily succeed of course one of the biggest problems with um a lot of distribution strategies such as distributed objects was 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 a completely bad idea and one of them is local calls don't tend to fail because the only way they'll fail is if the whole thing goes down anyway but

M calls will and so you have to decide what happens when I get a failure what am I going to do about it how am I going to 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 um as I said this is just a I've just highlighted what I think are the most interesting characteristics here so I've raised this question a couple of times are microservices just SOA and I've the answer to this question really

depends very much on what you think s SOA means for some people SOA is what I've just described in which case microservice isn't is just a a fancy new word that people are Shilling on top of the old idea of s SOA 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 who think SOA means the Enterprise service burst the very smart centralized management things of that kind and to them microservice is very different so the way I

tend to think of it is that microservices is a subset of what you might Calla a more firmly defined area in that subset and I think it's a useful term because it calls out that particular style of s SOA but the unfortunate thing with the term microservices is that micro bit right which implies something about size any microservices person I've talked to keeps telling me that size is not an important part of what microservices is about but with a word like microservices it kind of kind of forces it doesn't it um you can tell I

wasn't involved in coming up with a 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 there's a lot of variation as to how people take Services um from you know sort of uh 15 people 10 Services four people 200 Services I mean that's a big difference and it's not clear yet how that Maps out in terms of of usage so having explained a bit about what microservice is about we can then address the interesting question which is when you should

use a monolith and when you should use a microservice and this is an important point because with any new idea people tend to overuse it and it's reasonable because people have a new idea they they tend to push it because you don't really know where the boundaries of a good idea are until you've stepped over them and realized oh that was a bad idea and then you know where the boundary is and so it's natural that people will overuse it and I've already heard of people overusing um microservices the great advantage of a monolith is

that it's simple when I've heard people use microservices badly what I've heard is look this would be a straightforward monolithic application and they've gone and thrown a whole bunch of micros service stuff in it and now we got a distributed system which is a big complexity booster often in order to get performance good on a microservice system you've got to use asynchronous messaging asynchrony is a huge complexity booster whenever you want to play the distribution card or the asynchron card you know you're increasing the complexity of what you're doing it's often worth it it's often

necessary but you've got to hesitate before playing that card if you can't my my actual tendency is that this is big enough of a reason to say if you're not sure whether you should do microservices stick with a monolith because um it is going to be simpler microservices do give you an advantage of partial deployment you don't have to redeploy your whole system you can redeploy part of it that that was a driver for Netflix they had difficulty deploying new versions of their software that was one of the things that pushed them towards a microservice

approach having said that I do know of organizations that can successfully do regular deployments of even very large monoliths so it doesn't have to force you to microservices microservices can give you a degree of availability if you do your failure management well one service can keep giving some degree of degraded but still useful work even if other services fail and while with a monolith of course if anything breaks everything breaks but then you know if availability is good you know what that means consistency is probably going to be a problem and yes microservice is 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 um monoliths allow it allow you much more easily to change the shape of the code because if I need to refactor and move some behavior from over here to 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 in fact your

service boundaries will really Force early on if you get your service boundaries wrong early on on a microservice project then you're going to find it very difficult to fix them with a monolith you have more move maneuver for flexibility so that's another argument that if you're not sure go stay with a monolith that and I should point out that many of the examples of relatively successful microservices that I've come across cross 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 that's most of the cases so far is interesting interestingly as a kind of almost like a CED of this um you can actually be easier to preserve modularity with microservices 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 of 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 and one of the nice things about uh the microservices approach is it's really hard to jump round the boundaries and microservices allow you to support multiple platforms so as a result you don't have to all use the same programming language or even the same same programming environment um you can go as crazy as having some C++ some goang some net some Java some closure you know all different languages and platforms and stuff that obviously can be a recipe for a disaster if you've got too many but it can be very useful if you

pick a small set that worked 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 um 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 a Time stick with a monolith only go with a microservice when you feel a 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 though

with if you are interested in using micr Services there's some really important things you've got to make sure you get before you begin not necessarily before you start building the microservices 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 can go that way because otherwise you you're going to have a a whole load of delay in provisioning new machines and which 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 there um you've got to be able to deploy your

applications rapidly into these newly provisioned 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 going to need that devops culture that 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 if you don't think you can get these things into play with your first deployment definitely don't use microservices and this isn't the end of

course there's a whole bunch of further things um that you're going to have to do um in order to do microservices any further and that's it I'm [Applause] done