“Whether it's API-first that we just touched upon or microservices in the back end and the micro front ends in the front end. All of this fundamentally is driven by understanding properly the business context.” 

Intro:
Welcome to the Agile Digital Transformation podcast where we explore different aspects of digital transformation and digital experience with your host, Tim Butara, Content and Community Manager at Agiledrop. 

Tim Butara: Hello everyone. Thanks for tuning in. I'm joined today by Hemant Elhence, President of Excellarate, a global technology services company with over 20 years of experience across leading industries. In this episode, we'll be tackling the topic of microservices and how companies can use this approach to development to streamline their front end development. Welcome, Hemant. It's a real pleasure having you with us today, chatting with you about this. Do you want to add anything to the intro before we begin with our discussion? 

Hemant Elhence: No, thank you, Tim. I'm glad to be here. I think a lot of what I have to add will probably come through as we have this conversation. So nothing to add right away. 

Tim Butara: Awesome. Looking forward to it. And yeah, basically microservices are not very old, not a very established topic. So let's start off with you telling us a little bit more about what microservices even are. 

Hemant Elhence: Good question. I think the topic of microservices has been around for close to a decade for sure. And I think, the way I look at it is, it has come about as a way, as a software applications as used by consumers with business and otherwise, has become more complex and heavy. There's a need to make software more scalable. When we say scalable, scalable on two fronts. One form of scalable is where the end user should have better performance when they're using it. For them, the response time and all that should be much faster. 

And second time of scalability, which has become a complex software, more of a need lately, is when you have large number of teams, when you have 30, 40, 50 scrum teams trying to build the same piece of complex software, how do you make sure those teams don't step over each other and can relatively independently have the speed and the responsiveness to deliver new functionality and not get too, what I should say, jammed or coupled together, that they are dependent on each other and they can't make progress. 

So I think to make the software, complex software, more scalable in performance and its development speed, that's where the microservices idea came about. And the basic idea, core idea of microservices is to make your software into modular components, and each component is as independent of each other. So both at the database level and the logic level; then you don't have to wait for another team on the database site and all that. So keep it as independent so each team can run fast, independently and still deliver full functionality for the end user. That's the core idea of microservices is to achieve that level of independent development of speed. 

Tim Butara: Yeah, I think that modularity is the keyword here, right there. And what are the benefits of using such an approach for your front end development? Why, or maybe when should companies go for it? 

Hemant Elhence: Okay, so now let's apply this idea to what you just touched on, Tim, which is front end. So historically, a decade ago when this concept of microservices came about was primarily on the back end, which is most of the complexity of software was on the back end, the database, the logic and all that was mostly at the back end. So you wanted to make sure that if you're doing some sort of an update to your record, you can do it quickly without waiting for a large database update to happen and all that. 

In last decade, the concept of microservices has been largely applied on the back end database and back end logic site. So the general model has been, you have a front end of any kind and you have APIs exposed via microservices or microservices exposed via APIs. And these microservices on the back end are independent enough to modularize, like you're talking, so they can scale faster. That has been very well understood, has been practiced now for over a decade or so, and all that, and that all works well. 

But the new idea in the recent year that you just touched on, Tim, is a micro front end. And the idea there is now applying the same argument, same logic, because the front ends have become complex also. Now when you go to Amazon to buy something, there's so many windows, there are recommendations going on, there are ads going on, there are, of course, the product you are seeing and then you can click on if you're buying an apparel, click on a window, which gives you your size fit for your trousers you're buying is the right fit or not. 

So there's so much goes on in the front end these days in these large applications, same issue is coming up. Large number of teams are working. And so the front ends have become very complex now lately. And to make the front end very scalable for the same reason, so that different teams can relatively independently contribute to the front end without getting blocked by each other, and the end user can have a response time that they expect when they log into a page and you want to search for a pair of trousers, you can put some keywords, it shows up right away. You're not yet ready to buy. You don't need to do payment authentication and all that yet. You just want to look for stuff. 

