TPM Podcast: Vidya Vrat Agarwal on Microservices – Part I

A very interesting TPM Podcast with Vidya Vrat Agarwal on Microservices.  We talk about large enterprises moving from monolithic application patterns to microservices what that entails. We go on to talk about various microservices best practices.

TPM Podcast with Vidya Vrat Agarwal on Microservices

This has been split into three episodes:-

• Part I: Lives here.
• Part II: Lives here.
• Part III: Lives here. 

Vidya’s LinkedIn Profile – https://www.linkedin.com/in/vidyavrat/

Also, read my previous post on microservices here :-

• https://www.mariogerard.com/microservices/ 
• https://www.mariogerard.com/building-resilient-microservices/ 

We talk about :-

1. What is a microservice?
2. Advantages of microservices
3. Monolithic applications vs microservices ?
4. Why is there is renewed uptick in organizations using Microservices ?
5. Pain points of microservices
6. How do you break down monolithic applications into microservices
7. Microservices Advanced Topics

Vidya’s Interesting LinkedIn Posts

• Microservices Architecture 
• Single Team Owned Service Architecture
• Building A CI/CD  Pipeline

Thank you ! Hope you enjoed it !

————****************———–

Vidya’s Linkedin Post (Extract)

Abstract

The microservices architecture style is an evolution of the Monolith SOA (Service Oriented Architecture) architecture style. The difference between the SOA and microservice approach is how these are being developed and operationalized. With every new technology addition, our responsibility also increases to be abreast of pros-and-cons the new member has, and the pain points it is designed to solve.

Monolith

Think of any MVC pattern-based API codebase, where all your controllers and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed as a single unit, and for almost all the times a single data store was used for the enterprise. I.e. One database is housing all the tables for various responsibilities, for example, Customer, Payment, Order, Inventory, Shipping, Billing, etc. as shown in the logical architecture diagram below. I.e. all the various responsibilities are together.

Monolith Pros:

• Less Cross-cutting Concerns: Being monolith and having all the responsibilities together, single or few implementations can cover all the major cross-cutting concerns such as security, logging.

• Less Operational Overhead: Having one large monolith application means there’s only one application you need to set up logging, monitoring, testing for. It’s also generally less complex to deploy, scale, secure and operationalize.

• Performance: There can also be performance advantages since shared-memory access is faster than inter-process communication (IPC).

Monolith Cons:

• Tightly Coupled: Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability.

• Harder to Understand: Due to many dependencies, monolithic architecture easily become harder to understand.

• Deploy all or none: When a new change needs to be pushed, all the services need to be deployed. I.e. if something changed in OrderController and you want to proceed with deployment, all other controllers and code will be deployed unwantedly.

• Scale all or none: Scale up/out/down, it’s for entire functionality.

Microservice

Gartner defines a “Microservice as a small autonomous, tightly scoped, loosely coupled, strongly encapsulated, independently deployable, and independently scalable application component. “ Microservice has a key role to play in distributed system architecture, and it has brought a fresh perspective.

