Kevin Montalbo

Welcome to episode 44 of the Coding Over Cocktails podcast. My name is Kevin Montalbo. Joining me from Sydney, Australia is Toro Cloud CEO and founder, David Brown. How's it going, David?

David Brown

Good day, Kevin! 

Kevin Montalbo

All right. And our guest for this episode is a former ThoughtWorker and is now an independent consultant who specializes in microservices, cloud and continuous delivery. He helps clients around the world deliver software faster and more reliably through training and consulting. He's also an experienced speaker who has spoken at conferences across the world, and is the author of Building Microservices and Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith, published by O'Reilly. 

We'll be talking about both books today. Joining us for a round of cocktails is Sam Newman. Hi, Sam! Welcome to the show!

Sam Newman

Hi, Kevin! 

Kevin Montalbo

All right, great. So first of all, we wanted to congratulate you on the release of the second edition of Building Microservices. Congratulations! So, what has happened in the microservices space in the last six years that prompted you to do a complete rewrite of the previous edition?

Sam Newman: I mean, the rewrite actually started like, three years ago. So,  it was almost like three years of stuff. And it was a couple of things. The first edition was while we were still exploring the space of what microservices looked like. And so there were some ideas that I wasn't sure were going to stick around and there were some things I was maybe more equivocal about. Like, I think this is a good idea, but I'm not sure. And then I got like, three or four years of working with companies learning, from other people's case studies and realized, I know some of the ideas I had were really stupid. And other of the ideas I had were really the right way to do it. So, I wanted to be a lot more clear and concise in explaining some of those concepts and also explain a bit more of my reasoning behind some of it.

And also in some areas I felt I wasn't as explicit enough. Like, I want it to be really explicit and maybe a bit more detailed, so people could understand. I realized there's a bit more implied knowledge. I kind of assumed people had more understanding than they did. And that's just probably the problem of writing your first book. There are also some particular areas of the book that didn't serve very well in the first edition. I skimmed over this quite quickly. I just assumed people would work out. They had to break user interfaces apart now and then. But most people didn't. The security chapter did a complete overhaul. Obviously, Kubernetes wasn't a thing when I wrote the first edition. So, you've got to talk about Kubernetes and you've got to talk about serverless. And also I think the organisational stuff, I got a lot more information about, and I think that that idea came a bit more to the fore.

David Brown

I mean, we're going to get into all those details about the book, some of which you've just mentioned there. You've talked a little bit about the benefits of microservices, but you also covered a lot of the pain points. So, before we get into architectural type considerations, I'd like to hear some of your thoughts on your experience as a ThoughtWorker but now as also an independent consultant. I'm sure you've got a bunch of stories where you've come across some of these pain points in the real world that some of the customers are experiencing. So, can you run us through some of those?

Sam Newman

Yeah, just the top line, they’re a terrible idea. They're an architecture of last resort as far as I'm concerned. But to run through some of the issues you're going to have; firstly, you're going to experience the fact that a lot of the people using them don't haven't really ever built a distributed system before and may not be aware of the fundamental challenges of distributed system theory. You can't just say, “This used to be a method code. Now it's a network code,” and it's all fine because latency is a thing. Partitions are things. So, we've got the foundational stuff. You've then just got kind of a shift in where the complexity lies. A big shift of complexity into the operational space. And traditionally when you see developers or architects making a decision to go to microservices, they're increasing the pain in the operational world.

So, have you talked to the people who are going to run this infrastructure? A large amount of the pain points actually only hit you once you're in prod. So, you can theorize around some of these issues, but once you're in that production environment, that's where the real horror, pain and suffering really hits you. And so one of the perennial issues I see is people kind of come up with a sizable microservices architecture and then deploy it. And then they experience all those pain points at once. And that's a very difficult thing to grasp.

David Brown

You said it hits when they hit prod, the pain points hit when they had prod. What have they missed during the development process?

Sam Newman

