Sam Newman on Turning Up the Dial on Microservices

Andre Pino: In today’s episode I am joined by Sam Newman, who is an author, speaker and an independent consultant who focuses and specializes in cloud, continuous delivery and microservices. Welcome, Sam.

Sam Newman: Thanks for having me.

Andre: So Sam, you know just for our listeners why don't you give us a little bit of background of yourself and an overview of your career and how you got to where you are today.

Sam: Sure. I was sort of horrified to learn that I've been in the industry for 20 years this year. It's just, it felt a bit longer than that and so that's quite scary, but I took actually in many ways a very traditional view, approach. I went to university to study computing because I like computers and then I got a job in computing and now I've not had any career changed, I've not ducked around, and so I had a really great, we do these things called placement years. When you go to university in the UK they just think well you'll go and do a year in industry for some of the courses. And I was sort of drifting that year in industry, doing stuff for the European Space Agency; it was amazing. My eyes were opened and I never looked back really. I did that, carried on with that job for a couple of years doing stuff with satellites, it was all very interesting, and then I did join a start-up that didn't work out so well then joined another start-up that didn't work so well, I'm good at that by the way, and then I joined a consultancy called ThoughtWorks in 2004 and I had no idea what being a consultant was or what ThoughtWorks did. It's just I met one person who worked there down at the pub and he seemed like he was interesting so I thought, “I'll go and get to work with interesting people,” which turned out to be the case. I  was there for I suppose in the end about 13 years. ThoughtWorks was interesting because I was there at the very, very early days of continuous integration / continuous delivery stuff so I actually remember interviewing Jez Humble for a job at ThoughtWorks. Dan North and I interviewed him at the pub. We were trying to find somebody effectively to backfill me on a project so that was, I was just around at a - my first tech lead at ThoughtWorks was Dave Farley, who wrote the Continuous Delivery book so I was just around when all this stuff was happening. And I fell into being one of the three or four of us at that time I guess who were focusing on build, continuous integration, build pipeline design, and early days of the cloud. That was my focus was like, “How do I help people ship software quickly?” And over time that sort of morphed from being infrastructure automation stuff more into looking at the architecture so I realized increasingly that the architecture of people's applications didn't make it easy for them to be released quickly and in a fast and frequent fashion and that sort of led me down often to this sort of microservices thing. Sort of almost by accident that was my focus was shipping software quickly and it ended up being about microservices. And I wrote a book and then I decided that you know I'd been at ThoughtWorks and done all the jobs that they'd let me do. I'd have tried out some of the other ones but if they wouldn't let me do those ones I thought, "Okay, great. What's next?" I was working with Atomist, which is Rod Johnson's company, I had a real fun year working with them, and then basically that was working in Australia and then when I decided to leave Australia I thought, "Well what's next?" I went independent and it's been a busy year and a half since. So that's sort of a potted history, but I'd say the through-lines of maybe my last sort of 10, 15 years have been that. It was all about shipping software quicker, it was CI/CD, then it was cloud to make CI/CD work, and now it's sort of microservices that work kind of it's like almost those things all work together and because of those make microservices possible. And so you could argue that I've basically been stuck in a rut for the last 15 years but it's been an enjoyable rut.

Andre: Well if you've been in a rut you've been associated with some great people so it must've been a fun rut.

Sam: I like to think a lot of my expertise rubbed off on them and that's how they're successful as they are, but they may have a different view of it. I mean, who knows?

Andre: I'm sure they would agree. So listen, I know that you've had a number of key accomplishments throughout your career, but you know one of the earlier ones was you created the Lego XP game many years ago.

Sam: Yeah.

Andre: Which helped people understand the basics of agile. Tell us a little bit about how that came to be.