Unlike monolith, a microservice strictly follows the Single Responsibility Principle (SRP) due to being tightly scoped around the business capability/domain for example Payment. Think of an MVC pattern-based API codebase where a controller and POJOs (Plain Old Java Objects) or POCOs (Plain Old C# Objects) were developed, build and deployed for just one single responsibility i.e. business capability. This microservice architecture will then lead to having many such projects and each business capability having its own database.

Microservice Pros:

• Easier Deployments: Monolith was deploying all or none. Microservice is a small service, the dev team has complete control on what needs to be deployed and leave another feature’s code untouched. I.e. if changes made in Payment service, only payment can be deployed. This was not possible with a monolith.
• Scalability: Being a small tightly scoped service design, it gives freedom and flexibility to scale whichever service you want. For example, if needed only Payment can be scaled up/down/out.
• Easier maintainability: Each microservice service is autonomous and so being small service it’s much easier to maintain than a monolith.
• Problem isolation: Each service has its own codebase and deployed in its own space. Hence, any problem with self or other services remains completely isolated.
• Single Responsibility: Single Responsibility Principle is at the core of microservice design. This drives all other goodness microservice architecture offers.
• Separation of Concern: Microservices architecture leads towards building tightly scoped services with distinct features having zero overlaps with other functions.
• Deep domain knowledge: Microservice encourages the product mindset and leads towards establishing deep domain knowledge with “you build it, you run it” mantra.

Microservice Cons:

• Cultural Changes: It requires a cultural shift and organizational alignment to adapt microservice architecture, and the organization will require a mature agile and DevOps culture. With a microservices based application, service team needs to be enabled to manage the entire lifecycle of a service. Read my article on STOSA (Single Team Owned Service Architecture)
• More Expensive: Microservice architecture leads to growing costs, as there are multiple services. Services will need to communicate with each other, resulting in a lot of remote calls. These remote calls result in higher costs associated with network latency and processing than with traditional monolith architecture.
• Complexity: Microservices architecture by nature has increased complexity over a monolith architecture. The complexity of a microservices-based application is directly correlated with the number of services involved, and a number of databases.
• Less Productivity: Microservice architecture is complex. Increased complexity impacts productivity and it starts falling. Microservice development team usually requires more time to collaborate, test, deploy and operationalize the service which certainly requires more time.

Summary

Microservice and monolith architecture, both have their pros and cons. Microservice architecture is not a silver bullet, but teams which aspire to be digitally transformed and writing services with a product mindset, microservice architecture is certainly worth consideration.

Podcast Transcript

Mario Gerard: Hello and welcome to the TPM podcast with your host Mario Gerard. Today, we are going to talk about microservices and the advantages of using them and the reason for the increased adoption. I have a very special guest with me Vidya Agarwal and he’s a renowned speaker and a published author, a Microsoft MVP, and an established professional in the area of building microservices. He’s currently working at T-Mobile as a principal architect. Would you like to quickly introduce yourself Vidya?

Vidya Agarwal: Oh, hi Mario. This is Vidya Agarwal. Thank you for having me. Really appreciate the opportunity to talk about microservices. You are doing awesome job in hosting these TPM podcasts, which is really contributing to the community. And I’m honored to be part of this as well. So as you have just briefly introduced me, I am working with T-Mobile for past two years, as a principal architect. There, I have owned various micro-service initiatives around payments and order management and many others. Recently, I moved to different team. Earlier I was working with B2C. Now I’m working with B2B and T-Mobile is really, really focused on the digital transformation, building a whole lot of microservices and being a principal architect, my responsibilities around aligning business reason and technical direction, preparing roadmaps, and making sure that technical teams are really delivering and aligning their solutions to those business guidelines and roadmaps. Awesome to be here.

Mario Gerard: Thank you. Thank you so much for being here. And when you talk about digital transformation, what does that actually mean for an enterprise like T-Mobile?

Vidya Agarwal: So for any enterprise, I think digital transformation has very specific things in it, regardless of what industry and what company somebody is with. So for example, specifically for T-Mobile, we are very large telecom company. We depend on so many backend systems. We have like more than three or four billing systems. There are multiple payment domains. There are address, customer, billing, shipping, and many others like any organization has. Since there are so many moving parts, it is very hard for any organization to really go and deliver things right on time and adhere to customer needs and meet what market wants at what time. So in order to meet the demand, the speed, the agility, and the value to deliver to customers, somebody needs to adopt two things. One is the agile mindset and the dev ops culture. So agile mindset and dev ops culture are the two key ingredients into the digital transformation. If a company is not really deploying their code very often, they are not having small code stack. They are holding long code life cycle like piling up code for months and weeks, having very largest sprints, very large teams working on models. Those organizations are not digitally transformed. Any organization who has digitally transformed themselves are the ones who adopted these two things. In addition to the learn, we need to break our capabilities aligned to business or the domains. So if there is one big monolith where you do billing, shipping, address, payment, everything in one, whole base, one application, you build it once, you deploy it once, you scale it once, you monitor it once, everything is that, and you are not adopting Devops culture as well. Then I do not think those organizations are really on the path to be digitally transformed. Those organizations who adopted it, they broken down these things into smaller services, which we are going to talk more in this podcast.

Mario Gerard: And, the reason I was thinking about this, the reason behind somebody’s trying to do this is bringing faster value to the end customer, right? Time to market is one. And then how quickly can you give the customer that value instead of saying, oh, it’s going to take me eight months to deliver this end value to the customer. Can I deliver it in smaller chunks like you mentioned, right? The agile manifesto and agile model of making sure the customer see incrementally small value in shorter periods of time, which then kind of culminates into a larger, big picture.

Vidya Agarwal: That’s right. That is where we have the MVP, minimum viable product.

Mario Gerard: So let’s get started. So what is a microservice in your opinion?

Vidya Agarwal: So there are so many different definitions. I will keep it very simple for the laymen’s perspective, how I see it. So before microservice there was monolith and monolith has the name says it’s one big, chunky, bulky thing. Microservice is breaking those monoliths apart into small autonomous services, which are aligned with the bounded context or the business capability, which can be built by one single team deployed by that same team. And it’s scaled by the same team and managed and operated by the same team. And that’s why for such teams, this team which does it is also known as a two pizza team. Which means that a small team is good enough in agile terminology or according to our daily standards, the team of seven to nine people, that team will build the microservice. That team will own the microservice. So if there is a payment and billing and one team owns just the billing and the other team owns just the payment,

Mario Gerard: How do you, you see the life cycle of these? Do you see them like making incremental changes over a period of like every, they’re there for like three years, the stream is always continuing to make incremental changes.

Vidya Agarwal: That’s right. Yes. And that’s why little bit, microservices are a little bit complex in a way. And the productivity for many organizations may go down and it’s bound to go down because there are so many moving parts. Since there is no one big monolith, you need to do a lot of things. Like you need to really collaborate over the communication and then the agile manifesto, you need to really look at the backlogs and many organizations like T-Mobile as well are going above and beyond agile. And now they are going behind safe, [06:22 inaudible]. Where you invite all the stakeholders, you get their confidence vote, Hey, you know what, I am building [06:28 inaudible] payment. We are looking for this feature to be delivered to our customers. Can you adhere to those things? Then they will say, okay, yes, we are ready for that or we are not, then you to do all this communication dance between various teams. And since there are so many moving parts, it is a little bit more complex, but if you do it right, it’s really fun. It’s amazing to work on microservices and get the value of it.

Mario Gerard: So I was thinking about why the technical program management role has kind of, I feel it’s increased the number of technical program managers needed in the market, it’s kind of gone up in the last five to six years. And one of the reasons I feel the core reasons is there’s so much communication now needed, right? And the communication is not just from a project management standpoint, it’s a little bit of technical communication of how my API functions or how somebody else’s API function. And then how do these upstream and downstream systems kind of interact. And I think that’s where the technical program managers kind of play a very vital role because, an end feature cannot be delivered unless there are seven or eight microservices teams, which kind of come together to deliver something at the very end. So that’s where I feel that technical program manager kind of plays a pivotal role in bringing that to life. So we spoke a little bit about microservices, and you said they’re smaller autonomous services and they’re tightly scoped. Can you give an example or elaborate a little bit about that?

Vidya Agarwal: So what happens is if you are having, you know, some services, which you need to build. So when you talk about like small and tightly scoped, loosely coupled Bounded context, what all these means are that whenever you look for any new feature coming out, any TPM or whoever is the owner of that or architect, so these roles really, you know, step onto each other foot here and there, but in my view, all are important and everybody’s doing great job out there. So the key is that somebody really needs to figure out where the bounded context is.

Mario Gerard: And what do you mean by bounded context?

Vidya Agarwal: Bounded context means the business capability. So for example, you are shipping something. Whenever you ship something, you need to do address verification. Now this address itself is a separate business capability. Does it mean now that shipping service should have the code of address validation or address validation by itself is a separate resource. So there are so many companies out there which actually has built services, which many companies procure have licenses for all to do that as validation. In T-Mobile we have a separate domain for that.

Mario Gerard: Okay. I think what tax as well, right? [09:16 inaudible]

Vidya Agarwal: There are many third party. Then you build your own abstraction on top of it. And then you cater the needs within the organization and enterprise to cater those needs that all various teams, which are doing the same stuff can utilize a funnel, their API calls to your API call. And then you go to the backend.

Mario Gerard: Okay. So there could be several microservices just to do something like shipping and they could be internal services. They could be external as well. So what are the advantages of microservices?

Vidya Agarwal: Well, as we learned so far and we discussed a couple of times already, that microservices has name also says they are so small. Since they are small in nature, it’s easy to deploy. Then the scalability is easy because you are just scaling something very small in size. Then maintainability is also advantage because you just focused only on one thing at a time, you are a two pizza team member. You only own your service. You just want to do that thing so right, that nothing falls apart. Now, problem isolation is another advantage. Now, whenever you do triaging, you run into issues. It’s very easy to identify which service is breaking. Now, another thing is single responsibility. That’s the key, separation of concern is another advantage. And then the team which owns whatever microservice, they are building really strong and deep domain knowledge around it. So these are some of the advantages of the teams and organizations, which has adopted microservices architecture.

Mario Gerard: When you say separation of concern, what do you mean by separation?

Vidya Agarwal: So separation of concern is actually achievable even in monolith as well. So to give you an example, let’s say I’m building a monolith, which could be, think of any MVC based architecture, Java spring boot, mvc.net, C-Sharp, whatever language you are using MVC is a standard industry pattern. Now let’s say I’m building customer there. Now, what will I do? I will have a customer controller and [11:24 inaudible] for the customer. And now I need to build address. Now I’m not going to put address there. If I do it, I am violating separation of concern. So what people do, they will build a separate controller and separate POJO POCO of the model classes for customer. I achieved it there also, but it is still monolith. However, it is physically, and the best way achieved in microservice architecture, because [11:51 inaudible] is even physically separated, that concern, which I had, for example, logging or address or security or whatever concern you have is completely separate in a different container or maybe a micro service, or maybe a Lambda function or serverless wherever you are deploying your services is completely and physically separated.

Mario Gerard: So we spoke a little bit about physical separation, right? So for people who are listening in, when we talk about physical separation, what I’d like to think about how I think about microservices, then it’s running on a set of VMs, which has a load balance in front of it, right? And then there are say five or six VMs might have auto scaling when there are more calls there, more VMs automatically deployed, or it could be a Lambda function, as you said, but you know, that particular code part just is there on those microservices. And there’s a separate microservice for something upstream or downstream from that. And that’s when you talk about separating where the problem is, it’s very easy for problem isolation that, oh, the tax service is not functioning properly or the shipping service is not functioning properly, which is why we are having a lot of lag in the entire you know, response time. Let’s take something very simple. If you think about something like creating an account in T-Mobile or any web servers, that flow that API flow, probably goes through four or five or six different microservices, right? So you might have something where your first account creation, if you think about it, there’s something taking in the customer’s username and the password and the email address. And then there’s one which creates the customer entity from there, right. There’s something which is then looking at the payment and making sure that the payment information, which is captured is correct there. So there are five or six different Microservices even for a very small piece of functionality, which people might think, oh, that’s just one, it could be four or five different microservices.

Vidya Agarwal: So in T-Mobile we call it customer journey or any website, let’s say you want to pay one time bill. In order to pay one time, bill, as you just clearly mentioned, there are multiple things you are doing. People who does not understand, they might think it’s a monolith or just one single thing. Which is not, actually behind the scenes it take multiple hops. Those multiple hops are actually happening in a synchronous , asynchronous as the design needed to multiple backend systems. So in order to search a customer, we have a separate customer domain. We make our call there. We search you first, who you are, whether you are in the system or not, same for any organization, once customer is found, then you look for the bill information. How much do you owe us? What is the minimum do? What is the current statement? What is the last statement balance and whatnot, then that call has been made and how our UI is, you know, rendering all that information behind the scenes. And then we take you to the payment information. And then there is a payment domain involved. And the payment microservice is called. Now in many organizations, there is one more thing which sits on top of microservices, many times to render your UI what you see, which is called experienced services. It’s called many people call it aggregator or in pattern terminology, it is also called a scatter and gather pattern. So what happen in that case is let’s say I am rendering your UI and I still need to find information from multiple domains, multiple backends. Now I’m fighting up two or three calls to render your screen in front of you, to Rendell the UI. How do I do it? Maybe backend is not talking the exact same thing back to me what UI wants to show to the customer.

Mario Gerard: Because UI, just thinking about the UI, UI might have the customer name, which is populated because I’m just giving my, see I’m giving my customer ID, or when I’m doing a onetime payment, the customer name has populated. The customer phone number is populated there. Then the amount he owes is populated, and then it asks me for some kind of tax ID. So all of these are different services and it’s kind of aggregating.

Vidya Agarwal: That’s right. So from your UI, your call goes to the proxy. It could be any API gateway. And the load balancer as you called out. And then it goes to an experience service, which is an aggregator, which is another micro service hosted in a container or wherever you are deploying it as per your industry and organization standards and technical roadmap. And then it goes out and scatter through multiple domains asynchronously, gather all the information, do all the massaging and scrubbing as needed, and then send it back to the UI. But all these things in today’s world, most of the organizations are, you know gravitated towards two second rule. Within two seconds they want something to pop up on the screen. Many times. It’s not possible that you get everything in two seconds, but the key here is in two seconds, if you are not able to render the screen, you need to give some talking points back on the UI, to the customer. That what exactly is going on. For example, please hang on. We are processing your payment. Something like that. So this scatter and gather pattern will get all the data back and beautifully render on your UI. And you will say, oh, was there one call behind it. Or there were multiple calls behind it. It’s all black box for people out there. But when we are building it, there are so much stuff happening behind the scenes.

Mario Gerard: Yeah. And you were talking a little bit about synchronous versus asynchronous, right? Where would you use synchronous calling versus the asynchronous calling?

Vidya Agarwal: So think about it this way.

Mario Gerard: Let’s define that.

Vidya Agarwal: Let’s define it first. Synchronous means when your thread is locked until the response has been received from the backend.

Mario Gerard: So the next call is not made.

Vidya Agarwal: Next call cannot be made until this call has been resolved. You are in lock estate. Asynchronous is more like fire and forget. So whenever response will come back, it will just come back. But you don’t worry about it. Yeah. Now, since you asked for an example, let me give a one real world scenario of synchronous. Let’s say I am paying a bike credit card to any company, every company which is running credit card payments or any sort of payment, call it, any XYZ company on this planet earth. They all have some sort of fraud system in the backend. There’s always fraud system sitting out there, even though you are buying stuff daily, your credit cards are stored in your Ewallet and whatnot is still there. Our fraud systems, whenever a fraud system will trigger something, it is synchronous. The moment you punched your credit card information, and you say, okay, I don’t know, or checkout or whatever you do, the fraud system will lock in. And now that transaction is synchronous. There is no way your order can be processed. And then goes to the order confirmation page.

Mario Gerard: Without the fraud system saying yes.

Vidya Agarwal: Yes, exactly. So now you are in that logged state, nothing else can happen. And many times what happens when you receive the order confirmation that not necessarily mean that order system received your order.

Mario Gerard: Interesting.

Vidya Agarwal: What happens many times is since your payment processed inventory check also happened at the same time. That is another synchronous call. Before I’m placing an order, I want to check the inventory. Does Inventory has that? T-Mobile has its own standards to make sure how many items I need in an inventory even though you are buying just one. We have our own standards defined same as for every organization. That is another synchronous call. Because unless you really logged it and checked it, I cannot place your order right here. So that call is made in case of fraud is logged, it’s a synchronous thing until fraud resolved it either say yes, green light, you are good to go. Or they say, no, you are not a good person. This credit card cannot be processed. You are blacklisted candidate for whatever reason.

Mario Gerard: Or actual fraud that somebody else is using, making a purchase from France, for example, and this credit card has never made a purchase in France. So then it gets locked. So that’s interesting. So that’s a difference between synchronous and asynchronous communication.

Vidya Agarwal: Both has their own importance at times. And that’s why these TPMS, when they do technical spec, architects, all these people need to be cognizant and aware of which one will benefit more to the company. And it’s not that there is Asynchronous, so we do not need synchronous. Both has its own importance. Values based on what customer journey and flow and technical problem you are trying to solve.

Mario Gerard: And that’s all right. Sometimes you place an order, you get an order confirmation, but after like five minutes or seven minutes, you might get another email saying, Hey, sorry, we could not process your order.

Vidya Agarwal: That happened with me as well, many time you are right. Just exactly, there you go. So many companies who doesn’t want to do that, you have to really make that call synchronous. But the disadvantage of synchronous calls is since your [20:46 inaudible] is logged, customer is waiting on something to hear back from you. Because you are making calls until first call is resolved, other call cannot go. So there are pros and cons.

Mario Gerard: Sometimes they just say, Hey, 99% of our calls get accepted. So there’s a customer, let’s give a customer message on the screen saying order has been placed. But that 1% of calls where there is some problem, either you have the fraud check failing or the billing method is not accepted, then we’ll get back to the customer and say, Hey, order is non-processed. Please try again after some time or something like that. So interesting. So let’s talk a little bit about monolithic applications versus microservices, right. Monolithic applications, I think we’re kind of the standard up to like what five, seven years ago, or like when do you think, monoliths are still there?

Vidya Agarwal: Still there, It’s still there. I don’t think it is going to retire soon in the near time. The reason is because as you initially, when we started this conversation, you may ask them about digital transformation. So not every company is ready or really looking forward, or it’s not in their roadmap at all to really digitally transform. And if your businesses is really excelling, doing well with monolith and you are managing it well and all that stuff, need to not have those many complicated domains, moving parts and all these things that I think that company is fine. But in order to be really, you know, match your footsteps without industry where technology is growing, where IT industry’s leading towards, then the sooner you come out of that shell and really start migrating your monolith slowly into microservices is better. The longer you hold this adoption, the more troubles and the problems will come because you are continuously adding new stuff to your monolith as well to keep it, you know, keep it functional and serving the business needs. Now that’s why there are some guidelines as well that, many times why organizations do not do it. Because not many people understand how to really transform from monolith to microservice. What they think is they think it’s one tall order. One fine day we have to fall everything apart. We have to stop our services and we go monolith to microservice. This is not the right strategy to do it. The adoption of microservices from monolith has to be very strategic. And that can happen with something that you pick one service, maybe your lowest priority service. Call it, Let’s say address validation service, right. People know their address. It’s very rare somebody can, you know, mistype, things can happen. Whatever service is low priority for you. I’m sure every organization knows their priority list for the API is they have. Pick the lowest priority service and then take that code base out as in monolith, I was talking earlier to you about the MVC controllers you have. Take just that controller, those POJO, POCO whatever model classes you have out, and then put it in a separate code base altogether and start including the dependencies which you have from the monolith. Refer to those dependencies, take this code base out. Fine tune it as per the new technology stack you might have chosen to build microservices. For example, if you are on Java, it could be spring boot. If you are on Microsoft, it could be service fabric. All of these are very cool niche areas and platforms which are catching the needs of all the microservice needs. Now just take this thing as a microservice, start building it, set up a small team, which has the agile mindset and devops culture and build around it and then see how functional it is. If it works fine, all your test cases are passing. All these things look good. Just change the end point to this one and then slowly start transforming the next service and then next service. So the approach industry needs to take, or the organizations who are not there yet needs to take is crawl, walk, and run.

Mario Gerard: Don’t try to do it all.

Vidya Agarwal: Don’t try to do it all together. That’s the best suggestion I can make for any company who is not doing it. And my recommendation would be the sooner they start adopting it. It’s better.

Mario Gerard: Yeah, no, I was part of an organization which like most organizations had a very big monolithic application and then they wanted to launch mobile apps for their customers. And when they tried to start doing that, right, they’re like, well, mobile applications, mobile apps don’t work very well with monolithic applications. They all has to be kind of microservice based. So they took that as a primary use case and then slowly took out pieces and started doing microservices for each of those pieces. But this involves two changes, right? One is going from monolithic application onto a Microservice based architecture, but it also requires a lot of people

Changes. Right.

Vidya Agarwal: So it’s a cultural change. Unless that was the next thing as you brought it. Thank you so much for that. So it’s a culture shift. If your organization does not have that culture shift, there is no way you can do digital transformation where microservices just one player into it.

Mario Gerard: And when you’re talking about culture and shift, right. A dev team now creates, owns, and operates that particular microservice. They have to be on call.

Vidya Agarwal: Yes. So it is, there is a thing they call it like we build it, we own it. So, different mindset altogether.

Mario Gerard: Monolithic applications in general have an ops team sitting somewhere, which actually there’s actually a deployment team first. Which would actually deploys a code, which gets and tests and deploys the code. Then there’s a team which actually separate team, which actually operates when there’s a problem with a server, like adding a new server, all that is manually done. And now all that is kind of gone with microservices. So it’s an interesting shift. What else do we need to talk about from monolithic applications versus Microservice standpoint?

Vidya Agarwal: Other thing is like most of our organizations have monoliths as we were talking about the customer and billing and all these things. What happened in those cases is that where this information is living, all this information is somehow stored in some sort of relational or non-relational databases, right? So in those cases for monoliths, usually 99% time, there’ll be only one single database, like one large relational database, call it Oracle, SQL, whatever you have of that organization’s choice based on technology stack. That database will be one bulky monolith database as well, which is hosting all the tables, which has relationship primary key, foreign key, all that good stuff, stored procedures, triggers, and whatnot. And then housing all those schemas of the entire application in one single database. Whereas with Microservice, since we did bounded context, based on the business capability, we are dividing and conquering. What happens in that case is every responsibility has its own database. If you see, there is no primary key and foreign key relationship. Because, and mostly in such cases, all the databases are No-SQL as well. Or there are relational as well, in T-Mobile we have both relational as well and then non-relational as well, we call it No-SQL, right? So in that case, it is every domain, or every business capability will have its own database that is aligned with just one single microservice. So if we are talking about payment for example, then there’ll be a separate database for payment, which has no primary key foreign key established with billing and billing has its own set of services. We collectively call it microservice, which has its own database. And it has no primary key, foreign key going in and out to payment. However, at any given time payment cannot be successful without billing because billing knows how much to bill and what payment needs to be collected. So these two things will be now talking based on the event. So there will be a publishing and subscriber model or some sort of message queuing happening between these systems. They talk to each other based on the events published.

Mario Gerard: And you spoke, as we are talking so much about microservices with the advent of microservices, there’s been a lot of use of queuing methodologies, right? Like Kafka or streaming methodologies, why is it so important?

Vidya Agarwal: In T-Mobile as well. And many of the companies just call out Kafka. So Kafka is same thing, you know, it’s the based on the messages, based on the events. So think about it this way. So rather than going into too much detail, I will just introduce or share one more architecture pattern, which is very, very prominent in microservice architecture, it is called at CQRS. CQRS stands for command, query, responsibility, segregation pattern. Now what does it mean? That means is separating even the responsibilities of command and query with two different systems. Now what is command? In terms of CRUD, Create, read, update, delete. These are the operations. Since we are talking about microservices, rest architecture, [30:18 inaudible], Get, post, put, delete, map all these things to [30:24 inaudible], you will know what we are talking about. In this case what happens is, if you are creating a new customer each time, and then you are reading the information of that customer or the other customer from that same database, then your architecture is not right. It’s not a scalable. So what even in T-Mobile and many organizations adopted the pattern, especially with microservice and digital transformation and all that good stuff out there is they adopted CQRS, once again, command query responsibility segregation. In this case, what happens is you have a schema to write the customer information into the database. Now think about it. What you are writing may not be necessarily given back to the customers of your backend to read that information. Maybe you are writing [31:15 inaudible]. But are you giving it back as a[31:18 inaudible] every time, maybe not. So many times industry observed, and all these technological leaders observed that what we are writing is not necessarily being read all the time. That is first thing, means schema could be different. But when you are housing these things in one database, there is no way schema could be different. Only your API contact will define get and post what you are posting, what you are getting. Besides load, the scalability is another concern. You are, sometimes in some situations you are writing more. Think about the apple launch with T-Mobile. In those days, we were searching from the product catalog, checking the inventory, and processing payment. Nobody asked changed my address, change my line, add a new service. That was not the workload for us in those days or that night. You understand what I mean? So many times people think, okay, how do we scale it? When we are scaling it, let keep the read and that command, which is create, update, and delete separately. And in many cases, schema could be separate. Let’s talk about schema separate or does not, it’s not separate, doesn’t matter. Let’s disregard that for now. Coming back to the point, how do they communicate now? So what happened in this case as you said, Kafka, there are event mechanisms established. We call it event sourcing. Event sourcing what it does. It also call it pub sub, or publisher and subscriber model. So what will happen is the moment our customer is returning to the database, it will publish an event. I received a new customer, customer ID is this, this, this whatever. And then it will publish some information. Now, since it is publishing, it will have some subscribers which will subscribe to that event. Now this is the CQRS pattern. So the database schema and the API set, which was only posting and doing the command responsibility is publishing. And the read instance of the database is subscribing to this and it will read it within seconds. The moment you create it within few milliseconds, the same customer will be found in the read replica of the database. And now the API to get that is going to a different database. In T-Mobile we have billing domain. There are multiple billing domains that we have for prepaid, postpaid. There are multiple for prepaid, multiple for postpaid. Now all these things, we are heavily dependent on such, Kafka, event messaging, and all these things are taking place in [33:47 inaudible]. Not only among billing CQRS, there are other customers also, which are looking for the same information so they can adopt it. Think about billing and payment. So how do they communicate with each other? So all these things also can take place using these events.

Mario Gerard: And I’m thinking like supposing a new customer screen, then we want to send a marketing message to them, right. You understand that your SMS, for example, your welcome, your new customer, a new line has been added. Notification services.

Vidya Agarwal: So the moment notification service is subscribed to your event messaging to your publisher. Now they will bring the information, wrap it up in the notification service and you will get either an email or SMS.

Mario Gerard: So there are a lot of people who are reading from that que and then saying, what do I need to do based on this event. So the queuing services are now kind of an important component of Microservice, the Microservice patterns.

Vidya Agarwal: It is, it depends on how complicated and how elegant you want to make it, think about it. Like there is no need to be CQRS, but if you really want to be that elegant and adhere and align with the top notch microservice architecture patterns, then it is advisable to go behind CQRS. But if you are not doing it, you are still fine. Exactly. You are still fine. You may evolve, because there is no such thing of architecture now, the new thing is coming now, evolutionary architecture, because it’s so hard to achieve [35:19 inaudible] architecture. You are always moving towards north star. So organizations are evolving. So it’s hard to log on one architecture. Your roadmap is always under development. You’re always looking for new things. So in that case, you can do it later, but that’s not the end of the word as you said, if you’re not doing it.

Mario Gerard: And it’s kind of the I trader development model, right. Let’s try to get something out soon rather than make it 100% the best architecture, let’s create the microservice first maybe. Let’s after that, let’s introduce a quick queuing mechanism. Let’s make my database more scalable. Let’s add caching for example, or do all those kinds of things, I think is one step at a time.

Vidya Agarwal: One step as we just discussed, like crawl, walk and run. If you try to boil the ocean, that will fall apart.

Mario Gerard: Hi everyone. I hope you enjoyed the part one of the three part podcast on microservices with Vidya. I’ve added a link of Vaidya’s’ LinkedIn profile on my website, www.mariogerard.com. You can click on the podcast section and that’ll take you to the webpage. The webpage also has several diagrams drawn by Vidya himself and links to several other articles he’s written. Don’t forget to listen to part two and three of this podcast. So stay tuned. The part two and three of the podcasts are also live. See you on the other side.