A microservice architecture tends to be more highly distributed than other systems people have worked upon. And so the delta between your development environment and your production environment have increased quite significantly. It becomes increasingly difficult to pick up all the problems. Pre-prod with a single process monolithic application, you can do a pretty good job of simulating an awful lot of what you're going to experience in production before you get to production. That becomes increasingly difficult in a prod environment. I mean, it's just more network calls, more things to go wrong.

And the other thing I would say is that it's what happens when something does go wrong, but you also realize you've missed an awful lot of stuff. So when you do have that issue in production, it's like, “What the hell happened?” And often, you realize you don't have the information you need when that's already occurred.

I think my favorite tweet that sums this up is from the Honest Update Twitter account, which is “We've moved on my monolith to a microservice architecture so that every production outage is like a murder mystery.” And it's like, for entertainment value that's fun to watch on TV, right? But when you’re in the middle of a 4:00 AM support call and you just have no idea what happened, that's been some of those things where you start to hit home. And that's why I've become a big fan of firstly doing everything I can to not do microservices. And then if I have do it, [I’ll be] starting like really with an incremental approach, as you start with getting one thing into production, working with that, and then growing incrementally, because that allows you almost to ease yourself into that pain a little bit more easily and adjust a bit more easily.

David Brown

Presumably there's benefits for the pain. And in the end, given you have spent several years writing books on the subject. But we'll get to that point. You added a section to the new book called “Information Hiding.” It wasn't in the first edition. How does this concept relate to microservices information?

Sam Newman

So, it was mentioned in passing. Martin Fowler was kind enough to review both this edition and the first edition. And he said there might be something in “information hiding” in terms of it's associated with microservices. And so, I think I mentioned it in passing in the first edition, but it didn't go beyond that. And increasingly over time, as I spent more time really grappling with some of the issues that people have in finding the boundaries of their services, which is I realized a lot of the ideas from the early days of structured programming and modular theory in general do apply very well to a microservice architecture. So, one of the things you can get really wrong is if your boundaries are in the wrong place, you end up with lots of cross-cutting changes happening quite frequently. Well, this is something we have grappled with before, back in the late sixties and early seventies.

So information hiding was David Parnas’ theory around how we kind of delineate our boundaries on modular boundaries in a way that allows us to do work independently so you can change those modules independently, but also effectively maintain that flexibility so when I change one thing, I don't have to change something else. And so it was talking about effectively in which your default position is, you just don't hide anything. You don't hide anything, right? Anything you expose over a microservices boundary becomes part of a contract that that microservice has to fulfill going forward if you're going to maintain backwards compatibility. The less you share, the less you break.

David Brown

So, in the API space, we talk about abstracting APIs. Is that the same sort of concept you're talking about here?

Sam Newman

It can be. Probably a more common example of information hiding that many of you may be aware of is encapsulation. So, encapsulation in objects in modularity programming is a way of doing information hiding. So with APIs, you can almost do this at different levels. You know, a classic example of that could be a microservice might expose, say, a slightly larger API. You might stick that behind an API gateway, which further limits what the API exposes, maybe over the public internet. So then, I'm practicing a degree of information hiding to outside parties. So then if I changed my microservice, the API can kind of still serve that function. But really fundamentally, it's a mindset. And I think what I saw a lot of people doing microservices is they've worked out what functionality is going to be in it.

Say, that's in the database. “Well, we'll just put everything because we don't know how it's going to be used. We'll just create an API that lets anyone access whatever's in our database.” And they just see a microservice, like a wrapper around a table, which is the wrong way of thinking about it. Instead, what you want to do is flip your thinking around. You want to think from a consumer point of view, what do they need to create the right API event and end point for those consumers? And what that will mean is that you're only exposing the bare minimum of what they need. The rest of the stuff inside that service boundary remains hidden. And then, anything you hide inside your service boundary, you can change however you want. And it won't affect people from the outside. 