Sam: It was early days of ThoughtWorks when they did this sort of heated introduction to agile. When I joined people didn't know what agile was and so there was this thing called the agile, I think it was just called the Agile Game and it was, you know you were trying to do these things like make a paper airplane, blow up some balloons, and the idea was that you had to say, “Okay, your task was blow up five balloons,” you estimate how long it takes, it takes you less time, they teach you about estimation and all that sort of stuff but it wasn't software creation. I was basically in the office, I was on the beach as they call it, which is when there's no client paying for your time, and we had just taken our first intake of graduates in the UK. We hadn't done graduates in the past and someone said, "Can you keep them busy? Can you go and give them the Agile Game?"And a friend of mine, Nat Pryce, who wrote the Growing Object-Oriented Software Through Tests book with Steve Freeman, and he was sitting around and he overheard this, he said, "I've seen people do fun stuff with Lego." That's what he said and I thought, “Well okay.” So I took basically what was the Agile Game and I went and bought a box of Lego and sort of made up stories with a colleague of mine, Andy Yates, based on that structure. And we ran it for the grads and it was great and it was just a very quick, it was pulled together quite quickly and the idea was you get these participants to create animals out of Lego and the animals change so it's more like a real artifact you're changing. I've delivered that to hundreds of people afterwards and ThoughtWorks keeps using it inside their internal university and all those sorts of things. It was just a fun accident really, right place, right time, and it seemed to resonate quite well and it was, I'm not going to lie, any excuse to buy Lego I'm up for it.

Andre: That's awesome. So mostly your work has been focused on microservices; in fact, you're written a couple of books haven't you? Building Microservices.

Sam: I've just written one book, which is Building Microservices. I've contributed to others and done little, small pamphlets, but the only real book is Building Microservices at this point.

Andre: So Principles of Microservices is not yours?

Sam: It is, well it sort of is, but what O'Reilly did is they took a little subset of my book and put it out as a thing so it's really the book is from Building Microservices.

Andre: Okay, so let's start that part over. Most of your work has been focused in microservices; in fact, you've written a book called Building Microservices, haven't you?

Sam: Yeah, yep.

Andre: And so what are the key things that you think a developer really needs to know about microservices and I guess the other question is how is it going to change their world?

Sam: So the first thing I think a developer should know about microservices is you'd better have a really good reason for using them. Now I think they're a great way of solving certain problems that we have in software development, but they bring a lot of complexity, a lot of baggage with them, and so you've got to have a really good reason for picking them up. It's unfortunate that a lot of the people I work with don't always have a clear view as to why they've decided to go down that route, that can make it difficult because there are so many different ways you can use the technology, there are so many ways you can adopt it and move towards it. It's very hard to do that unless you've got a clear understanding of what the hell it is you're trying to do. I talk about microservices, it's not like a switch. It's not like an off and on switch. It's more like a dial and you're ramping that dial, you're turning that dial up to 11. How far do you need to turn that dial? The answer is you don't know unless you've got some understanding about what it is you're trying to do. And so that's the main reason is it's like you need to have a reason, you need to have a problem that you're trying to solve with these architectures. And then the other thing I say is just all microservices are, it's not about technology or anything else really; they're just independent services. They're just independently deployable services modeled around a business domain. It's a very simple pitch. It's just a type of service-oriented architecture. It's not different to SOA; it's just a type of SOA. That's all it is really and you could certainly argue that really a lot of the benefits that come from it just extend straight from the ideas of modular software going all the way back to... and...in the early 1970s. It's just that microservices happened to communicate over networks rather than communicating within the process boundary and that you've got enforcement of that modularity. And I think that with the independent deployability, those are all the great things that allow autonomy that also open up some interesting scaling, organizational scaling and application scaling techniques, but with them comes all the baggage of distributive transactions, people worrying about data and sharing of data, managing deployments, observability. These are all hard problems to solve at scale and so you've got to know why you're doing it; otherwise it's very hard to justify that time.

Andre: So one of the principles that you outline in your book is decentralize all the things. Can you tell us what that's all about?

