How to get your microservices up-and-running with Ronnie Mitra

Kevin Montalbo

Joining us from Sydney, Australia is Toro Cloud CEO and Founder David Brown. Good day, David!

David Brown

Good day, Kevin!

Kevin Montalbo

All right. And our guest is the Director of Technology in Publicis Sapient, helping 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.

Ladies and gentlemen, joining us for this episode of Coding Over Cocktails is Ronnie Mitra. Hi Ronnie, great to have you here!

Ronnie Mitra

 Hello! Thank you for having me.

Kevin Montalbo

 Great. Now, before we discuss some of the topics on microservices from your books, I'd like to hear more about your experience as the Director of Technology at Publicis Sapient. You describe your role as "enabling financial service companies to digitally transform and unlock the value of the digital ecosystem around them." So, what changes are you witnessing right now in the financial services space?

Ronnie Mitra 

That is a crazy description for my role. I guess I wrote that.

Kevin Montalbo 

Yes, you did.

Ronnie Mitra 

Well, it's LinkedIn. We all write stuff like that on LinkedIn. So, let's be honest. I'm not the Director of Technology. I am a director. So, there's a few of us, thankfully, because we have a pretty big client base for Publicis Sapient as a consulting firm. I mean, what we're really trying to do is help organizations with what we call "digital business transformation" which means, "The world is changing how can clients cope?", right? How do they serve their customers? How do they change their business models? How do they change the way they run their organization from top to bottom, across every aspect? So, that's an exciting thing to try and tackle.

And a lot of my work is specifically in the financial services industry, but we, as a company, cover all kinds of industries: retail, manufacturing, et cetera. So, a lot of us were out there trying to help people use things like APIs and microservices to reinvent themselves and compete fundamentally with others.

David Brown

 And there's obviously a lot of trends in the financial services space. Fintech has been an enormous area in the last couple of years. What changes are you witnessing? The structural change, the transformation that’s going on in there?

Ronnie Mitra 

Well, let's be honest. I'm an API and data guy at heart. What's amazing to me is if it was, five or 10 years ago when I was talking about, "Hey, you know, APIs are something you really should be paying attention to", the overwhelming reaction in financial services back then was really, "Oh, that's fascinating. We'd love to hear you talk about it." All we do is internal APIs, and we're not really interested in any of this other business transformation and changing the way we do business.

Whereas now, there are a number of global banks ?— you can call them tier one banks? — commercial banks who have embraced this not just from a tech perspective, but they are now looking at how do we take everything we do and put these in new places where our potential customers are. And that fundamental change is exciting. And at the same time you mentioned fintech. There's this idea that how do we take the stuff that other people are doing and use their services so that we can power our organization and company. And that is fundamentally different from the way a bank technology worked five or 10 years ago. Right? It's a big, big shift and it's exciting.

David Brown 

Are you involved in the fintech space as well as the traditional banking space?

Ronnie Mitra 

A little bit, yeah. I mean, certainly we work with fintech firms quite a bit. In some cases going in and helping them with their product especially around Open Banking, the regulatory requirement in Europe and spreading to the rest of the world in variations. A lot of what we do also is helping the big banks figure out how to work with fintechs and get the most from them.

David Brown 

Buy them.

Ronnie Mitra 

Or use them, right? Use their capabilities. Use their APIs.

David Brown 

Teach them to survive and grow and buy them. Okay, so you mentioned that APIs are a passion of yours. So where did this passion develop from?

Ronnie Mitra 

I don't know. I guess at some point someone kept paying me to do things in the API space. That's how all of this starts probably for any of us. But there is, for me, such a strong correlation between how systems talk to each other and how people talk to each other, these kinds of parallels. That large things are actually made up of small things that communicate right? And we get emergent behavior. For me, a lot of that is where the interest comes from. And being able to see in our technology space, something to me that reflects what's in the real world has always been pretty fascinating. Right? Just this kind of unlocked potential. But you know, since I'm on the couch, I don't know where the passion comes from.

David Brown

 And of course you've written a couple of books on microservices. So, presumably, you were implementing APIs and then came across microservices and emerging architecture for building the backend of services. Is that how it came about?

