Microservices: Up and Running

Microservices have long been a hot topic in software development, with both pros and cons associated with them. In “Microservices: Up and Running,” Ronnie Mitra and Irakli Nadareishvili go on a mission to offer guidelines for your first experience with microservices. In this Book Club discussion with Ronnie, world-class expert of API design, security and enterprise development in general, and Mike Amundsen, author of the book "Design and Build Great Web APIs," you’ll discover the decisions that you’ll need to consider, the reasoning behind each, and how to get started with microservices.

Intro

Mike Amundsen: Hi, Mike Amundsen here. Great to be with you. I have the pleasure of introducing and interviewing today a good friend of mine, Ronnie Mitra, from Publicis Sapient. Ronnie, how are you doing?

Ronnie Mitra: I'm doing pretty good. Is that the first question?

Mike Amundsen: That is the first official question of our interview.

Ronnie Mitra: I'm doing fine. How are you?

Mike Amundsen: Very good. I mentioned you work at Publicis Sapient in London. Who or what is Publicis Sapient? And what is it you're actually doing there?

Ronnie Mitra: Publicis Sapient is a digital consulting agency. We mainly help companies with digital transformation, which is a really fancy way of saying, building really good technology to support businesses. What I've been doing there is getting waist-deep in some of that work, helping mostly banks nowadays build digital architectures with things like APIs and microservices and all kinds of new cloud-based tech.

Mike Amundsen: So you mentioned APIs and microservices. That's a great cue. I met you in 2012. I don't know if you remember this. But the very first time I met you… I think it was June of 2012, in Vancouver in the waiting room lobby area of a company called Layer 7. That was the start of you and me. And Matt McLarty founded the API Academy. So that goes back quite a ways. That was 2012, almost 10 years. What's happened since then? I mean, how did you get from Academy to Sapient. What's going on? What's that path like?

Ronnie Mitra: If I bring myself back to that day, Mike Amundsen was gonna be my new colleague. Apparently, he had written some books or some books that I had never read. It was this big deal, and you were as impressive as you had been built up to be. Then somehow, since that point, I ended up writing a bunch of books on different themes. So, in a lot of ways, that changed my future path. Since those days, as I said, there's been kind of a shift in my thinking. A lot of what we did was really setting the future path, what design could be, what APIs could look like, what a version of the world could be. For the last two years, it's been really exciting. Maybe pull it back a bit and see what can people actually do with what they have and what are the real problems people face on the coalface when you're in the trenches, and you can't afford to think in terms of 10 years, what's that like?

Mike Amundsen: Yes. I think the way I remember that experience was very similar. I was going to meet my new colleague who knew this whole API security space really, really well. I was the outsider looking in. I hadn't done a lot of industry. I had no financial experience. So we both been on quite a journey. 

An overview of “Microservices: Up and Running”

Mike Amundsen: That journey definitely has books in it. That really is one of the reasons we're together today, right, is to talk about this latest book that you and Irakli Nadareishvili wrote called "Microservices: Up and Running." So can you tell us a little bit about how that book came together and what that book is about?

Ronnie Mitra: Yes, absolutely. So Irakli is, of course, another ex-colleague of ours from the academy days. We had all, you included, worked together on a book called "Microservices Architecture." This was way back in the early days when we had people asking us, "What is this microservice stuff? Can you explain it?" A lot of maybe misconceptions about what it was. We had written that book, if you remember, as a short guide. So if you were hearing about this, here's what it's really about. These are the principle models, the things that you can understand. So now, you can talk intelligently about microservices and plot your path. What it wasn't was like an instruction manual, and here's how you implement it. Years after that got published, I had met Irakli somewhere in London, I forget why, and he had said to me, "You know, I always wished we had written that second part of the book. And this is how you would do it."

If you've ever met Irakli, he's very strong-minded. His greatest feature is he's very opinionated. This book is very much in his style. So we agreed this could be a book that if you wanted to learn how to implement microservices, we'll hold your hand. We'll make the decisions for you. You get to build the first one in this kind of safe environment, walking you through from beginning to end. So when it's time to build your own, you already have that experience, right? You've built one. Now, you can build the next one. And that was a general concept.

Mike Amundsen: So that really intrigues me. I noticed this too when I was reading through the book. And by the way, a fantastic book. I really urge everybody to pick this up. 

One of the reasons is what you just stated, which is this notion that it is very opinionated. You actually say, "We're gonna decide this." You need to decide this, our decision is X. So do that, and step after step. 