Sam: I think it's a way of trying to talk about what are this idea of autonomy and organizational autonomy. One of the ways in which I think you get the most benefit from microservices is aligning it with organizational structures, which themselves are more autonomous as well. You know there's sort of the two pizza team idea from Amazon was driven more about organizational autonomy that led or architectural autonomy, right? You want those teams, Jeff Bezos once famously said, "Communication is terrible." Now whatever message that sends about his internal culture, I don't know but the idea being actually he wants people to reduce the amount of communication and coordination you have to do because you go faster, right? So how do you ensure people can own more and go faster? Well give them bits of software that they themselves own. And so this idea of or independently deployable services being owned by a team that is empowered to manage those services how they see fit, that's where you get the best of both worlds. And it's sort of, it is still interesting to me that I do see organizations that are happier with more of a centralized command and control mindset are also going the microservices route because I feel that in that situation they're likely going to have the worst of both worlds in a way. And I think that decentralization really is about saying, "Do you need to centralize decision-making? Do you need to centralize who can provision and environment? Do you need to centralize who picks what technology you use? Or are you able to say there are these things that we're happy to push into the teams?" I don't think it's a one-size-fits-all model, I don't the Amazon model works for everybody, I don't think the side of you build it, you run it, you ship it makes sense for everybody, but I certainly think that you get more from a microservice architecture if you're able to look at all the things that delivery involves and work out what bits can actually push into the teams themselves. And I think in the organizations I see using this architecture well they're doing that together with looking and revisiting this view of what a delivery team looks like. I spent time with a price comparison site up in the UK last week and you know they had to fundamentally shift their thinking about what delivery team is. Their delivery team just used to be a pool of developers. Now it's developers with embedded operations and test people with a product owner inside that team and almost like their primary unit of reporting is now their product owner on the business side. Those are sorts of shifts that are happening anyway when you look at design thinking and you look at sort of that shifted product development that's happening. And those models seem to work really well with those microservices architectures but it does involve those of us in the ivory towers. I am an architect. We've actually got to work out well what is it that we don't centralize anymore? What can we push into the teams? What can we empower our people to do and how do we help them because actually it's two things. The people who own the power now have to be willing to give it up and the people that don't have the power now have to be, have to understand what owning it means and they might need new skills to do that.

Andre: That's really interesting. And so in your experience when an organization decides architecturally that moving towards a microservices architecture is their future, you know, culturally how do they start to adopt that? Do they change organizationally first or do they start to implement the technology and let the organization follow as things progress? What's been your experience?

Sam: It's sort of tricky. If I see microservices coming out of a particular IT play it tends to be very much, “We're just going to change IT,” and then I think over time they start to realize that they're not really getting the most out of it. And I think then it's much more, the conversation is often much more driven by technologies that we're going to pick, it's driven by specific technology requirements, a desire to have new technologies like, “I want to change programming languages, how do we do that? ...databases, which is there a way we can do that?” In those where it's come purely out of IT and technology it's often unconnected to the business goals and therefore you're unlikely ...to the organizational realignment. I think it works best where you get those two things happening together. Quite often what happens is you have people thinking about this microservices stuff over here in the tech side and then the business, like the CEO is with the Harvard Business Review and says, "We're moving to these sorts of organizations." And IT goes, "Oh, hang on. Microservices fixes that," and that's where it kind of works the best. I feel that when the IT, when it's driven purely from technology and purely from IT I don't necessarily, I see that there is limitations in how far that cultural stuff spreads. It's sort of an interesting thing. So I go, there was a great, I think it was the Architectural Alignment Gap or the Enterprise Alignment Gap, it was done by MIT Sloan years ago, and they looked at IT organizations that tried to align themselves to the business or organizations that tried to improve their IT delivery capability first and they found actually they got the best results from people that sorted out their house in IT and then aligned themselves with the business rather than trying to do it the other way around, which is sort of interesting. I actually think IT teams in general have done a lot more of the low-hanging fruit stuff now and I think it is that next step for everybody is that starting to break down those barriers. I think when it comes from a business change, if it comes if it doesn't come with the word microservices on it normally other terms get used normally. It's you know it's wanting faster, it's becoming a technology company; that's the big one. We're going to become a technology company. Well what does that mean? Well all of our product owners now need to know about technology. And for me if either of those things happen in isolation, you don't really get the benefit out of it. And I think what you really want, if you really are a technology company your CEO, the leaders of your company need to understand technology and these things have to work together. What tends to happen is it gets driven from one place to the other, you get some friction, and hopefully work things out. It's no one transformation is the same as any other I've seen. They all look a little bit different.

Andre: One of the other principles that you point out in your book is the culture of automation. How does that play into microservices?