So it makes the end user's life at the front end also just as easier and with a faster response time. And for the company who is building that front end, it makes them build and make progress on the front end just as quickly with the large number of teams. So the idea is, what was microservices applied to the back end? The same thinking is now getting applied to the front end. That's what the micro front ends are. 

Tim Butara: I had no clue that it started with back end, actually, because I've had a few conversations about microservices and mostly they've been with front end engineers. Mostly they've been in the front end context. So I only ever learned, read, talked about microservices on the front end. So I just assumed that it's always been that way. So, yeah, thanks for enlightening me. Awesome. 

Hemant Elhence: Absolutely. 

Tim Butara: So, yeah, we've gone over the benefits or the advantages. Maybe now let's take a look at the other side. So what are the implementation considerations or the technical challenges of using microservices approach to development? 

Hemant Elhence: Yeah, excellent question. So this topic, like I said, microservices has been around mostly for the back end, been around for a decade or so. And the advice and the best practice has been, and the same thing will apply to the front end part also, is that you have to be very deliberate and thoughtful about how you partition your software functionality, keeping the business context in mind. 

So in the back end, for example, whenever you're building something new, the idea was, you don't have to start out with a microservice. In fact, the advice is – don't start with microservices first, because you don't know yet how you should partition your domain or your context yet. So build a functionality that the end user actually needs. Make sure the end user actually needs what you think they need. Right. 

So you build that, you get some adoption. You get a fair number of users adopting. Now you can observe the patterns in which they're using. You find, for example, that some users, most of the users come to the landing page and then go away. They're all browsing. A small fraction actually go do authentication and then search for some stuff. And some smaller fraction of users actually click on a button and buy some stuff and all that. Right. So you know the nature of use cases and then you can partition your functionality in a way, so that the microservices are then around those functionality domains. 

So the idea is that don't rush into defining microservices either on the back end or on the front end too early. So the opposite of microservices is monolith, meaning something combined, which is not partitioned properly and all that. And the advice is – build the monolith first, understand how users are actually going to use that scope of functionality that you're building. And once you have some data about the end user usage and have understood, then you can partition and refactor. So you can refactor your back end into microservices. And you realize that a lot of people are using landing page. So you peel that off as a microservice now because that needs to have better response time. 

And same ideas apply on the front end also; don't rush in to build a micro front end approach first, you're okay to build a monolith front end. Let the user adoption happen, and then as you observe how the users are using your front end, then you start peeling logical functionalities that allow you to scale because that functionality is used by a large number of users, needs a better response time, you have ten teams working on it, they need to work independently. So just be patient and deliberate about peeling off parts of the functionality into micro front ends rather than rushing into it. So that's very important. 

The related term that comes up is domain-driven design. And I don't know if your users are familiar with it. If they're not, I highly recommend just looking up this topic called DDD – domain-driven design, which is, the idea is that you want to really partition your software, both front end and back end, in the context of business domain. So a domain could be in one example, if you’re ecommerce, could be, a payment is a domain. So the authentication of the payment gateway and all that is the domain, you peel that off separately. Similarly, a recommendation engine, search and recommendation engine could be a domain. 

So you just partition based on the subject and the context of the business use case you're building and go about it that way and try to avoid partitioning by the software components. So don't let the software component design govern how you partition into microservices both front end and back end. Let the business context domain govern that. 

Tim Butara: Yeah, I think that was a really important point right here in the end. Right. Because for somebody who's not really experienced in this, the first assumption might be that, yeah, we will kind of take this component or framework driven approach to this partitioning and you just showcased that this probably isn't the most efficient way to go about it. 

Hemant Elhence: Right. It doesn't solve the real problem. So, see, what happens with development. I told you there are two main benefits of any of these approaches. One is from the end user perspective, they get better performance. That's important. Second is the developers themselves are less constrained by each other. So each team can be independent enough to make progress. And that progress the team can make is in the context of a business domain. 