And with a lot, especially my larger clients, the thing they really want out of microservices when you get down to it is mostly, they want more developers to be able to work at scale without getting in each other's way. They're talking about moving to independent autonomous teams. So, you need a team to be able to make some changes happen in the services they own without breaking other people. So it's really important that that idea of being quite parsimonious in what you expose, be really limited in what you expose. Because like the bigger API, the bigger the things that you've got to maintain going forward, and that just becomes a killer for things like backwards compatibility.

David Brown

You also wrote a book about migrating monoliths to microservices. And actually you reference it in the second edition of your microservices book as well, where you're saying the monolith is rarely the enemy. So, you kind of alluded to some of this where you said microservices are the last resort. So when you say monoliths are rarely the enemy, what do you mean by that?

Sam Newman

The monolith has gone from being a statement of a style of architecture to being a value judgment. We don't hear the word “legacy” anymore. We hear the word “monolith” and that's replaced that. And that's what I think is unfortunate because monolithic architectures are perfectly sensible architectures in many different situations and a single process. Monolithic architecture would actually be my default architecture unless I knew any reason to do something else. When you actually sit down and talk to people about, “Why is it you are moving to microservices or thinking of moving to microservices?” What I start with is, “What is it you're hoping to achieve out of this transition?” And when you get to list out the goals they have, they'll talk about things like, you know, “improved autonomy within my organisation”, “a faster pace of delivery.”

They might talk about being able to scale in different ways, maybe use different technologies. And when you list all of those things out, none of those things are, “I hate the monolith.” None of these things are, “I want to remove the monolith.” Sometimes, you've got customers or projects. Or you’ve got a burning platform, like you've got a mainframe and the mainframe program has all retired, so you need to get off it. But most of the time when you see organisations actually go through these transitions, the monolithic system rarely actually is removed in its entirety because it still has value. 

What you normally do is they remove enough functionality out of the monolithic system to achieve what they want to achieve. And you might as well leave the rest of the monolith where it is. And I think the danger then is if you see the monolith as the enemy, then the enemy must be stopped at all costs. And you lose sight of the mission. Your mission becomes killing the monolith. Whereas your mission should actually be, “I'm looking to change my architecture to improve something for my end user.” Let's do that. Let's focus on that positive outcome because the answer might sometimes be a better monolithic architecture. So that's what I'm trying to get people to think. That [they] don't think monolith equals a value judgment. Think monolith is just a style of architecture and that's all it is.

David Brown

Well, you have a book about migrating monoliths to microservices. And one of the topics you cover, which I find interesting is where to begin, because I think this is an interesting challenge because it seems overwhelming at first. And you talk about breaking it down into parts and potentially leaving some component of the monolith still standing. So as a developer, where do you begin?

Sam Newman

Well, I always start with the “why.” As developers, it's very easy for us to become activity oriented. It's a tab I quite like, which is we get obsessed by doing something without often understanding why. And a lot of developers say, “Oh, are there microservices?” And then have to reverse engineer a reason. Always start with a “why.” Who cares? If I'm being mildly provocative, I'll say your boss probably doesn't care about microservices and the users, your software, absolutely doesn't care. So, what's in it for them? Often, the people that struggle to know how to start don't have that overarching understanding about why they're even starting that journey. Once you have that goal in mind, “We have a scaling issue with our application.” “We've stuck as many copies behind a load balance as we can.” “We still can't serve the scale we're going to see for our customer base.” So, that's what we were making a change for our architecture for. That reason straight away, that sharpens the mind. That means you're going to look to extract functionality, which is around your scaling bottlenecks or you want to do more development in parallel. 

Well, then you may be looking to split your architecture down around organisational boundaries, but you've got a target which is looking at your improved cycle time and your decreased coupling between teams. Once you have that, where you start becomes a much easier conversation. And I think the other challenge that larger enterprise organisations face is even if there was a “why,” at some point that “why” has become so overloaded with other things people are trying to attempt. You've now got a list of a hundred different things this organisation thinks that microservices architecture is going to bring to them. And when you've got so many competing priorities, again, you get into that haziness. 