Ronnie Mitra 

Yeah. The microservices thing happened while myself, my co-author of the book, Irakli, and a few others of us, were in a group called the API Academy. So, we were pretty heavily invested in talking about what APIs should look like, how you should build them. It was a thought leadership team and people started talking about microservices. So, we had to start paying attention way back then. And, you know, the more we dug into it, the more we realized that, "Hey, this moniker that this group of architects had come up with looked like it was interesting." And there was some practical application and it sounded a lot like the way we were talking about how applications should be built. So, it was kind of a natural fit in terms of a vein to mine.

David Brown

 And of course you've written a couple of books. So you started with Microservices Architecture in 2016 and more recently, Microservices: Up and Running in 2020. What's the difference between the two books? Has the architecture evolved or is it you identifying new techniques? What was the difference there?

Ronnie Mitra

 Well, I think what's evolved is our understanding and let's call it the adoption cycle, right? Where we are in terms of our microservices story as an industry. So, when we wrote that first book, we were at that time, as thought leaders, getting a lot of questions about, "Hey, what are microservices? How do I do them? What does it really mean to do microservices?" Sam Newman had written his great book on microservices that was very technically oriented. We were trying to create something to go along with that. That would be shorter. Something that someone who just really wanted to get the essence of it could get it. So, it's a pretty, pretty small book. One of the ideas was this should be something you could read on like, a long haul flight, right? You could read half of it going out, read the other half going back in and you could walk into the meeting with a really strong understanding of the principles of microservices. Right?

The second book is the opposite of that. The second book is my co-author, Irakli and I together saying, "You know, what's missing now is something that helps the person who has been told, ‘Now we need to do this’", and helps them in terms of the landscape of things they need to figure out in a very guided way, in a very prescriptive way. So, you can just get going. Which is why we love the "up and running" kind of theme that O'Reilly uses for these books ‘cause that's really what we were going for. So, a much more practical version.

David Brown 

Yeah. So, you've taken that "up and running theme" and you've applied it to the microservices model. You talk about a team design and data design deployments to cloud platforms, as well as obviously the microservices design. So, how do you correlate the "up and running" model to your, in, in your book?

Ronnie Mitra

When you're learning a new skill... it's much easier if you start by following someone.

 I think the parts of the model you're describing are really based on the experience from Irakli and I having to do this in real life. Those are the parts of the system we need to pay attention to. And they're highly interrelated. For me though, the "up and running" aspect of this is that we, as authors in this book in particular, have made a series of decisions across all of those spaces for you. Right now, when you do this for your own company, you're going to have to make all those decisions. You're going to have to figure out, "Are we using a cloud platform? Which one are we gonna use from their services? Are we going to try and be agnostic? Are we going to try and be portable? Are we doing serverless? Are we doing a venture in…" like, there's this constellation of decisions.

And what we wanted to do instead was give you a guided version of the first one. In the book we mentioned there's this idea of the Dreyfus model of learning. It’s the Dreyfus model of acquisition if I remember correctly and that was written by two brothers, the Dreyfus brothers, who were both university professors, years and years back. And it always stuck with me. And the idea is that when you're learning a new skill, whether it's tennis or golf, or even microservices, it's much easier if you start by following someone. So, the first step is to have a really guided learning trail where someone holds your hand and they tell you how to do everything before you understand why you were doing those things, right? So, that's the first step. You need to go through it.

You need to go through the motion of it. And then there's subsequent steps where you start to understand the game within the game, the reason why you're doing these things, and then the true mastery comes when it's almost like subconscious. You're not even thinking about why you’re doing things. So, you're just doing it because, you know, these are the right things to do. So, the goal here is we'll start you on that path, right? So, you get to do the first one in a very guided way so that the next time you're doing this for real, you've already gone through this process and you can start to see the decisions within the decisions and the impacts and the muscles that you'll need to make this work for real.

David Brown 

So how prescriptive is it? Are you deciding on some of these architectural decisions? You mentioned a whole bunch of things, like event-driven architectures and serverless and all of this stuff. Are you deciding on a particular architecture and prescribing that and guiding someone through that process?

