How do microservices improve scalability compared to monolithic architectures?

Overall, while granular scaling provides considerable benefits in terms of resource optimization, performance, and availability, it also brings complexity that must be properly handled in order to reach its full potential in microservices architectures.

I myself have worked with both and have to say the following: - microservices: gives the abilty to work on 1 certain scope regardless of the whole project. A microservice has its logic, any thing that needs to interact with it has to obey they openAPI specs, message formats (for event driven com). It also allows for scaling certain parts of your system seamlessly, however it comes at a cost in delivery time, increasing costs when deploying on cloud and most importantly the data spread out accross mutiple microservices, and here the saga pattern can be applied. - monolothic: faster delivery time and better exception handling but maintaining such a thing is costly it terms of dependencies and communcationswith multiple databases.

Monoliths work best when the scale and complexity is small. As the complexity increases over time, putting all that complexity in a single server is a recipe for failure. Chances of some issue in a remote location in the code bringing down the entire application increases. Also, it would be hard for any person to onboard and work with such a system. Breaking the application into multiple services with clear interfaces for interaction makes the system more robust, easy to maintain and easy to understand. Also adding new features becomes easy.

One should start with a monolith, if he/she unsure about microservice use case in their system and later on move to microservice acrhitecture as per needed

Microservices are a really good choice if your monolith system is getting a "Frankenstein" feeling. Sometimes you have systems inside your system that can be unstructured in a microservice and it may help with scalability, maintainability, etc... In these, Microservices are perfect every time. But, watch out! To maintain multiple microservices working and scaling, you may need a good team, or you might get lost.

Monoliths usually need a trustable structure to keep everything alive in the worst situation possible. This trustable structure may cause an over-engineering of the most time. Microservices you can configure small structures to handle only what that microservice is designed to do, with no much over-engineering or surprise in your pay bill at the end of the month.

One should be careful in granular breakdown of the services to not over do it. Data integrity also should be taken care of in scalability.

Microservices offer significant scalability advantages over monolithic architectures. In a microservices architecture, each service operates independently, allowing teams to scale individual components horizontally as needed, without affecting the entire system. This granularity enables efficient resource allocation, enhances performance, and facilitates rapid response to changing demand, making microservices a preferred choice for scalable and resilient applications.

For independent scaling, microservices should be ideally stateless and isolated. They do not store client session data. Any necessary state should be stored externally, allowing instances of the service to be added or removed dynamically without affecting user sessions or data integrity.

Microservices alone might not be enough. Introducing things like CQRS to split reads and writes, or doing more asynchronous processing to allow consumers not to wait can do much more than decomposing code and processes. Also, depending on your environment, tendency requirements (large shared Kubernetes Clusters) might negate the advantage if containers get scheduled on the same nodes.

On the flip side, there can be a cascading effect if one microservice fails and causes other microservices to fail and eventually the entire system fails. However, there are solutions available to deal with this situation like retries with exponential back off, circuit breakers and use of messaging queues. These mechanisms make the system fault tolerant and resilient.

Microservice architecture enables the ability to update each component in the system independently. In addition, it would also enable A/B testing opportunities at specific components to determine if new functions or features perform better. If the application is written with consistent interfaces for the components around it, rolling deployments are also possible eliminating downtime entirely.

?? Deployment Agility Microservices offer enhanced deployment agility for faster updates: 1. Independent Updates: Modify and deploy individual services without impacting the entire application. 2. Continuous Integration: Facilitate continuous integration practices by enabling rapid service updates. 3. Reduced Risk: Minimize deployment risks by isolating changes to specific microservices. 4. Market Responsiveness: Respond to market changes swiftly with faster deployment cycles. 5. Downtime Reduction: Decrease downtime during updates as only the affected microservice is impacted. Deployment agility in microservices enables rapid iteration and adaptation to evolving business needs.

The same principle of Microservices and its layers of isolation can be applied to business architecture with portfolio management. When architecting a change, ensure the foundations are robust, usable, and understandable. Agility is not about launching a new release; rather, it's about the entire business being able to pivot as needed. This is achieved by funding releases sooner and monitoring business benefits, e.g., OKRs and Score Cards, while also ensuring the Business Architecture knowledge base is current, constantly checked, and benchmarked.

Microservices enable a phased deployment approach, which aligns perfectly with Agile methodologies and business objectives. - Business OKRs (Objectives and Key Results) are broken down into smaller, achievable goals - These goals are then tied to product backlog stories, which describe specific features or functionality - Each microservice can be developed and deployed independently, allowing for phased releases - Releases are tied to specific business objectives, ensuring that each deployment delivers measurable value This approach enables organizations to: - Deliver value incrementally - Iterate and refine services based on feedback - Align development with business objectives - Achieve faster time-to-market and improved agility

Addressing this challenge in Microservices requires a combination of architectural best practices, robust monitoring, alarms and fault-tolerant design patterns. Implementing techniques such as circuit breakers, retries, fallbacks, and distributed tracing can help mitigate the impact of fault and improve the isolation.

Microservice architecture may allow to isolate the failures. But if that one service is critical to business and which can impact business operations. That why there should be a back up option which can reduce business impact and for that reason we need have have an asynchronous or work flow architecture in place to handle such scenarios.

In a microservices architecture you maybe able to use different stacks, but keep in mind the amount of technical debt you will incur. Overtime, developers move on to the next company and you will be left with technology sprawl, and observability challenges. I would look to balance out by standardizing on some defaults and have escape hatches.

My company has undergone a significant technology transformation where the prior architecture was monolithic and a single application stack was the dominant technology (all MS tech). The new architecture is all cloud native and we did, as @roland mentioned, defined architecture standards and principles where there was a smaller set of languages that we defined for specific use cases (UI tech / services&APIs / AI&ML). We also cascaded this to persistence tiers (DBs) and messaging for both cloud and edge workloads. So the net is the architecture is flexible and adaptable but also structured to limit tech sprawl.

If you have a small team with a product that can be handled in a monolith... do it! Don't try to create the perfect engineering with multiple databases, services, integrations... But if you're getting big, and feeling that the Monolith is costing more time to you keep it alive now... It's better to start removing some parts of that service into small ones.