Table of Contents
We return to our weekly microservices community spotlight with a talk by a speaker who is certainly no stranger on the conference speaking circuit. Martin Fowler, Chief Architect at Thoughtworks, recently spoke to a packed house at YOW! Australia where he delivered a 3-part presentation. Check out Part 1 complete with transcription below.
We hope you enjoy the presentation as much as we did!
Software Development in the 21st Century
presented at YOW! Australia
If you’ve ever heard me speak before, you’ve heard me speak to this title because I’ve gotten tired of making up titles for talks ages ago. This way I can just use one title and reuse it to mean absolutely anything. It’s kind of like the UML, it’s got no semantics. You can really do what you like with it. If you’ve heard me speak before, you’ll also probably know that I don’t like to bore you with one long talk. Instead, I prefer to do it with three short talks instead, and I’m going to do that today. I’m going to kick off with the world of high fashion.
Over the last few years, microservices has become the big thing. That’s the Google trends report. Actually, it was a bit of a time ago, but you can see the effect it’s had from not very much to being quite the talked-about thing. Like with all of these kinds of things, there are some sensible things and a lot of stuff that’s not so sensible. So this is going to be my 20-minute, hopefully mostly sensible summary of how I see this topic.
At its heart is the idea that when we think about building our systems, instead of putting all the capabilities and features of a system into a single process as a single monolithic thing, we should instead break it apart into several independent processes and services that collaborate with each other. That’s the essence of it, but there is rather a lot more to it than that.
I first got involved in this, in fact, in conversations with many of my colleagues and various contacts I have in the industry who were talking about this style that they wanted to work with. I thought we mentioned back in the Thoughtworks technology network radar back in 2012, I think it was. Was it when you were still around helping trying keep it under control. It was so very interesting, but what did it really mean? I mean it’s all very well talking about breaking things apart into separate services, but what would be a better definition of that?
Definition of Microservices
This concerned me as it got more and more interest, and I got the feeling, “Well, this has all the signs of a big hype about to come over with it.” What I wanted to do was to try and say, “We need a better definition,” but the problem is that something like this you can’t really have a strict definition, like so many things in our industry. The only way you can approach a definition is to say, “Well, what are the common characteristics?” For the various people out there who say they are doing microservices, what are the kinds of things that most of them doing? I think of it as, “What is it that most people that say they are doing microservices are doing most of the time?”
Characteristics of Microservices
[3:02] This led to a collaboration with another of our colleagues, James Lewis, and we wrote this article that you can find on my website, and that corresponds fairly closely with the beginning of that tick-up. It did help sort of generate a lot of interest, but more importantly, I think it helped lay down at least some sense of what this term means. In that article we outlined this list of characteristics. I am going to start off by going through what I think are the most important ones of these. I am not going to go through all nine, you can go through the article if you want a description on that, but I will go through what I think are the most important points.
Componentization via services
The first of these is the first one on the list, somewhat unsurprisingly. It’s a fairly awkward phrase, that, “Componentization by services.” It means a lot to me, means a lot to James, but what does it actually mean to most people? To begin with thinking about that, we have to say to ourselves, “Well, what do we mean by a component?” This is term that in the software industry has been around for a long time with not very good definition. I remember in the early days of OOP, people saying, “Objects and components are really the same thing,” but it never really gelled very well. I always struggled with, “What do we mean by components?” There’s a whole wave of component-driven software at one point, etc. etc., but it was really, I think, clarified to me very much by someone whose ideas I have stealing steadily for the last two decades, which is Ralph Johnson. He said, “Really when people think about components, they’re not really so much thinking about software itself. They’re more thinking about how we want to relate to software. We want to work with software the way we like to work with, say, our stereo, our hi-fi, where we can actually take our components and replace them independently, and we can also upgrade them independently when we want to get a new unit.” So the key to my mind of componentization is this notion of independently replaceable, independently upgradeable.
Now, when we talk about how we’re going to do this, there are two broad ways we might want to do it. We might want to do this as a library, which could be something like say a .gim file or a .ja file or whatever that we bring in, or we could do this through the notion of a service, which is a separate process available on a network that we call and talk to through interprocess communication. The first principle of microservices is to say that we’re going to take this componentization route. We want to componentize what we’re doing, and we’re going to do it by using services, not libraries.
There’s an important corollary to this, a very key point to figuring out. If you’re using microservices, you should be able to replace and upgrade your services independently from each other. If you’re in a kind of situation where if you need to deploy a new version of a service, you have to coordinate the deployment of half a dozen or a dozen other services and get them all to flow together in the right order, then you’re not doing microservices. You’re doing some different service approach, but it’s not a microservice approach. Every service needs to be able to deploy independently and upgrade independently. That’s a very firm characteristic of this style. Of course, how you do that is a whole other question, and a lot of the art of actually doing microservices if about trying to be able to pull that off, but that is a really crucial part of the definition of the term.
[6:43] So that’s what we mean by componentization by services. It’s really quite a strong statement, even though it’s quite a small phrase. To some people, and in fact, my colleague, Sam Newman, who wrote the book on building microservices, that is the most important characteristic of microservices. I tend to agree with Sam in most things, mostly because I just steal what he says and parrot them to more people, but actually on this point I’m not quite so sure I agree, because actually I think in many ways the most important point about microservices is the second point.
Organized around business capabilities
Now this really talks about how we organize people as opposed to anything else. A lot of organizations, a lot of projects organize themselves around the software. The common one is this kind of layered organization. Lots of people I run into say, “Oh yes, we have a UI organization and a server organization, database people who are completely separate.” They’ll often just seem like a completely different profession, but the point is we’re organized that way, and even if it’s not strictly by layers, people are organized by what software system are you responsible for dealing with, things of that kind.
The microservice approach says, “We want to change that. We want to change that by organizing these services around the business capabilities, and what’s more, we want to keep the sizes of the teams small.” When people talk about microservices, a lot of people say, “It’s all about how big the software is, how many lines of code are you about.” I’ve even heard people say, “If it’s more than 1000 lines of code, it’s not a microservice,” but that’s not what the meaning originally came from, at least not for most people. For some people it was, but most people would say, “No, it’s more about the fact that we have a team of people that’s not that big that are looking after each service.” So one of the big inspirations of this thinking was the organization of Amazon. You might have heard they came up with the notion of the two-pizza team. If I’ve got a team that needs more than two pizzas to feed for lunch, then something’s wrong. That’s how it was phrased. Now, of course, this is America, we’re talking about American pizzas, but even so, it’s a limit on the size of your team.
One thing that’s often missed-out of description is not just should the teams be relatively small, they should also be directly traveling through to the customer and have some customer interaction directly in place. It’s not just the size, it’s also this vertical nature. Everything that’s needed in order to fill some part of the customer need. Whether that customer be an end-customer of the business or an end-user within the business. We do not separate in terms of analysis, UI, database, things of that kind, we get a cross-functional group of people all there to support a single usage, which, in fact, is a theme that goes back a long way. If you look at the early days of Agile, it’s the same thing, Scrum teams are always supposed to be a small cross-functional group of people aimed to support a particular product. There’s nothing particularly new in this idea, but it’s a very strong part of this definition.
[10:09] Again, if you see people saying they’re doing microservices and they have their frontend services and their service services and the database services, that should indicate there’s something wrong. Everything that’s required in order to deliver functionality to the customer should be within the notion of that team. So that’s the business capability organization.
Smart endpoints and dumb pipes
The next point I want to bring out is pop down to the number fourth one here. Smart endpoints and dumb pipes. A lot of people when they think about services and particularly things like service-oriented architecture, I think in a system where you’ve got a whole bunch of service applications and some smart middleware that’s in the middle, that’s kind of routing everything around together, often coming under the title ESB, which, as we know, stands for egregious spaghetti box, or at least that’s what Jim Webb had told me, and he must be right. A key element of this is to move that smart out of the bus and into the systems themselves. So if you’ve not got some bus cleverly figuring out how to route message around, how to do authentication and rate limiting, perhaps even how to apply business rules. Often the core of these ESBs was actually from fairly simple, but very effective middleware, that did messaging and then it decreated all of its extra stodge until you put your entire application, it seems, into the ESB, give you no way to version control it or manage it any sensible form.
The microservice movement very much rejected that because that was then most of what they saw in services and said, “No, every service has got to do its own. The communication between them we keep really simple.” So you hear of things like REST HTTP calls and things of that kind or if you are using messaging, which most of them do, you just use a simple messaging layer. You do not attempt to put smarts in there.
[12:10] Another big theme of this is decentralization. Decentralization in terms of governance, but in particular decentralization in terms of data management. Again, when you look at lot of organizations you see these multi-layered applications built on top of a database that supports many different business capabilities. Even if you’ve got multiple applications, they often share via a database. Now I’ve always found this a little bit odd. I was taught from my very early days of structured programming that shared global state was generally a bad thing and sticking it in a database doesn’t necessarily make it any better. So, what the microservice people do is they say, “No we separate all this.” We say, “No, we’re never sharing data with a database.”
If two separate services need to talk to each other, they talk to each other through the service collaborative protocols and they talk through service endpoints. Database and data storage is always private to a service. That means not just can they use different logical databases. They can be completely different database technology. If it makes sense for one service to use a graph database, the other services to use a relational database, another service to use document databases, that’s fine. That’s their own decision. It depends on the services individual needs. It doesn’t mean you have to have separate databases. You can actually share one physical relational database, but there have to be separate schemas, and there are no links between the different schemas. All the linkage goes through the services.
[13:54] The next one to mention, infrastructural automation. I’m going to go into this in a separate chunk of my talk, a separate 20-minute talk in a moment, where I’ll talk about infrastructure as code. I will just leave that as a placeholder for that. I will talk about a bit later.
With all of this, we have an interesting list of characteristics. But one of the first questions people asked once microservices became talked about, in fact it became the perennial talk, and once we started publishing our article, is, “Is this really the same as SOA?” Services-oriented architecture. This is actually quite an interesting question to ask. As we were publishing more and more of the characteristics because we published the article in installments, people said, “Well, this is all what SOA is. There’s no difference between this and services-oriented architecture. You’re just coming up with another name to mean SOA.” That’s one group of people who had experience with SOA, but for many people, SOA means something completely different. It means the egregious spaghetti box. It means teams organized in this very vertical layer. The problem was that SOA itself never really had a very good definition. This came right at the start.
I remember being at a conference. It was the Microsoft one that launched Longhorn. Anyone remember Longhorn? The future of Microsoft? I was at the PDC where they launched that, and they had a full day themed on service-oriented architecture, a whole bunch of different speakers talking about it. I was on the panel at the end and got the biggest laugh of the day by just pointing out that I’ve sat through the whole day and I still didn’t understand what service-oriented architecture was. That’s because there’s so many competing definitions. Yes, what I call microservices is what some people considered to be true SOA, but there’s lots of other SOA that doesn’t fit that definition at all.
What I see is that microservices is a subset of SOA. One particular style of SOA that’s worth talking about on its own, and it really needs a label because SOA is too diffuse as a label. So we call it microservices.
[16:14] Now, microservices is a curious kind of name. I want to stress I didn’t come up with this name. I would like to think I would come up with a better one. I didn’t come up with this one. It was actually coined by a group of other people, including James Lewis, the guy who co-authored the article about me. When you use a name like microservices, the term micro- does tend to raise the question of size. How big should a microservice be? I asked some of the early people who did microservices, “How big are your microservices?” Look at a couple of things that are responses to this. First thing is, there’s really quite a range here, right? If you look from sort of smallest to largest of that. Also look at how I asked the question. I didn’t ask lines of code because I knew that wasn’t the way to ask it. I asked, “How many people, how many services.” Give you a feel for that. Again reinforcing the point that this is really about people, not about the software.
Another survey on microservices is one by, again another early user, Gilt. They created this little graph. They did look at lines of code. I love this graph because who else but somebody in the software industry would plot their x-axis like this? Log 2 of lines of code, right? Let me translate that for you into something a little bit more sensible. One thing to see again is quite a range. Some of those microservices are hundreds of thousands of lines of code large, a bit more than micro. Even if you look kind of in the median range there, what are we talking about? We’re talking about a few thousand lines of code. We’re not talking hundreds of lines only. So there’s still quite a range within this point.
I still stress on the fact that it’s really about team organization, but I do want to point out that there is a generally accepted official definition for the length and the size of microservice. It’s how much code can you fit into James Lewis’ head. Now we are trying to get this adopted as an international SI standard. Unfortunately, what it requires is that James’ head be detached and sent to a fridge in Paris. At the moment, we haven’t persuaded him to go through with that, but, you know, we have hopes.
[18:42] So this I think gives you a bit of an idea of what microservices really mean as a terminology. There’s a lot of stuff talked about it, not all of it matches those nine characteristics that James and I pulled out, and of course, there’ll be endless arguments for decades about what microservices do and don’t mean, but that’s what I mean, and that’s what’s based on the early adopters of this technique and what they tended to do. I am hoping that what we tried to do with that article will give it a bit more of a definition so that at least we have something to fall back on when people spout about all sorts of crazy things and have 60-person teams supporting microservice and that kind of stuff.
Although we’ve put this effort into describing the technique, one thing is very important to realize is like most architectural techniques, this is not the future of computing. We said that right from the beginning when we wrote the article. We do not see this as the one big answer to the way all computing goes. There’s quite a lot of stuff out there on the net that does imply that if you’re working on a monolith, you’re clearly doing it wrong and you’re going to be replaced by all these microservices, but it’s not what I think. It’s not like what most of the people who started this whole thing thought either.
Microservices benefits…and costs
[20:04] The thing is that microservice have costs and benefits. Obviously the independent deployment is a big factor. It’s really nice that you get a great deal of technological diversity. You can choose your database, you can choose your programming language, have different microservices operating with different programming languages. Interestingly, one of the biggest benefits that’s pointed out is that it forces you to have strong boundaries between your modules, between your components, which otherwise get too loose. That’s kind of sad in a way. I’d like to think we could build a single codebase a single-process monolith with strong boundaries between its modules, but in practice it seems very hard to pull off. I partly blame language designers for this because they don’t often give us the tools to help, but it’s also we don’t seem to be very disciplined at doing it.
So microservices can give you those things, but they come at costs. The biggest cost, right at the top of that list, is distribution. As soon as you move into microservices, you’re moving into a distributed system, and distributed systems always come at a big cost of added complexity. This not a card you want to play lightly. Suddenly you’re going to have to deal with a whole bunch of crap that you otherwise would not have to deal with.
For a start, you’ve got to worry about communications. You’ve got nice, fast in-process method calls if you’re working in a monolith. If you’re working with microservices, we’re now talking about interprocess calls, which are going to be orders of magnitude slower. In order to cope with that, you’re probably going to move towards asynchronous calls. Oh, I’ve got asynchrony. If that solves the problem, it must have been a frigging big problem to start with if that’s a useful solution. That’s what you’re faced with because asynchronous software, that’s really hard to debug. So, all of that kind of comes up.
And consistency. In a monolith you can reasonably expect that all of your data is going to be in a consistent state. You can work with that. In a distributed system, no way. You’re going to have to deal with eventual consistency, not every service is going to be quite in tune with everything else. Nothing’s going to update exactly in sync. You can cope with that, but you are going to have to deal with extra complexity.
And of course, now if you’ve got a hundred services to manage instead of one monolith, you’ve got a lot more operations stuff you’ve got to deal with. Yeah, people tell you yeah the tools will solve it. Yeah, Kubernetes, Docker, Docker, wonderful. It’s still all complexity compared to a monolith. You’re taking on more stuff.
I like to summarize all this by saying really what’s going on here apart from my microphone falling off when I say Docker, Docker, Docker is you’ve got a situation where for a system that has a lower level of what I would call basic complexity, and basic complexity is a real fuzzy term, I know, but hopefully you’ve got a sense of what we mean, you know and there’s not that much logic, not that much load on it from … You’re not talking Facebook or Amazon kind of scales here, we’re talking much lower scales, not that many people working it, maybe a lot of cases if you’ve got a dozen people working on a simple web app that doesn’t do much more than pull data in and out of database for a few hundred people, you’re going to use a Rails App or a simple Spring app or drop wizard or whatever your choice of simple web app technology is. That’s going to work just fine, and that’s going to be a lot better than trying to go the microservices route because you don’t want to deal with all of those complicating factors that come from distribution and the multitude of services. Then, as base complexity rises, then microservice become more attractive and, again, one of the core things I think to look at is people. If you’ve got 5 people, you probably don’t need microservices. If you need 50 people well then you should be considering it. If you’re in hundreds of people, then you’ll definitely need to break it up somehow. You can’t have a single cohesive team of 500 people. So microservices become attractive as you get that high level of complexity, but at the low end, there’s a real premium to taking on microservices. Believe me, we have already seen this go wrong. We have already gone into projects where they used microservices and we went in and we said, “Okay, the best thing to do is throw them all away, start from scratch, and build a monolith here because we going to be faster than we would be trying to get this thing into shape and getting it into a condition that you could actually send it into production.” That’s within the early days of the hype cycle. I’m sure there’ll be a lot more of that going on.
[25:08] So, microservices is not the best compared to a monolith. The choice between a monolith and microservice is like most of these things, it’s an area with two obvious endpoints and a very large gray band in between. You’re going to have to make a judgement call as to which way to go. In particular, be very wary of using microservices in a domain you don’t already know well. That one argument is to say if you’re building a new system you should start with a monolith and expect to replace it with microservices later if you’re lucky enough to run into the kinds of problems that raise up that base complexity. That’s, I think, fairly good advice. It’s not universally-held, but I think even the people who would argue against it would say if you don’t know your domain, microservices aren’t a good place to start because the problem is those strong module boundaries will actually work against you.
The strong module boundaries only help you if you make a good choice as to where those boundaries should fit. Of course, the whole thing in early on is you don’t know where the boundaries are going to be, right? So who knows if you’re going to get them right. In a monolith you’re better off because you can refactor things more easily across the boundaries.
[26:21] One last thing. There are certain other skills you are going to need if you’re going to be able to do the microservices thing at all. You need to be able to provision your software rapidly. You need good monitoring. You need to be able to provision all your servers and stuff rapidly, and you have to bring in this whole notion of devops. Remember that operational complexity? You going to bring in a Devops culture.
This is just really the basic list. When I was asking around my contacts about this, I said, “Just tell me the starters.” Just to deploy a half a dozen microservices you need this. To get serious about microservices, you need a lot more.
That’s a very brief sort of 25-minute intro to microservices. If you want more, I have a page on my website where I’ve collected together a whole mass of stuff written by myself, my colleagues, a bunch of conference videos, all that kind of stuff. That provides hopefully a fairly good guide to getting started on microservices. There’s a lot of material indexed of it. If you want it all in a coherent form, I recommend the book by my colleague Sam Newman. The main thing to realize is that monoliths and microservices, it’s a choice. It’s a choice that depends on the context that you’re in, the complexity of the application you’re trying to do, and really the heart of it is the team organization, how you want to organize people. When I talk to people who have used microservices in the beginning, that was the main driver. We’ve got a lot of people, we need to organize them into a way that makes sense. Microservices we felt was the best way to break that team into useful groups.
As I commented at a recent event, people always complain about silos, but it’s human nature to form silos to group some people that want to get together. What you want to do is to want to arrange things so that those silos are in the most productive manner possible. That is really what is driving a lot of interest in microservices. The feeling that that’s the best we can do with that situation. So, that’s the first talk on microservices.
About the speaker
Martin, renowned author, software consultant and speaker, brings two decades of experience helping corporations utilize object technology for mission-critical information systems. He was one of the authors of the Manifesto for Agile Software Development, and has written five books on software development and collected awards for them. He’s also a highly regarded speaker at international conferences, although these days he prefers to stay off the stage. His main interest is to understand how to design software systems, so as to maximize the productivity of development teams. In doing this he has looked to understand the patterns of good software design, and also the processes that support software design. He finds he learns a lot from listening to the experiences of his fellow ThoughtWorkers: digging for useful ideas and communicating them to the wider world.