Martin Fowler – Microservices

for the next one I'm going to move into the world of high fashion so I started hearing about micro services some various colleagues of mine 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 try to listen to people who do so I hear some talking about something I go it's kind of sound of interesting a little bit weird and when 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 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 quickly explode 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 refer 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 vague 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 micro services try to split this up and say let's take every individual capability of the piece of software and put it in its own process 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 it to many servers while with the micro services 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 of deployment many ways similar to service oriented architecture I'll talk about the how I see the difference between the two later on but that very broadly is what I was hearing about micro-services now as I said that leaves open a lot of questions you've got a feel for what it is but not much more than that so I thought to myself can we can we get a bit further I would like micro-services 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 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 I just spent a while writing a book on no sequel databases and again that was a very very ill-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 very much into the micro services camp over the last couple of years and we wrote an article that's on my website that talks about 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 that I think are 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 micro service architectures have most of these characteristics but there's always going to be a certain amount of variation so the first one componentization via services is in some ways one of the most subtle ones and 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 are components I remember at one point Accenture changing their object systems group to a 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 box and replace it and plug in a new 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 like this piece so I can get rid of it bring in something new and a corollary to that which is actually more common and in software is that we can upgrade it independently but 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 will independently upgrade then will 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 language is environments call mechanisms to call that library but that library effectively could 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 20 years in software developer these libraries are so much more common now now I can usually grab a library for things where 20 years ago almost certain before Sui writing it from scratch services are very similar except instead of bringing an image into my executable and using in process calls I make remote calls between different executables and that's really all it is that when we think of how we componentize our system we do it by these separate process services rather than using libraries another important characteristic is the organization of a teams but 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 service within a larger organization the micro service 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 say where that said each team has to be fairly small there are two 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 or so you're not talking about 50 you're talking about a dozen and eat 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 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 recommendations on the Amazon site 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 and although I've seen a lot of breaking people down into teams that part of it but it has to go all the way through to the end user there is a thing that's often missed so this brings in a very important fact that micro-services 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 chosen to build it or common theme that you hear in micro-services 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 leading themselves into trouble if there's 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 focus around business capabilities another 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 our 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 route messages from one thing to another how to translate from this to that will actually figure out and often have the whole business process you know you can have your workflow you put it in there as well the micro service approach very much rejects this and says no the pipes that network must be dumb all the smarts must live in the applications all the network really should be able to do is say tell me where this message has got a girl 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 micro-services 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 for complex complex middleware and things of that kind and this is a lot of people find this very interesting because are 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 was I don't know however it still as bad as it used to be but I certainly remember the days when ESB s could not be put under version control in any meaningful form I mean that the closest they get is I'll wait and take a binary and throw in subversion well that's really helpful thank you if you can't go in version control then it has no business being any part of our development environment that's my opinion so smart end points 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 facts usually worse than that it's usually one database than many monoliths but we won't go down that particular rathole the 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 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 sequel 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 the very minimum connectivity things you push almost all your decision-making out to the individual teams so that they make those decisions infrastructure automation anybody doing micro services 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 they do things like continuous delivery blue/green deployment which are techniques for being able to deploy new systems about any downtime phoenix servers you hear phrases like that a lot of infrastructure automation comes as part of the micro services world and also the realization that things are going to fail if you've got micro services they are going to break they're going to break frequently even to the point that Netflix or one on a major uses of micro services have this thing called the chaos monkey one of my favorite 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 they're monitoring and recovery is able to deal with it now that's an interesting thing if you're going to do micro services 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 because one of the biggest problems with 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 remote calls will and so you have to decide what happens when I get failure what am I going to do about it how am I going to write over that what does it mean to me how could 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 that I've just highlighted what I think are the most interesting characteristics here so I've raised this question a couple of times are micro-services just SOA and I think the answer to this question really depends very much on what you think SOA means the some people SOA is what I've just described in which case micro services and is just a fancy new word that people are shilling on top over 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 who think SOA means the Enterprise Service bursts the very smart centralized management things of that kind and to them micro services is very different so the way I tend to think of it is that micro services is a subset of what you might call s away a 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 micro services is that micro bit right which implies something about size any micro services person I've talked to too keeps telling me that size is not an important part of what micro services is about but with a word like micro services it kind of 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 micro services be and the answer is actually there's a lot of variation as to how people take services from you know 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 out in terms of of usage so having explained a bit about what micro service is about we can 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 overuse it and it's reasonable because people have a new idea 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 micro-services 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 would 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 it's a 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're doing it's often worth it it's often necessary but you've got a hesitate before playing that card if you can undermine my sexual tendencies that this is big enough of a reason to say if you're not sure whether you should do micro services stick with them on the lift because it is going to be simpler micro services 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 micro service 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 micro services micro services 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 the veil ability is good you know what that means consistency is probably going to be a problem and yes micro 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 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 micro service project then you're going to find it very difficult to fix them with a Monell if you have more maneuver for flexibility so that's another argument that if you're not sure stay with a monolith that and I should point out that many of the examples of relatively successful micro services that I've come across so far started with a monolith and then went micro services 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 counter to 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 and one of the nice things about the micro services approach is it's really hard to jump round the boundaries and micro 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 dotnet some 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 micro services 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 with 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 though with if you are interested in using micro 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 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 straightforward 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're going to have a whole load of delay in 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 there 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 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 and that you're going to have to do in order to do microservices any further and that's it I'm done you

Channel: Thoughtworks

Views: 195,517

Keywords: Thoughtworks, Martin Fowler (Computer Scientist), Computer Science (Field Of Study)

Id: 2yko4TbC8cI

Length: 24min 56sec (1496 seconds)

Published: Sat Jan 31 2015