So, with those types of clients, I just often do some sort of stack ranking. Okay, you've got these 10 different priorities. Some of them are more important than others. So let's just do a little bit of that. Like, “Okay, well, this is actually the most important thing.” “Okay, well, we'll try and do all 10, but we're going to focus it. We’ll work through this lens first. And, we'll just see how we go.” And that's the other problem with this. How do you know if it's working out, if you don't know what it is you're trying to achieve? How would you know when to stop or when to reverse course or when to change your mind? You know, do you want a thousand microservices? I don't know. So, you need that sort of understanding about what your expectations are, about how you're going to achieve this goal to also mean that you can just be giving you counseled feedback onto it. Like, you know, is it working? Should we stop? Should we do something else? And I think if you decide it's not working great, change your mind. That's all right.

David Brown

Is there also like, “Be careful what you wish for?”  You mentioned, you know, okay, we've got a thousand microservices. Now we have a thousand applications to maintain, instead of one. So do you find that clients actually get there? And it's like, yeah, it solves some problems but introduces new ones which we didn't really expect.

Sam Newman

It tends to push pain points into unexpected locations. One of the early ones you'll start seeing is around, you know, as I mentioned, some of the changes you get in the operational space, right? In many ways, we will see this stuff first, because you suddenly realize that the way of monitoring an application, the behaviors are that have to change quite fundamentally. And then you start seeing issues about ownership. So, if you've just tried to tackle this through the lens of architecture, not adjust your ownership boundaries, that's the next page you start seeing pain points. 

So, organisations which are still trying to adopt this kind of collective ownership model, where any developer could change any microservice for example, those organisations start hitting pain points very early on. I’ve worked with a client when I was still based in Australia, who was suffering from this pain easily. So chaotic an environment, they realize, “Actually, you know, when we were 10 people or 20 people, we could afford to have anybody work on any part of the system, because those 20 people could chat and exchange ideas. We've now grown to a hundred people, or 150 people.” This idea that anyone can change anything, it doesn't scale anymore. I mean, it would be problematic maybe in a large single process, monolithic application, but somewhat manageable, especially in a statically typed language.

But when you get to a distributed system, you often find that if you want to keep going down that path towards that architecture, it pushes pressure to change your organisation. And obviously that goes in reverse as well. I know a number of organisations that have wanted to change their organisation and the reason they were going to microservices was to make that change possible. So, I think there's a lot of organisations and, look, let's be really clear. In the short term, you're going to see increased costs, right? I mean, let's just get that out of the way, it's going to cost you more money in the short term. Anyone says, it's gonna save you money inside the first 12 to 18 months, I don't think they can back that up. So you're going to see increased costs as well in the short term. So, that's also why it's even more important to make this sort of an incremental journey as well.

David Brown

So microservices in themselves, the domain driven design, so we have a particular domain that particularly with a database and a schema behind it is resolving to a particular domain. Whereas a model, I think architecture is going to cross multiple domains. Typically you think of an ERP system or some of these monolithic type systems they're going to cover multiple domains. If you're going to break down a monolithic architecture into microservices, what challenges does that represent? We're talking about now at that domain level, that database level of that model, and how does that influence how you migrate microservices?

Sam Newman

Yeah. So, using domain driven design is my favorite approach to finding those boundaries. There's always other overlays, but that's my starting point, right? So if I've got an existing monolithic system and I want to move to microservices, one of the first things you've got to do is actually probably help capture what that domain model is, and that probably hasn't been done. So a good starting point is, “Well, let's come up with our domain model.” So once you've done that exercise and, you know, I've just made that sound glibly, like it's an easy thing to do. Actually, it's not hard to do the work. It's hard to get the people in the room to do the work right. Getting on people's calendars is always the hardest thing in it. Once you've done that, you then come up with this lovely domain model that you think might help influence a lovely architecture.