So if they're solving a problem, let's say related to search and recommendation engine, they understand that domain. They know exactly, so that team should own that scope of functionality as a micr service, either in the front end or the back end in this case. Similarly, if you're doing like a payment example, same thing that domain is– so, domain or subdomains, for example. So organize your microservices around business context of domains or subdomains. That's the core idea. 

Tim Butara: And if I understand it correctly, this kind of approach can actually be applied retroactively, right? As you said, you can first build out a monolith and then partition it. 

Hemant Elhence: In fact, it is better to apply it retroactively is what I'm learning right now, which is– because what happens and this has been a core kind of a belief system around agile software development. As a builder of software, sometimes you think you know what the users want, and sometimes you do, often you don't. So what happens is you build something thinking how users are going to use it, and then you observe the actual users and see how they come, where they fall off, what functionality they click on, what they actually do. 

And once you have that real data of user adoption and usage patterns, that's when it makes sense to start partitioning your software to address the things we said about end user performance and development team scalability. So it's better to do a monolith first, because the reason, one thing I didn't touch on, very important, is there is the overhead of using micro services. There's an architectural and DevOps overhead to coordinate between these teams and have DevOps tooling in place and all that stuff. 

So it is not a good idea to commit to that overhead of engineering upfront and overcomplicate your time to market in the beginning, in the beginning, what you really want to do is get to market quickly, get the user validation, end user validation and adoption patterns, and where it makes sense, then go back and complicate the DevOps and the engineering – where it actually has a bang for the buck. Otherwise, you will end up over investing in complexity without any user benefit. 

Tim Butara: Yeah, I was actually just going to add that, that probably this approach makes the most sense because there's a significant investment to implementing micro service that likely will pay off at some point. But if you don't know yet exactly how they'll serve you, then you don't know what the ROI of that investment will be. 

Hemant Elhence: Right. It's very consistent with the fundamental belief system around agile practices, which is – get to market quickly, get feedback, and then based on feedback, don't be shy about refactoring stuff into microservices later. That's a good practice. 

Tim Butara: I love that. And you just mentioned DevOps. And actually, in the beginning, we started off with the kind of this important factor of collaboration in all this, so, different teams collaborating more efficiently. So let's say, how exactly is the developer experience connected to microservices? And specifically, how does something such as DevOps affect microservices-based development? 

Hemant Elhence: I think to properly do microservices, you got to have enough coordination because each service now is peeled off. So the developers should be able to do their part of the development and quickly do a build so they can get fast feedback that what they build actually works or not. So DevOps tooling, so that you can do continuous integration part quickly within a matter of seconds, worst case minutes. So DevOps tooling should be in place to allow the rapid feedback to a development team working on a microservice, either on the front end or the back end. 

And that basically means there has to be a modern DevOps tooling in place to allow someone to check in for continuous integration test to run and for them to at least be able to test it in the staging environment quickly and know that it is working as intended. Without that, I think it becomes very problem, because the main reason I said in the beginning to go in that direction of microservices is when you find that your front end, in this example a front end, is taking, let’s say, an hour to do the build. 

So if a front end team finished some functionality and now they hit the build and it is going to take an hour for them to find out whether it works or not, that's a long feedback cycle in software development. And because if you do that, then you will only be able to push to staging no more than, let's say, I don't know, six to eight times a day. You need to be able to do much faster. So DevOps tooling is– modern DevOps tooling is paramount requirement to have that foundation of tooling in place so that you can iterate faster and quickly push your builds out to at least the staging environment for testing. 

Tim Butara: That makes a lot of sense. I assume that there's a lot of elements to microservices-based approach to developing that DevOps would really facilitate in this sense. Okay. I think that we've covered most of the important bits about the current situation. So now let's take a look to the future. How do you think the microservices landscape will continue developing? What are the most likely trends that you would like to see maybe? 

Hemant Elhence: I think the general understanding that the teams have arrived now, that microservices way of building software is a good scalable way both for the end user performance expectations and all that, but also for the engineering teams. So the bigger trend that I think this will connect to now, which is coincidental in some ways, is a remote development. 