There's lots of code and lots of detail in here. About this idea of being super opinionated of actually building a working version of this in just a certain way, why did you decide to do that? Because this is not going to apply to everyone. This is not going to be the way everyone builds their microservice stack. Why did you pick this one? And why did you take this approach?

Why did you take this approach?

Ronnie Mitra: There are two ways you can get better at something, right? One way is to really understand what it's all about. Like, we meet these people who've been in tech forever. In every new innovation, they look at it and scratch their chin and say, "Well, actually, all this is is a reinvention of principle X. This is just David Parnas and modularization. This is just SOA but done right." That's one way to approach it. And I think that's the way we had approached it in our kind of previous work. The idea here, though, is the other way to really get good at something and understand it is to dive in.

I'm a big fan of this model called the Dreyfus model of skill acquisition. That if you need to learn how to do something, the first step is to really have someone guide you through it, where all you do is repeat what they're showing you. Those are the steps towards eventually getting to mastery. At mastery, you understand the domain so well. You almost create your own model, your own principles. So the concept of the book is pretty simple that, look, I believe this model works, right? That taking someone through a guided, holding their hand process first will accelerate how quickly they learn. So we're trying to give readers that first step. So you follow along, you build the system, you almost get a tour of the kinds of decisions that you'll need to start making so that when you have to do this yourself, you have that feeling of confidence, that feeling of understanding because you've gone through it with us.

The other thing I really tried to highlight here along with Irakli was that it's about the decisions. So we try to catalog those important decisions as we're taking you on this journey through building the microservices implementation. So when you go back, maybe you're gonna make different decisions. That's fine, right? But at least you know kind of where the paths and the roads are. I think it comes out and I think it works. We've had feedback that it's helped a few people in terms of getting up to speed.

Architectural decision records

Mike Amundsen: Yes, that was one of the things I noticed that I really liked about the book is you have these little call-out boxes, you call them ADRs, architectural decision records, or something. And then it was like, "Oh, I just made a decision. This is a decision we have to make, so on and so forth." And you get the sort of collection. Where did those ADRs come from? What is the story there?

Ronnie Mitra: You probably know the history of ADRs. I think I knew it at one point. I don't remember. But we see it in so many different forms, decision logs. If you talk to people who do a lot of agile work or Kanban work a lot of project management work, they'll have a decision log. We all keep decision records in some form. I think it was Michael. Michael Nygard started talking about lightweight architectural decisions. The main point is just this, what I've seen work is you need to log important decisions so that when people look at what you've done, they can understand why right? This is about really making a rationale for a decision clear so you can list some options — can list some impacts.

One of the things I've seen in my day-to-day work is that teams often get stuck in these circles because what they don't do is leave the breadcrumbs as they're having their conversations, right? They have a two-hour in-depth conversation, and then they have the same conversation two days later because there's no consensus agreement. The other magical thing that happens when you start writing this down is you find out what you thought you agreed on, you didn't. 

I wrote down a decision, and you and I fundamentally just never agreed on what that thing meant until I wrote it down. So as a way of taking something complicated and complex, like a microservices architecture, it's a great way to start attacking it in pieces and you start making progress. "Okay, we've gotten these decisions done. So now, we can start to tackle these other ones." That's why I like it.

Mike Amundsen: Yes I like this style of ADRs too because it's sort of like a little mini post-mortem on the meeting or the discussion you had. It's contemporaneous notes, from legal and other aspects of other professions where you do just what you said, you take notes, you leave breadcrumbs, you have this little set of steps along the way. So I really appreciate the fact that you add those into the book, which I find really interesting. 

What do you mean by an operating model?

Mike Amundsen: Another thing that I really hadn't thought about until I read through the book was this notion of an operating model. You talk about an operating model in a way that I hadn't heard before. Can you explain to the viewers what it is you mean when you two say operating model?

Ronnie Mitra: Yes, sure. Maybe that comes across as a little bit of consulting, but I definitely hear that kind of vocabulary more in the bigger companies we work with nowadays. You know, fundamentally, if we look at what microservices really are for, and we talk about this early in the book, the great benefit seems to be that it means we have to talk less within our organizations, right? And by that, I mean, I can deliver value, I can write code, I can implement features of my product without having to talk to lots and lots of different people. That's because we're breaking something up into smaller pieces. The challenge, of course, is that the bottlenecks don't really happen in the software. The bottlenecks happened in terms of the people, right? It's actually the people part of the equation that we need to look at closely.