And then to your point, you're going to look at your existing monolithic system and the data model doesn't match that. And just as likely the code doesn't match that either. You might be very lucky to find that the code closely matches your domain concepts, but it probably doesn't. So, what you've got now is the actual data model and the logical domain model. And those two things do not map. And so then you've kind of got a choice and sometimes the right answer is, well, can we rework the monolithic system or the part of the monolithic system we want to extract in terms of those domain concepts and then extract them? And sometimes that's the right answer. And especially if you're looking to reuse code in your market. So, that might be the right answer. In other cases, you might say that the delta here was just too large.

So effectively, you know, this piece of domain functionality, which isn't explicitly modeled here, but it does exist, what we'll do is we'll just rewrite that little piece of domain functionality from scratch, you know, microservice architecture. And then what we've got to do with a monolithic system is understand how to find your entry points and exit points. A lot of the challenges, even if you are looking to use different programming languages or rewrite rather than reuse code often comes down to the fact that, to adopt an incremental approach, you will still need to make some changes probably to your monolithic system. There are some exceptions, but generally you will have to get your hands a bit dirty. And this is often where the other issue is. A lot of the time people are moving to microservices is because they hate working with their existing monolithic application.

And so you do have to encourage them to say, “No, there's some things you're going to need to do. Trust me, it's worth it.” Then you've got the issue of, often the monolithic system has been allowed to deteriorate. It might not have good test coverage. It might not be factored. It's not going to be defined maybe in terms of domain concepts. So again, you know, that's the way often. You know, the book I recommend probably more than the other at this stage is Michael Feathers’ book, Working Effectively with Legacy Code. It's like, “You're going to go into the monolith. It's okay. I've got a safety rope for you.”  Mike wrote it. Just go read this book, it's going to help you out. So those are kind of the immediate challenges. It's kind of that mapping between those two worlds.

David Brown

It's an interesting point where you say that, you know, you need to be prepared to change that code base as the monolithic architecture, because often those monoliths, if we go back to that “legacy” terminology we're talking about before, often legacy systems get to the point where you're too afraid to touch them. You don't want to change the code base because you don't want to touch it in case you break it, right? Because the boundaries are not well-defined. And the developers, the developers have gone a long time ago. And so the expertise may not be there necessarily either to touch it. And so it's interesting that while you think that the microservices migration is a potential path to get you off that monolith architecture, you may still need to touch them on the architecture regardless. 

Sam Newman

Yup, absolutely. And there’s like one pattern I talk about which is the “Strangler Fig” pattern, which theoretically doesn't require you to change. The underlying monolithic applications are useful for dealing with vendor products as well. But that can only take you so far. And just in general, if you really are unable to change your own monolothin system, your migration will have to be in slightly bigger steps. If you can change it, it's going to actually be, not only could it be very empowering if you're not actually going to kill the entire monolith, getting a bit better at dealing with the monolith is probably a good idea anyway. But also by doing that, you'll be able to make lots of smaller changes, which will mean you'll get to production more quickly and it will also de-risk the journey. So, I think it is worthwhile. And a lot of this is about saying you don't ignore the mess you've made in the past, just because you’re off to microservices land. You might actually have to clean up some of your historic debris that you've left lying around in your IT ecosystem.

David Brown

Well, I was going to ask you about this, you refer to it as “strangling the monolith” as this potential strategy. So what does that imply? “Strangling the monolith”?

Sam Newman

