Aaren Quiambao

Welcome to Coding over cocktails, a podcast by Toro Cloud. Here we talk about digital transformation, application integration, low code, application, development, data management, and business process automation. Catch some expert insights as we sit down with industry leaders who share tips on how enterprises can take on the challenge of digital transformation. Take a seat. Join us for a round here are your hosts, Kevin Montalbo and Toro Cloud CEO and founder David Brown.

Kevin Montalbo

Joining us from Sydney Australia Toro Cloud CEO and founder David Brown. Good day, David.

David Brown

Good day Kevin. 

Kevin Montalbo

All right. And our guest for today is the Director of Technology at 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 Cocktail is Ronnie Mitra. Hi, Ronnie. Great to have you on the podcast.

Ronnie Mitra

Hello. All right. Hi, thank you for having me. 

Kevin Montalbo

Great. Now, before we discuss some of the topics on micro services from your books, I'd like to hear more about your experience as the director of Technology at Public SAPIEN, 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, I guess I wrote that at some point, right? And I should, I should. Well, it's linked in, you know, we all write stuff like that on linkedin. The truth is, 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, for a publicist 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, you know, 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? Right? From top to bottom across in every aspect? So that's an exciting, exciting thing to try and tackle. And a lot of my work is specifically in the financial services industry, but like we as a company, we cover all kinds of industry, retail, manufacturing, et cetera. So I mean, just like, just like a lot of us, we're out there trying to help people use things like APIs and microservice reinvent themselves, you know, 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 for the last couple of years. What sort of changes are you witnessing the structural change, the transformation is occurring there?

Ronnie Mitra

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

Whereas now there are a number of global banks, large 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 services 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

Hm. 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 the regulatory requirement in Europe and spreading to the rest of the world in, in variations. A lot of what we do also is helping the big banks figure out how to work with fintech and get the most from them or use them. Right. Right. Use their capabilities, use their APIs.

David Brown

See which ones survive and grow and buy it. Like I said, you mentioned that APIs were a passion of yours. Where did this passion develop from? 

Ronnie Mitra

I don't know, I, I guess, I guess at some point someone kept paying me to do things in the API space, right? That's how all of this starts probably for any of us. But there is a, for me, a such a strong correlation between how systems talk to each other and how people talk to each other, these kinds of parallels that, that large things are actually made up of small things that communicate, right? And we get emergent behavior. 

For me, a lot of, a lot of that is where the interest comes from. you know, and, 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, this kind of unlocked potential. But you know, since I'm on the couch, I I don't know where the, where the passion comes from.

David Brown

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

Ronnie Mitra

Yeah, the microservices thing happened while myself, my co author of the book or Rockley and a few others of us, we were in a group called the API Academy. So we were pretty heavily, you know, invested in talking about what API should look like, how you should build them. It was a thought leadership team and people started talking about micro services. 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, this moniker that, you know, the, this group of architects had come up with looked like it was, it was interesting and there is some practical application and it sounded a lot like the way we were talking about how applications should be built. So it's 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 Microsoft's Architecture in 2016 and more recently, Microsoft is up and running in 2020. What, what's the difference between the two books? Is the architecture evolved or is it you identifying new techniques? What's 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 micro surfaces 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, like, 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, 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 or Rockley 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 because 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 micro services model. You talk about team design and data design deployments to cloud platforms as well as obviously the micro services design. So what, what do you, when you, how do you correlate the up and running model to your in, in your book?

Ronnie Mitra

I think, I think the parts of the model you're describing are really based on, based on the experience from Rockley and I having to do this in real life. Those are the, the parts of the system we need to pay attention to and they're, they're highly interrelated. For me though, the, 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 their services? Are we gonna try and be agnostic? Are we gonna try and be portable? Are we doing serverless? Are we doing event driven? Like the 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, this idea of the Dreyfus model of learning the Dreyfus model of acquisition if I remember correctly. 

And that was written by 22 brothers, the Dreyfus brothers we're 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 like tennis or golf or even micro services, 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 just kind of got, 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 like the game within the game, that the reason why you're doing these things. And then the true mastery comes when, you know, it's almost like subconscious, you're not even thinking about why I'm doing things, 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 like the muscles that you'll need to make this work for real.

David Brown

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

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 DEV ops and, and data and all of that stuff in like what, what is it? 200 pages, 300 pages.

David Brown 

Yeah. It's a really practical hands on hands on guide as to when you get to the end of it, you've actually produced something. 

Ronnie Mitra

Yeah, absolutely.

David Brown

Yeah. Now you also talk about a Seeds method. Seven essential evolutions of designer services for designing micro services. What is the seeds method?

Ronnie Mitra

So we should, we should give credit to Iraq. Iraqi named the the Seeds method. It's, it's reflective really of the way both he and I approach API design and microservices and anything he mentions in the book specifically, he's modeling that after the work he was doing in in health care 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 of who's going to use them, what they want to use them for. And from that, you start to evolve a picture of the capabilities, the you know, 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 needs focused way of implementing and designing a service.

David Brown 

Well, run us through those seven processes. So I believe, you know, you you're talking about identifying the stakeholders associated with the the services. So presumably you you you're identifying the stakeholders 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 in seeds, it's called identifying actors. you can call that whatever you like. But the the main thing is to identify the the users or communities of users that are going to use the service. Now, you know the corollary there that can be a challenge if what you're trying to build is something that's highly flexible and generic, right? If you're building something that you actually want to be reused across channels across services in 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. It's a little bit of-

David Brown 