Sam: The basic truth is that you've got more things. And so when you've got one thing you can kind of handle it manually. You can, I mean this is the pets versus cattle thing to an extent that you can love it and pet it and name it and look after it, make sure it's well-watered and everything else. When you've got 200 things that manual effort means you actually add more services. You have to add people to do the manual work. That's going to constrain how effective, how aggressive you can be in adopting a microservice architecture. Neal Ford says that whenever human beings do the same thing over and over again all the robots take the ... down to the pub. Computers are good at doing the same thing over and over again and it becomes increasingly hard to justify doing the same thing over and over again when you're doing even more things over and over again. And if you look at all the organizations that have been effective in adopting microservice architectures that's gone hand-in-hand with really being very focused on automating common tasks, sometimes standardizing common tasks, but very much automating and that might often mean changing technology just to make it more automatable. But we're talking about everything here from automated deployment, provisioning of your infrastructure, ... up. I'm not saying you have to do all of these things, but it's almost like you need to build a culture of it like, "Oh, I did that twice. Should I automate that? I did that twice. Should I automate that?" And actually also being okay with having a constant investment, almost an ongoing investment throughout this process of, it doesn't stop. One thing I like doing with teams is saying let's pick a number and that's the percentage of your backlog budget that you're going to spend this week on improving your delivery process and that could be in automation so is it 10 percent, is it 15 percent? And it's just relentless. And certainly the technology is starting to help us even more in this space. I mean this is one area where things like Kubernetes and those sorts of things can help is that you're getting things that are more automatable in the same way that public cloud providers help hugely here. It's just adding more people to do more manual work is just a really bad use of people because unfortunately those manual tasks still need to be done by really smart people and they're like, there's not a lot of them around so it seems a bad use of people's time to me.

Andre: Microservices are going to be really important for developers in the future, it's an architecture that organizations are going to adopt, but containers and Kubernetes are all the rage so like what's the overlap and how do we piece all these things together?

Sam: We probably should remember that containers have been around for a very long time. I mean you're looking at LXC, you're going for the back. I mean you've got Solaris ..., you've got stuff that was in BST ..., all those sorts of things, so the concept of containerization has been around a long time. The thing that shifted that into being useful for us as developers was the work done by Docker to take that container idea, that isolated part of your kernel and put a nice tall chain around it. And actually the big thing was having an artifact format so now I can package up my software and the things that software needs to run like my interpreter or whatever else into that little small bundle my Docker container, my Docker image. And it's all around how you distribute those images and redeploy them. Now that's great for us from a microservices point of view because we almost want to see our, you know with microservices we often we want isolation of execution. We don't really want to run lots of services in one application container because it's not really as isolated as we'd like. So we want this autonomy and independent deployability and along come containers and the Docker container format of being these really portable images that we can just spin up whenever we want and treat them like a black box. I don't care if that's running Ruby on Rails, I don't care if that's running PHP, I don't care if it's running Java, I launch my container and I'm away. And that was really great because before that there's lots of Puppet, Chef, those sorts of things, manually configure things, if you're rolling custom VMs or custom Amazon machine images and things like that. So that Dockerization process was fantastic from that point of view and then what you needed though was how do I manage deploying containers over lots of different machines and that's where you needed like what they often called orchestration or scheduling software. So you know Kubernetes has emerged from that space as being the best or the most popular of those tools to help you okay, “Now I've put my application in an image. Now I can run lots of copies of that across lots of machines.” I mean that's the sort of positive aren't Google nice, they've contributed this lovely abstraction to help us run container workflows and it's all for developers and we should all be thankful for them. Obviously the other reason that Kubernetes exists is because Google will write about the existential threat of Amazon gobbling up all the public cloud, they were a distant third and remain a distant third, and thought, "Well how the hell do we stop people being locked in?" I don't like using that phrase but if they were in Amazon they weren't going anywhere else or, “Why don't we create a developer-friendly abstraction that could write in lots of different places and get people to like that abstraction and then they'll be portable?” And they've been as unsuccessful as they've been at making inroads in the cloud market they've been successful in creating an abstraction that is portable although you know at last count I think still something like the last server I think for the Cloud Native Computing Foundation showed something like 70 percent of all Kubernetes workflows are still run on Amazon. So you know Amazon are winning anyway, but out of it we don't care. We've now got a little bit closer to having more vendors we can work with so if you're worried, “Do I want to be in a public cloud or a private cloud play?” Well if I just adopt Kubernetes I can hedge my bets.” I don't think that always makes sense but if you really are in that space, great, fine. I spoke to a government agency recently and they think they can go into the public cloud and they're going to but they also know a change in the political climate might mean they now can't. And so picking for Kubernetes, for them I get it and it's a higher-level abstraction. We're stepping up a level. We're not worrying about Puppet and Chef. We're getting a bit closer just worrying about our applications. I'm all for Kubernetes. I think it's one of those things that's going to allow more people to adopt microservice architectures. I think the fact that it's all the rage right now is a momentary blip. I think within a couple of years most people won't even know it exists because I think it will be hidden under higher abstractions.