So when we talk about an operating model in the book, it really has to do with how are you going to run these things that you build in a way that you can talk to people less? How are you going to run these things in a way that they're not expensive to maintain, right? That's what we mean by operating. There's a great tool called Team Topologies that comes from a book, that really gives you a way of modeling the coordination between teams. So we have only used that as an example when we talk about the operating model.

Mike Amundsen: So the operating model is sort of beyond the tech. It's like, "Yes, we're gonna use Docker and we're gonna use Java and we're gonna do these things." But this is how you sort of operate under these conditions. Is that really, kind of, what that means?

Ronnie Mitra: Yes. It's the model for how you will maintain what you build, how you will change it, how you will operate it, how you will work as a team and continue to use tools and run the microservices that you built.

Where does serverless or event-driven fit in the book?

Mike Amundsen: Now, I talked a little bit about techy, I mean, you've got all sorts of technology in here. Where does serverless fit in or event-driven, and all these other things in this microservice world that you guys are talking about?

Ronnie Mitra: It's a reasonable question. Unfortunately, it didn't make it into the book. But I think serverless and event-driven has a really strong place in the microservices world. I guess fundamentally, right, what is a microservice? We didn't really talk about that inevitable question. The challenge is if microservices are really about breaking things up into small pieces so that we can move faster, there is an almost inevitability of going into that serverless and event-driven world, right? So I see serverless as if you start going into microservices, well, serverless will reduce some of that operating costs in the long-term, right?

Now, I don't know if we are all there already in the same way that, we have electric cars, but not everyone is ready to drive an electric car because all the infrastructure is not there and some of us have to make long trips. But it kind of feels like there's an inevitability to that technology. And then the other challenge with microservices is the data. When we start talking about how to deal with that data, we kind of end up in this world of event-driven architectures and async APIs.

Mike Amundsen: Interesting. You see this as not so much a path or a progression, but just this inevitability of moving more towards event-driven architectures and serverless, primarily from the point of view of the sort of ease of operation, part of this operating model idea. Is that right?

Ronnie Mitra: Yes, I think so. I mean, for me, the value of a serverless function is that I have to do less work. I mean, it has an influence on how I compose or decompose something. But I'm pretty sure if I try hard enough, I could build a monolith in a serverless architecture. 

If someone gave me the challenge, I think I could do it. But what it really does, of course, like, kind of in its name, is hide some of those operational aspects that have to do with building something in the cloud. So, today, a lot of the book, if you go through it, it’s here's how you run this thing on Kubernetes. There's a book called "Kubernetes: Up and Running." If you really want to learn about Kubernetes, there's a thick book you can go through. If I start moving to something like serverless, maybe now I don't have to pay a lot of that complexity cost, and I can focus just on the microservice itself and Amazon, or Google, or Microsoft, or Mike Amundsen's cloud startup will handle all that other costs for me.

What are the difficult parts when doing microservices?

Mike Amundsen: So you sort of hit on a nice little device there, like you could build a monolith in serverless if you really set your mind to it. So let's flip that around a little bit. What are the difficult parts of doing microservices in general? What do people commonly sort of stumble on or get wrong? What kind of advice do you have to people in that space when we talk about designing and implementing microservices?

Ronnie Mitra: I think one sign of success for everyone who's been involved in this microservice space is that almost everyone has heard of it. So I can have a conversation with a business person and talk about how we should improve their technology platform to support their business. They'll start talking about microservices. In a way, that's the biggest challenge here right at the outset. What the heck do they mean when they say microservices? What do they think they're getting if they implement a microservice architecture?

The funny part, this is often in organizations where they've already built out whole web services, SOAP-based architecture, so they did that. Then they built out a whole "REST," HTTP API platform. So what are they getting when they then say, "We wanna do microservices"? The biggest challenge, I think, is getting some of that shared understanding, not about what they are, but about why, why would you want to do this? 

If you can't get that shared understanding, then you can start to make the right decisions about, "Here's what we're going to actually do. And here's how we're gonna decompose this."

Mike Amundsen: That sort of took a turn I wasn't expecting. That was that you sort of went in from what to why pretty quickly there. So it's not so much about what a microservice is or what a RESTful API is or what SOA is. It's sort of about why we're doing it, right? I mean, what are the reasons behind, or the principles, or the advantages. Is that something that is missing, you think, from the way people are talking about microservices, in general, or is that sort of a separate topic entirely?