Ronnie Mitra 

In the book? Yeah. In the book we are. And partly because, hey, it's a book, right? You've got a certain number of pages. So, we need to get you from thinking about what a microservice is all the way to having one running with DevOps and data and all of that stuff. And like, what, what is it? 200 pages, 300 pages. So we need to be fast.

David Brown

 It's a really practical hands-on guide. When you get to the end of it, you've actually produced.

Ronnie Mitra 

Yep, absolutely. Yeah.

David Brown 

Now you also talk about a SEEDS method. Seven essential evolutions of designer services for designing microservices. What is the SEEDS method?

Ronnie Mitra 

So, we should give credit to Irakli. Irakli named the SEEDS method. It's reflective, really, of the way both he and I approach API design and microservices. And I think he mentions in the book, specifically, he's modeling that after the work he was doing in healthcare, when he first started playing with, building microservices. But I have to say, you know, I follow almost exactly the same process. The idea is that you don't create APIs in a code first way or microservice strictly to code first way. Right? So, if we're making interfaces, what we do is we start with understanding who is going to use them, what they want to use them for. And from that, you start to evolve a picture of the capabilities, the queries, the commands, all of the things you need to do to serve those needs, right? So, it's a very customer-centric, user-centric and needs-focused way of implementing and designing a service.

David Brown 

Run us through that, those seven processes. I believe you were talking about identifying the stakeholders associated with the services. So, presumably, you're identifying the stakeholders who are collaborating with them on the implementation and design of those services. Is that right? Is it the starting point?

Ronnie Mitra 

Yeah, I think in SEEDS, it's called "identifying actors." You can call that whatever you like, but the main thing is to identify the users or communities of users that are going to use the service. Now, the corollary there, that can be a challenge if what you're trying to build is something that is highly flexible and generic, right? If you're building something that you actually want to be reused across channels, across services and 16 million different ways, it's a little bit harder. So, then you have to find a few more of these actors, right? But typically, in the microservices context, we have some idea of who we're building these things for. So, you start with that. And I think the next step would be the "jobs to be done" step.

David Brown 

I think the sequence diagrams.

Ronnie Mitra 

Right. Okay. So yeah, this is a bit of a test for me, you know, I just write them. I don't read the books, I just write them. The key though, so if we figure out who needs to use the service and we figure out what they want to get from it, that's how you can start mapping out the interactions. And in the SEEDS method, which is more prescriptive, it's with a sequence diagram, which is a way to start bubbling up the questions of like, "How does this actually have to work so that that actor can actually achieve their need or the job that they're trying to do?"

David Brown 

I understand. I mean, this is a real practical guide to getting up and running with microservices, with hands-on tutorial type concepts of getting a microservice up and running in a prescriptive format. Where do I go after this book? What's next? Do you then start learning more about architecture and different implementations? Where do you go after "up and running"?

Ronnie Mitra 

So, this is a very valid question. I guess it depends on who the reader is. Right? So if your goal is that you want to be an expert in microservices architecture, I would say after this book, you need to do this again, right? I mean, the true concept of mastery is going to come from gaining experience. One of the reasons why we've tried to catalog the decisions is that we think it gives readers an opportunity to go back and change some of those decisions and see if they can improve the architecture to fit the context that they have, or the needs that they have. And see the impact of changing that. I mean, ideally what we all really want to do is do it for real, right? So, I would say after going through the book, what you want to do is find a project and actually apply some of this and start to decompose.

Now, I will say in reality, very few of us get the chance to do it the way we did it in the book where you have a complete Greenfield and you get to just say, "What I'm going to build is this, and I'm building it with microservices." The missing handbook is probably the one that tells you how to sell this, or you know, how to make it fit your existing business, or how to select the parts of your existing application that you want to start decomposing and pulling apart. Right?

David Brown

 That's an area I'd like to talk to you about in terms of your experience with saving. Because that's what you're doing on a daily basis, right? In your role of saving, it is the actual implementation. So, how do you find those concepts from your book translating to the real world and where do you find that? Because you're dealing with people a lot, right? In a real world situation, the complexity is often around people and organizational structure and bureaucracy and all the rest of it. So, tell us about the experience there and where I guess some of that sort of theory comes a little bit unstuck.

