Microservices • Martin Fowler • GOTO 2014

so microservices have been talked about a lot over 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 micro services and for me the struggle was to try and figure out well what exactly are they what what do people really mean when they talk about microservices and also you know when should we consider using this technique is it new or not do we use it do we not use it and what nerf is it in the first place I mean the basic idea is fairly straightforward you contrast it with what's 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 typically running in a single process and you think of it as one thing the micro service approach and its crew disciplines is 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 in the monolith and putting it on multiple machines while we're microservices you've got more of a flexible approach because you can put different services on different machines so that if some services get more load than others they can have more copies of them made 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 this vary from everything I've been hearing people Yammer on about service-oriented architecture for the last 10 years but the trouble is with something like a topic like micro services it's very hard to come up with any kind of firm definition yes I mean I've filled the same thing with no sequel right I mean no sequel databases I mean what's the definition and no sequel and even further back I mean you know what is the definition we come up with really solid definition for functional programming well you know there are plenty out there you can choose from quite a wide range what I think is better to think about is instead of thinking about a definition to talk about common characteristics and what I mean by common characteristics is to say if you burnt the talk to AB whole bunch of people doing micro-services and you look for the common things that most of them are doing your test is that most people who say they're doing micro-services should be doing most of these things and I got together with one of my colleagues who's one of these guys has done a lot of work with micro services and we came up with an article that we published earlier this year those of you at the back are going to struggle with all that everything on the slides that's at 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 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 that I think are particularly interesting so the first thing is this notion of componentization via services now the idea 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 a one point object being substituted for components and then components came back to objects again and it all got very confusing what 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 would assemble stereo components you know you have an amplifier you have speakers you have a CD play have a tape player you can replace any of these items independently that's a crucial thing and indeed you can upgrade any of these items independently so if I want to get an improved amplifier I don't have to change everything else that's a goal of what we're aiming for a component is something that's independently replaceable independently upgradable so in terms of software and we see components to becoming two forms we obtain libraries that we use from third parties and we make them part of our process and to some extent we have then the choice of when do we 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 upon how the dependences are all laid out a service is a different kind of component where it's running in its own process and while with a library we talk using the language communication facilities that we have built into whatever language we're using with a service we're 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 even when it tends to replace ability and upgrade ability if I've got a monolith with 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 monolith 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 they would be running in completely different runtimes and they could operate they could be upgraded more independently now there's a cost of course with that but that's part of the notion of how it ties into the independent upgrade ability so for the next one organization in around business capabilities is another important theme in the micro services view of the world so a lot of lot even development organizations organize themselves around technology I mean you'll see this in a lot of big companies I'll have their D bas and their database group that might have a completely different group of people on the UI it's focused around technology the key thing with the micro services view of the world is that we should instead organize 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 common certainly inspiration for the micro services community where when they divided everybody knows Amazon divided themselves up into two pizza 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 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 the way 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 as 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 talk about the idea of let's get some powerful piece of middleware that will automatically do all sorts of stuff it'll route messages it will apply 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 micro-service community very much regret reject this notion and says the smarts instead should move to the endpoints themselves what we want is everything to connect together and to be able to easily route messages or communications between them but it should be up to the endpoints where all that smartness goes any business logic any routing stuff all of this 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 needs a relatively dumb set of pipes and puts all the intelligence onto the endpoints another thing that also brings out this variation to a lot of service stuff is the notion of decentralization decentralization in terms of the overall way in which a service landscape is governed and in particularly decentralization 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 to write across a company you know our company's standard is Oracle or our company's standard is db2 everything goes in the same place and even a lot of service-oriented architectures it's really a lot about multiple services or pulling data in and out of one logically large database the micro service appoint point of view is to say now 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 push as well now this is a couple advantages first it removes this horrible mess of integrating through a database which causes no end of problems in enterprises all over the place the second thing it does it frees up individual services to use a datastore that make sense to them some 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 yours choice of data persistence should be entirely up to the individual service themselves and that's part of this general notion as I said of decentralization 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 Bluegreen deployment that allow you to put stuff to live with zero downtime these kinds of things are mandatory in too 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 you have a very automated way of getting these things going you also want to be able to get new boxes and spin them up rapidly it also puts a lot of emphasis on monitoring as well 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 going to 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 it it's most famous level you have things like the chaos monkey Netflix is one of the most well known MA micro service architectures and they built a tool that goes around randomly destroying nodes and they use that in order to detect how resilient their overall network is I mean I don't run it all the time they run it during office hours when there's 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 you're resilient I think it encapsulate svelt 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 our set of common characteristics and I hope gives you a bit of a flavor for the kinds of things that people talk about but it still raises a number 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 SOA but in order to answer that question you have to say to yourself well what is SLA in the first place and that is really I think at the heart of the problem because I've heard SLA defined in many different ways in many different incompatible ways by different people for some people SLA 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 a really ticked off at the micro service people because their attitude is well we've been doing all of this and calling it SOA for years why do you invent this new term and bring it along what what is are you just calling words because everybody knows of course we become incredibly rich by coining terminology I wish but of course SOA means different things to different people to 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 the health services supposed to connect to each other it's a very different world indeed so the way 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 micro services 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 of micro services is it carves out a cut and consistent space within that but he is perfectly fair to say that the micro service approach has been done by people under the name of SOA for at least a decade if not more so it's not a new technique at all and it's perfectly reasonable that people are annoyed about it when they say Oh micro services are 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 micro-services as a term is that has this implication of size and of course as soon as you say micro is that 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 right I mean it's all size I mean it's very responsibilities are very flexible right james lewis has this statement he says mirco services have got to be small enough to fit in my head now James has config rate deal in his head as it turns out but his point is of course the survey that if you've got a service it should be understandable to a single person that's his test for it but that's still a bit vague I started asking around people trying to get a sense of size people were extremely reluctant in many ways but the way I was able to get some figure by saying well how many people per service in your application and I got a lot of different answers and as you can see there's quite a spread here now 15 people 10 services for people 200 services there's quite a range of different sizes it's certainly true that pretty where everywhere I come across the notion of the to pizza team from Amazon 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 two American pizzas and you can feed a hell of a lot of people with two American pizzas but I think the notion is still there but within there's 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 you know 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 micro-services compared to monoliths now one big advantage of a monolith is it a 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 micro-service stuff because it's so cool we want to do it and they ended up getting themselves into trouble where they really should have built a simple model if 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 micro services introduced distributed computing they often introduced asynchronous communication and those are significant complexity boosters so the monolith still has the advantage of up to a certain size at least simplicity one of the great advantages of micro services is the ability to deploy the various pieces independently if you want to upgrade a monolith you've got to upgrade the whole thing I heard the story of an insurance company where they've got one monolith that handled all their different lines of insurance if they wanted to in to upgrade their auto insurance they had to upgrade the home insurance as well they couldn't do them independently and that's a disadvantage of a monolith you're forced to upgrade all at once now if you're really good at your continuous delivery pipelines 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 gave them more flexibility and this is of course very important in in an 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 are granted 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 right so nothing must stop the shopping now that 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 we've modeled 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 your software 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 micro services too quickly if you don't understand the module boundaries well you've very easy to get a lock yourself into a pure design and anumana lift can be a good way of figuring out module boundaries are before you actually do the split and we 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 now 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 it in practice it's too easy to kind of do little end runs around and expose little things and 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 maintained it 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 micro service is kind of a discipline that forces you to keep your modularity together and then I mean the last big advantage in micro services they allow you to go with multiple platforms if some parts of your application stack are best off with a traditional you know Java whatever language you can use them in some places and then you use sort or an even experiment with 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 20 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've got to 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've 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 then the last point I want to say is if you're going to go down the micro-service point there are certain things you've got to make sure that you get sorted out otherwise 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 set up and provisioned and ready for use you're going to have a lot of problems in the micro service world this is of course why micro 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 um you don't want to be spending two days deploying the service it's got to be there in hours at the very least and preferably minutes and it should be as much as possible automatic process that's just the basics that's just for running with just a couple of certain amount of services and to do more you've got to add more there's 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 one I missed DevOps culture that is you've got to break down the barriers between the operations group in the applications group so that they're working together if you've got a difficult communications between the two again you're not going to be able to manage the quantity of services that you've got to deal with so as I said those I think are the minimum things to have when you first go five 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 there's tons of stuff out there on the web you can go and find out more and that's the end of my first talk you

Channel: GOTO Conferences

Views: 451,373

Keywords: Microservices, Micro-Services, Martin Fowler, Software Development (Industry), Software (Industry), GOTO, GOTOcon, GOTOber, GOTO Conference, GOTO Berlin, Conference Keynote, Extreme Programming, Computer Science (Field Of Study), Programming Language (Software Genre), Software As A Service (Industry), Software Engineering (Industry), Software Testing (Industry), Videos for Developers

Id: wgdBVIX9ifA

Length: 26min 26sec (1586 seconds)

Published: Thu Jan 15 2015

Reddit Comments

[u/goto-con]

FYI, here's the talk Abstract

In the last decade or so we've seen a number of new ideas added to the mix to help us effectively design our software. Patterns help us capture the solutions and rationale for using them. Refactoring allows us to alter the design of a system after the code is written. Agile methods, in particular Extreme Programming, give us a highly iterative and evolutionary approach which is particularly well suited to changing requirements and environments. Martin Fowler has been a leading voice in these techniques and will give a suite of short talks featuring various aspects about his recent thinking about how these and other developments affect our software development.