Ronnie Mitra: I think it's definitely missing on the ground. There are some terms in our industry that we say that people don't question, but we often don't have a shared understanding of what they mean or why we would do them. 

I encourage everyone if you were considering this kind of architecture, or even if you have labeled one as microservices, to be as articulate as you can about the purpose. So, for example, I could be building architecture to reduce my cloud bill, right? So then I wanna split things up so that I can scale them independently as my primary driver.

That's going to fundamentally change the way I build my architecture, or I could be trying to set up a system where what I really want to do is make it very flexible. I only want to build a set of five services, but I want to build 100 products on top of those services. But where it kind of leads to is a fundamental challenge in microservices, I'm finding this for people to figure out how to break the thing up. You know, how do you draw the boxes? And if you don't know what the optimization goal is, it's really hard to figure out how to break that beast up into pieces.

Mike Amundsen: So it's breaking it up into pieces that optimize for the goal you have, right? You're really saying, "You could do this in a lot of different ways." It just has to do with what it is you're optimizing for, or what it is you're trying to get to at some point along the way. This is really a design sort of decision, right? This is not a technical decision, right?

Ronnie Mitra: Yes. Where do you draw the line nowadays? So it's absolutely a design decision. This is a design decision that's massively influenced by technology. 

Deciding to build something in the cloud changes your whole cost and operational structure. So, suddenly, the way you design something is fundamentally different. It opens up a whole new set of choices that I may not have done, which is why sometimes we get the greybeards scratching their chins saying, "Well, we had that before." It's not that no one has ever thought of building systems this way, it's just that the costs, the optimization goals, and the tech and tools we have fundamentally changed in the last 10 years. 

People want to move faster now. We can build tech on top of an insane, incredibly rich set of tools and technology and platforms, and we can build much more complex software with effectively fewer people in less effort. That's why I think we're at this point where microservices have almost become de facto for people building new technology.

What should you look at when transforming an existent company?

Mike Amundsen: Yes, it's like the idea that microservices are sort of a fait accompli. It's like, "Well, we're gonna do microservices. So I guess we need to figure out what we're doing with them or why we're doing it this way." 

Lots of times you have to do some experimenting, you have to kind of start out a little bit slower. You don't want to do these big bets like, by September, we'll change everything, right? So you've got to build in this culture where you talk about cost or you talk about principles and that sort of thing. I think that's a really important element that can be pretty challenging. You're actually in the field doing it. You're working with banks now. I assume you're doing these kinds of things. In reality, just outside of whatever's in the book, what are the things that really matter? Like, what are the things to really focus on when you're, say, trying to transform an existing company? How do you guys approach it at Sapient?

Ronnie Mitra: Well, one thing that's for sure is that size matters a lot — the size of your organization. So we've done some work with some fintechs. If you think about the reversibility of a decision for an organization that has fewer people who meet often, they're really able to take more risks, be a little bit… have that agility where they come together, they make a decision. If that doesn't work, they change. What you notice at larger companies with established structures is that the boxes on a piece of paper don't just reflect technology, but they also reflect politics, power, structure, those kinds of things. So there's greater resistance to shaking things up or changing.

One of the things I've noticed is the organizations that seem to do it well, the bigger ones, have the courage to almost plant a new seed. So what they do is they start a new implementation, a new build, a new architecture, and they start with some of these modular architecture concepts from the beginning, with a culture that makes sense from the beginning. They attract the people who are interested in working that way, right? So you start with this greenfield as t were. Otherwise, it becomes really difficult for change to happen. 

Now, there are people that might come in as more well-versed in the art of transformation, right? I mean, to me, everything looks like an API microservice. But at least in terms of those boxes, the reality is that understanding that the services and the microservices we talk about also represent people. And thinking about how that change happens is probably more important than figuring out how to run an API on Kubernetes.

Mike Amundsen: Yes, so that sort of brings it back around to where we were in the beginning, you're talking about this idea, it's really about people. It's about people, it's about your legacy, it's about the culture that you already have. I think one of the things that I remember from the time you and I and Irakli were doing our API Academy work is as we visited around, you sort of saw people at different stages, companies at different stages of this experience of transforming in some way, adding APIs, building microservices, but you always saw sort of the same costs of legacy or the same challenge of change over time. And that's amazingly difficult to sort of capture or explain.

What should you do after reading “Microservices: Up and Running”