Ronnie Mitra 

If you're trying to introduce a microservices stack into a big company... you need to establish a little bit of a Greenfield approach.

Yeah. Thankfully this book is actually reflective of the real world work that both Irakli and I have done including my Sapient work and his work at a big bank. I think he mentioned the bank. I think we're allowed to say Capital One. So, it's definitely grounded in reality, but it's simplified a bit, right? So that it can be digestible as a book and it doesn't have the context of a particular customer's technology and constraints. And like you said, I think that's where, when you try to do this for real, you need those skills if you're doing it in a big enterprise. So, if you're trying to introduce a microservices stack into a big company, our experience is you need to establish a little bit of a Greenfield approach. It's a lot harder to do this in place, in an existing application.

It's much easier to do this if we say there's an aspect of the application or architecture that we want to pick off, and we're going to do that by almost, like, planting a seed in a new place and we start building it there. And I've seen that done in a few ways. Some banks have been more ambitious and they want to do it almost like a big bang. Like, "Hey, we're going to rebuild the entire bank on the cloud" aspirationally, which requires a lot more upfront design. And then other banks might be saying there's a specific application. You know, the op costs are too high. It's too slow to change and we need to improve that. And we want to do this microservices and cloud-based approach.

So you can start to pick it off a little bit smaller. But either way, if you take the chapters of the book and you start going through them, what I find is it helps you come up with the right questions to ask, for example, when that client or when your business tells you, they want you to improve an existing online application, a web based application, and you start going down the microservices route, don't forget about data.

Don't forget about the operating model, because you're probably going to have to change the way the team works as you move this thing over right into a new world. The other thing from the real world is that businesses don't care that much about microservices, right? And we need to keep that in mind, like they know what they are nowadays, but if you think about it, what is the value to a business of breaking something big that you run as a tech organization into five things? Well, the answer is operating cost is lower as speed of change. They care about those things. But one of the biggest shifts you have to make, if you're an enterprise company, is how do you make it so the technology team can do that optimization without justifying it every time to the business? Because what you really want it to deliver to your business is, "Hey, you know, that app, we were able to deliver it in three months" or "We just improved the functionality really quickly because we did some internal tech optimization and we made it all work." That turns out to be a bigger shift, right? Because then we need everyone to establish trust. We need to remove the barriers to that trust. And that's bigger than microservices.

David Brown

 Yeah. Like you said, they don't really care about the implementation. They care about change. They care about transformation, delivering new products and services to customers and what the market wants or even the internal stakeholders like employees or business partners want. And if microservices is a way of implementing or providing that then fine. But equally, whilst five services as opposed to one may mean that you can roll out those changes faster, it also means you've now got five times as many services to manage. And there's a cost as well. Right?

Ronnie Mitra

Absolutely. Yeah.

David Brown 

How are you seeing that cost thing managed? Do you see any headaches associated? Because five is probably more like 500 in terms of a financial application in a large bank. So, how do you find that process of managing, breaking down these monoliths into many, many services?

Ronnie Mitra

If I'm honest, I think this is what most people struggle with. How big should the microservice be? How do I decompose my application into them? Because we all are worried about the 500-microservice scenario, right? It's in the back of everyone's head, we're all worried that if you break it up too much, the end-to-end performance might suffer. That's the first one that gets thrown out there. Okay. What's that going to do to performance? And then we worry about how we're going to manage all of these things. How are we going to find them, discover them, operate them. Right? And that's why, when you start pulling on this microservice thread, usually you end up—and I think this is good—you start pulling on these other threads too, like Kubernetes, to help with reducing the cost of operating a lot of things. The cloud to reduce the infrastructure cost of operating things and to get elastic scalability.