The fact that using microservices you can have a team in let's say Central European time zone and build a micro service relatively independently, because that's the nature of microservice. You can have a team in Dallas, Texas, where I'm sitting right now in US Central time zone. You could have a team sitting in Pune, India, which is some of our team members from Excellarate are sitting. 

You can have different teams each working on a different microservice and that's a very effective way to leverage remote development team and very effectively. But of course it calls for the foundation of DevOps and all that is of course needed. But the remote development that we just saw in the Covid times has become even more of a supporter of adoption of microservices because it just seems to work very well with remote distributed teams. 

Tim Butara: It seems to go hand in hand. Right. It's probably that this kind of remote nature of work made microservices more appealing. And then as microservices gained in popularity, that made remote work and remote collaboration more prominent.

Hemant Elhence: Exactly. Another thing I'm sure your audience hear about is API-first kind of a way of designing software, that also goes along with this. It just makes software development a distributed sport now. Each team is distributed in a different time zone, different geography. They own a certain business context and domain and the technology framework that goes with it. They're building their stuff at their speed, at the speed of innovation that is appropriate for them. 

But they have API-based– exposed contracts that are respected so the other teams can similarly make the progress relying upon the API contract they have with each other. So using API-first design, which is very fundamental now for complex software design, using microservices for distributed team is a very effective and elegant way to speed up innovation across time zones and geographies. 

Tim Butara: Yeah. That's well put. APIs are definitely at the core of software nowadays and at the core of kind of digital experiences that go beyond just the basic level. 

Hemant Elhence: Absolutely. This is a given now. 

Tim Butara: Well, this has been an awesome discussion, Hemant. I think, as I said, we covered a lot of important stuff. I certainly learned a lot of new stuff. Before we finish, do you have any final tips or any words of advice to businesses that are trying to implement this, that are trying to move to microservices? 

Hemant Elhence: Yeah. So the only advice I'll amplify again is, whether it's API first that we just touched upon or microservices in the back end and the micro front ends in the front end. All of this fundamentally is driven by understanding properly the business context. So don't lose sight of the fact that– understand the business context first before you partition the problem, because otherwise chances are your partitioning will not achieve the objectives you intend to achieve. So business context. Business context. Business context. 

Tim Butara: Yeah. That's definitely one to repeat. Definitely one to keep in mind. 

Hemant Elhence: That is where the crux is. Technology will follow. But if you're not fully understanding your business context, then chances are you will probably get your partitioning wrong. 

Tim Butara: Yeah. It's easier to adapt technology to the business context than vice versa. 

Hemant Elhence: Absolutely. Yeah. 

Tim Butara: Awesome, Hemant, before we wrap it up, if listeners would like to reach out or learn more about you, where can they do that? 

Hemant Elhence: The best way to reach out to me and I'm very active and engaged on LinkedIn. Linkedin is the best way. And good thing is my last name is unique enough and the combination of my first name and last name will bring me up right away on my LinkedIn profile. So I always keep up with any email messages or any kind of a connection request and all that. Of course my policy has been I only connect with people I actually know but I'm always responding to messages on LinkedIn. Linkedin is the best way to connect with me. 

Tim Butara: Awesome. I'll also add the link to the show notes just in case. 

Hemant Elhence: Yeah, absolutely. Well, great. Enjoyed this conversation, Tim. 

Tim Butara: Yeah, me too. Thanks for joining us. It's been a pleasure speaking with you, Hemant. 

Hemant Elhence: Likewise. Thank you. 

Tim Butara: And to our listeners. That's all for this episode. Have a great day everyone and stay safe. 

Outro:
Thanks for tuning in. If you'd like to check out our other episodes you can find all of them at agildrop.com/podcast as well as on all the most popular podcasting platforms. Make sure to subscribe so you don't miss any new episodes and don't forget to share the podcast with your friends and colleagues.