Andre: Universally adopted and it's just there.

Sam: It's just there. It's there in the same way virtualization is there, the same way that VMware is there; it's under there somewhere but I don't engage in it as a developer because I still think it's not a very developer-friendly abstraction compared to what we've been shown we can have. I still think Heroku is the gold standard as a developer-friendly Platform as a Service play and there's a reason why Cloud Foundry wrote their entire user interface to mimic Heroku, which is a smart play by Pivotal, very smart play. I think we'll increasingly see higher order, higher abstraction developer-friendly services that might sit on Kubernetes and things like functions and service frameworks fit perfectly in that space. So it's real hot right now. If you're a developer you should definitely spend some time in it. It will make you more marketable. It's also really interesting, well put together technology that enables some really interesting things. But I think in the future developers will be spending their time in higher abstracted things.

Andre: Cloud native is certainly a huge focus for our DevOps World|Jenkins World events in San Francisco and in Nice, France, this year, huge focus. In fact, we've got all the cloud providers are key sponsors of those events and I think that the intersection of software development in the cloud is going to get stronger and stronger.

Sam: Yeah and I think like Jenkins X has been doing great in that space for James and the team and that's made real good inroads and so certainly that as one of the problems early on with Kubernetes. This is my CI/CD howl, and was talking to the things at CNCF and things was okay, we've got our deployment orchestration story right but what's our CI/CD story? And so we're now starting to see things through Jenkins X, which is bringing those CI/CD ideas into that platform world. And it's not surprising I mean the Cloud Native Computing Foundation has done a good job of curating a set of projects that help you build cloud native applications more easily. The only concern I've got with any of this stuff is that it might encourage some people to continue down their route of sunk cost fallacy around, “I've already got machines; I should keep running my own machines because now I've got better stuff I could run on my own machines, right? I've got all this awesome stuff from the Cloud Native Computing Foundation that's been great, it's great companies. That means I've got better quality stuff and I can run it myself.” And the worry I've got is actually a lot of them should just be not, they should just be shutting their data centers down and running on public cloud because I'm sorry most people can't justify that cost. I just don't get it.

Andre: We've certainly come a long way in that thinking, right? It wasn't too terribly long ago banks would say, "There's no way we're going to the public cloud," and now we've got companies like Capital One saying, "This the way we're going. We're committing to it."

Sam: Years ago [I] accidentally ended up helping create and run the first ever training courses for Amazon. So Amazon AWS when they first had AWS stuff, they were just providing it and their view was this is just electricity for people, right? They just use electricity. People don't need to be taught how to use electricity. And I said, "But with that mindset you're selling electricity but people are electrocuting themselves with it," because it's like there's a lot of stuff with AWS so it was actually they had reached out to a colleague of mine, Chris Reed, at the time at ThoughtWorks and said, "Can you do a course with us?" and so we ended up doing this course and in that course we were hitting all kinds of barriers for people because we were showing them this awesome tech but they were like, "But we can't use it because X, Y, Z." And back then you know we would help people adopt it by saying, "Don't buy a DR center. Use Amazon as your DR." That was the way in. And then it was like, "Oh, we can't use it because we're PCI." A really interesting switch happened when Amazon got PCI accredited where all these clients that said we can't use them because they're not PCI, the moment they got PCI compliance they were running to Amazon and the reason was they did the certification of this huge, giant stuff, they do like 80 percent of it and it's just not handled where we have to worry about the ... of our stuff. They flipped that switch so quickly they were running towards it because they could offload those concerns. And so there's still some interesting legal issues. Certain countries I work in have concerns around certainly overarching things like the US Patriot Act, none of which has been clarified. You know we have this interesting situation where the US Patriot Act basically gives the US government permission to ask for data held by companies even if those are overseas entities. So if cloud provider X that runs in Belgium, if they're actually an entity that's owned by a US company the US government can say, "Give me their data and don't tell them," and the US company has to oblige even though it violates local data protection laws. Microsoft have done a very good job of calling that out. That problem exists today because it hasn't been clarified and so you've got a lot of people that would like to go to public cloud but are not allowed to because of those types of situations and things. I think you're starting to see more local, regional players who are now running Kubernetes as a Service but are not US entities and that's opening up possibilities for other people and it's a whole new world out there actually. It's very exciting.