Mike Amundsen: I know a lot of times people wanted to say, "Well, just tell me what to do next." But there are so many different moving parts. So at the risk of making that same mistake again, I mean, when people are reading your book and going through this opinionated way, reading these ADRs, actually getting their hands on all of the bits and pieces, the code, the implementation, the release, what is it that they need to do once they complete that book? What do you see them doing next? What is next for them? Once you get to the end of this sort of book experience, are they done? I mean, have they got it? Where do they take this from here?

Ronnie Mitra: I think the classic answer here is it depends. That's probably the right answer.

Mike Amundsen: That's the consultant's answer.

Ronnie Mitra: I think I know what you're getting at… I can imagine a lot of different types of readers going through this. But if we're talking about the type of person who is responsible for building their microservice architecture, ideally, starting small, you'll hear a couple of different versions of this. A steel thread is something that we talk about a lot in Publicis Sapient, which is if you imagine you build first a steel thread and then you keep adding threads and eventually you have a thick steel rope, all of these kinds of talk to the same idea that what you want to be able to do is start small, do a small experiment, apply this to one piece. If you have the luxury of that, that is absolutely the best way.

Now, we don't always. In some situations, the reality is you are given a certain amount of budget and you have a certain time frame where you can make change happen. In those cases, the best you can do is make change really upfront and center, one of the features of what you're building. So, in a microservices case, the way we wrote the book, we optimize for, let's be honest, readability, we optimize for you to be able to actually follow along and do this in the context of a book. If I'm doing this in a project, what I might optimize for, in that case, we just talked about, is changeability, so how can I build these microservices in a way that if I need to reshuffle it, because we don't have all the answers, they won't be hard?

An example of that might be: let's use the same technology everywhere. So instead of you get to use Go, and I use Java, and someone else uses something else, which is going to hurt our ability to reshuffle, let's use the same technology, the same language at the beginning. I want to be able to move people around quickly. So let's call it all one team, we'll have sub-teams. But in two months, I might assign you to a different team, right? It's having that kind of mindset, I think, becomes important.

Mike Amundsen: Interesting. I always learn something new from you every time we talk, and we talk quite a bit. The steel thread story really kind of intrigues me. Maybe we can get a chance to talk about that again in another setting. But Ronnie, I want to thank you so much. Again, I want to tell people, this book is just great. You know from our experience together, I don't dig into the code really deeply. I do a lot of sort of proof of concepts, but you really got me building it from start to finish when I was working on this. 

It was actually pretty exciting. So I really thank you very much, Ronnie. Thanks to you. Congratulations to you and Irakli on the book, "Microservices: Up and Running." And thanks for the interview. I hope we get a chance to talk again soon.

Ronnie Mitra: Fantastic. Thank you.

About the authors

Ronnie Mitra is an author, consultant, and speaker who helps companies around the world improve their organizational designs and system architectures. He combines a focus on UX principles and managing system complexity to tackle the challenges of building effective API programs and establishing practical strategies for transformation. His most recent work is the O'Reilly book Continuous API Management which he co-authored.

Irakli Nadareishvili is the vice president of Core Innovation at Capital One Financial Corporation, leading the teams responsible for building Capital One's modern, cloud native, microservices-based core banking platform. Before Capital One, Irakli was co-founder and CTO of ReferWell, a successful New York City-based health technology startup, and held technology leadership roles at CA Technologies and NPR. Irakli is coauthor of Microservice Architecture (O'Reilly).

Mike Amundsen is an internationally known author and speaker, Mike Amundsen travels the world consulting and talking about network architecture, Web development, and the intersection of technology and society. He works with companies large and small to help them capitalize on the opportunities APIs and microservices present for both consumers and the enterprise. You can see more of his talks on his YouTube channel.

Amundsen has authored numerous books and papers. He contributed to the O'Reilly Media book Continuous API Management (2018). His RESTful Web Clients was published by O'Reilly in February 2017, and he co-authored Microservice Architecture (June 2016). Amundsen's 2013 collaboration with Leonard Richardson RESTful Web APIs and his 2011 book Building Hypermedia APIs with HTML5 and Node are common references for building adaptable Web applications. His latest book Design and Build Great APIs for Pragmatic Publishing.

Recommended talks

Practical API Design • Ronnie Mitra

GraphQL, gRPC and REST, Oh My! A Method for Unified API Design• Mike Amundsen

GraphQL, gRPC and REST, Oh My! A Method for Unified API Design • Mike Amundsen