Okay, I think we are live. It says, we are over here. It shouldn't happen like last time. We thought we were live, but we weren't live on YouTube for some reason. either way. So hello and welcome to Momentum Office Hours. My name is Yash and I'm joined by my co -founders, Harsh, Jay and Koushik. To discuss the topic of the week.
which is monolithic versus microservices architecture. I hope I said that correctly. Our goal is to provide you with actionable insights and practical strategies that you can apply to your own products. Throughout the session, we encourage you to ask questions and share your thoughts. This is a fantastic opportunity to learn from each other and give new insights and help drive your SaaS initiatives forward as well. So let's get started. Jay, Harsh, Koushik, how are things going?
Going great. Right in the middle of the week, just finishing up with meetings and planning to the next ones. Going ahead with the flow and then we have the podcast schedule. So quite occupied in that. then coming to office hours, it's an interesting topic. To be very honest, little techie from my point of view. And it's interesting. Have some questions from my side, but I would like others to get started.
So, needless to say, today none of the three of us understand this topic enough to be able to say anything. So, will have to take the lead on this one. So, let's start with the basic one. What is, like the basic and the only question that we are qualified to ask, which is is monolithic architecture and then what is microservices architecture? Like why do we need to talk
Like why is this simple? Like can't I just have simple architecture? Yeah, so if you know architecture as a simple architecture, it is a monolithic architecture. so architecture is a monolithic architecture. So you just took the simple as a word and then made it complicated. Not me. Correct.
So we can say if you want to build any product, we have many applications. So there are different type of components, modules, If we combine all these things in one product, then we build one product. In monolithic, all these components, functions, modules, they are interconnected with each other. And we can say they all are in only one server. So we can say in one module.
all these modules or components are combined and there is a one big modular component and all things are you know only one server this is known as a monolithic when they interconnected with each other where in monolithic where in microservices all these components are independent with each other and they are working very differently with each other and if they want to communicate with each other
we can say there is an API or GLSK right so in this way they do communicate with each other so we can say I will give example you can get an answer like we can say we can take example we have Amazon Amazon right Amazon e -commerce website where they have a search they have listing of all the products right we have a search where you can search like F140 pro
So, all these things are small core component and where all these components are
So when I say interconnected, so what is the meaning of interconnected? So in this way, all these things have the same code base. They have same text tag. They have one repository for all these things. And when all these are interconnected with this, and so this is one of the monosynchronic architecture.
Yeah, if I'm understanding it correctly, with respect to what example you stated with e -commerce platform, does that mean that if they have microservices architecture as an example, they can just optimize or scale it payment processing services independently without even changing anything in product catalog services or any other module in itself? Yeah, so CCL is one of the advantages, right? With the scalability, right?
Yeah, so tell you, so I tell you Amazon inventory management, invoice management, product management, can say the notification right, where is my order of this thing. Here are the small modules. Now just consider I want to improve my listing page, you can say the inventory page right, where Amazon stores all the products. Now if I want to optimize, so you can say scale right, if I want to scale this thing right,
So for that if all these components are interconnected, right? So if I scale, like the, you can say I have some small things, right? And then I, this is my big issue, right? So all these things automatically become the last. There is a whole requirement only for the inventory, you can say this thing. I don't want to scale for my, you can say the, you know, management or not, they are perfectly fine. So,
So in monology there is a disadvantage. If you want to scale any one module or we can say the one function, it can't proceed by monology. If we scale down, that whole application becomes a scale. So this is one of the advantage, we can say the same advantage we have in microservice. Now this is how I tell you, so in monology all these are
in microservice what we can do we divide these components or modules in the different we can say the category where they have different text rate they have different on database they have different servers like the product lifting right they have different database right they have different server now if you want you can buy anything right and after there is a invoice management, booking management so there is a different server database
and then we can say notification there is a different server or database. Now, if I know that there are if suppose like Black Friday, where they have high traffic on my own listing page, right? But my you can see the shipping and the notification services working fine in high -end. If I want to scale, I just need to increase my inventory management database or server on a high scale. So then from this way we can
can say we can, if we have high target then our service are scalable but we don't need to scale our different modules for different service like the invoice or we can say no safety. So here is an analogy and tell me if this is a good way to sort of think about it. So as an example, all humans, all people or all animals are monolithic architecture
as and when they grow, they scale at the same rate. However, like if you think about Dr. Reed Richards, which is like one of the characters in Fantastic Four, who's like the elastic man. So if he wanted to catch the bad guy, he'd be able to grow his arms really, he'll be able to grow his arms or legs or neck, depending on the bad guy that he wanted to catch.
Like is that microservices? so. A very poor analogy, but is that like for non -tech simple people like us, is that a good way to think that I'll be able to scale a particular part of my application disproportionately with others if need be? Yeah, right. So yeah, so the example will be, we can say not 100%, but 50%, it's like, the example you said, there is a woman body,
So why is there requirement for an app to scale different parts of itself?
in like at a different proportion, right? So, as an example, if I have like 1000 users who are using five features of my application, why, mean, if those 1000 users become 10 ,000 users, won't they be using like all of my apps, so like all of my app needs to scale to 10x, why would disproportionate scaling be a requirement? Yeah, so I tell you,
Let's talk about FIFA World Cup. That's a more global.
They are live streaming of the football match. So there are two components. First is where J &K is the list of matches. are currently or we can say upcoming matches. Now think is the traffic that we are getting in the list of matches. Where you can say what are the scores currently, what are the upcoming matches. And the traffic which we get on the live streaming.
Both are very different. Now, can say, now especially there are those here who are live, they are watching live stream of football match. 20 million people who are watching. 20 million people are watching the live stream on the 25x. So these people are not coming to
We can say the listing page where they can just bring up history or upcoming images, right? So we don't need to We don't need now We can say the same traffic There is a different traffic, right? Now we can say that this should be one to now This why we need that right? So I just consider our history
It is divided into two things, the listing and the live streaming. Now even if on listing page there is very small traffic, but because of I can't be posting it, I have to increase my server or some capacity. So I have to pay X amount for that service. Now just consider if I divide this service into two components, one is the listing and other is the service.
If I maintain the requirements for the listing and streaming, it is different. So in this case the force is very low because even if traffic is increasing, I just have to increase my scalability on the streaming server, not the listing server. So I can say that the force of the streaming server is low. The streaming will be high but it is overall lesser than if I have only one server.
who have both the in one setup. So these are also the differences. Now according to use case, now if I have live stream, so what is the best technology that I can use? The lower desk is the best thing in the software and it is good for the live stream. If we talk about the listing.
So we can say the Python or Django is good for the listing. But if I have microservice architecture with the two modes are different, so I can use different text text, different database. But if there is only one server, then I have to fix, either I have to use more text or the Python. So according to my disk case or the features, if I want to change my text text or database, then it can only be possible with Microflash.
So here is another like, so am given that I am a mechanical engineer, I sort of try and find analogies in that space to understand it a little better. So this is like a classic challenge with assembly lines as well, right? So as an example, let's say if there is an assembly line to assemble an iPhone, if it takes two minutes to put on the camera, but five minutes to put on the chip, then what you would want to
is you want to have two stations that are putting in the chip and one station that is putting in the camera and then that's just diverting the traffic. So like in a way and then you can essentially make sure that there are no bottlenecks and that you don't have to, you can scale one component fairly independently than the other component as well and at times when there are peak traffic or at times
in a very short amount of time, a large number of people are going to be joining in, you will still be able to manage that. Then, like the next question that I have that I want to understand from you is, is that, I assuming that when most people start to build their product, they start by building it as monolithic, because it is simple. At what point do you consider, like at what metric needs to happen, what event needs to happen that should trigger the change of going from monolithic to a microservices?
architecture.
that I'm using our platform. And now we can say that at that time my CPU was sort of we can say there are only two RAM GB, right, two RAM. They are handled by 1000 users. Now, once the product grow, right, the classic will be I said like from 1000 to we can say that the continuum is just of users, right, they are already using the platform. So for that if I want
If I want my product is stable right, I have to increase my server. There will be 4 jb. Now again the traffic will be high and I have to increase 4 to 6. There is a horizontal scaling right. 2 to 4, 4 to 6, 6 to 8. It will have a very high cost. Once you know
This is my some limit of course. I cannot go above this course. So this is one type of problem. Now this is a course. Now I have to divide in such a way that course will be decreased because once product will go right, it's not likely we have 10 modules and all these 10 modules have the same traffic, all have the same users. There are some of two things.
very important for product. Mostly users are using that yeah, some of the service then for the service we are we have high cost. So in this way if we move from the main components. So in this way we can divide the modality to two or three services. And for environment we have to identify which service is best to move out from the modality.
whether it is mostly or not. So first is the scalability. Once we know there is a high level, we can go. Second thing is the flexibility. Now, if we start a model, we have to decide one text type, like the node .js or Python, Now, have a new feature is coming. We have changed the proposal.
that we allow multiple users. Now we know if you want to implement this, then this is a text tag, this is the best for that. I can't use the same text tag because they don't have good capability to handle this type of traffic. If we know this, if we have this type of resources, know this text tag for database, it is the best for this case.
we have to move from one edge to other side. So second is the flexibility. Third is the maintainability. We can say we have around 10 people in my team. Everyone is in one module. Now, if one wants to deploy some
new changes on production. At the same time also the team 2 also different there all the changes on the production. So, now the two members are going to deploy the different things on the production. If we have one server then we have to maintain whether this changes one or not affected changes two. So, if we know if this maintain it
If the cost of the maintain is very high, we can say because of we have to maintain our product is not breakdown. So then we have to do so much thought testing. It will take too much time. In here time we know now it's time to move from logic to micro service. Then we divide the response with it. Then so that every module or everything can deploy their core on their website or have to think about how if I can.
So, now most product flow right, we can say if there are few changes are different products right, then because of that we can say whole application is breakdown. Now, we can take
like the inclined or whatever product right. What is the main thing is sign up login will be always you work it right. Even if something is happened but user can do the sign up if there is monolithic right and if you can say because of some changes in payment module or efficacy breakdown. Now, it goes to my research stuff right because my authorisation my sign up login module is also down.
Now it is critical to get the lead as you sign up even if my application is down. At JTM we have to divide our app like we can say authorization module is different for the application. So that even if there are we deploy anything our application both module is working fine. So that we can get the lead. So there are four things that mainly we can say like
This is one of we have to decide which characteristics is important for us and for that we have to and when we reach when we know this is a very important characteristic for us, at that time we have to move from monolithic to macro -saturnic. So does that mean like is it possible to have one set that is monoplethic a hybrid of both? Is that even
have a monolithic and a microservices. think hybrid of both by definition is microservices. As soon as you have one component that is out of the monolith, it becomes a dualith or within microservices by definition I think. again that's a guess.
I have divided my authorization modules from the application. So you can say now I have the Microsoft architecture where authorization have Microsoft architecture but still my application is monolithic. So in my application there are still so many components they are interconnected. Yeah. One thing to add on this Harsh, you mentioned with respect to an example there, know that certain basic
like sign up and login are going to be here. Those things should not get down when we are deploying certain features. So does it mean that even incorporating microservices architecture inside the product would also reduce the downtime while implementing new deployment? So for example, let's say a product is having 11 modules out of which just one or two modules are getting new updates. So you know deployment of those modules would not affect any other module. Then let's also the
downtime which occurs because of the new deployment that is also reduced because of this. Yeah, so we can somehow it will impact but there is not very much impact because the deployment timing right is not that much depend on the microservices. If we deploy using the other there are different we can say the methods such as the blue -green architecture or general we have some automated if we use this.
the only tool for deployment, then we already get the zero downtime. You can say if I have monolithic architecture and I want to deploy something on products, there are few changes because of in monosil architecture all application is deployed again, not only small changes. So, we can say it will take two minutes to deploy the whole application even if there are only few changes. But in
So we can say the timing of deployment can be reduced by using the micro service.
which you mentioned, it's going to shift to microservices, right? So just from team point of view, let's say they reach to anywhere between 25 to 50 people of development team. And now they want to move to microservices architecture. How does adapting to this microservice architecture affect team organization and overall productivity?
Yeah, so we can say even if even in monolithic already things are divided by using the modules. Right. So for team wise it's somehow is difficult because we can say accuracy is different. Right. But once we decide the monolithic to accuracy, then if the exercise will be changed, right, then it is difficult for team to learn the new language and other things.
Yeah, and still, even if we move from Microsoft, right, then we have to use so many other services, right? Just like the currently if there are monolithic, right, if they want to send the data from one module to another module, right, there is a simple function calling. Right? Once we divide the microservice, right, thereafter, there are two different components. If there was two intercoms, they would be each
Then they have some API right when they can transfer the data. So team has to build this API. So in this way, you can say the team has to learn, but team have to develop, do so many changes to move from monolithic to macro architect. And so typically how long does it take to move from monolithic to microservice architecture? And who does that like in a team?
that has full stack engineers, front end engineers, DevOps people, product managers, project managers. I'm assuming product and project managers don't know that. But like who does that activity? So we can say if once we said, right, now we want to move from, we want to Microsoft, right? So we can say first architecture is one, we can create the architecture. See we charge the services.
it can be more and it's not like there are services, less more 10 services, less convert all the services to one, one time. Right? Now what are the, we can say, less impact services, right? Because if you want to move, right? Then it is also one type, we can say, we are doing testing, right?
the moving of moving from Microsoft architecture right. So this particular service, the architecture which we are following is correct or not. Because in microservices there are in Microsoft also we have different services. Whether there is server or we can say server electric or not. Whether you have to use lambda for the NK calling or not. So we don't know. So what we can
What we follow is what are the list of important service in our product. We have to identify this service and then after how we can move this architect, move this service from our main code base and once we want to move right and then we have to see in future which tag tag we want to use, which database we want to use because previously possible we are using a relation database.
But now because of so many changes, it's good to move from MySQL to the NoSQL. So this type of decision has to be taken when we move from microservices. Sounds like a long and a collaborative exercise that is not going to lead us to build new features.
But one thing that I found very exciting, I mean I found very interesting based on what Ash mentioned was that each module based on what is the most efficient tech stack for it, you take that and you implement that. But that also wouldn't it bring, that is a great part of the account, there is a layer of complexity that comes up with that. Wouldn't each tech stack have its own set of ways to deal with it? For example, debugging will be very different.
from one text track to other text tracks. So how do you manage this complexity level when it comes to this? So, the best way is to hire the best one. Hire people who have done this before. that's I think a way to think about it.
Yeah, and other thing is always each language extract have their own prompts. So that's why it's not likely when we decide that we want to we want to distribute and we say, I want to convert this module to mycology. So there must be some reason. So there is some problems which I facing. That's why I want to move.
My chat is not working fine. This is one problem. How I fix that? What are the best technology that I can use to fix that? Then after I decide, Python, Node, these are all available. What is the best thing I can decide? Then after we will, even after we sign the language, is the same thing which you also have to follow for database too. If database is correct,
for my use case. In this way we can decide which tech tech or the database is perfect for my microservices. So I think, think, think Koushik, like again a very inaccurate maybe need to think about it is, is that it's like, it's like how many knives should you have in your kitchen, right? It depends on the scale of the kitchen. So if I'm cooking for
probably one or two knives are okay. But if I am cooking for like 150 people, then I need to have six different knives. So, say one knife which is used to cut vegetables, another one that is used to cut meat, another one that is used to cut fish specifically and stuff like that. So, probably these are certain and so if you are running a kitchen that serves 150 people and if you have two knives, then you know that you will run into trouble.
cut will not be fast enough, will not be fine enough, will not be good enough and I think it adds complexity for sure because there will be some knives that are you know that evening no one walked into the restaurant and ordered fish so that knife is just laying there on the kitchen counter but that's okay because there will come an evening when everyone will come in and order fish and so I think but what interesting here that
I think this was a great conversation. Thank you Harsh for coming in and talking about monolithic and microservices architecture. This was a good chat and thank you everyone for joining in while the session was live. If you liked the conversation that we were having and would like to see more, let us know. We do this on every Wednesday in the evening.
And if you have a specific topic that you'd like us to cover, know, Koushik is our head of design, Jay is our head of growth, Harsh is our head of engineering. And so across the whole product life cycle, we'd be happy to sort of have a conversation and talk about it. And you can join us, ask questions in the comments and things like that. Well, thank you everyone for joining in. And until next time, see you soon. Bye -bye. Bye.
.svg){kind=small}
.png)