Andre: Well if I can ask you to put your continuous delivery hat on for a minute, I know that's a space you've been operating in for quite some time. What are your thoughts on where we are today as an industry and where it's going?

Sam: I think that around the technology we're in a lot better place. I think honestly the technology side of things and the mechanical side of things almost in a way I think we're in a really good place. I think we understand the things that need to be done and we're iterating on newer versions of those tools and techniques. There was a void for a bit around CI/CD with things like Kubernetes, but those gaps are being closed. I think the gaps for me are still around some of the softer aspects of CI/CD. I still think it's around some of the hygiene around that. I still see very few companies for example measuring their cycle time. I see very few people ever doing cycle time when they're studying where the bottlenecks are; I don't see that happening enough. I still don't see enough of a holistic view of software. I still see too many siloed roles of stuff going on. There's this idea that you have a test person who does test management that doesn't look at the production landscape and then you've got operations people you've got operations people that look at the healthier application in production and say, "Is it of good enough quality?" and then you've got test people that say, "Is my software of sufficient quality before I've released it?" They don't talk to each other, and they use completely different tool chains and speak different languages. It's like there's still a lot of that stuff that we could really you know sort out. And so for me it's more about actually putting some of that measurement in place and really understanding where your pinch points are. I think there's still too much of what people do is not driven by understanding of data or the real information. I think it's driven on cargo cult and what worked for you well before. And I think some of the stuff we're seeing like the State of DevOps Report has been fascinating and fantastic in that space because it has become a lot easier for me to have conversations with people about those things. I can point to the evidence and the work done by you know Nicole and Jess and Jean and everyone else and say, "Look, they've actually got evidence for some of these things," but also by the fact that I can talk about data and what data they've gathered it becomes easier for me to have data and conversations around that with them so much. The number of people that I work with that are made to use Jira and hate Jira and I'm like you know what, all of those ticket management tools are, they're a pain in the bum to use; they're annoying. It's a hard problem. I don't think it's Jira's fault. I just think it's a hard problem to do well. But if you're going to use those tools at least use them well and get all the other core stuff out of it. You could do so much of your cycle time analysis just by using those tools a little bit better and that's the thing I see time and time again and a lack of ongoing and a lot of those refinement activities I really don't think people get continuous improvement. I think what we get is transactional improvement. People let things atrophy to a state or they get shouted at and they think, "Oh quick, how do we clean it up? Let's get a consultant in." But how many tech leaders do I see actually regularly looking at that cycle time and optimizing it and running through it, looking at their defects, where those defects come from looking at holistically how can we fix these things more efficiently, and so that really building that, I don't think people get that in their bones. I think it needs to be, it's got to eat in your bones a little bit. I still don't think we have that enough.

Andre: It may take some time for people to internalize what it all means and how they can really benefit from it.

Sam: I think it's understanding the power in the hands. All the information they've got in their hands, I think there's still that. And of course every now and then you have to have the same argument all over again. Git may branch in the thing again so we have to have that conversation all over again. That’s fine. Then Gitflow happened and I had to stop myself putting my fist through a wall but these are the things that we reinvent the wheel and some wheels need reinventing and some wheels are bad ideas. We're continually creating better, new ways of doing things and reinventing bad ways of doing things and it's just experience that helps us shift those things apart I guess.

Andre: Well Sam congratulations on being named one of the top 100 DevOps Movers and Shakers.

Sam:Thank you.

Andre: And congratulations on your book, Building Microservices. Where can people get it if they want to buy it?

Sam: For more information about it go to buildingmicroservices.com and there you can find out information about the book. It's been translated into six languages now. There are links through there so you can buy the book. If you're on Safari O'Reilly's e-learning platform you can get a free trial of that by the way for 30 days and you can read the book for free on that. I've also got a video series on surveillance and security there that you can watch. But buildingmicroservices.com is great; it would be the place to start with. I'm actually working the 2nd edition. It's probably about, depending on what it looks like, we could be talking six to 12 months out, but we'll see. I am working on updating that content at the moment, but buildingmicroservices.com is the place to go.

Andre: Great. Sam, thanks very much for joining us today. It was a great conversation.

Sam: You're more than welcome. Thanks for your time.

Like what you’ve heard today? Don’t miss out on our next episode. Subscribe to DevOps Radio on iTunes or visit our website at CloudBees.com. For more updates on DevOps Radio and industry buzz follow CloudBees on Twitter, Facebook, and LinkedIn.