A sequence diagram, right?

Ronnie Mitra

So yeah, this is a bit of a test for me. You know, I just write them. I don't, I don't read the books. I just write the key though, right? is so if we figure out who needs to use the service and we figure out, you know 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, it's with a sequence diagram which is a fantastic way to start bubbling up the questions of like, you know, 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 

Instead the 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 they go after this book? Like what, what's, what's next? Do they, do you then start learning more about architecture and, and different implementations where do you go to 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, if your goal is that you, you want to be an expert in microservices architecture, I would say after, after this book, you need to do this again, right? I mean, the the true, 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, right? 

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, and start to decompose. Now, I'll say in, 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 green field and you get to just say what I'm gonna build is this and I'm building it with microservices. The kind of the missing book here. 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, you wanna start decomposing and, and pulling apart, right?

David Brown

And 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? And your role of saving it is the actual implementation. So like how do you find that those concepts from your book are translating to the real world? And where do you find that, you know, because you're dealing with people a lot in a real world situation that the complexity is often around people and organizational structure and bureaucracy and all the rest of it, right? So tell us about the experience there and where I guess some of that sort of theory comes a little bit unstuck.

Ronnie Mitra

Yeah. Thankfully, this book is actually reflective of, of the real world work that both Rockley and I have done including my SAPIEN work and, and his work at a big bank. I think he mentions 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 customers, you know, 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 experiences, you need to establish a little bit of a green field approach. It's a lot, 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 wanna pick off and we're gonna 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, some banks have been more ambitious and they want to do it almost like a big bang like hey, we're gonna rebuild the entire bank on the cloud aspirationally, which requires a lot more of upfront design. And then other banks might be saying there's a specific application, you know, the costs are too high, it's too slow to change and we need to improve that. And we want to do this micro services and cloud based approach so you can start to pick it off a little bit smaller. But either way if you, you take the the chapters of the book and you start going through them, What what I find is it helps you come up with the right questions to ask. 

For example, when that, when that client or when your, your business tells you they want you to improve a, you know, an existing online application, a web based application and you start going down the microservices route. You know, don't forget about data, don't forget about the operating model because you're probably gonna have to change the way the team works as you move this thing over right into a new world. The, the other thing from, from 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 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 OK, operating cost is lower speed of change. 

Yeah, 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, 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 wanted to deliver to your business is hey, you know, that app, we were able to deliver it in three months or we just improve the functionality like 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 microservice. 

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 they're even internal stakeholders like employees or business partners. and, and if microservice is a way of implementing or providing that then fine but equally, whilst five services as opposed to 1 may require, may mean that you can roll out those changes faster. It also means you've now got five times as many services as to manage. And so there's, there's a cost as well. Right.

Ronnie Mitra

Absolutely. Yeah, I mean, that's the-

David Brown

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

Ronnie Mitra

If I'm honest, I think, I think this is what most people struggle with. how big should a microservice be? How do I decompose my application into them? Because we all are worried about the 500 micro service scenario, right? It's in the back of everyone's head. We're all worried that if you break it up too much, the, you know, end to end performance might suffer. That's the first one that gets thrown out there, right? Ok. What's that gonna do to performance? And then we worry about how we're gonna manage all of these things, how are we gonna 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 like turn down the volume on some of the like the the fear we've got ways of managing that. The cost. Thanks to tech, the cost of doing this has actually gotten cheaper, right? But where you'll be left with is still the fundamental question of like, so how do we decompose this? Right? And where I try and take our clients is, you know, 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. What you actually want to get to is that you're, you're continuously like playing with this in the book. 

I think it was a Rockley who wrote this part, actually give 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 hate to break it to you. These are all design 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 a 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 increase, but also the technology has made all this much more possible, right? Because you couldn't manage that risk and cost 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 proposito on them as well. How do the architectural decision records come into play when it comes to building software?

Ronnie Mitra

Yeah, these are one of those things that's like dead simple as a concept, right? But I think not enough people do it. What I really like about logging decisions, whether you use ADRs or Michael Nygaard L ad R 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, 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? But 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 end up in those circular conversations and we don't make progress. So it's just one of these simple tools that I've found in practice is 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, you're always sort of brainstorming ideas in a sprint,

Ronnie Mitra

Right?

David Brown

And we found the same thing as we kept on going around in circles talking, you know, actually didn't we talk about this a few months ago? What, what was it we talked about and so actually starting to document it as you go, let's write that down, record it. So you can have a permanent record and reference it later is becoming vain.

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, 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, it's all over there.

David Brown

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

Ronnie Mitra

I think it's primarily both of those rules you described. Yeah, I mean, I could see definitely also CC level CTO 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, right? So this is all about giving that person and some guidance. And also if you are currently running a micro services system, this gives you a validation point, you know, you can go through the book and say, OK, well, we did that, we did that., 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 new scenes 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, you know, probably linkedin. You could follow me on linkedin. You can 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.

Kevin Montalbo

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

Ronnie Mitra

Right. Yeah, 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.

Kevin Montalbo

All right. That's a wrap for this episode of coding over cocktails to our listeners. What did you think of this episode? Let us know in the comments section from the podcast platform you're listening to. Also, please visit our website at www.torocloud.com for a transcript of this episode as well as our blogs and our products. We're also on social media, Facebook, LinkedIn, Youtube, Twitter and Instagram, talk to us there because we listen, just look for Toro Cloud on behalf of the team here at Toro Cloud. Thank you very much. For listening to us today. This has been Kevin Montalbo for coding over cocktails. Cheers.