Hey everyone. I hope y'all are having a wonderful conference at con 42 Machine Learning 2025. My name is Asif Mabu, and today I'd like to talk to you about a topic which has kept me awake quite a few times at night, especially when designing new applications. And that is the decision to choose between which architecture is right for the application that I'm currently building. Whether to go with microservices or to go with monoliths, the decision between this monolithic or microservices architecture is a really critical one because whatever you decide with, you get stuck with it for a long time. And changing the architecture at a later time is not always a straightforward one. This decision early on is what shapes the future of your application. In this presentation we'll we'll explore how each approach impacts key factors like scalability, performance, the efficiency to help you make the optimal choice. This slide illustrates the contrast between between the two. Monolith is a single unified structure versus microservices are distributed modular components. And understanding the trade-offs between these two architectural types is what is going to be crucial for your application and selecting that right fit is really important. So what is this software architecture dilemma, and why is it so critical? It's because once you decide on an architecture and you move forward with that architecture, it becomes really difficult to switch lanes at a later time. It's not as easy as just replacing a function or replacing a piece of code within your application. It's it's something much bigger than that, and more often than not, it'll be a rebuild from scratch if you want to change the architecture of your of your application. So the software architecture Choice is a critical foundation decision that will impact the entire development process going forward. It and the right architecture can enable scalability and business agility as your product and company grows. However, this architecture, it also affects your long-term maintenance costs and your technical debt. So it's really important that you choose wisely and ultimately your architectural decision. It needs to support your strategic goals and the market responsiveness for the business to succeed. So now that we've heard the two terms that we are discussing over here, let's like break that down and see what each of them means. So what is a monolithic architecture? A monolithic architecture refers to a single unified application where all of your components everything lives within one code base. Components in a monolith are tightly coupled, which means that they are directly interacting with shared memory and resources. The entire monolithic application is deployed as a single unit. Now this architectural approach has of course some advantages, otherwise it wouldn't really be used. Simplicity of development, simplicity of deployment. However as your application grows it becomes more complex to scale this kind of an architecture. And then in comparison, we have the microservices architecture. In this architecture, your approach when you're building your applications is to build them as a collection of small but independent services, right? Each service is focused on a specific business function or capability, and the communicate with each other through well-defined APIs. This allows for decentralized data model where each service maintains its own database. Thereby reducing dependencies between services the whole independent and modular nature of microservices makes it easier to develop, deploy, and scale individual components as your application grows. Now this architectural style, it promotes flexibility, scalability, and resilience of your software systems. Think of microservices, architecture as service oriented architecture done right. So let's summarize that, what are the core differences between your monolith versus microservices architecture? The key differences between these two architectural styles are what on the slide. On the left, we have the characteristics of the monolithic approach. Centralized code base, unified deployment, shared database direct function calls, and a single technology stack. In contrast, we have the microservices architecture on the right. It is basically distributed with independent service deployment separate databases per service, API or network communication and the ability to use different technologies for each service. These fundamental differences in architecture have. Significant implications on your application, scalability, its flexibility and long-term maintainability. And we'll explore all of that in in the presentation further. So let's look at some of the pros and cons of of the two different architectural styles. So the pros of monolith simplicity and speed. Direct function calls between your components that eliminates network overhead which in turn makes your communication really fast. Debugging is simpler. Since you can trace execution flow through a single code base. Initial development is quicker with less infrastructure complexity to set it up. And using a single technology stack means a simpler tool chain with fewer tools for developers to learn and manage. Now some of the cons of this like we spoke about, it limits your flexibility, right? So they often have tight coupling between your components, which, in turn like I said, limits flexibility and makes it difficult to make changes without impacting the entire system. Scaling a monolith can be really challenging as I've seen multiple times in my career. Because you have to scale the entire application, even if a small part of your application is what is experiencing the bottleneck, you'll have to scale the entire application to, to scale that particular component. And as a monolith application grows over time, the code base can become increasingly complex increasingly unwieldy, and therefore it makes maintainability a challenge as your code base grows. Now for the pros and cons of the microservices architecture pros scalability, agility, right? Microservices. It allows us to scale individual services independently rather than scaling the entire application. So this gives us much more control over what our infrastructure needs are and what the costs are going to be. Each mi microservice can be deployed independently, and it does not affect the rest of the application as long as your contracts between those services remains the same. So this enables us to release new features and updates much more quickly and much more frequently. With microservices, we have the flexibility to choose the best programming language, the best frameworks, and the best tools for each individual services. You want to do something in Python do that. You want another portion written in rust or go for it. You want something in do net you're free to use that, best tools for the job is what microservices enables. So this allows us to optimize for performance. It optimizes the developer's productivity and also other specific needs of the application. Microservices also enables a high degree of team autonomy, so different teams can work independently on different services without having to coordinate extensively between each other, right? As you saw with monolith architectures, that is a channel challenge with that architectural style. It's not all hunky dory when it comes to microservices either. There's cons on that too. Mostly around complexity and overhead. It can introduce a lot of complexity in managing the the coordination between your different services. Running more services means, you need more infrastructure your operational costs to maintain those services. Then increases debugging issues because, now that you have multiple services, it requires more sophisticated tools and by, it can be a little bit more challenging. Network calls between your services and the latency between those causes your communication overheads, right? So this is an interesting visualization and shows you a visual comparison between the two architectural styles, right? So as you can see on the left, that represents the monolithic architecture. So it's basically a single large weight. And on the right you have the microservices architecture where you are. You've got smaller distributed weights. This basically says that when you are scaling a monolithic architecture, your entire application must scale. Whereas with microservices, you can scale individual services. Right now, monoliths have lower resource efficiency. As you have to scale everything together. Whereas microservices allow for more targeted scaling, so your resource efficiency is higher. Scaling a monolith is a much simpler process. But microservices requires more coordination. Monoliths have limited elasticity, whereas microservices are highly elastic and scale up or down much more easily. Right now let's look at some of the performance of the architecture. Internal function calls within a monolith typically takes around one millisecond to complete because it is within the same memory space within the same shared resources. Calling an API between microservices usually takes 50 to a hundred milliseconds, right? Microservice to microservice communication adds about five to 10 times the processing overhead compared to a monolith because of, serialization network cost. The performance latency differences between a monolith and microservices architecture are significant, and it is important to to understand because these latency differences can have a big impact on the overall user experience and your systems responsiveness. So careful design and optimization are required to mitigate these performance impacts when mo moving forward with the microservices architecture. This slide basically highlights the differences in failure modes between your monolithic architectures and microservices architecture. On the left we see that a single critical bug in a monolith can bring down the entire application because, it's one, one single unit, right? Anything happens within one component of it. It affects the entire application, just like. When you're scaling the application, you have to scale it completely. A bug affects it completely, right on the right we see a microservices architecture, and in there service failures remain isolated and the system can degrade gracefully. It shows that how microservices. Enables resilience patterns like almost like circuit breakers and fallback mechanisms to handle failures. The key point is that microservices provide more fault tolerance and reliability compared to a monolithic approach. Now, of course building an application is one thing. After the application is completed, there are maintenance and update scenarios that need to be considered. Of course they are very important when choosing between monolithic or microservices architecture. With the monolith, changes to the shared code base requires modifying the entire application, which then needs to be completely tested, and then the entire application gets redeployed. In contrast, microservices allow you to update specific services independently, and this minimizes the scope of your testing and deployment. For development, a monolith requires modifying the shared code base while microservices lets you update just the affected service. Testing is also more efficient. With microservices, you only need to test the updated service and all of its integration points rather than the entire application. Deployment is simpler too with microservices. You can deploy just the updated service rather than the entire application. Now smaller teams work well with the monolithic architecture, whereas microservices are more for accommodation of multiple teams. Monoliths require less coordination between the teams, whereas microservices involves more cross planning. Monoliths have a lower initial complexity while microservices require more distributed systems knowledge. Monoliths allow for faster delivery initially, but microservices enables long-term feature delivery in a in a more quicker pace. Now here's a comparison between the cost and resource considerations between monolith and microservices architecture. The bar chart shows the relative cost for for the different categories. Including initial development, infrastructure, maintenance, scaling anti onboarding for initial development. Microservices have a higher cost compared to a monolith infrastructure costs are also higher for microservices. Maintenance costs are lower for microservices, obviously. Scaling costs are significantly lower for microservices. Team onboarding costs are higher for microservices. And overall the trade offs between the two approaches. Is what you need to consider carefully because that determines the scale of your application and that determines the future of your application. So based on the needs and constraints of your project you need to look at these trade offs. Really so where does the monolith architecture make sense? Small, simple applications with limited functionality. You don't need to really go into the overhead and the complexity of microservices architecture go for the simplicity of of monoliths and the ease of maintenance that this architectural style provides is best suited for smaller applications. Like I said, the overhead and complexity of microservices architecture is not worth the investment for these type of applications, for early stage startups, speed to market is more important than your perfect software architecture. So focusing on validating the business idea should take priority over optimizing the infrastructure. Teams with limited resources, such as tight budgets or smaller head counts, can minimize infrastructure cost. By going with the monolithic architecture approach smaller teams can also more effectively maintain that entire code base. Rather than the distributed code base of a microservices architecture microservices are a very powerful architectural style that can be highly beneficial for certain types of organizations and applications. They're particularly well suited for large enterprises with multiple development teams high traffic web apps that need to. Scale depending on consumer needs have complex business domains with distinct bounded contexts and organizations that require rapid independent releases. The distributed nature of microservices allows teams to work autonomously deploy features to production quickly. Without impacting other parts of the system. Think Amazon, right? I. Microservices can also enable scalability as individual resources can be scaled independently to handle increased traffic or load, Christmas shopping at Amazon. However, microservices also introduce additional complexity in areas like service discovery interservice communication, and overall system observability, right? These trade offs need to be, carefully considered. And the key is to evaluate whether the benefits of microservices outweighs the added complexity for your specific use cases and organizational needs. So Netflix started as a single monolithic Java application and then, they had a major database corruption, which led to a multi-day outage. And that kind of highlighted to them the need for a more scalable and resilient architecture. So gradually they decomposed the monolith into cloud-based microservices, and it now runs over 700 microservices that handle over 2 billion API requests daily. The microservices based architecture provides greater scalability, reliability, and flexibility. Compared to the original model. With, so this slide provides a framework for deciding between a monolithic or microservices architecture for your application. So there's four key factors that you need to consider when you're making this decision. First, assess the complexity of your application. Simple apps tend to work better with a monolithic app approach, whereas complex domains often benefit from Microsoft. Next evaluate your scale requirements. So high volume or variable workloads can be better handled with the targeted scaling of microservices. Also think about your team structure. Large distributed teams, they'll often work more effectively with the ownership boundaries that is provided by by microservices. And finally, map out your growth trajectory for the next three to five years. This can help determine which architecture will best support your company as your application evolves. And considering these factors carefully is what will enable you to make an informed decision about the right architectural approach for your specific needs. In conclusion, I'd say there's no one size fits all solution when it comes to application architecture. The right approach depends on your specific business context and goals. And rather than being dogmatic, it's important to be pragmatic and flexible when it comes to your architectural decisions. Hybrid approach that starts with a modular monolith and strategically extracts microservices that can be effective an effective way to balance your immediate needs with long-term scalability. And ultimately, the focus should be on choosing the architecture that best supports your business objectives. And not what is the norm or fad of the day. This requires balancing short-term requirements with your long-term maintainability and growth. With this I come to a end of my presentation. Hope this proved useful to you and hope you have a good rest of the conference. Thank you.