Yeah. So, it's a pattern. The strangler fig pattern is inspired actually by the type of plant that you get in Australia a lot, right? So you get the old, I think like the Moreton Bay figs and stuff, where you get effectively one plot that wraps around another, right? And so the figs that grow in that way can't exist without the on-line support. Over time, over hundreds of years, they wrap around more and more, and then they can stand by themselves. This pattern is applied to software. Migration is, you've got an existing system, which does everything you want. You wanna move that functionality over to a new platform. You want to make that happen incrementally. So, what you do is you wrap the new system incrementally around the old. So, a call comes in to use the functionality in your application and your new system intercepts that call and says, “Hang on, can I handle that call? Now, if I can't, I'm gonna allow that call to continue on to the monolithic system. If I can, I'm going to divert that off and divert that to my new microservice architecture.” 

And it's a pattern I've used and have seen used in multiple times. In fact, at ThoughtWorks, I used it in about three or four different locations where we were actually doing monolith-to-monolith migrations. So we used this pattern effectively in the early days, the rebuild of The Guardian website, and also where we're doing this in the UI. Also, for this autotrader in the UK. But it works very well. Also for microservice migrations. One of the real benefits is [that it] effectively depends on how you do it. The monolith is unaware that anything has changed and you don't have to change the monolith because you're intersecting.

Those calls on the perimeter of the system are actually outside of your old system. It’s also why I've seen it work very effectively for helping people migrate all around, away from CRMs and ERP systems. And, you know, one case used it to help the team move away from using Salesforce. So basically, you effectively used the strangler fig pattern to migrate functionality out of the Salesforce platform. Obviously you can't go and change the code of Salesforce. So, it's a very useful pattern  and it's often one of the easier patterns to implement. The challenge is that there are some types of problem spaces it can't fix. And you also have that issue that, if you want to extract a small piece of functionality, it's now in your new architecture. What if that small piece of functionality still needs some functionalities back in the monolithic system? Well, now we've got a call back into the monolith. The only way you are able to do that is by exposing that functionality from a monolithic system, which means changing the monolith. And if you can't do that, you're also going to have to extract every piece of functionality. It depends upon which then makes it a bigger migration. 

David Brown

Salesforce is a really good example of that and ultimately with a CRM system, you are going to want to call some of the functionality within Salesforce if you're trying to migrate right from it. So, yeah, that's an ideal example. Can we talk about technology? You often hear about implementation. “Should I use GRPC?” That's the buzzword. It's fast, it's what everyone seems to be doing in microservices, then you hear about REST, but of course you have the broken models of pub-sub type systems, whether they’re using Kafka or ActiveMQ or some sort of message queue. When should you choose between any of these types of technologies in microservice implementation?

Sam Newman

You've got to have an overlay of your understanding of what your non-functionals are here, your “cross functionals”as my friend Sarah calls it, right? So firstly, you kind of probably need to get a bit of a sense of what is the acceptable latency of its operation. For example, what scale we're looking at, what kind of concerns do we have around the robustness of this transport? What happens if these calls don't work? So that's that stuff you've just got to have and that's an overlay and that's going to help you restrict or help me choose technology. 

The second set of overlays is then what style of communication is most appropriate in the situation you're in? And there, I broadly break the world down into sort of request response oriented interactions, which is what's going to suit in general GRPC and GraphQL, REST does this and other stuff as well, because REST is always more than you think.

And so request-response in one world and then event driven collaboration, right? And those are from a logical standpoint, quite different styles of collaboration, communication. So once you've made that choice, is it more event driven? Is it more request-response driven? That actually helps limit your solution space. So, if I'm thinking request-response, I can use some brokers for that, right? You know, you can use brokers, but if I'm using event driven, brokers look really good. If I want to be vendor driven, GRPC is probably a choice, right? But GRPC could be fantastic for request-response. So that's the kind of the combination of information you're taking to help guide that decision. I was chatting to Greg yesterday about this and he said, you know, a lot of what the job of an architect is, is not always to come up with the solution. It’s to help define the model by which we are going to come up with that solution.

