Microservices

[Music] So, microservices have been talked about a lot over the last year or so. Um, I see a huge amount of stuff on Twitter and the like talking about this topic. Um, 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 to try and figure out well what exactly are they? What do 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 on earth is it in the first place? I mean the basic idea is fairly straightforward. um you contrast it with u what's considered to be a traditional monolithic application. A monolic a monolithic application means you've got various capabilities, various uh things that you want to provide and you put them all in the same application typically running in a single process um and you think of it as one thing. The micros service approach and its crud disapproach 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 monolith, you scale by effectively cookie cuttering the monolith and putting it on multiple machines. While with 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 a definition of it. I mean, how does this vary from everything I've been hearing people yammer on about serviceoriented architecture for the last 10 years? But the trouble is with something like a topic like microservices, it's very hard to come up with any kind of firm definition. Um, this I mean I've the same thing with NoSQL, right? I mean NoSQL databases. I mean what's a definition in NoSQL? And and even further back I mean you know what is a definition? How can we come up with a 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 it's 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 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 together with one of my colleagues who's one of these guys who's done a lot of work with microservices and we came up with an article that uh we um published earlier this year. Um those of you at the back are going to struggle with all the everything on the slides that's at the bottom because of the way the things laid out, but um 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 um 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 that 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 at one point objects 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 um 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 player, you 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 our goal of what we're aiming for. A component is something that's independently replaceable, independently upgradable. So, in terms of software, um, we see components typically come in 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 dependencies 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 interprocess communication facilities such as um web service calls or messaging or something of that kind. And the services give us some useful advantages when it comes to replaceability and upgradability. 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 upgradability. So for the next one um organization in around business capabilities is another important theme in the microservices view of the world. So a lot of lot even development organizations organize themselves around technology. I mean you'll see this in in a lot of big companies. They'll have their DBAs and their database group. group that might have a completely different group of people on the UI. It's focused around technology. The key thing with a microservices 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 a common certainly inspiration for the microservices 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 the 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 comes um 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. Now 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 um let's have smart endpoints and dumb pipes. When a lot of people talk about serviceoriented 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 root messages. It'll apply business rules. It does all sorts of things. This of course is the the ESB, the enterprise service bus, or as it's more correctly known, the egregious spaghetti box. The microser community very much regret rejects 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 end points where all that smartness goes. Any business logic, any routting 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 is 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, right? And it's often can be right across a company. You know, our company's standard is Oracle or our company standard is DB2. Everything goes in the same place. And even a lot of serviceoriented architectures, it's really a lot about multiple services all pulling data in and out of one logically large database. The microser 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 serviceoriented 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 microser people um push as well. Now, this has 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 the place. And the second thing it does, it frees up individual services to use a data store that makes sense for them. Some services, a relational database would make sense. Others would want to use one of these hot new NoSQL fancy things. I mean, in which case they use it for that. But the idea is your's 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 um techniques like blue green deployment that allow you to um 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 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. Um, 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 at its most um famous level you have things like the chaos monkey. Netflix is one of the most well-known uh micros service um architectures and they built a tool that goes around randomly destroying nodes um and they use that in order to detect um how resilient their overall network is. I mean they 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 uh encapsulates very well the attitude that the microser 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 of questions of which one of the biggest things is is this really serviceoriented architecture is this just the same kind of stuff that we've been hearing about for a long time in the context of S SOA but in order to answer that question you have to say to yourself well what is S SOA in the first place and that is really I think at the heart of the Because I've heard S SOA defined in many different ways, in many different incompatible ways by different people. For some people, S SOA is exactly what we've been talking about in the microser world. And that's why a number of people in the S SOA community are really ticked off at the micros service people because they their attitude is well, we've been doing all of this and calling it S SOA for years. Why do you invent this new term and bring it along? What's what are you just coining words? because everybody knows of course we become incredibly rich by coining terminology I wish but of course S SOA means different things to different people to many people in the microservices community they've been around big enterprises and to them S SOA means the enterprise service bus it means committees of people who are there to lay down standards for how services are supposed to connect to each other um it's a very different world indeed So the way I tend to think of it is saying well S 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 S SOA terminology. Um in my view the S SOA term is too broad. I mean it means so many different things it's practically meaningless. Um but the value of microservices is it carves out a a consistent space within that but it is perfectly fair to say that the microser approach has been done by people under the name of S 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 microservices are nothing new. That's a perfectly reasonable response. [Music] Now one of the problems with microservices 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 microservices as a term is that it has this implication of size and of course as soon as you say micro is well how big is a microser and you actually talk to any of these people in the microser world and they're always very reluctant to answer this question they always say well you know it should be one responsibility Well, 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 it's all size. I mean, it's very responsibilities are very flexible, right? Um, James Lewis has this statement. He says, "Murka services have got to be small enough to fit in my head." Now, James has can fit a great deal in his head as it turns out. But his point is of course the service the 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 um 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 um you know 15 people 10 services four people 200 services there's quite a range of different sizes it's certainly true that pretty everywhere I come across the notion of the two pizza team um from Amazon is is fairly well uh 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 um I think the notion is still there, but within that 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 microservices compared to monoliths? Now, one big advantage of a monolith is it's a relatively simple and familiar approach to use. And this is not to be underestimated. I mean, I've already started hearing in trickling in stories of projects that, you know, decided, oh, we want to use this microser stuff because it's so cool and we want to do it. and they ended up getting themselves into trouble where they really should have built a simple a monolith 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 micros service because microservices introduce distributed computing. They often introduce 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 microservices 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 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 um the separate pieces. And that was in fact one of the the crucial reasons why Netflix went down this route. They had difficulties getting their systems um being able to deploy as rapidly as they need to do. So, they found that switching to a microser approach gave them more flexibility. And this is of course very important in the internet 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. Another advantage of microservices 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 microser 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 um 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? Um which is the kind of thing that goes wrong when you don't do consistency. Well, another big issue with mono with the uh 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 monolith 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 um these remote calls. So that's also I think one of the problems with running to to microservices too quickly. If you don't understand your module boundaries well, you're very easily going to lock yourself into a poor design. And a monolith can be a good way of figuring out what your module boundaries are before you actually um do the split. Having 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, you know, 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 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 micros service world, your communications are purely through your network interfaces and it's ma and it makes it really easy to ensure you don't share mutable state, which is of course one of the the best ways to get yourself into a confusion in a monolith module architecture. So in many ways, microservices kind of are a discipline that forces you to keep your modularity together. And then I think the last big advantage of microservices, 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 or or 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 lose JavaScript. That's the one thing I really don't want anybody to do. You 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 would say if you're not sure, if you got a relatively small system, don't worry about it. Um, but on the other hand, they can be an appropri 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 microser 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. Um, 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 microser world. This is of course why microservices 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 um 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 um 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 most and preferably in minutes. And it should be as much as possible an automatic process. That's just the basics. That's just for running with just a couple of c of services. Um 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. Uh and the one I missed, DevOps culture. That is you've got to break down the barriers between the operations group and the applications group so that they're working together. Um, 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 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. Um, I've written various things on it. There's tons of stuff out there on the web. Um, you can go and find out more. And that's the end of my first talk. [Music]