So, you can start to turn down the volume on some of the fear. We've got ways of managing that. The costs, thanks to tech, the cost of doing this has actually gotten cheaper. Right? But where you'll be left with is still a fundamental question of, "So how do we decompose this?" Right? And where I try and take our clients is, well, firstly, you know that there's not going to be a final state, right? Like it's not going to be that, you’ve broken this up into four things and you're done. Where you actually want to get to is that you're continuously like playing with this in the book. I think it was Irakli who wrote this part that actually gives some very strong guidance, which is a great, useful tool, like starting with Event Storming as a technique, drawing out some boundaries, using those as a way to start figuring out where things are.

But the truth is, I hate to break it to you, these are all designed decisions. So, you can have all these techniques and methods to get you started. But what you really need to do is to build a habit of optimizing. Measuring and optimizing, and you need the technology that lets you make those changes. Last thing I'll mention here is like we all know none of this is new, right? I mean, since the early eighties, late seventies, Larry Constantine, David Parnas — everyone's been talking about structured design. Mel Conway said his thing way back. The reason it's so relevant now, I really think, is because not only has the pressure for speed and safety at the same time increased, but also the technology has made all this much more possible, right? Because you couldn't manage that risk and costs you talked about before, but now you can. So, now we can build this way. We couldn't do it before.

David Brown

In your book, you've dedicated a chapter to architectural decision records. And you also have a GitHub repository on them as well. How do the architectural decision records come into play when it comes to building software?

Ronnie Mitra

The challenge of the microservice space is every decision you make has an impact on 16 more.

Yeah. These are one of those things that's like dead simple as a concept. But I think not enough people do it. What I really like about logging decisions, whether you use ATRs or Michael Nygard's LEDR format, or if you just call it a decision log and you put it in JIRA, whatever you do, it's so useful because the microservice thing is huge and complex. And what I noticed was happening is, you end up in these meetings where people are talking about the same thing over and over and then you have a meeting the next week and you talk about the same thing over and over. Right? Well, instead, what we want to do is to be able to pick off the parts of this into almost like bounded decisions where we can say, "This is a decision we're making and we're moving forward now and you can revisit it." Right? That helps us because the challenge of the microservice space is every decision you make has an impact on 16 more, which is why we ended up in those circular conversations and we don't make progress. So, it was just one of these simple tools that I've found in practices really, really effective. So, I encourage everyone, you know, to do some form of this on your project.

David Brown 

We do it in our own sprint records. Because you're always sort of brainstorming ideas in a sprint, right? And we found the same thing as we kept on going around in circles, "Actually, did we talk about this a few months ago? What was it we talked about?" And so actually starting to document it as you go, write that down, record it so you can have a permanent record and reference it later is becoming valuable.

Ronnie Mitra 

And where it really pays off, when someone joins your team and you can point them to this thing and say, "Hey, look, if you want to see how we got here, it's all right here. Because you're about to ask the same question we asked, it's all over there."

David Brown 

Yeah. Ronnie, the book is clearly some very clear, concise and practical advice on microservices. And the target market is an architect or programmer? Who is the audience of this book?

Ronnie Mitra 

I think it's primarily both of those roles you described. I mean, I could also definitely see C-level CTOs getting value from the book, but we wrote it for the architect or the engineer, developer who needs to build one of these and who is a little bit unsure about the things they will need to do to get there. So this is all about giving that person some guidance. And also, if you are currently running a microservices system, this gives you a validation point. You know, you can go through the book and say, "Okay, well we did that. We did that. Oh, I never thought about that. Maybe we should start looking into this piece."

David Brown 

Brilliant. Ronnie Mitra, thank you very much for your time. How can our listeners stay in touch with your musings and what you're reading and writing about?

Ronnie Mitra 

That's a good question. I have a Twitter account that I don't tweet on. I tweet once a year. I think probably the best way is probably LinkedIn. You can follow me on LinkedIn. I'm all over Google. If you search for me, you find me, I guess. I don't know what kind of answer to give you here. The other thing is, hey, you can come and hire me and I would be happy to spend time with you.

Kevin Montalbo

Well, that's how we found you. We googled you.

Ronnie Mitra

I'm all over Google. I don't know if I'm the only one.

David Brown 

Ronnie, thank you very much.

Ronnie Mitra 

All right. Thank you.