So it just starts with, “Okay, let's list out as many of these cross functional requirements that we know we have in this situation, what kind of interaction model makes the most sense?” Okay, now that helps us choose a technology. Whereas again, I find a lot of people say, “I'm going to use Kafka” and then they sort of have to deal with the limitations of that technology or, “I'm going to use GRPC” and then suddenly realize that they do have a flow that would ideally be more event driven, but they've kind of left themselves a bit of a pain point. I'd also say that within virtual microservice architectures, real world ones that I've worked with my customers that you do actually end up with often a mix of styles. There are some interactions that suit more request-response oriented interaction, and some that make it event driven. So, don't be surprised if you maybe have more than one technology in play. But I think the framing is important now. You know, how fast, how reliable, et cetera, et cetera. They should come into play with this conversation. 

David Brown

It makes sense. To wrap up, we had James Lewis on the show a couple of months ago. He mentioned you and actually it doesn't often happen that we have guests mentioning other people, but he mentioned you. And he said, “We spend a lot of time working together and I fully endorse everything that comes out of Sam's mouth. There's some stuff around board games, which I'm not too sure about. And he's got a weird taste of Lego.” What’s the Lego reference?

Sam Newman

I don't know. Well, we do have a sizable Lego collection. The Taj Mahal is over there. My kid's 22 now. Right? James, his kids were younger, so we got to play Lego with them. We also don't agree on our favorite type of rugby. I'm a big league fan and he's a union boy. So we part company there. But yeah, we did work with James a lot and an awful lot of his thinking. I mean, I credit James with being the person that sort of first identified and kind of helped name this service oriented architecture. And so that allowed it to be saying, “Okay, this is distinct from other types of SOA we're seeing.”

And that was the work that he did. And that influenced a lot of my thinking. I came to some of it from a slightly different angle because I was a bit more Ops focused at the time. But yeah, I, I tend to agree with virtually everything James says as well. Although he does say things like, you know, “A microservice should be as big as my head,” but he's got a bigger head than me. So we may disagree. I mean, not in terms of ego, but just physically, you know? So those are the only things that we do part company, but I tend to agree with most things he says as well. And that's been worthwhile. I think there's been lots of people in the microservice ecosystem that have come to it from different vantage points.

I mean, James and I both came from the same company. So, you can't really claim that, but who has helped influence this. And that's also maybe why I wrote the second edition. You know, I spent a lot of time working with James and Martin and I was fortunate enough to have a lot of time and help from people like Ben Christensen at Netflix and things and the folks over at REA based in Melbourne. And that influenced my thinking a lot. And then I got to meet loads of other people and hear from all their other ideas and that influenced a second edition. 

So, I think we're really fortunate to have a community which is primarily about sharing these ideas. It's not seen somehow as our special source of things that we have to keep secret. The only thing people keep secrets with are their mistakes and I wish more people share their mistakes, but I think it's fantastic for all of us that we can learn from what everyone else is doing around them.

So I think if anyone at home wants to contribute, the best way you can contribute is actually just talking about your experiences. Case studies are the best things. If things didn't work out well, please share it. And there's space for, I think, a whole load of more voices in our industry in general, but certainly in this space. And so, you know, it's going to have to be at least another five to 10 years because the last book? That killed me. Maybe I'll write a third edition 10 years time from now, when we've got even more information that we can share.

David Brown

And at least we can agree on the pronunciation of Lego, not Legos. Anyway, Sam Newman, it has been a pleasure to have you on the program. How can our listeners follow you on social media and other sources?

Sam Newman

Yeah. The website is Samnewman.io and on Twitter, I am “@samnewman.” I don't do the LinkedIn thing. So, you know, you're not gonna get hold of me that way, really. But yeah, go to the website and Twitter “@samnewman” and there's information over the website about how you can get hold of and read the second edition and the other stuff I've written as well.

David Brown

And of course look up Building Microservices and Monolith to Microservices on Amazon.com. Thank you, Sam Newman, for joining us today!

Sam Newman

You're welcome! Thank you, David. And thank you, Kevin.